Microservices architecture is an approach of building software where app is broken down into smaller components which are deployed independently. As an architecture pattern, microservices has been around for a while, but it gained immense popularity when Netflix open sourced their implementation of MicroService architecture making it very easy for any one to onboard to MicroService bandwagon. In this post I want to discuss some of the concepts and difference from traditional architecture, also called as monolith and my approach to decompose a monolith to microservice.
Monolith architecture sounds like a bad word but essentially its been the way we have developed application for years before SOA and MicroServices. I personally do not like the term as it automatically creates an image of a giant pile of unmaintainable mess of code. I prefer to call it “Traditional Architecture” but I don’t want to confuse you further, so we will stick with monolith terminology. So in our monolith, we have all the features required for an application packed up in a single deployable. If we were to build an online shopping application, our traditional architecture would look something like this.
Whats wrong with Monolith?
The biggest issue with monolith is that monoliths are very difficult to scale horizontally. Which means the bigger the application is, the more resource it would require to run a single server, and scaling them horizontally would require lot more resources. However if we break them down into smaller component, individually the components can be deployed on smaller machines or containers, which would allow us to scale individual component independently. For example , in the online store architecture, I would require more scaling on the features which are customer facing while supplier facing features may not require the same level of throughput as required by let’s say payments module.
Why should you use Monolith?
Monoliths are inherently simpler application, and they are the natural way of building application. Monoliths are easier to develop, easier to maintain and we have huge amount of experience developing and maintaining monolith applications. We will discuss some of the challenges of micro services later.
Microservice very broadly is a style of architecture to break application in to smaller components which can be deployed independently and maintained. There are various frameworks, styles of creating micro services depending on choice of language, you can even have heterogeneous mix of micro service, for example some of the service running in java while others in node js or python. Lets take a look at our online store in micro service world.
This looks just like 5 monoliths, where every component have their own data layer, authorization, security and UI. However each of these are relatively very lightweight application, which can be run on a less resource intensive containers. These micro services may or may not talk to each other depending on the use case. There are multiple ways of communicating between micro services.
Advantage of micro service
The obvious advantage is the ability to independently scale the components based on scaling requirements, however since each of component is usually a separate code base repo, this architecture allows teams to develop and deliver faster and they can be assured they cant break other services. In an agile environment, you can have smaller scrum teams responsible to manage, maintain and develop individual microservices.
Why not micro service?
Micro Service is not a “Silver bullet”, if you know why you are using micro services, it would work great but if you are just following the fad, you would end up with lots of complicated edge cases.
Distributed transactions are broken.
If you have a use case where you need transaction boundaries need to span over two or more micro services, it is a very good indicator that either you do not need micro services or you have designed your micro services wrong. There are some very complicated architectures which will allow you to run distributed transaction but it would take away every benefit which moving to micro services could have given you.
Your application uses RDBMS and is write heavy.
If your application is write heavy and you use an RDMS, scaling a write application is never a good idea, as very quickly database would become bottleneck as RDBMS do not scale horizontally.
I hope this helps you make the right choice with “To Micro Service or Not”