The pains of microservices - Part 1
There are many buzzwords in the tech industry, and one of them is microservices. This word sounds sexy to many engineers and some engineers chase this type of architecture for no reason.
Microservices bring a lot of benefits to the architecture but it also brings extra complexities to the system as well.
Side Note: For microservices topic, I have another series called The path to microservices. If you are interested, go check it out.
Recently, I saw Elon Musk’s post on Twitter. That’s what he said in his tweet:
This makes me come up with this topic — The pains of microservices. When talking about microservices, people always focus on the benefits that microservices bring to the system. But, what about the pains of microservices? In this post, I will be sharing some of my thoughts about the pains of microservices that I’ve seen during my jobs.
Huge DevOps cost
For running microservices architecture, you need a dedicated team to help to build an environment to support the application from building, shipping, managing traffic, etc. That said, you need to hire DevOps experts for the team.
To ensure the system is highly available, you might need to consider different release strategies and replicate the services into multiple nodes. These costs are the extra DevOps efforts that microservices bring to your system. If you don’t consider these things, then microservices cannot bring too many benefits to your system.
If your system and tech team are still small and traffic is not huge, maybe you don’t really need microservices architecture. It cannot bring many benefits to your system but brings extra complexities to the team and architecture.
Extra communication overhead
Imagine a system using a monolith architecture, every call in the system is in memory, and it is super fast. But now you upgrade the architecture to microservices, every invocation between service and service is no longer in memory but HTTP or other protocols. Just to make it easy to understand, we take HTTP as an example.
Now, if A service needs to talk to B service, A service needs to create an HTTP connection with B service to ask B service to do something for A service. Imagine if we have 10+ service dependencies in A service, then A service needs to connect with these 10+ services. It brings extra communication costs for A service and slows down the whole call chain.
Also, the network is not reliable, what if one of the HTTP calls fails, how do you deal with this situation? This question, I’ll leave it for you.
Distributed Transaction
This is really a hard-core topic in a microservices architecture.
Imagine a placing order scenario. When placing an order, the system needs to create a bill, create an order record, and decrease the product stock.
In monolithic architecture, everything is in a single central place. The system can simply create a database local transaction to do these operations inside a single transaction. If anything fails, just roll it back.
But now, the system has upgraded to microservices architecture, and this particular scenario gets split into 3 microservices including order service, billing service, and product service.
When placing an order in this architecture, actually the system needs to invoke 3 services.
Side Note: In case you don’t know what is Backend for Frontend, please read my another post.
https://blog.awesomesoftwareengineer.com/p/api-gateway-aggregation-pattern
We have 3 steps for this scenario:
Decrease the SKU for a product
Create order
Create billing
Now, the operation in order service is failed but actually, we already decrease the SKU in product service. As you see, a simple operation in monolithic architecture becomes a complicated operation in a microservices architecture. Now, how can you take care of the state if one of the calls is failed in the whole call chain? How do you rollback the state and keep the data consistent?
If we want to solve this problem, we can use the Saga pattern, eventually consistent solution, or other similar solutions. But, if we need to put a lot of effort to resolve this problem, it will slow down the development velocity.
In a system, it may have many scenarios similar to this, If we need to solve it in all the scenarios, will your product manager accept your team's development velocity? In the end, to save your life, maybe you will just simply correct the data manually.
Let’s wrap it up. Microservices are not a silver bullet. Bringing it into the system will increase the system's complexity and maintenance cost. So, consider the actual scenario when choosing architecture or building microservices.