Ne tombez pas dans le piège des « microservices, c'est cool » et sachez quand vous en tenir à un monolithe

Les monolithes et les microservices sont deux approches de base pour la création d'applications. Certains les considèrent respectivement comme héritées et modernes. Mais ce n'est pas tout à fait vrai. Choisir entre les deux est une question très complexe, les deux ayant leurs avantages et leurs inconvénients.

La plupart des nouvelles applications n'ont pas besoin d'être des microservices dès le départ. Il est plus rapide, plus simple et moins cher de commencer en tant que monolithe et de passer aux microservices plus tard si vous le jugez bénéfique.

Au fil du temps, les applications monolithiques devenant de moins en moins maintenables, certaines équipes décident que la seule façon de résoudre le problème est de commencer à refactoriser en divisant leur application en microservices. D'autres équipes prennent cette décision simplement parce que « les microservices sont cool ». Ce processus prend beaucoup de temps et entraîne parfois encore plus de frais de maintenance. Avant de vous lancer, il est essentiel d'examiner attentivement tous les avantages et les inconvénients et de vous assurer que vous avez atteint les limites actuelles de votre architecture monolithique. Et n'oubliez pas qu'il est plus facile de casser que de construire.

Dans cet article, nous n'allons pas comparer les monolithes aux microservices. Nous allons plutôt discuter de considérations, de modèles et de principes qui vous aideront à :

• tirez le meilleur parti de votre monolithe actuel et préparez-le potentiellement à passer aux microservices ;
• assurer une migration transparente du monolithe vers les microservices ;
• comprendre ce qui peut encore changer avec la migration des microservices.

Monolithe modulaire

La première chose à faire est de regarder la structure de votre projet. Si vous n'avez pas de modules, je vous recommande fortement de les considérer. Ils ne vous obligent pas à changer votre architecture en microservices (ce qui est une bonne chose car nous voulons éviter toute maintenance correspondante) mais en tirent de nombreux avantages.

En fonction de l'outil d'automatisation de la création de votre projet (par exemple, Maven, Gradle ou autre), vous pouvez diviser votre projet en modules distincts et indépendants. Certains modules peuvent être communs à d'autres, tandis que d'autres peuvent encapsuler des domaines de domaine spécifiques ou être spécifiques à une fonctionnalité, apportant des fonctionnalités indépendantes à votre application.

Cela vous apportera les avantages suivants :

1. Parties découplées de votre application.
2. Les fonctionnalités peuvent être développées indépendamment, minimisant ainsi les conflits.
3. Il est beaucoup plus facile d'intégrer de nouvelles personnes car elles n'ont pas besoin de se plonger dans l'ensemble du projet ; au lieu de cela, elles peuvent commencer à partir de parties isolées.
4. Tests améliorés, car vous pouvez désormais tester chaque module séparément.
5. Si vous devez éventuellement migrer vers des microservices, vous disposez d’une base très solide pour cela.

Comme vous pouvez le constater, le monolithe modulaire est le moyen de tirer le meilleur parti des deux mondes. C’est comme exécuter des microservices indépendants dans un seul monolithe, mais en évitant les frais généraux des microservices collatéraux. L’une des limitations que vous pouvez rencontrer est de ne pas pouvoir faire évoluer différents modules indépendamment. Vous aurez autant d’instances monolithiques que le module le plus chargé l’exige, ce qui peut entraîner une consommation excessive de ressources. L’autre inconvénient réside dans les limitations liées à l’utilisation de différentes technologies. Par exemple, vous ne pouvez pas mélanger Java, Golang et Python dans un monolithe modulaire, vous êtes donc obligé de vous en tenir à une seule technologie (ce qui, généralement, ne pose pas de problème).

Le modèle de figue étrangleuse

Pensez au modèle Strangler Fig. Il tire son nom d'un arbre qui s'enroule autour de son hôte et le remplace à terme. De même, le modèle suggère de remplacer les parties d'une application héritée par de nouveaux services, une par une, en modernisant un ancien système sans provoquer de perturbations significatives.

Au lieu de tenter une refonte risquée et globale, vous mettez à jour le système pièce par pièce. Cette méthode est utile lorsqu'il s'agit de monolithes volumineux et complexes qui sont trop difficiles à remplacer en une seule fois. En adoptant le modèle Strangler Fig, les équipes peuvent progressivement éliminer l'ancien système tout en favorisant la croissance du nouveau, en minimisant les risques et en garantissant une création de valeur continue.

Pour mettre en œuvre le modèle Strangler Fig, vous devez suivre trois étapes :

1. Transformation. Ici, vous identifiez la partie à extraire du monolithe et l'implémentez en tant que microservice distinct. Réécrivez cette partie à l'aide de technologies modernes et résolvez les problèmes de l'implémentation précédente. Saisissez votre chance de faire mieux.
2. Coexister. Lorsqu'un nouveau microservice est prêt pour la production, vous l'exécutez dans votre infrastructure, en conservant l'implémentation existante. Vous répartissez le trafic dans une certaine proportion, en déplaçant progressivement de plus en plus de trafic vers la nouvelle implémentation, mais vous disposez toujours de votre version précédente en tant que restauration.
3. Éliminer. Après un certain temps, lorsque vous estimez que votre nouveau microservice est suffisamment fiable, déplacez tout le trafic vers le nouveau microservice et supprimez l'ancien.

