18 December 2020
Overview
“Divide & Conquer”. These lines have ruled history and shaped humankind to be what we are today. From algorithmic thinking to availability solutions to platform engineering. If you can compartmentalize your “problems”, you’ll have an easier time dealing with it. And it was about time it was going to come to enterprise level solutions. The same principle that you’re advised to apply to your code( decoupled & modular code ! You’re already doing that right. Right!? ) can be applied to a bigger set of code ergo your application. Now obviously there are certains pitfalls with generalization and modularity and qualms with the whole approach but certainly there are merits to this principle. Which is why microservice architecture is as popular as it is today.
Microservice architecture as the name suggests comprises of smaller instances of services instead of one giant composite service layer. Hence you break up your application into multiple smaller services. They are hence decoupled while also each being separate application instances.
Benefits
Scaling
Services are easier to scale since once your services are separate instances of their own. You can easily scale just a few of the services that need scaling and leave the rest of your services as they are. Easy scaling and cost efficient.
Let’s say the transaction services of your application is experiencing heavy load. Now inorder to handle this in a conventional application you’ll have to scale up your whole application. Which means all your other services are also scaled thereby wasting resource. In MS architecture you can simply scale up just your transaction service thereby just using resource that is necessary.
Migrations
Codebase can be migrated iteratively and hence one can easily smoothen the process of migration.When porting your platform from one technology stack to a newer one. One can easily adopt the microservice architecture to phase out the old architecture . Adding new services iteratively and hence having the added benefit of being able to show stakeholders the new process sooner.
Intuitiveness
Placement of code is extremely intuitive. A big struggle in a huge codebase is where should this part of go. Once you’ve decoupled code, the placement realization becomes really vivid. More than once as a developer of a codebase with more than 42k lines of code, it becomes increasingly hard to place out new features as each of the services are so inherently intertwined with each other. In a microservice architecture one has better clarity about the architecture of their code.
Compartmentalization
From a management point of view, once each team is assigned to develop and maintain their own service , there is an inherent harmony for each team which now has very specific responsibilty. Code maintainance become easier and it is easier for management to handle a large project.
Pitfalls
As is with every thing else, generalizing the solution too early can result in suboptimal solutions. One has to keep in mind that while the goal is to break it up into smaller chunks. A way too much modularized codebase is as inefficient as a messy codebase. Hence one should avoid that. The other obvious concern is budget, creating multiple instances of multiple services obviously will be more expensive than one monolithic application. Hence we also have a trade off in that aspect.
Conclusion
The concept of microservice certainly has a lot of great benefits, however it might be hasty to convert your application into a microservice, especially if it is not intended to scale as much. While scaling should always be in mind, it should not be the first thing one considers while building an application. A simpler solution will many a times suffice that the industry grade solutions designed to solve a specific problem set. Therefore, before adopting this architecture make sure your application actually needs it.