Architecture monolithique ou microservices : les microservices sont dépassés, les monolithes font leur retour

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

Que tout le monde se calme. Respirez profondément, puis avançons doucement au cœur de la guerre entre microservices et monolithes qui fait rage sur Internet.

L’essentiel :

Amazon a récemment publié une étude de cas expliquant sa décision d’abandonner les microservices au profit d’une architecture monolithique, avec à la clé une réduction des coûts de 90 %. Cette étude de cas a déclenché une avalanche de commentaires et de tweets sarcastiques sur Internet, opposant les microservices aux architectures monolithiques sur le ring technique.

La réalité :

Si vous avez l’impression de vivre un sérieux déjà-vu technologique, vous ne vous trompez pas. C’est la même situation qu’a connue l’architecture orientée services (SOA) vers 2009, lorsque Anne Thomas Manes a annoncé sa mort. Le lien renvoie vers un commentaire de David Linthicum sur l’article de Manes, car l’original semble avoir été englouti par Internet.

Cela dit, Manes se montrait hyperbolique et quelque peu sarcastique car, comme nous le savons bien, l’architecture orientée services n’est pas morte. Elle a assez rapidement ressuscité sous la forme des microservices et, à en croire les lamentations que l’on trouve sur Internet, les concepteurs n’ont toujours pas compris à quel point « le réseau » joue un rôle important dans les performances.

La SOA est « morte » pour deux raisons :

1. Des normes concurrentes et pléthoriques basées sur XML, qui rendaient les architectures excessivement complexes. Personne ne garde un bon souvenir de WSDL, SOAP et UDDI. Personne.
2. Les lois de la physique et les normes d’interopérabilité limitent l’échange de paquets réseau à la vitesse de la lumière et à 1 500 octets.

Nous avons peut-être surmonté le premier défi, mais qu’en est-il du second ? La seule réponse à ce dernier a toujours été, et reste encore aujourd’hui, de trouver un équilibre délicat entre la granularité de la conception des services et une bonne compréhension du temps nécessaire au transfert des données entre les services.

Le transfert de données n’est pas gratuit. Il prend du temps. Les communications entre services n’ont jamais un « coût nul ». Il faut du temps pour placer un paquet sur le réseau, le transférer, en extraire les données et, enfin, les traiter. Et n’oublions pas que les communications liées au transport prennent elles aussi du temps. Ouvrir des sockets et accepter des requêtes a également un coût, tout comme la sérialisation et la désérialisation des charges utiles dans un format que le service peut traiter.

Maintenant, multipliez ce coût total par le nombre de services que vous essayez d’utiliser.

Plus la conception de votre système est granulaire, plus le traitement d’une requête prend du temps. En d’autres termes, le temps total nécessaire au traitement d’une requête dépend du nombre de services par lesquels elle doit transiter.

Une granularité plus fine ? Un temps de traitement plus long. Davantage de services ? Une congestion accrue du réseau, qui finit par allonger le temps de traitement, car les cartes réseau et les périphériques tentent de remettre les paquets dans l’ordre et demandent leur retransmission.

Ainsi, à l’instar de la SOA, les microservices peuvent pâtir — et pâtiront — de modèles de conception reposant sur une granularité excessive.

Amazon a choisi une architecture monolithique pour remplacer ses microservices. Cela signifie que, pour son cas d’usage, une architecture monolithique était la meilleure option. Faut-il en conclure que les microservices sont morts ?

Non. Nous devons plutôt en retenir deux points essentiels :

• Premièrement, nous devrions nous inspirer d’Amazon et faire preuve de davantage de discernement et de réflexion dans la conception de systèmes reposant sur des services, tout en veillant à bien comprendre les conséquences sur les performances d’une répartition des responsabilités entre un trop grand nombre de petits services.
• Deuxièmement, nous devons nous rappeler que les architectures monolithiques constituent un choix viable pour l’architecture des applications. Ce n’est pas sans raison que 60 % du portefeuille d’applications d’une entreprise est constitué d’applications reposant sur une architecture « traditionnelle », et que 16 % des organisations ne prévoient pas de les abandonner.

Les architectures applicatives ne sont ni bonnes ni mauvaises, et ne conviennent pas non plus à tous les cas d’usage. Les organisations doivent prendre du recul et réfléchir attentivement à ce qu’elles cherchent à accomplir ainsi qu’à l’architecture la mieux adaptée à cet objectif, plutôt que de choisir l’architecture la plus « moderne » simplement parce qu’elle est en vogue.

Lorsque nous affirmons que l’avenir réside dans l’informatique hybride, nous ne parlons pas seulement d’une combinaison de déploiements multicloud et sur site. Nous voulons également dire que le portefeuille d’applications d’entreprise restera hybride — mêlant architectures traditionnelles et modernes — dans un avenir prévisible. C’est pourquoi le portefeuille F5 continue de prendre en charge toutes les applications, qu’elles soient déployées sur site, dans le cloud public, ou dans les deux environnements.

À 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