Monolithique vs. Architecture des microservices : Les microservices sont sortis, les monolithes sont de retour

Pour ceux d’entre vous qui ont l’impression de souffrir d’un grave cas de déjà-vu technique, vous n’avez pas tort. C'est la même situation dans laquelle se trouvait l'architecture orientée services (SOA) vers 2009, lorsque Anne Thomas Manes a déclaré sa mort . Le lien renvoie vers un commentaire de David Linthicum sur le message de Manes, car l'original semble avoir été mangé par Internet.

Maintenant, Manes était hyperbolique et quelque peu sarcastique car, comme nous le savons bien, l’architecture orientée services n’est pas morte. Il a été ressuscité assez rapidement sous la forme de microservices, et malgré les regrets d’Internet, les concepteurs n’ont toujours pas compris le rôle important que joue « le réseau » dans les performances.

SOA est « mort » pour deux raisons :

1. Des normes XML concurrentes et surchargées qui ont rendu les architectures trop complexes. Personne ne se souvient avec tendresse 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 le deuxième ? La seule réponse à la deuxième question a été et continue d’être 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. Cela prend du temps. Il n’existe pas de « coût zéro » en matière de communication entre services. Il y a le temps qu’il faut pour placer un paquet sur le câble, puis le transférer, puis le retirer du paquet et enfin le traiter. Et n’oubliez pas que les communications de transport prennent également du temps. L'ouverture de sockets et l'acceptation de requêtes ne sont pas non plus gratuites, tout comme le temps nécessaire pour sérialiser et désérialiser les charges utiles en quelque chose que le service peut traiter.

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

Plus vous concevez votre système de manière granulaire, plus le traitement d'une demande prend du temps. En d’autres termes, le temps total de traitement d’une demande dépend du nombre de services par lesquels la demande doit passer.

Une plus grande granularité ? Temps de traitement plus long. Plus de services ? Une congestion accrue sur le réseau, ce qui augmente finalement le temps de traitement lorsque les cartes et les périphériques réseau tentent de mettre les paquets dans l'ordre et demandent une retransmission.

Ainsi, comme les SOA, les microservices peuvent souffrir et souffriront de modèles de conception qui reposent sur une granularité trop importante.

Amazon a choisi un monolithe pour remplacer ses microservices. Cela signifie que pour leur cas d’utilisation, une architecture monolithique était la meilleure option. Cela signifie-t-il que les microservices sont morts ?

Non. Au lieu de cela, nous devrions retenir deux points essentiels :

• Premièrement, nous devrions nous inspirer d’Amazon et être plus délibérés et réfléchis dans la manière dont nous concevons des systèmes qui s’appuient sur des services et nous assurer que nous comprenons les implications sur les performances de la répartition des tâches entre trop de petits services.
• Deuxièmement, nous devons nous rappeler que les monolithes constituent un choix d’architecture d’application viable. Il y a une raison pour laquelle 60 % du portefeuille d’applications d’une entreprise est composé d’applications basées sur une architecture « traditionnelle » et 16 % des organisations n’ont pas l’intention de les retirer.

Les architectures d’application ne sont ni bonnes ni mauvaises, et ne conviennent pas à tous les cas d’utilisation. Les organisations doivent prendre du recul et réfléchir soigneusement à ce qu’elles cherchent à réaliser et à l’architecture qui pourrait le mieux répondre à ce besoin au lieu de choisir l’architecture la plus « moderne » parce que, eh bien, elle est à la mode.

Lorsque nous disons que l’avenir est à l’informatique hybride, nous entendons bien plus qu’un simple mélange de déploiements multicloud et sur site. Nous entendons également que le portefeuille d’applications d’entreprise restera hybride, un mélange de traditionnel et de moderne, dans un avenir prévisible. C'est pourquoi le portefeuille F5 continue de prendre en charge toutes les applications, qu'elles soient sur site ou dans le cloud public, ou les deux.