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:

  1. Easier to debug and test.
  2. Application security 
  3. Simplified operational strategy including monitoring, alerting, dash-boarding etc 
  4. Defined Infrastructure strategies 

Having talked about benefits there are lot of limitations which Monolithic applications can have such as:

  1. Time to market can be quite high
  2. Lower fault tolerance, one component failure can lead to failure of entire system.
  3. Developers with that specific skill set are not readily available and can be expensive at some times.
  4. Because of boundaries and limitations, technical debt is ever increasing.
  5. 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

  1. Independence and flexibility 
  2. Components can be easily plugged in or out, and excess baggage of legacy can be avoided. 
  3. Time to market can be reduced.
  4. Deployments are simpler and faster. 
  5. Every component can build and rebuild independently. 
  6. 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

  1. Good chance of over engineering,
  2. With distributed components defining a correlation can be quite challenging
  3. 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. 
  4. Usually micro services are stateless which implies that transaction management can be quite tricky. This can lead to higher reconciliation requirements.
  5. 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. 
  6.  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.

要查看或添加评论,请登录

Sandeep Singh的更多文章

  • Can BlockChain solve Delhi Stubble Burning issue

    Can BlockChain solve Delhi Stubble Burning issue

    I came back to Delhi after 5 years and was deeply saddened by seeing the impact of pollution. A few days were so bad…

    3 条评论
  • Tech Trends 2017

    Tech Trends 2017

    As we are about to enter 2017, I have jotted a list of areas/technologies/trends which I am looking forward to explore…

    1 条评论

社区洞察

其他会员也浏览了