En suivant ces trois étapes, vous décomposerez progressivement un monolithe en microservices.

Les principaux avantages de l'utilisation du modèle Strangler Fig sont :

• Migration progressive. Plutôt que de vous lancer dans une refonte complète du système, qui vous prendra du temps, sera écrasante et risquée. Le modèle vous permet d'effectuer la transition étape par étape. Vous pouvez mettre à jour votre système lentement et synchroniser cette transformation avec les plans de développement des fonctionnalités. Par exemple, vous pouvez trouver une partie du monolithe qui sera sérieusement affectée par le développement de certaines fonctionnalités et la choisir comme candidate à la migration des microservices.
• Livraison continue. Cet avantage découle de l'affirmation précédente. Le processus de modernisation n'empêche pas votre équipe de fournir en permanence de nouvelles fonctionnalités. Pendant qu'une équipe développe de nouvelles fonctionnalités, une autre refactorise des modules indépendants.
• Atténuation des risques. Le modèle Strangler Fig aide l'équipe à se concentrer sur la modernisation de parties spécifiques du système. Cette concentration permet à l'équipe d'accorder une plus grande attention aux détails dans des domaines spécifiques, de détecter les problèmes potentiels plus tôt et de minimiser l'impact global sur l'application.

Enjeux et considérations

Lorsque vous appliquez le modèle Strangler Fig, vous devez planifier soigneusement la stratégie de migration. Cela comprend l'identification des composants à remplacer en premier, la garantie d'une intégration appropriée entre les anciens et les nouveaux composants et le maintien de modèles de données cohérents. Les équipes doivent également établir des canaux de communication clairs et des systèmes de surveillance pour suivre la progression et l'impact de chaque remplacement.

Répercussions de la migration des microservices

Comme nous l'avons vu précédemment, la transition vers les microservices présente des avantages. Cependant, elle rend également de nombreuses autres choses plus difficiles et plus coûteuses.

Par exemple, les équipes d'assurance qualité et de développement peuvent être confrontées à une situation dans laquelle elles ne peuvent plus effectuer de tests sur des machines locales, car la capacité à exécuter plusieurs microservices localement est limitée. Ou vos journaux peuvent devenir moins pertinents car, au lieu d'un service traitant un seul flux, plusieurs services le traitent désormais. Par conséquent, pour afficher la séquence de journaux complète, vous devez mettre en œuvre une instrumentation et un traçage appropriés.

Discutons de quelques aspects cruciaux que vous devriez prendre en compte et peut-être planifier avant le début de votre transformation en microservices.

Déploiement et infrastructure

Les monolithes et les microservices ont des exigences d'infrastructure minimales différentes.

Lorsque vous exécutez une application monolithique, vous pouvez généralement conserver une infrastructure plus simple. Des options telles que des machines virtuelles ou des solutions PaaS (telles qu'AWS EC2) suffiront. En outre, vous pouvez gérer une grande partie de la mise à l'échelle, de la configuration, des mises à niveau et de la surveillance manuellement ou avec des outils simples. Par conséquent, vous pouvez éviter les configurations d'infrastructure complexes et vous appuyer sur des développeurs ou des ingénieurs de support sans avoir besoin d'une expertise DevOps approfondie.

Cependant, l'adoption d'une architecture de microservices modifie cette dynamique. À mesure que le nombre de services augmente, une approche manuelle et pratique devient rapidement impraticable. Pour orchestrer, faire évoluer et gérer efficacement plusieurs services, vous aurez besoin de plateformes spécialisées comme Kubernetes ou, au moins, d'un service de conteneur géré, ce qui introduit une nouvelle couche de complexité et d'exigences opérationnelles.

Couche de plate-forme

La maintenance d'une application monolithique est relativement simple. Si une CVE survient, vous mettez à jour la dépendance concernée à un seul endroit. Vous avez besoin de normaliser la communication des services externes ? Implémentez un wrapper unique et réutilisez-le dans toute la base de code.

Dans un environnement de microservices, ces tâches simples deviennent beaucoup plus complexes. Ce qui était auparavant trivial implique désormais de coordonner les changements entre plusieurs services indépendants, chacun avec son cycle de vie et ses dépendances. Cette complexité accrue augmente les coûts en termes de temps et de ressources. Et la situation s'aggrave lorsque vous avez de nombreuses équipes et de nombreux services différents.

Par conséquent, de nombreuses organisations introduisent une couche de plateforme dédiée, généralement gérée par une équipe de plateforme. L’objectif est de créer une base dont tous les microservices peuvent hériter : gestion des dépendances communes, mise en œuvre de modèles standardisés et fourniture de wrappers prêts à l’emploi. En unifiant ces éléments au niveau de la plateforme, vous simplifiez considérablement la maintenance et favorisez la cohérence sur l’ensemble du système.

Conclusion

Diviser un monolithe en microservices est une transformation architecturale importante qui nécessite une réflexion et une planification minutieuses.

Dans cet article, nous avons discuté des étapes que vous pouvez suivre pour vous y préparer et mener à bien le processus en douceur. Le fait de vous en tenir au modèle Strangler Fig vous permettra de suivre le processus incrémentiel et d'assurer la stabilité du système tout au long de la transformation. En outre, le monolithe modulaire peut non seulement être une étape de préparation utile, mais peut également apporter des avantages qui peuvent vous inciter à reconsidérer votre décision de transformation des microservices et à éviter la complexité opérationnelle correspondante.