Migration vers les microservices : aboutissement ou point de départ?

Sommaire

De nombreuses entreprises de logiciels ont migré leurs applications monolithiques vers des systèmes de microservices afin, entre autres, d’accélérer la livraison, d’améliorer la qualité, de faciliter l’évolutivité, permettant ainsi de gagner en agilité et en compétitivité. Par exemple, en 2008, le fournisseur de films en continu (streaming) Netflix a connu une panne de trois jours et n’a pas pu vendre de DVD en raison de la structure monolithique de son code source. En réponse, Netflix a migré son monolithe vers une architecture de systèmes logiciels modernes (SLM) comprenant plus de 700 services et traitant 15 milliards d'appels d’API par jour dans le monde entier. 

Pourtant, nos recherches démontrent que la migration vers les microservices n’est que le début du parcours et non la destination ultime. Même après la migration, la maintenance des différents microservices nécessite encore beaucoup de coordination entre les équipes. Nous avons étudié l’un des fournisseurs nuagiques les plus populaires, OpenStack, afin de comprendre à quel point différents services peuvent dépendre les uns des autres en ce qui a trait à la maintenance. Par exemple, les modifications apportées à différents microservices, gérés par différentes équipes, dépendent-elles les unes des autres? Si la dépendance entre les composants augmente, faut-il modifier l’architecture (par exemple, retirer des projets)? Si oui, modifier l’architecture permet-il de réduire le nombre de dépendances entre les modifications? Nos conclusions révèlent que l’adoption d’une architecture moderne n’est pas un objectif ultime : les services peuvent toujours dépendre les uns des autres, et les développeurs peuvent devoir coordonner les efforts entre équipes pour résoudre les problèmes. Restructurer les projets peut aider à maîtriser le nombre de dépendances entre les différentes équipes. Nous diffusons les leçons tirées de la gestion des dépendances auprès des professionnels du logiciel et des chercheurs afin d’améliorer la maintenance et l’évolution des systèmes à composants multiples.

Mots-clés : maintenance logicielle, évolution logicielle, modularité, étude empirique

La migration vers les SLM n’est pas une panacée

Les systèmes logiciels modernes comprennent généralement plusieurs composants faiblement couplés qui sont développés, maintenus et déployés indépendamment. Les équipes sont souvent responsables de leurs composants respectifs et sont censées travailler de manière autonome sans nécessiter de fréquentes coordinations. Ce style architectural offre un avantage clé : une mise en marché plus rapide, assurant la livraison rapide et sécurisée des logiciels. Lorsqu’un composant est modifié pour répondre aux demandes en constante évolution, seul ce composant devrait être déployé, sans affecter le fonctionnement des autres services. 

Si c’est vrai en théorie, est-ce également le cas dans la pratique? 

Dans ce travail, nous avons mené une étude empirique sur les modifications au code source soumises à OpenStack, une solution nuagique libre (open source). Pour identifier les dépendances entre les services (modifications apportées à différents services interdépendants), nous avons utilisé quatre balises que les développeurs mentionnent dans leurs descriptions de modifications : « Depends-On », « Needed-By », « Change-Id » et « Related-Bug ». « Depends-On » signifie qu’une modification dépend d’une autre modification. « Needed-By » signifie qu’une modification est nécessaire pour une autre modification. Certaines modifications connexes partagent le même « Change-Id ». Plusieurs modifications peuvent corriger le même bug ou appliquer la même fonctionnalité indiquée par la balise « Related-Bug ».

On pense souvent que migrer une application monolithique vers des microservices est une solution toute faite aux problèmes rencontrés par les professionnels du logiciel dans les systèmes existants. Cependant, la littérature et notre étude montrent une réalité différente. Les services post-migration peuvent toujours exhiber des interdépendances entre plusieurs équipes. Environ 10 % des modifications OpenStack dépassent les limites des projets et environ 6 % dépassent les limites des équipes créant des dépendences entre les changements de code, comme l’illustre la figure 1. Les professionnels du logiciel travaillant sur des systèmes à grande échelle doivent donc s’attendre à un certain degré de couplage (avoir des changements de code qui déclenchent des changements dans d’autres composants/services gérés par d’autres équipes) des services et de coordination entre les équipes, même après la migration.

Les professionnels du logiciel doivent également être prudents quant à la fréquence des interdépendances et à leur croissance potentielle au fil du temps, comme le montre la figure 2. Nous avons observé une augmentation des dépendances entre les changements à différents composants/services, en particulier au cours des six premières années d’OpenStack, avec un pic en 2016. Lorsque les dépendances atteignent certains seuils, les équipes ont besoin d’outils automatisés pour surveiller, gérer et atténuer leur impact sur l’ensemble du système.

Afin de minimiser les dépendances entre les services, les professionnels du logiciel doivent envisager de restructurer les projets au besoin, même dans les systèmes à plusieurs composants. Une architecture modulaire n’est pas forcément une solution à long terme. Nous recommandons de restructurer les composants qui présentent un grand nombre de changements intercomposants. Par exemple, nous avons observé que le nombre de changements intercomposants augmentait au fil du temps, pour atteindre un pic en 2016, puis diminuer après l’archivage d’un grand nombre de projets. Cette refonte à grande échelle a également réduit le nombre de projets externes dont dépendait un projet donné.

Le suivi des dépendances au fil du temps peut contribuer à réduire les dépendances interprojets inattendues. Une mesure pratique consiste à suivre le taux d’interdépendances par projet. Lorsqu’un projet commence à dépendre de plusieurs autres, les équipes de maintenance peuvent examiner rapidement les facteurs sous-jacents pour gagner du temps et réduire les coûts de maintenance. Les professionnels du logiciel pourraient également envisager des migrations ou des restructurations supplémentaires en fonction du nombre de fichiers qui déclenchent des dépendances externes. Par exemple, les fichiers d’un projet qui causent régulièrement des modifications dans plusieurs autres projets pourraient indiquer la nécessité de diviser le projet en sous-projets plus petits et indépendants, avec un faible couplage et une forte cohésion.

Conclusion 

Dans l’ensemble, nous constatons que la migration vers les microservices n’est pas nécessairement une solution définitive. Les services peuvent continuer à dépendre les uns des autres, et ces interdépendances se sont accrues au fil du temps, en particulier au début des projets. Les professionnels du logiciel doivent être très attentifs à ce type de comportement. Une coordination entre les équipes peut également être nécessaire, ce qui est difficile dans les systèmes à grande échelle comprenant des centaines, voire des milliers de services gérés par différentes équipes. Nous recommandons aux professionnels du logiciel de ne pas négliger les dépendances, car elles peuvent rapidement se multiplier au fil du temps, ce qui peut entraîner le retrait d’un grand nombre de microservices. De plus, surveiller les interdépendances et détecter les premiers signes peut aider à déterminer le moment de restructurer un système ou d’envisager une autre migration. 

Informations supplémentaires

Pour plus d’informations sur ce travail, veuillez consulter l’article suivant : Arabat, A., & Sayagh, M. (2024). An empirical study on cross-component dependent changes: A case study on the components of OpenStack. Empirical Software Engineering, 29(5), 109.

References

Sampaio et al. “Supporting microservice evolution.” International Conference on Software Maintenance and Evolution (2017).

Bogner et al. “Assuring the evolvability of microservices: insights into industry practices and challenges.” International Conference on Software Maintenance and Evolution (2019).