I published a feature article on the onepoint website about a low-visibility risk of distributed architectures: the entropy of microservices. Here, entropy means the disorder that builds up in a software’s structure as it evolves. The article explains why applications split into microservices, often chosen to replace ageing monolithic applications, are in fact more exposed to this disorder than monoliths themselves. It is aimed at architects, IT leaders and the development teams that run these rebuilds.
Why are microservices exposed to entropy?
A monolithic application bundles all of its features into a single code base deployed as one unit. Simple at first, it loses its ability to evolve over the years, until it becomes too costly and too fragile to change. Its average lifespan is between 6 and 8 years. Distributed microservice architectures promise to move past that limit, but they bring their own fragility. Here are the key points of the article:
- Software entropy is the root cause of an application’s death, ahead of the complexity of the code itself: the disorder of dependencies between the software’s parts is what eventually makes it impossible to evolve.
- Code quality tools and documentation are not enough, because they address the internal complexity of the code and not the structural disorder that condemns the application.
- Distributed microservice architectures are more exposed to entropy than monoliths, because of three factors: interdependence between services, reliance on the network, and eventual data consistency.
- The anti-pattern to avoid has a name, “distributed spaghetti”, even harder to fix than the spaghetti code of a monolith.
- The laws of software evolution formulated by researcher Manny Lehman establish that every change to a business application increases its complexity and reduces its future ability to evolve.
- The only safeguard is to measure and track entropy over time, so you can act before reaching the threshold of irreversible complexity.
Key takeaways
- Entropy, meaning the structural disorder of a software, grows continuously and silently with every change.
- Microservices do not escape this phenomenon: they are even more exposed to it than the monoliths they replace.
- Measuring entropy over time is the prerequisite for preserving an application’s ability to evolve and extending its lifespan.
Read the full article on the onepoint website: Microservices: the risks of entropy (the original is in French, and the page also offers the publication as a PDF download).