Why so many Microservices Posts?

I've been on a bit of a Microservices blogging binge of late. I write these to get my thoughts out there and help me organize future plans and I've recently been doing some work on one of my projects to put more things in Microservices. In the process I've either stumbled across things or had thoughts about why this is working out so well for me. Thus, more blog posts on the topic.

I'll use this one as a bit of a post-mortem of sorts.

First up, while I knew I had paved the way for Microservices with my original architecture (there were 3 main services to begin with already), what I had not expected was how well it all worked out. My first service took less than an hour from coding to testing to deployment. And that was a very positive experience. None of these are mission critical services which made the decision to start the work easier, but it has helped affirm that this is a good approach.

I'm also REALLY happy with the code footprint of the new Microservices. Each one is basically the Program.cs and a single service file. The rest all comes from shared project libraries. There is one larger service. And I might split some of the functionality there into smaller classes to keep things a bit cleaner. The maintainability of this is just so good now though. 

And as a result of that, my main service is also much slimmer now. I'm not going to go as far as converting the whole thing into Serverless functions. In fact I probably won't make the main application any smaller than it currently is. It COULD be broken down smaller, but I'm not sure there is much value. This is a smaller project operated by a single individual and the architecture is pretty clean. I could break out some domains like Customers/Work Orders/Storage but unless I plan to reuse those for another project (and I don't currently), I don't see the value. It just isn't a big enough project for that.

Logging is another benefit of the whole thing. And one I think people overlook when considering Microservices in smaller applications. The problem with logging is that if you don't log enough you miss important data and if you log too much you stop looking at it. And, if you leave it all up to configuration, you can suppress logs which would be useful to strike a balance.

For this application I'm not using anything like Elastic Search. It is just console logging. It is a small application. One business. 2 users. Maybe a few hundreds records changing daily. If you're using a more production/enterprise scale logging facility this one won't matter as much to you.

But from the console logging perspective Microservices give some free granularity. And that frees you up to increase the verbosity. Prior to this, I had a bunch of logs which were set at debug level and I had the default log level at Information. When looking at the console output from a Monolith, you need to be much more stingy about what you log, otherwise you can miss important logs. Or worse, stop checking them. By splitting these services out though, I have separate console logs for each service and I can be much more verbose in what I'm logging. It is also MUCH easier to detect anomalies in my microservice logs since they typically the same sort of data over and over. Deviations stick out like a sore thumb.

Downtime is another thing which has been great. When I first took these services out of the main application I had to stop pretty much everything. But, for the updates I've applied since I just do a "docker pull" on the compose file and then another up and only the updated services need to stop. If this were Kubernetes it would not have been an issue. The scale of the application though does not demand Kubernetes.

Lastly is control. I moved my archiving logic out to a Microservice and was concerned it might be archiving things it shouldn't. So I just stopped that Microservice while I took a look at the data. In essence, I temporarily disabled a feature of my product suite on the fly. There are other ways to manage this, and again Kubernetes would also have done this without disruption. But, this also frees up the resources and isn't a code based solution to the problem (thus no potential for bugs). When the service doesn't exist, I can be confident it isn't running.