Microservices architecture took the world by storm and became the most popular architectural style on the web. Ever wondered why? Keep reading to know the secret!!
Before microservices — The Monolithic Architecture
Generally speaking, the term “Monolithic” means composed all in one single piece. However, in technical context of web development, the same happens with the software program using Monolithic Architecture.
Monolithic software is designed to be self-contained which means components of the program are interconnected and interdependent on each other. In an architecture like this, even a tiny bug in any of the component can have a drastic effect on the whole project.
Let’s study in detail the two major disadvantages of Monolithic Architecture which emerged the need for something new.
1. Heavy interdependencies and interconnections
As all the components are bound together forming a single unit it becomes really difficult to fix bugs or update any of component of the project. Also, things really become nasty when a project is deployed.
For example, you have developed your own e-commerce application for local vendors of your city and codebase of which is developed in Monolithic Architectural style.
It’s deployed and being used by thousands of people. Some day your team observes that there’s a bug due to which your application is behaving in an unexpected manner. So now, you have to keep your application running and also solve that bug.
The solution can be,
There are several instances of our application running on the cloud and they are load-balanced, we can fix the bug in our code base, build the binary, stop any one of our instances (load balancer will balance the traffic accordingly) run the binary again. Repeat the same process for all our instances (only deploy in this case).In the solution above did you notice one thing? Doesn’t matter how small the bug is or in which component of our application it is present, it’s still having a huge effect on our whole application and after solving we still have to build the whole codebase. That is because all the components here are tightly bounded and interdependent on each other.
2. Huge codebase in the long run
The size of the codebase of an application designed in Monolithic fashion keeps increasing with time. At some point, it becomes really difficult to locate a piece of code. Secondly, if the structure of the project requires refurbishing it will surely become a time consuming and tiring task for the developers.
Remember we said that the above two disadvantages emerged the need for something new, that something new is Microservices.
Microservices
The microservice architecture replaces the traditional monolithic style with granular services that talk to each other in some kind of agreement. Every component in the project is independent of any other component or should we say every component is a service in itself. Also, in microservices kind of architecture, every service has its own database.
Let’s revisit our e-commerce application example which we studied above in monolithic section. The solution was to fix the bug, build, stop any instance and run it again (load balancing the traffic).
This solution will solve our problem but there is a major downside of doing this, which is as follows: -
Even if the bug is present in one component and doesn’t matter how small it is, we still need to build whole project’s codebase again which is not a fast and efficient process to be done at the time of deployment.Although, that above is not a feasible option if we want the whole deployment process to be speed and efficiency. That’s were microservices architecture comes as a saviour.
Assume this e-commerce application of ours was designed in microservices fashion then every operational area like shopping cart, orders, wishlist, sign-in and sign-up etc were have being different individual services (or projects in themselves) deployed separately on the cloud. They would have their own database.
In that case, if any bug occurred suppose in wishlist component only that service would needs to be fixed, build and a restart, leaving all other components of an application untouched.
- Here we are repeating the same solution that we did in case of Monolithic but the difference is the time and efficiency. Former required rebuilding the whole project while in latter we can just rebuild a service whose bug got fixed.
- If we need Continuous delivery and deployment, we need to use microservices over monolithic because making and deploying a small code change iteration to the server is much easier with small separate services than with an entire monolithic application. A large monolithic application may take a while to test, build and deploy.
- In contrast, with a microservices, this often takes just minutes making the release process faster and easier. As Microservices are lightweight compared to Monolithic application, it saves a lot of time in the deployment process.
Useful isn’t it? Making things easy to build and not banging your head while deployment. But this architecture also has some disadvantages.
- It is complex to manage an application developed using a microservices architecture.
2. Though every service is running individually separate from other services, there are still some minor dependencies between them (in terms of data).
For example, if Microservice A requires data from Microservice B it cannot directly access the database of Microservice B as it would violate the rules of this architectural style. So, there need to be some communication between microservices which requires extra code.
