Microservices have been the talk of the town for quite good reasons. Almost every big organizations like Google, Amazon, Netflix has adopted this architecture style. But the question arises what makes microservices the need of an hour?
Let’s go back to the traditional way when organizations used the monoliths approach and try to recall a few of the hurdles which we came across while doing development, deployment, debug, bug fixes, and scaling the application which will ultimately guide us to our quest on why we need microservices.
One of the common scenarios in today’s development world is a gradual decrease in the performance of the application with incremental usage even after adapting to microservices. This could be due to more data to fetch and process, heavy load on one the services which reduce its response time, network latency to name a few.
To make it easier for you, let’s take a closer look at how microservices are making complex processes into simple and easier ones.
Microservices: The foundation of today’s enterprise application:
According to Martin Fowler, the software guru “a microservice architecture consists of “suites of independently deployable services” organized “around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”
In simpler terms, it means microservices architecture is easy to build, maintain, and can be broken down into small pieces if required. For instance, when your business grows then managing a single architecture can be a hassle task especially when different stakeholders are involved.
But with microservice architecture, you can easily divide the application into distinct independent services that can be easily managed by different developer teams without impacting the work of other stakeholders.
Here is another example for your understanding:
Do you remember the traditional way where there is a huge code base of a web application that serves numerous business functionalities with scattered references all over? Now to enhance any one of it, the first step is to find where all it has references, then analyze what impact it can make to current functionalities.
Not to forget for deployment, prepare instruction with all the related files. Now let’s add one more realistic scenario to it, given from the list of above files few common files have bug fixes for other business use cases.
Whereas in post-deployment let’s assume one of the bug fixes has resulted in another bug. There are two solutions to it either revert all the changes (this includes pull out the enhancement and other bug fixes as well) or fix the issue and test the entire application end to end with the outage.
But when it comes to the scaling part, since the code base is huge and the need for scaling arises for a single popular functionality, it means resources won’t be used effectively.
Now, let’s imagine the same with microservices in place.
All related functionalities and files are in one place, this reduces the effort to zeroed down the changes required and impact analysis. However, the Bug fixes file may or may not go to other files depending on the nature of functionality but certainly, it will be assured no two unrelated fixes are getting served from the same file.
I can create different builds for different fixes or enhancement as it would be less tedious this time. In advance, it’s known which file to open to debug and last but not the least scale the popular module only!
But one has to keep in mind that microservice has its own set of challenges which is constantly getting evolved in terms of design patterns, we will talk about it in some other blog.
Advantages of Microservices:
There are endless advantages of microservices that have attracted many big enterprises to adopt it. Compared to more monolithic design structures, microservices offer:
- Can scale up or down the services as per requirement very easily and minimum configuration.
- Services are responsible only for one task.
- Asynchronous calls, no need to wait for a response
- Replay or re-fire the events in case of failure as events can be stored.
Moving ahead with Microservices:
In REST way of calling a microservice from other binds the two tightly and hence the after-effects. What if it just publishes the required info and other services which needs it simply consumes.
Now a day there are many event-driven frameworks are available and make entire development very easy in terms of retry, replay, and event tracking comes out of the box. When has to understand the fact that the way application development is evolving, there will be a continues to fight whether to go for microservice architecture or leverage traditional monolithic way.
Before switching to microservices make sure to wisely evaluate what we can live within an application, its obstacles, and which technology or pattern should be used, etc.
Again, like coin has two sides, this also comes with some cons, managing transactions across services are not easy and need efforts to track it properly (further read: Saga pattern). Also, Kafka or Rabbit MQ can act as a single point of failure and before processing events sometimes they have to be stored somewhere in the database/cache which can lead to redundancy at times.
So, for smaller or mid-sized enterprises, microservices can be an easy and quick way to implement whereas the big companies with millions of users are the ones that can hugely benefit from it, as they need to ensure the uptime, scalability that the added modularity can provide.
