Microservices : moins de « micro », plus de services

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

L’architecture orientée services (SOA) a été déclarée morte il y a près de dix ans. Le réseau a contribué à sa disparition, bien que ce facteur soit rarement évoqué. La latence entre les services empêchait les architectes de décomposer entièrement les applications en services suffisamment granulaires pour favoriser leur réutilisation et, à terme, permettre la création d’applications composables.

C’est là qu’intervient l’architecture de microservices (MSA). Ses principes exigent une décomposition encore plus poussée, en privilégiant les fonctions (verbes) plutôt que les objets (noms) comme principal critère de découpage d’une application. Ce changement d’orientation en apparence subtil permet d’obtenir des services plus granulaires : dans un système donné, les fonctions sont bien plus nombreuses que les objets.

Le réseau est prêt. Les débits et les performances du réseau physique ont considérablement augmenté. La puissance de calcul a elle aussi progressé conformément à la loi de Moore, au point que la latence réseau n’est pratiquement plus un problème.

Malheureusement, la latence des communications prendra sa place.

Nous avons reproduit la complexité d’Internet au sein des environnements de conteneurs utilisés pour déployer des microservices. Même si un microservice n’a pas nécessairement besoin du DNS, il repose toujours sur le même type de résolution de noms que celui qui fait fonctionner Internet. Les étiquettes des applications — les métadonnées — doivent être traduites en adresses IP. Les registres de services et les entrées complexes des tables IP font office de DNS miniatures, traduisant les étiquettes en adresses et permettant la communication entre les services.

La nature éphémère des microservices et des conteneurs qui leur sont associés aggrave la latence liée à ce processus. Leur durée de vie se mesurant en secondes ou en minutes plutôt qu’en heures ou en mois, la résolution de noms doit être effectuée à chaque appel. Dans l’univers des conteneurs, la durée de vie (TTL) est donc, en pratique, nulle.

Même si nous faisons abstraction de cette reproduction de l’une des principales sources de latence des communications, il reste la latence associée à TCP. L’établissement ou la fermeture d’une connexion TCP n’est pas gratuit et ne l’a jamais été. Cette source de latence est certes faible, mais elle s’ajoute bel et bien aux autres. Chaque connexion — chaque microservice — nécessaire à l’exécution d’une transaction ajoute de la latence, jusqu’à finir par dépasser le délai tolérable.

HTTP/2, malgré les changements radicaux apportés à son fonctionnement, ne résout pas ce problème. HTTP/2 est conçu pour faciliter le transfert de plusieurs objets sur une même connexion, réduisant ainsi la latence des contenus composés de plusieurs objets, tels que les pages web et les applications web. Dans l’idéal, les microservices sont conçus de sorte que chaque service renvoie une seule réponse. Si l’envoi de plusieurs requêtes sur une connexion établie réduit assurément la surcharge liée aux communications, ce n’est pas possible dans un système où plusieurs requêtes sont réparties entre plusieurs services distincts .

Le problème ne réside donc pas dans la latence du réseau, mais dans celle des communications. Le nombre de connexions reste déterminant, et les améliorations apportées aux protocoles conçus pour optimiser les performances des communications web impliquant plusieurs transactions ne seront d’aucune utilité pour les transactions faisant appel à plusieurs services.

Le résultat est SOMA, pour « Service Oriented Micro Architectures ». Il s’agit d’un étrange hybride entre les architectures orientées services et les architectures de microservices, au point qu’on peut se demander où finit l’une et où commence l’autre. La décomposition des applications en services fonctionnels qui les composent est limitée par la latence des communications et, en définitive, par la maintenabilité de la base de code. Si les progrès des réseaux ont certes permis d’accroître le niveau de granularité auquel cette décomposition peut raisonnablement être effectuée, ils n’ont pas supprimé cette contrainte. Il faut également tenir compte du fait qu’une application comporte plusieurs ordres de grandeur de plus de fonctions que d’objets. La gestion d’une application reposant sur une architecture de microservices pure devient donc un véritable cauchemar logistique pour les équipes d’exploitation réseau, sans parler des développeurs d’applications. Compte tenu également du problème intrinsèque posé par la latence des communications, les organisations développent de plus en plus des microservices orientés objet plutôt que de véritables microservices orientés fonction.

C’est en définitive la raison pour laquelle nous voyons les applications se décomposer au-delà de l’architecture traditionnelle à trois niveaux, sans toutefois aller jusqu’à constituer une représentation fidèle d’une décomposition fonctionnelle.

Tant que nous n’aurons pas résolu le problème de latence inhérent aux communications basées sur des connexions (TCP) — soit en adoptant une nouvelle approche, soit en nous concentrant sur les implémentations au niveau système — nous resterons cantonnés à des architectures de microservices qui tiennent davantage des services que du « micro ».

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie