Microservices can become painful to manage

The Monolithic vs Microservices debate has been going on for quite some time now. I know many developers who started breaking down their monolithic apps into several microservices. I was one of them.

Microservices have been gaining a lot of popularity in the developer community, we can not ignore the advantages of monolithic architecture in certain applications.

You need to make the right architecture choice depending on numerous factors like the capabilities of your team and how the deployment of your projects are done.

Converting Monolithic to Microservices

We had a monolithic application that became big over time and the memory footprint increased as well. It took us about a couple of years our monolithic project codebase exploded. We had to move to bigger servers to accommodate the application. Even the codebase became unmanageable with too many features in a single application.

We had a big project which has a lot of background workers and hundreds of APIs. We wanted to reduce the memory footprint to improve performance and to reduce the EC2 instance size.

We started breaking down the project into multiple logical parts. There are various challenges in doing so:

• Reorganizing the code. Can not be avoided.
• Maintaining multiple projects and repositories.
• Changes in deployment scripts
• Complete testing cycles are required.

At the same time we saw the following upsides to the microservices:

• Smaller memory footprint
• Different projects can be scaled independently
• Cost-saving on the cloud infrastructure

We divided the project into 5 smaller projects. It was a nightmare to split them. There was a lot of common code that we moved to various libraries. Reorganizing the code, making changes to the test cases and deployment changes took far more time than we estimated (as usual).

We started seeing advantages in a couple of weeks. We could scale different functionalities separately that we were unable to do before. It reduced our cloud infrastructure cost as well.

Bullish on Microservices

Initial changes to the system responded well. It felt like the microservices approach was the silver bullet to all the problems. We started applying the same philosophy to everything, literally everything. We created numerous microservices over the next few months.

It was exciting to create new repositories of code that are deployed separately and maintained properly.

We got carried away and in no time we had more than 20 services running separately.

Harsh Truth

It was not long before we started facing issues with so many repositories. It was not easy to change so many codebases in situations like:

• dependent codebases.
• config changes.
• access to various resources.
• change in one service affecting other services.
• infrastructure changes

We reanalyzed our approach and stopped creating unnecessary services. We in fact clubbed a few services to make it easy to do changes. Maintainability effort reduced as well.

In the process, we created a few more microservices, but we did that because needed them.

Wrapping it Up

Microservices is a great concept, I loved it and used it in a good and a bad way. We have seen it as a solution to our problems and at the same time, we created quite a few complications due to the overuse of microservices.

In my opinion, just like any other concept use microservices when there is a use of them. Don’t just use it because it is a hot topic.