Posted by Abhishek on December 11, 2019
Development Community around the world is pushing the software development approach to shift from Monolithic to Microservices architecture. Most of us accept this shift without understanding the WHY, WHAT, WHEN and HOW of Microservices. In this blog, we will try to understand
Essential Ingredients to adopting Microservices In order to successfully develop software in Microservices realm, you need to get these three things right.
Organization – There is a strong consensus in the development community that instead of having large development teams, small & autonomous teams (not more than 12, ideally 6 to 8) that can work independently is highly desired.
Process – There is also a strong consensus that you should be developing using Agile processes with Continuous Delivery/Deployment.
Architecture – On a very high level, you have to make either of these 2 decisions. Monolithic Architecture or Microservices Architecture.
Imagine an online store, its modules and their interactions. In a monolithic architecture, the functionalities like Catalog, Orders and Reviews would be layered and modularized, clearly separated. But when it comes to packaging, everything has to be put together as a single application that talks to the database.
Well, there are reasons why organizations choose Monolithic Architecture.
So, what’s the downside of Monolithic Architecture?
Well, the solution to solve all these problems is to adopt Microservices Architecture. Chris Richardson explains the meaning/definition of microservices in a simple & neat way.
The X-AXIS (Horizontal Duplication) refers to the running multiple copies of your application behind a load balancer. The Z-AXIS refers to running copies of the same application on different servers and some routing logic controls which server responds to the requests. Both the X-AXIS and Z-AXIS approaches is how we can scale in Monolithic Architecture. The Y-AXIS seems much interesting as it refers to running different modules separately on servers. Each module on a server can be horizontally and vertically scaled separately. For us to put different modules on separate servers, we have to functionally decompose our application’s monolithic logic. This way of functional decomposition leads us to Microservices Architecture. Thus, the modules which we saw in a Monolithic Architecture becomes standalone, deployable & independently scalable services in Microservices Architecture. Each service will have its own database (which helps that service to be standalone). Sitting in front of these services is an API gateway (which acts like a Facade) that exposes the meaningful business operations to the clients (like browser, apps).
However, the good news is that solutions (like Docker, Kubernetes, Publisher-Subscriber) exists for removing these drawbacks. 🙂 We do understand that Monolithic Architecture and Microservices Architecture has their own benefits and drawbacks. But a key takeaway that we can understand is that the benefits of Microservices Architecture outweigh the drawbacks of large monolithic applications. In the next blog, we will deep dive into Event Sourcing in Microservices Architecture.