J’ai publié sur le site de onepoint un article de fond consacré à un risque peu visible des architectures distribuées : l’entropie des microservices. Le mot entropie désigne ici le désordre qui s’accumule dans la structure d’un logiciel à mesure qu’il évolue. Cet article explique pourquoi les applications découpées en microservices, souvent choisies pour remplacer des applications monolithiques vieillissantes, sont en réalité plus exposées à ce désordre que les monolithes eux-mêmes. Il s’adresse aux architectes, aux DSI (directions des systèmes d’information) et aux équipes de développement qui pilotent ces refontes.
Pourquoi les microservices sont-ils exposés à l’entropie ?
Une application monolithique regroupe toutes ses fonctionnalités dans une seule base de code déployée d’un bloc. Simple au départ, elle perd en évolutivité au fil des années, jusqu’à devenir trop coûteuse et trop fragile à faire évoluer. Sa durée de vie moyenne se situe entre 6 et 8 ans. Les architectures distribuées en microservices promettent de dépasser cette limite, mais elles introduisent leur propre fragilité. Voici les points clés de l’article :
- L’entropie logicielle est la cause profonde de la mort des applications, avant même la complexité du code lui-même : c’est le désordre des dépendances entre les parties du logiciel qui finit par le rendre inévolutif.
- Les outils de qualimétrie (mesure automatique de la qualité du code) et la documentation ne suffisent pas, car ils traitent la complexité interne au code et non le désordre structurel qui condamne l’application.
- Les architectures distribuées en microservices sont plus exposées à l’entropie que les monolithes, à cause de trois facteurs : l’interdépendance entre services, la dépendance au réseau et la cohérence à terme des données.
- L’anti-pattern à éviter porte un nom, le « spaghetti distribué », plus difficile à corriger encore que le code spaghetti d’un monolithe.
- Les lois de l’évolution des logiciels du chercheur Manny Lehman établissent que chaque modification d’une application de gestion augmente sa complexité et réduit sa capacité future à évoluer.
- La seule parade consiste à mesurer et à suivre l’entropie dans le temps, pour agir avant d’atteindre le seuil de complexité irréversible.
Ce qu’il faut retenir
- L’entropie, c’est-à-dire le désordre structurel d’un logiciel, augmente de façon continue et silencieuse à chaque évolution.
- Les microservices n’échappent pas à ce phénomène : ils y sont même plus exposés que les monolithes qu’ils remplacent.
- Mesurer l’entropie dans le temps est le prérequis pour préserver l’évolutivité d’une application et allonger sa durée de vie.
Lire l’article complet sur le site de onepoint : Microservices : les risques de l’entropie (l’article propose aussi le téléchargement de la publication au format PDF).