Should I migrate my monolithic application to microservices?

I know. I know. You must be thinking what is the need of yet another article when the internet is already full of high quality blogs on microservices.

Yes. Your thought process is in right direction & (in a way) qualify you for understanding this complex domain 🙂. The purpose behind this article is to share the knowledge which I have gained over the years through my experiences (good & bad) in microservices realm. In return, I too will receive additional knowledge through your (expected)comments. You see, the benefit is mutual 🙂.

Before moving ahead, I am assuming that you have a fair knowledge of -

• what are microservices
• how to create a microservice (in any language of your choice)

Start the journey in this forest only AFTER you have collected above mentioned weapons in your arsenal. Only then would it be a fun otherwise you will get lost in this dense jungle of microservices!

Enough talk! Let's start!

Nowadays, microservices domain is in rage. Almost every company is trying to move to microservices architecture. This type of architecture is assumed as a silver bullet to all the problems & if your company is not using it, bad news! You will be looked at like you are a warrior from some old world having forgotten tools in his arsenal. Sadly, this is far from reality & a project is destined to be doomed if it's wrongly decided to be a candidate for microservices. Choosing the right technology is the most important starting point for any project which many ignore & succumb to choosing the latest trends of the market.

Consider you are a Lead of your project & handling a team of 10 members. The project is basically a monolithic application. The requirement comes to analyze if it's time to migrate it to a microservices architecture. How would you go about it? How would you analyze if the project is a good fit for microservices? What are the factors which you should painstakingly evaluate? Let's find out.

Over the years, I have figured that finalizing microservices approach does not depend only on technical requirements of the project but, in equal measures, on the other factors as well. Let's try to understand them one by one as below -

1) Scope of the application

We should start by asking the scope of the application. It means, how diverse is the application's functionality. Is it a social media application having good number of separate modules? Is it an ecommerce application? Is it a simple application which converts a user word document to pdf? Is it a simple data entry application? The idea here is to understand the scope in terms of functionality. If the functionality scope is simple, straightforward and does not cover a diverse area, the application might not need a microservices architecture.

2) Load on the application

Find out what is the user traffic on the application on live environment. Is it high or normal ?If it's high, does the application have different modules & every module's traffic is different from the other? If yes, you might want to handle every module's traffic independently, for e.g. consider an example below -

Suppose, there is a social media application which has one module for showing user's feed, one for showing games section, one for creating user content. If the user traffic on this application is high then it makes sense to consider it for microservice migration as you can create separate microservices for every functionality & can handle the load independently for every microservice.

3) Scalability

This factor is more or less related to #2 above. If your application modules need scalability on an independent level i.e. if you need granular control over scaling of different modules of the application, microservices is a good way to achieve this.

Let's take the same example of social media application mentioned in #2. This application is a good fit for microservices migration because all these modules can be broken up into separate microservices which can independently be scaled as per the need.

4) Application Roadmap

Find out the future roadmap of the application by discussing with stakeholders. Is there any plan to include more modules? Are those modules very small in terms of functionality or medium scoped? The idea here is to understand what is the target we are eyeing on in the long run. If the roadmap consists good amount of functionality planned, it might be a suitable candidate for microservice migration.

5) Productivity

Your team is working with monolith architecture & they all have access to the same code base. Is the smallest change disrupting the communication between teams and changing the entire application? Does even a small change require the need for frequent testing to avoid the conflicts thereby slowing down the entire release process? Is the productivity of entire team is getting hampered because of these factors? Well, microservice architecture provides a very good way to handle all this & could turn out to be a go to approach for you.

6) Maintenance

Consider that the monolithic application in question is a stable one. The application roadmap does not have any ambitious plan to include more major functionalities. The load on the application is normal & there is no need of achieving scalability on granular level.

BUT.

The application has become a maintenance nightmare! Even a small change requires a lot of reviews to make sure that it does not impact any other functionality. The codebase has become so big that even a small change requires ~ 1 hour to be deployed on Sandbox/QA environments resulting in delayed testing. The codebase is drifting towards being a complex pile of code which will become difficult to understand over the time. Now, you should give it a thought to migrate it to microservices.

7) Time to Market

This factor is a direct descendant of #6 above. The longer it takes for the new changes to be tested by QA team, the longer will it take to get to live environment. If we have to fasten the time to market for the new features, microservices is a viable candidate to achieve the same.

8) Team Decomposition

Going for microservices approach, you will require separate small teams for almost every microservice. Are you ready to do that? Do you have proper process in place to achieve it? Are the stakeholders ready for this? These are some question which you should seriously try to find out. If the answer is no, then it will be hell lot of (already)difficult to swim in a microservice ocean. Think twice then!

9) Team Skills & Adjustment

Working in a microservices environment require some specialized skills & roles like Cloud computing, DevOps, Patterns, Containerization, Docker, Kubernetes, Sprint, Agile & much much more. Does your team have that kind of skills? If not, is your company ready to invest in acquiring those kind of skills & roles? Think carefully. Very carefully.

10) Costing

Again. Costing factor is a direct derivate of #9 above. Going microservices way WILL require costing.

Skills! Roles! Process! Everything will require good amount of cost. Do you have approved budget for the same? Think thrice!

11) Defined Process

Do your team follow a defined process to carry out the specified tasks? Agile? Sprint? Extreme Programming? Kanban?

Remember. Working in microservices environment needs a well defined process within the team. If there is no set process, are you willing to accommodate one? Is the company ok to invest in a well defined process? Questions to ponder!

The golden rule: can you make a change to a service and deploy it by itself without changing anything else?

There are many more considerations which should be analyzed but the mentioned points in this article are just some guidelines to give you a head start. In the end, to decide if monolithic application should be migrated to microservices or not will need broader discussions involving major stakeholders of the company. The migration decision does not depend only on technical grounds but business & costing grounds as well.

With that, I would conclude this article with an excellent excerpt from Building Microservices: Designing Fine-Grained Systems by Sam Newman -

A single team finds it easy to communicate about proposed changes and refactoring, and typically has a good sense of ownership. Now let’s imagine a different scenario. Instead of a single, geolocated team owning a service, suppose that teams in the UK and India both are actively involved in changing the service — effectively having joint ownership of the service. Geographical and time zone boundaries here make fine-grained communication between those teams difficult. Instead, they rely on more coarse-grained communication via video conferencing and email. How easy is it for a team member in the UK to make a simple refactoring with confidence? The cost of communications in a geographically distributed team is higher, and therefore the cost of coordinating changes is higher. When the cost of coordinating change increases, one of two things happen. Either people find ways to reduce the coordination/communication costs, or they stop making changes. The latter is exactly how we end up with large, hard-to-maintain codebases.