Is #Microservices Architecture Killing Us?

Is #Microservices Architecture Killing Us?

I remember when I first started programming it was a monolith code, It was a huge codebase. In parallel, nearly 30 developers used to make changes. A lot of code merge problems and other problems, Let me list a few of the problems I faced.

  1. A lot of Code changes on functionality would break some other functionality, Since it was a huge code base, most of them were unaware of the impact overall.
  2. A single code line change was made used to rebuild the entire code base.
  3. A single code line change was made used to redeploy the entire code base.
  4. During redeploying there was a complete downtime of the entire application.
  5. If a single line of faulty code goes into production may end up impacting an entire huge set of applications.
  6. Unit Tests, Automation tests, and other tests were executed for every change on the entire code base, which was a killer.
  7. As the application grows needed a bigger machine to scale up. No option to scale only a few functionalities that are used heavily.


There were a few advantages of the monolith as well, which I found.

  1. One single source code.
  2. One single code repository.
  3. One single CI/CD Job/Script.
  4. One single Server.
  5. One single property file.
  6. Lots of code reusability since everything was in the same source code.
  7. One single base URL.
  8. One single jar/war of any binaries to deploy.
  9. In production monitor only one single App and server.
  10. Single API documentaion


To solve the problems in a monolith, We started using microservice architecture. Let's understand how? In microservices, The idea is to divide one huge source code into multiple small sources how based on a few criteria's as mentioned below there might be many, I am listing a few of them.

  1. Classify based on functionality
  2. Classify based on how much chatty functionality is and group them together.
  3. Classify based on Usage of the functionality.
  4. Classify based on reusability.
  5. Classify based on the impact of the functionality to the user etc..,

Based on the criteria we ended up classifying and grouping functionality and made a few microservices. The problem here is there is no one hard rule to classify functionalities and create microservices, Which resulted in creating of so many microservices.

Example: A Legacy monolith app was developed using microservices and a team ended up creating nearly 18 microservices.

Now we were able to gain an upper foot over the disadvantage of using monolith architecture for sure But lost ground in the advantages that monolith was offering. Below are a few areas of disadvantage.

  1. To many source code.
  2. Too many repositories ( One on Git, one on SVN, etc..,). One developer has access to the repo and no access to another repo.
  3. Too many property files to manage.
  4. Every microservices has some piece of duplicate code/Unit test cases.
  5. Every microservice has its own base URLs.
  6. Now we ended up handling deploying for 18 microservices.
  7. To many CI/CD Jobs/Scripts.
  8. To many servers/apps to monitor.
  9. Too much API documentation.


As you see there is a huge increase in operation efforts, we were able to solve problems in one area but increase in operation efforts by adding new tools with some extra efforts, Now I see we started using a lot of tools to manage configuration ( config servers), Health check of servers(Service discovery), etc...., Few of the real-time problems I faces was.

Example :

  1. One time config of one of the 18 microservices was not updated, ended up inserting data in the wrong database.
  2. One time one among the 18 microservices, was not patched/updated. We ended up processing data wrongly.


If there are such disadvantages, Why use microservices? I would say microservices are good If properly implemented. I see many microservices created with only 3-4 rest Apis, Such things have to be stopped. Instead, create microservices based on some strict criteria and reduce the number of microservices, and don't create unnecessary microservices unless needed. By doing this we should be able to have minimal services which serve the purpose. The solution would be a mixture of monolith and microservices architecture and create mini services, Which is neither too big to handle nor too small to increase operational efforts.


This was my opinion based on the experience I had, Please comment/share your opinion. Open to hearing it all.

#microservice #monolith #miniservice #microservices #miniservices #architecture



Nabarun Mondal

Engineering Leader - Precision Shooter (Not that precise)

2 年

The way i see it, this has tremendous potential to be actually an Engineering article, and became a Software article in between. If only we start with let there be N basal service which only loads data form data store. Then, how many microservices are possible? Automatically some foundations will pop up, which this article is talking about it. But on the + side, at least some one is talking about it.

Dinesh Chettri

Software Engineering Manager - Passionate for Product, Technology & People. PMP, CSM, IITL, Azure Certified.

3 年

Good observation

Veerayya Shetty

Software Engineer

3 年

Nice explaining... There are some points which I listed out below based on my experience, Choosing a monolithic architecture : 1. A simple application. Small applications which do not demand much business logic, superior scalability, and flexibility work better with monolithic architectures. 2. If you have No microservice expertise. 3. If you need Quick launch. If you want to develop your application and launch it as soon as possible. Choosing a microservice architecture : 1. If you have Microservice expertise. 2. If you require a complex and scalable application. 3. If you have enough engineering skills (devOps, CI/CD,Testing,App support,vetc).

要查看或添加评论,请登录

Goutham Nithyananda的更多文章

社区洞察

其他会员也浏览了