Two (And Only Two?) Reasons To Break Monolith Into Microservices

Microservices architecture has become quite mainstream and popular in the last few years, and rightly so. For years, software architecture patterns have thrived to achieve goal of making software modular and microservices has proven to be very successful at it. Large organizations like Amazon, Twitter, Netflix have moved their large scale applications from monolith to Microservices and in the process have become success stories and blueprints for other organizations to follow.  

Before I jump into more details, let’s quickly define Microservices. I find Martin Fowler’s definition good as it rightly defines it quite loosely. 

"a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data."

Over a year back we decided to break our business critical and large monolith application to microservices. This application was already on Service Oriented Architecture i.e. we had UI and backend separated with REST APIs. It seemed like a great idea as that is the direction everybody seemed to be moving, plus, if you search benefits of microservices architecture, you will get a list of 5, 7 or in some cases even list of 10-15 benefits. 

It took us extensive work involving around 10 developers for a year to move our monolithic application to microservices. It was a complex exercise given number of modules, scale of the system and most importantly we had to keep the system up and running during this time. Here is a very detailed guide which I found very useful on how to break monolith into microservices and we used these techniques. After successfully breaking our monolithic application into microservices, we decided to evaluate the benefits and gains. While we are in a much better place today than earlier, we also learnt that benefits of microservices are overstated in certain areas. Here are the two major challenges Microservices solved for us and these could be the two (and only two?) main reasons you may want to consider breaking your monolithic application to into microservices. 

1. (Potential) hot spots: Your current architecture has scaling issues in specific areas. You may have a system that otherwise scales well but certain parts/sub systems need to scale more than others. You may also require specific technology (DB, software, hardware, etc.) to scale only a part of the system and not the whole system. 
2. Bigger team size: Your system has become large and business wants you to roll out more features faster. You want to add more heads but that's not helping you. Having large teams working on common codebase is inefficient and can also cause lot of regressions. While this problem can be partly solved by modularizing the code, with the lack of clearly defined contracts between these modules, risk continues. 

Microservices solves these problems very elegantly. You can have smaller scrum teams focussed on individual microservices. Each team can make appropriate technology choices, build, test and deploy them independently. 

While there are other benefits in theory like CI-CD, security monitoring, fault isolation, migration to cloud, etc. in my experience you can achieve these without going through the painful exercise of migrating your application to Microservices. You may also consider that, Microservices brings in set of challenges like additional failure points, performance issues due to additional layer of communication between services. If you have a small team, having to maintain multiple services could be a challenge as well.