3 raisons pour lesquelles vous pourriez vouloir utiliser Monolith au lieu de Microservice | de Edward Huang | décembre 2022

La plupart du temps, Monolith est assez bon. Sauf si vous êtes Google

Lorsque vous entendez parler d’architecture monolithique, votre esprit passe immédiatement à l’architecture héritée.

De nombreuses entreprises ont fait des microservices le roi de l’architecture de développement logiciel moderne. Tout cela est dû au fait qu’il est largement adopté par les grands acteurs – FAANG.

Cependant, de nombreuses grandes entreprises technologiques, telles que Netflix, Uber et Amazon, ont toutes commencé avec une architecture monolithique, et il y a une raison pour laquelle elles sont passées à une architecture de microservices.

De nombreux ingénieurs pensent que l’architecture monolithique pourrait être améliorée car elle est moins fiable et moins modulaire, il est donc difficile de maintenir et de faire évoluer votre système à long terme.

C’est différent de la raison pour laquelle ils passent à l’architecture de microservices, bien qu’il y ait une part de vérité dans ce problème technique qui a conduit ces grandes entreprises à adopter l’architecture de microservices.

Tout d’abord, nous devons comprendre pourquoi les organisations migrent vers les microservices en premier lieu et examiner comment les microservices résolvent deux types de problèmes : les problèmes techniques et les problèmes humains.

Un problème technique dans l’architecture monolithique est qu’un composant alourdit l’architecture globale, provoquant une mauvaise expérience utilisateur (UX).

Par exemple, le traitement d’images nécessite beaucoup de CPU. Si cette charge CPU devient trop élevée, elle pourrait priver le reste de l’application de ressources de traitement. Cela pourrait affecter la latence du système. Et, si cela devient suffisamment grave, cela pourrait affecter la disponibilité du système.

D’autre part, un problème de personnes a tout à voir avec l’organisation de l’équipe et le processus de développement logiciel. Plus vous avez de personnes travaillant sur une partie donnée de l’application, plus le développement et le déploiement sont lents.

Par exemple, supposons que vous ayez 30 ingénieurs en compétition pour « déployer en continu » (CD) le même service. Dans ce cas, vous allez avoir beaucoup de files d’attente, ce qui signifie que de nombreux ingénieurs qui pourraient autrement expédier des produits attendent leur tour pour se déployer.

Si votre système/équipe/organisation ne rencontre pas ces problèmes, vous devez utiliser une architecture monolithique au lieu de microservices. Voici trois raisons.

Les ingénieurs pensent souvent à tort que l’architecture de microservices peut aider à la tolérance aux pannes.

Ce n’est que partiellement le cas.

Une architecture de microservice aide à résoudre les problèmes liés à l’infrastructure, tels que les fuites de mémoire ou les pics de processeur, qui sont plus faciles à détecter sur un composant spécifique plutôt que sur un grand monolithe.

Monolith peut être tout aussi tolérant aux pannes et fiable que l’architecture de microservices. Vous pouvez facilement faire évoluer plusieurs services dans un environnement cloud avec des configurations appropriées.

Dans un monolithe, le problème dont vous devrez tenir compte concerne les erreurs d’exécution, tandis que pour le microservice, vous devrez gérer les erreurs de réseau, qui sont sans doute plus complexes.

Dans une étude de cas Shopify sur la migration vers une architecture monolithique, ils ont déclaré que la plupart des échecs après la migration vers une architecture monolithique provenaient souvent de leur code ne sachant pas où trouver les définitions d’objets, ce qui entraînait des erreurs d’exécution.

L’équipe d’ingénierie peut s’assurer que rien n’a été manqué en exécutant ses tests localement et en CI sans échec et en exécutant autant de fonctionnalités que possible localement et sur la chaîne.

Avoir un nouveau système différent signifie augmenter un point de défaillance supplémentaire.

Vous pouvez appeler directement différents composants plutôt que via le service d’application Web. Vous n’avez pas à vous soucier de la gestion des versions de l’API, de la rétrocompatibilité ou des appels en retard.

Les ingénieurs expérimentés se demandent souvent quand une architecture nécessite l’ajout d’un nouveau microservice, car l’ajout d’un nouveau microservice entraîne souvent plus de latence et d’échec.

L’un des principaux inconvénients du microservice est la maintenance de l’infrastructure. Les microservices s’accompagnent d’une surcharge opérationnelle accrue et de problèmes liés à la réutilisation du code.

Votre équipe d’ingénieurs utilisera des bibliothèques partagées qui nécessitent des services avec des fonctionnalités communes. Ensuite, vous vous rendez compte que changer un champ demande une semaine de travail car cela nécessite de changer cette bibliothèque partagée qu’utilisent des centaines d’autres ingénieurs.

C’est l’une des raisons pour lesquelles Segment est revenu à une architecture monolithique.

« L’équipe a créé des bibliothèques partagées pour fournir un comportement similaire à tous les travailleurs. Cependant, cela a créé un nouveau goulot d’étranglement, où les modifications apportées au code partagé pouvaient nécessiter une semaine d’efforts de développement, principalement en raison de contraintes de test. La création de versions des bibliothèques partagées a accéléré les changements de code, mais a annulé l’avantage que le code partagé était censé fournir. »

Ensuite, il y a l’aspect observabilité de tous les services.

