Monolithic or Micro services Architecture
With emergence of cloud system design a lot has been written about issues with Monolithic architecture, however there are certain benefits which Monolithic design architecture offers. In the below article we will look through some of the benefits both architectures offer and common pitfall for both of them
So what is monolithic architecture? It usually constitutes of the components which are built as a single unit, are tightly coupled and follow a common integration pattern.
As a analogy it is like a chocolate cake, though it has various elements to it however it comes out as a single unit. If we need to change the flavour the entire cakes needs to be rebuild. Similarly in monolithic architecture if new features have to be added a complete deployment is typically required. If this architecture had such a big drawback then why do we have so many systems running with it – the simple answer to this would be convenience. Wont it be convenient to define the pattern and tech stack once rest of the project follows it, with lesser hops the chances of things going wrong are less and a better control is achieved.
Some of the other benefits which monolithic design offers are:
- Easier to debug and test.
- Application security
- Simplified operational strategy including monitoring, alerting, dash-boarding etc
- Defined Infrastructure strategies
Having talked about benefits there are lot of limitations which Monolithic applications can have such as:
- Time to market can be quite high
- Lower fault tolerance, one component failure can lead to failure of entire system.
- Developers with that specific skill set are not readily available and can be expensive at some times.
- Because of boundaries and limitations, technical debt is ever increasing.
- If build on a proprietary package then licence costing can be painful.
What about micro services, do they solve the problem. Micro services have been in industry for quite a while now. I remember working on a SOA project back in 2005 using BPEL, however there has been quite a big surge in its demand over last few years. This architecture principally distribute the services in form of business oriented API. For instance an authentication API from Facebook can provide authentication mechanism for a grocery service.
Thinking of food it can be compared to pizza with different favoured slices which can be developed and deployed independently.
If design and implementation are correctly applied it offers a lot of benefits such as
- Independence and flexibility
- Components can be easily plugged in or out, and excess baggage of legacy can be avoided.
- Time to market can be reduced.
- Deployments are simpler and faster.
- Every component can build and rebuild independently.
- Fault tolerance is higher, if a component is faulty then the entire offering don’t need to be taken down and can be independently worked upon.
There is nothing in the world which doesn’t have drawbacks and micro service architecture is no different. Some of the pitfalls which have been observed so far are
- Good chance of over engineering,
- With distributed components defining a correlation can be quite challenging
- Over layering and structuring of components can lead to performance hazards. Imagine if a simple mobile application has to call 10-20 different micro services then it can lead to a very poor experience for the end users. This situation then needs to be handled using different caching mechanism which only complicates things further.
- Usually micro services are stateless which implies that transaction management can be quite tricky. This can lead to higher reconciliation requirements.
- Operational and maintenance can be quite difficult. With smaller services around the knowledge can be limited to a certain group of individuals and can be lost in due course of time.
- A central IT Ops is difficult to maintain, though components can fail and recover in isolation however it makes it difficult and harder to determine when compatibility or interface contracts are broken.
So how do we conclude which is better monolithic or micro services architecture.
If it is a complex system with multiple teams operating in parallel and want to ship faster then micro services architecture is the way to go. However less complex systems should be built on monolithic architecture however different level of clustering or modules considerations should be taken.
Nice Summary. Just to add, one of the core principles and a difference from traditional SOA is building complex logic in end points (smart endpoint) and keeping the pipe just for communication (dumb pipe). We can argue SOA had similar principles but the biggies implemented and marketed it a different way. Absolutely agree that Micro can be an overkill and potentially a bottleneck for less complex system. In my experience, I prefer starting the application as a layered monolith and maturing into Micro if it gets too complex to scale and manage.