Do you think you are doing microservices? Do not!

Do you think you are doing microservices? Do not! You just made a distributed monolith that is worse than the monolith! Before going to bed last night, I ran a few chat records of group chats.

Do you think you are doing microservices

I found a very interesting term “distributed monomer”, and I took a look at the previous chat records. Because of the content, I won’t post it. . . The general content is that a company is doing microservices transformation, but the changes are nondescript, like microservices in form, but in essence it is still a single unit, and even a single unit is inferior. Do you think you are doing microservices.

Such a transformation phenomenon is actually quite common. Let’s talk about this interesting topic: distributed monoliths. Everyone, see if your company has also made such a mistake? Do you think you are doing microservices.

Why is the distributed monomer bad?

Let’s think about a question first: did you follow these steps when transforming from monolithic to microservices? Do you think you are doing microservices.

1. Determine business areas, split storage, and define the boundaries of each microservice
2. Modify the code logic and change the original internal service call to a remote call such as dubbo or feign

Through this transformation, we have obtained many benefits, such as:

1. The code base is separated, reducing the trouble of resolving code conflicts
2. CI/CD are separated, and each service after the split can be independently developed, deployed, and run
3. The databases are separated and run independently, and different business modules will not affect each other

With such an operation, we have turned a bloated single application into multiple refined distributed applications. It seems that the transformation has been perfected? But does this achieve the core goal of microservices? Continue to think about the following questions:

1. The code base is separated, but is each service iterating independently? Does every requirement need to coordinate a lot of synchronization interfaces?
2. CI/CD are separated, but is each release free? Does each feature release drag on a big push of the service to be released together?
3. The database is separated, but it seems that a service is down, which still causes many functions to be abnormal?

It seems that we have gained a lot of benefits, but has our development efficiency really improved? Although we used to start a single application in 3 minutes, now after splitting, a project starts in 30 seconds, but every time we develop and debug how many projects should be started at the same time? Is this kind of development experience really cool?

It seems that the microservice transformation has been completed, but in fact it is still a single application, but it has changed from a centralized implementation to a distributed implementation. It turns out that we only did a useless effort, and the real gains were minimal. Do you think you are doing microservices.

But in fact, this kind of transformation, in addition to low profits, also brought out more disadvantages. If your company does this, have you found that after doing so, it seems that the frequency of system failures has become higher? The stability seems to be worse than the monomer application? (If not, then we must thank your operation and maintenance team for their great work, and it is recommended to transfer this article to the operation and maintenance team. After the interview, do they become more tired after such a transformation?!)

Why would such a transformation make the system more unstable? In fact, the reason is very simple. Originally, in our single application, the undivided remote calls were all internal calls. The failure rate caused by this internal call was minimal. After dividing this part of the content into remote calls, every One call increases the network IO factor, and the failure rate of each call increases. Then the overall failure rate of the system increases with the number of simultaneous remote calls the system has. When the operation and maintenance team and development level do not support this part of the increased complexity, the modified system will inevitably have worse stability than the original single application.

Therefore, as a result of this transformation, not only did not get a lot of benefits, but it would bring a lot of stability losses. Do you think you are doing microservices.

The culprit of the distortion

So why does it cause the problems mentioned above? I think there are two main aspects:

1. Unreasonable domain split, leading to too many synchronous remote calls

This is the most fundamental problem, and it is also the most common in the transformation process. To be honest in this part is the most difficult part of the entire transformation process, because it requires a very in-depth understanding of the business and a sufficient understanding of the domain model of the system design and user behavior.

When doing splitting, try to reduce synchronous remote calls as much as possible, instead of asynchronous interaction with messages, and at the same time, appropriate data redundancy can be done according to business needs. In this way, it can be ensured that a lower degree of coupling can be obtained between each split microservice.

Because of the lower degree of coupling, we can obtain less stability loss caused by distribution without any optimization. For the second point to be later, the workload will be less. At the same time, true independent development, deployment, and operation are also possible.

2. Simple and crude implementation, lack of distributed protection mechanism

In many teams, because of the contradiction between more business needs and less staffing, developers are prone to failing to provide adequate protection mechanisms for remote calls, such as: the current limiting strategy of the interface provider (protect yourself from being killed by others) ), the downgrade strategy of the interface caller (to protect the higher availability of the business), and the fuse strategy of the interface caller (to protect yourself from being dragged by others). Only by taking every dependency point in a distributed environment seriously, can we solve the many problems involved in the distributed transformation.

But to do a good job at the core of this point, you still have to grasp the first point. Only by making a more reasonable split plan on the domain model can we support developers to do this well, otherwise they will split at will, a lot of interface calls. If you put pressure on developers who are already under great pressure, the quality of this part of the development is definitely difficult to guarantee. Naturally, the stability of the system begins to decline as the complexity of the interface increases. In the end, developers will start to complain in our group…Even everyone starts to suspect that microservices can’t bring efficiency improvements at all!

Finally, think about it. Does your microservice transformation have the situation I mentioned here? Or are there other different problems? Join our Spring technical exchange group and chat about your views! Do you think you are doing microservices.

Recommended reading

Do you think you are doing microservices?

Do you think you are doing microservices