Micro services vs. Monolithic Architecture
One thing that is sure to wake me up from a boring meeting at work is a good discussion topic that is also riddled with in-built assumptions. We all go through this from time to time, arguments are made on both sides, and there is consensus and enlightenment in the best cases, or agreement to disagree when things don't go so well.
One such topic is micro services, an architectural concept and application deployment topology that I have been immersed in for many years. I have noticed that a trend to "micro service anything and everything" started picking up steam and accelerating sometime around the second half of the 2010s and reached what appeared to be a peak recently with some dissenting voices expressing independent thought on this phenomenon.
These days with the easy (though high cost) access to CI/CD systems and cloud hosted applications and services, it is trivially easy to deploy a piece of code as its own service. In my experience, the barrier of entry is now so low that it is easy to get carried away. This ease and convenience to deploy services can and does promote what I would argue is an unnecessary and very wasteful proliferation of micro services.
When compared to monolithic architectures, micro services are a newer concept. They are perceived as a conscious choice made during the design phase, while in contrast, monolithic architectures are more often than not seen as an unplanned (and unfortunate) outcome of perhaps a lack of planning or architecture oversight.
I feel like when the discussion comes up, there is a bit of dogma about it. "micro services are better than monoliths" is frequently assumed, I have observed. Because monoliths are "bad". "Everyone knows they are bad" right? Right?? When it comes to software architecture thinking this certainly seems to be the case.
It doesn't help that the word "Monolith" itself carries a bad idiomatic connotation to it. Much is written about the benefits of micro services, the good points look good on paper, the bad points, and there are bad, seem to be seldom mentioned.
The cost benefit balance of micro services vs monoliths is more nuanced and less straightforward than what, in my experience, I normally see people giving it credit for when the topic is discussed.
The Good and Bad of Micro services
The Good
- Micro services allow for a loosely coupled architecture
- They have less code duplication between services
- They are more scalable than monolithic architectures
- They have higher fault tolerance, meaning that one service can fail without bringing down the entire application.
- They encourage development teams to work independently from each other
The Bad
- It requires a lot of technical knowledge and expertise to set up and maintain a micro service architecture
- There are many moving parts that must be monitored closely in order for the system to function properly, which can be time consuming and expensive.
- If one service fails then it could bring down the entire application
- Beyond the initial build out costs, it is (a lot) more expensive to maintain in the long run
The Good and Bad of Monolithic Architectures
The Good
- It is easier to maintain a monolith as there is only one codebase that needs to be updated at once. Monorepos invalidate this somewhat, but it is still a valid point.
- They are more stable than micro services, which makes them less likely to suffer from outages or other issues due to their simpler design. Having less moving parts can do that.
- They can handle larger amounts of data without slowing down the entire application since there is less data handover overhead between component that run independently from each other
The Bad
- For large scale applications, it can be difficult and expensive to scale a monolith as it requires additional hardware resources in order for it to keep up with increased demand on its services.
- Updates are less flexible, and many times must be applied across all components simultaneously, and that could lead to downtime if something goes wrong during the update process
How do I decide?
Both approaches have their advantages but ultimately the team technical leadership (Not necessarily the developers) should choose which option works best based on their project’s needs.
It is important to weigh the cost benefits of each approach before deciding what solution will provide the highest ROI for an application.
Micro services can be a good choice for applications with many interconnected components, as they allow developers to work on one service at a time without impacting other services. On the other hand, monolithic architectures are more suitable for applications with fewer features and less complexity because it allows them to focus on one task at a time rather than having multiple tasks running simultaneously.
If I were writing an application for a single purpose such as hello world, I would use a monolith because of its simplicity and low cost. If I had to build something that spanned multiple domains and systems, I may have a harder time building with a monolith. In this case micro services would be the better choice since it allows me to break down complex problems into smaller pieces.
Micro services is a style of architecture where you break up your application into small services that can run independently from each other. This allows for more flexibility and scalability when compared to using a single application or monolith approach. However, there are also some big trade-offs associated with this type of architecture such as increased complexity in deployment, testing, monitoring etc.
Overall, it is important to evaluate the cost benefit analysis before deciding on an architectural style for your project so you can make sure that whatever solution you choose will be most appropriate in the long run given its scope and scale requirements.
If costs were no object, and the availability of talent is not a limiting factor, I would tend to agree that very a granular and well proliferated micro services architecture would be a much better fit. In the real world, where things like team headcount, costs, and ROI matter, the theoretical advantages of micro services run into the need for pragmatic trade offs and astute technical decision making.
Conclusion
Micro services have their advantages but they come with much higher costs (depending on the degree of proliferation) associated with them.
On the other hand, monolithic architectures also have their advantages but are less flexible.
As such, it’s important for teams debating these two approaches to understand both options well, without the dogma, before deciding what works best for their particular project needs.
There is also no need to choose one or the other. If one looks at both ends of the spectrum, where on one end we have the (huge) monolith, and on the other we have a (grossly proliferated) micro services architecture, a happy medium somewhere in between the two ends could be and usually is the best option.
The takeaway is that a more restricted and deliberate approach to the current "more is better" trend of impractically granular micro services proliferation may be in order.
