Monolith v/s Microservices debate

There is a lot of discussion going on in the Monolith v/s Microservices world. Most of my early career was spent building monoliths and of course as service oriented architectures started to take root, we did adopt them with a good measure of success.

My experience

I don’t need to sound cool here and throw stuff like Conway’s law at folks. My limited experience has taught me that we have had individuals, small teams and large teams, who were clearly given charge of a particular module (call it a service if you’d like). As part of their responsibility, they had to do the following:

• They had to own it
• They had to maintain it
• They had to communicate about it
• Create interoperable APIs that honored the contracts
• Test their own software
• Be mindful of integration tests
• Be able to specify how to deploy their stuff in environments
• Debug and importantly trace a call in the overall scheme of things.

Could we have done it via a monolith, sure why not? Did we do it that way? Yes, we did it for a few applications? Did we try to split it into different services? Yes, as we moved on to newer deployment environments that made the task easier, though it brought on some complexities in learning and managing the environments. Was it perfect? It never will be.

It’s not about Monolith or Microservices

There is really no silver bullet. There is no definitive angle to going microservices or going with a monolith. Any one who talks about going one way or the other is not having any wrong intention in trying to swaying you but with due respect, every organization and its development teams will be different, their requirements will be different, how they need to evolve or support new services/devices will be different. You will need to be in the drivers seat in understanding your own organization first before blindly adopting any view of a large company or influencer.

At no point should any organization under-appreciate the need to manage teams of people, bringing some order to it, automation, testing, giving the teams the freedom and flexibility to choose tools and yet keeping them disciplined and more.

Keep the point of monoliths and microservices aside for a moment. Are you addressing fundamental concerns like team communication, hierarchies, decision making, software engineering discipline and hygiene, test coverage, automation, autonomy and more? Think about that for a moment.

What do I recommend?

In my book, I prefer to look at an application in its entirety and fundamentally why does it exist in the first place? Once you have those answers, look at what are the use cases or customer user journeys that users interact with your application? For me, it eventually comes down to the following:

1. You need an efficient process (fully automated or not) to develop and deploy your application in various environments and be able to move versions between them.
2. You need an efficient process in place to trace your source code changes to what’s been deployed in production.
3. Finally and most importantly, when shit happens and which will, do you have the ability to track and trace what is happening, locate the component that is causing the problem, efficiently debug and understand the root cause and then have a process to roll out the changes to mitigate the users impacted.

I could have addressed the above points in terms of words like DevOps, CI/CD and more but I have intentionally not done so.

Now if monoliths and / or microservices architecture can help you address that, given your organization constraints, go with that. You are not Google, Facebook, Microsoft, Amazon and they are not you. You don’t even need to immediately compare yourself to other organizations, who might be more smarter, agile or any of those characteristics.

All you need to do is that in true spirit, is to build out a healthy culture in your organization that is open to discussion and starts to measure what DORA recommends:

• Time to Restore Service
• Change Failure Rate
• Lead Time for Changes
• Deployment Frequency.

See where you stand on those first. I am not calling out cost explicitly in the article and you know where I am going with that by now.

My concluding remark is to focus on what makes you deliver your software efficiently (cost, operations and everything included). Everything else is like a 9 PM News debate.