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.
There were a few advantages of the monolith as well, which I found.
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.
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.
领英推荐
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 :
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
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.
Software Engineering Manager - Passionate for Product, Technology & People. PMP, CSM, IITL, Azure Certified.
3 年Good observation
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).