Vous aurez besoin d’un outil de surveillance distribué pour dix services différents avec leur processeur, leur profil de mémoire et leur charge. Il s’agit d’un travail beaucoup plus opérationnel que la simple surveillance d’un seul service.

Ensuite, vous devrez continuer à écrire de la documentation sur votre service pour le rendre détectable. Étant donné que les membres de votre équipe peuvent aller et venir, si vous ne documentez pas efficacement votre service, il peut être difficile pour d’autres personnes de l’utiliser.

Maintenir l’intégralité de la base de code en un seul endroit et déployer votre application en un seul endroit présente de nombreux avantages.

• Vous n’aurez besoin de maintenir qu’un seul référentiel et de pouvoir rechercher et trouver facilement toutes les fonctionnalités dans un dossier.
• Vous n’avez pas besoin de lancer cinq services différents localement sur votre ordinateur pour tester une seule fonctionnalité.
• L’intégration de nouveaux ingénieurs est beaucoup plus rapide puisque tout est au même endroit.
• Les tests de charge seront beaucoup plus faciles que les tests de charge de trois services différents.
• Vous pouvez gérer la cohérence de votre application.

La plupart des technologies n’ont pas à « évoluer indépendamment ».

Un monolithe peut être facile à mettre à l’échelle verticalement pendant longtemps. Par exemple, les applications Web classiques peuvent aller très loin en déployant la base de données sur une instance dédiée, en la redimensionnant verticalement et en redimensionnant le reste horizontalement avec des tâches et des files d’attente.

Étant donné que les microservices sont plus rapides à générer que le monolithe complet, vous pouvez être plus réactif en agissant sur les pics. Cependant, les pics de microservices ont également tendance à être plus brutaux que les pics monolithiques.

Supposons que vous ayez dix points de terminaison d’API, et que deux d’entre eux obtiennent à un moment donné un pic de trafic multiplié par 5. Si chaque point de terminaison réside dans un service distinct, vous devez multiplier par 5 la capacité des deux services. Ce n’est peut-être pas un changement trivial, surtout si vous devez le faire rapidement.

Inversement, si tous les terminaux vivent dans un seul monolithe, l’impact sur la charge globale est plus faible et peut être plus facilement absorbé.

À moins qu’un élément de fonctionnalité ne soit lié au processeur, aux E/S ou à la mémoire, l’effort d’évolutivité ne garantit pas la maintenabilité.

La plupart du temps, vos serveurs attendent des choses à faire. L’ajout de « plus de gestionnaires de routes HTTP » à une application ne la videra pas soudainement de toutes ses ressources.

Les monolithes sont préférables si votre intention première est de mettre un nouveau produit sur le marché et de l’itérer rapidement.

Habituellement, vous travaillez dans une architecture monolithique pendant quelques années pour optimiser la vitesse de développement, car connaître le travail du produit est plus important que d’utiliser une pile à la mode.

Vous pouvez toujours extraire les microservices d’un monolithe traditionnel et les réécrire dans n’importe quel langage qui a le plus de sens. Mais vous ne pouvez récupérer le temps que vous avez passé à le faire qu’une fois que vous avez trouvé un produit adapté au marché et une clientèle décente.

D’après Martin Fowler, « presque tous les cas où j’ai entendu parler d’un système construit comme un système de microservices à partir de zéro, il s’est terminé par de sérieux problèmes… vous ne devriez pas démarrer un nouveau projet avec des microservices, même si vous êtes sûr que votre application sera grosse assez pour que cela en vaille la peine.

Les ingénieurs déploient tous les composants d’une architecture monolithique en une seule instance. Les appels de service sont dans le même processus, et aucun RPC. Les tables de données relatives à chaque composant sont généralement déployées dans la même base de données.

Dans une architecture de microservices, chaque composant devient un service autonome maintenu par une équipe spécialisée. Les frontières entre les services sont clairement définies. L’interface utilisateur communique avec plusieurs services. Il convient à la mise à l’échelle de l’entreprise lorsqu’elle a une croissance substantielle à une taille plus grande pour que cela en vaille la peine.

L’architecture de microservice est toujours la référence – presque toutes les entreprises technologiques adoptent une architecture de microservice. Mais maintenant, les entreprises commencent à repenser les avantages et les inconvénients des microservices. Certaines des définitions les plus controversées des microservices sont l’utilisation exclusive d’une base de données et la création de plus de 1000 RPC dans une seule requête client.

Voici les trois raisons pour lesquelles vous n’avez probablement pas besoin d’une architecture de microservices pour votre entreprise :

1. L’architecture monolithique peut également être fiable. Avec la bonne conception, vous devez résoudre les erreurs de réseau d’exécution plutôt que de microservice.
2. L’architecture monolithique est beaucoup plus maintenable que l’architecture de microservice.
3. Avec un meilleur accès à la technologie et un matériel plus sophistiqué, l’évolutivité verticale est moins coûteuse qu’au début des années 2000.

Voici quelques études de cas sur des entreprises qui sont passées du microservice à l’architecture monolithique :

Vous voulez plus de conseils pratiques sur le génie logiciel ?

Abonnez-vous à la newsletter GRATUITE pour obtenir des conseils pratiques chaque semaine et des sujets sur Scala, la programmation fonctionnelle et les systèmes distribués :