Microservices : Moins de micro et plus de services
L’architecture orientée services (SOA) a été déclarée morte il y a près de dix ans. Un facteur contribuant à sa disparition, mais rarement évoqué, fut le réseau. La latence entre les services empêchait les architectes de décomposer entièrement les applications en services avec la granularité nécessaire pour encourager la réutilisation et, en fin de compte, les applications composables.
Entrez dans l'architecture des microservices (MSA). Ses principes exigent une décomposition encore plus poussée, en mettant l’accent sur la fonction (verbes) plutôt que sur l’objet (noms) comme critère principal pour diviser une application. De ce changement d’orientation apparemment subtil naît une plus grande granularité des services ; il y a beaucoup plus de fonctions que d’objets dans un système donné.
Le réseau est prêt. Les vitesses et les débits du réseau physique ont augmenté de façon spectaculaire. L'informatique a également progressé conformément à la loi de Moore et a fait de la latence du réseau un problème quasi inexistant.
Malheureusement, la latence de communication prendra sa place.
Nous avons reproduit à l'intérieur des environnements de conteneurs utilisés pour déployer des microservices la complexité d'Internet. Même si un microservice n’a pas besoin de DNS, il s’appuie toujours sur le même type de résolution basée sur les noms qui gère Internet. Les balises d'application - métadonnées - doivent être traduites en une adresse IP. Les registres de services et les entrées de tables IP complexes agissent comme un DNS miniature, traduisant les balises en adresses et permettant la communication entre les services.
La nature éphémère des microservices et des conteneurs associés aggrave la latence associée à ce processus. Avec des durées de vie mesurées en secondes ou en minutes au lieu d'heures ou de mois, la résolution de nom doit se produire à chaque appel. Le temps de vie (TTL) dans le monde des conteneurs est, en réalité, nul.
Même si nous ignorons cette reproduction d’une des plus grandes sources de latence de communication, il nous reste celle associée au TCP. Il n’est pas – et n’a jamais été – gratuit d’initier ou d’interrompre une connexion TCP. Cette source de latence est certes faible mais absolument additive. Chaque connexion (chaque microservice) nécessaire à l'exécution d'une transaction unique ajoute une latence qui finit par dépasser la tolérance au retard.
HTTP/2, malgré ses changements de comportement spectaculaires, ne résout pas ce problème. HTTP/2 est conçu pour faciliter le transfert de plusieurs objets sur la même connexion, réduisant ainsi la latence pour le contenu multi-objets tel que les pages Web et les applications Web. Les microservices sont idéalement conçus de telle sorte que chaque service renvoie une réponse unique. Bien que plusieurs requêtes sur une connexion établie réduisent certainement la charge de communication, cela ne peut pas se faire dans un système où plusieurs requêtes sont réparties sur plusieurs services discrets .
Le problème n’est donc pas la latence du réseau, mais la latence de la communication. Les connexions comptent toujours, et les améliorations apportées aux protocoles conçus pour optimiser les performances des communications multi-transactionnelles basées sur le Web n’aideront pas les transactions multiservices.
Le résultat est SOMA. Microarchitectures orientées services. Un étrange hybride d’architectures orientées services et de microservices qui laisse perplexe quant à savoir où l’une se termine et où l’autre commence. La décomposition des applications en services composites basés sur des fonctions est limitée par la latence de communication et, en fin de compte, par la durabilité de la base de code. Bien que les avancées du réseau aient certainement augmenté la granularité avec laquelle la décomposition peut être raisonnablement réalisée, elles n’ont pas éliminé la contrainte. Un autre facteur est le fait qu’il y a des ordres de grandeur plus élevés de fonctions dans une application que d’objets, ce qui fait de la tâche de gestion d’une application purement architecturée en microservices un véritable cauchemar logistique pour les opérations réseau, sans parler des développeurs d’applications. Combiné au problème inhérent soulevé par la latence des communications, les organisations développent de plus en plus de microservices orientés objet au lieu de microservices véritablement orientés fonction.
C’est pourquoi nous observons une décomposition des applications au-delà de l’architecture traditionnelle à trois niveaux, mais pas au point d’être une représentation fidèle de la décomposition fonctionnelle.
Tant que nous n’aborderons pas le problème de latence inhérent aux communications basées sur la connexion (TCP) – soit avec quelque chose de nouveau, soit en nous concentrant sur les implémentations au niveau du système – nous continuerons d’être limités aux architectures de microservices qui sont moins micro et plus de services.