Your Microservice Architecture Will Collapse

I came across a scientific article published by Science magazine more than 6 years ago, which seemed to me to be exciting to share with you. This article discusses the anticipation of critical transitions, and it has many use cases, including microservice architectures. In this article, we will, therefore, present what a critical transition is, how to discover them in advance, and how to protect yourself against them.

What Is a Critical Transition?

A critical transition is a sudden drop in a system, whether in its production, its ability to evolve, the number of instances it contains, or its performance. This expression can thus be applied to a financial system, a productive system, an ecosystem, and generally to any system with an architecture. And this applies particularly well to microservice architectures (even if no case studies have been done) because the analogy is obvious. We have entities (microservices), connected to each other, which can be heterogeneous or homogeneous.

The interest of the study is, therefore, to predict the moment when a microservices architecture will no longer support any evolution.

To Which Types of Systems Does This Apply? 

The author Marten Scheffer has determined that this type of fall occurs in systems (not only computer systems...) characterized by high homogeneity and strong interconnection.

You can see a descriptive schema here: http://science.sciencemag.org/content/sci/338/6105/344/F1.large.jpg

Very clearly, microservice architectures are very concerned. There is no debate about connectivity. Homogeneity could, because it is recommended to have not only one technology to do microservices, but in practice, this does not change much. Your microservice, whatever its language, will probably exchange in the same way and be structured according to the same principles.

On the other hand, modular and heterogeneous systems, which are poorly interconnected, will experience a more gradual decline. In any case, highly interconnected and homogeneous systems benefit from a plateau. We have nothing for nothing.

How to Detect the Onset of a Critical Transition? 

Studies on this subject are still in their infancy, but a number of highlights have been discovered, which can be found on the author's website:

• Slow recovery from disturbances: If a small, harmless evolution takes much longer to be made, it is a big weak signal that your logical architecture will not stand up for long.

• Increasing autocorrelation: To stay away from math, in our case, this means that the time it takes to make a new change is close to the last change. If you make a drawing of the time spent to make a change, you would have a plateau.

• Increasing variance: The various shocks received (major evolutions, inextricable problems) by the system increase and degrade the system compared to the past.

• Increasing skewness: I'm not sure that this applies to microservice architectures, but it could apply to the evolutions you need to make, but for which you often have to come back.

• Flickering: This is when random phenomena apply to your system to change its state, which can result in evolutions bringing their set of unexpected side effects.

Another point is that the basic ingredient of a tipping point is a positive retroaction that, once a critical point has passed, propels the change to an alternative state. 

So What Can We Do? 

If we consider that a highly interconnected and homogeneous system is the archetype of microservice architecture, I think we should continue to prefer this architecture. The plateau that this architecture offers in terms of time spent on business evolution is much preferable to a system that is becoming less and less efficient.

To date, I have not found anything like an archetype of the perfect system. But a few leads may emerge to avoid the fall:

• DDD design in a modularized way.

• Have microservices interconnect, but limit these interconnections (no more than two paths to go to a microservice?).

• Share your developments in an open source mode, with people in charge to govern a certain amount of microservices. It lets people have knowledge of the architecture, and it lets people know what is good or not for a microservice.

Detect weak signals and put yourself in a position to quickly review an architecture in depth, perhaps through regular technical and architectural debt management sprints.

So, maybe you're not concerned! But keep it in mind to keep your microservice architecture alive. There are so many systems that don't manage to live more than twenty years, it would be good to get a system that could live forever!