Migration monolithe vers microservices : la méthode étape par étape
Obtenez un résumé intelligent et des insights personnalisés
La migration monolithe microservices consiste à extraire progressivement des fonctionnalités d’une application unique pour les transformer en services indépendants. La méthode la plus fiable est le Strangler Fig Pattern. Elle a notamment été popularisée par Martin Fowler en 2004. Son avantage ? Elle évite le big bang et permet de garder l’application en production pendant toute la transition.
Votre équipe passe plus de temps à contourner le monolithe qu’à livrer des fonctionnalités ? Chaque déploiement bloque les autres ? Le moindre changement fait craindre une régression ailleurs ? Voici les signaux qui justifient une migration. Vous pouvez notamment utiliser la méthode du Strangler Fig Pattern pour ce faire. Il suffit de respecter les étapes concrètes pour découper votre premier service. AquilApp accompagne vos équipes techniques sur ce type de projet depuis plusieurs années.
Votre monolithe est-il vraiment un problème ?
Un monolithe n’est pas un défaut de conception en soi. D’ailleurs, beaucoup d’entreprises performantes tournent encore sur une architecture monolithique bien structurée. Le problème est le monolithe devenu un « big ball of mud ». Autrement dit, vous avez un code couplé sans frontières claires entre les domaines métier.
Pourtant, un monolithe bien conçu concentre l’essentiel de ses fonctionnalités dans un seul processus. Le code y est fortement couplé. Ainsi, cette architecture reste efficace tant que les équipes restent petites et le périmètre fonctionnel limité. Néanmoins, elle devient un frein quand plusieurs équipes doivent livrer en parallèle sur la même base de code.
Avant de migrer, on distingue donc deux cas.
- Le monolithe modulaire, bien architecturé, qui peut encore vivre plusieurs années.
- Le monolithe enchevêtré, où toute modification devient risquée.
Seul le second justifie une migration monolithe microservices.
Quels sont les 5 signaux qui indiquent qu’il est temps de migrer ?
Cinq signaux concrets doivent alerter une équipe technique :
- Les déploiements se bloquent mutuellement : une équipe ne peut pas livrer une fonctionnalité sans attendre la release d’une autre équipe sur le même pipeline.
- Le scaling devient impossible à cibler : une seule fonctionnalité sature les ressources, mais toute l’application doit être mise à l’échelle.
- L’onboarding des développeurs prend des semaines : la base de code est trop large et trop couplée pour être comprise rapidement.
- Les équipes n’ont plus de frontières claires : plusieurs équipes modifient les mêmes fichiers, ce qui crée des conflits permanents.
- Un incident isolé provoque des pannes en cascade : un bug sur un module fait tomber des fonctionnalités qui n’ont aucun lien métier avec lui.
Un seul de ces signaux est présent ? La migration vers le micro-services n’est pas forcément urgente. Cependant, si trois signaux ou plus s’accumulent, le coût de l’inaction dépasse généralement le coût de la migration.
Quand ne pas migrer ?
Il y a trois cas où la migration vers les microservices ajoute de la complexité et laisse peu de bénéfices. Exemple :
- Une équipe de moins de dix développeurs
- Un produit encore en phase de recherche de marché
- Ou un monolithe modulaire sans douleur de déploiement.
Mieux vaut structurer le monolithe en modules avant d’envisager une décomposition complète.
En effet, les microservices résolvent des problèmes d’organisation et de scaling. Ce n’est pas le cas du manque de tests ou une dette technique généralisée. Migrer une architecture mal testée vers des microservices revient souvent à multiplier le même problème par le nombre de services créés. Notre conseil : faites un audit de dette technique préalable pour éviter cette erreur de diagnostic.
En outre, le coût caché d’un monolithe bloquant ne se limite pas au temps de développement perdu. Il se répercute sur :
- Le time-to-market
- La capacité à recruter des profils seniors qui refusent de travailler sur une base de code jugée trop rigide.
- Et, la confiance des équipes métier dans la capacité de l’IT à livrer dans les délais annoncés.
Ces effets indirects pèsent souvent plus lourd que le coût direct d’une migration bien menée.
Comment réussir votre Strangler Fig Pattern : la migration progressive sans big bang
Le Strangler Fig Pattern est une stratégie de migration monolithe microservices. Il consiste notamment à construire les nouveaux services en parallèle du monolithe. Puis, il suffit de rediriger le trafic vers eux domaine par domaine, jusqu’à ce que l’ancien système puisse être retiré.
Le nom vient du figuier étrangleur. C’est une plante qui germe dans la canopée d’un arbre hôte et grandit lentement autour de son tronc, jusqu’à devenir autonome et remplacer l’arbre d’origine.
Martin Fowler a formalisé ce terme en 2004. Il s’est inspiré de la croissance de cette plante observée en Australie. Le principe central reste simple : au lieu de remplacer tout le système en une fois, on extrait et remplace des morceaux de manière incrémentale. Pendant ce temps, le reste du système continue de fonctionner.
Pourquoi le big bang échoue ?
Remplacer entièrement un monolithe en réécrivant ou en refactorisant tout le code d’un coup est un projet risqué. En effet, cela entraîne une forte perturbation de l’activité. Pendant la réécriture, il devient souvent impossible d’ajouter de nouvelles fonctionnalités. Ce qui gèle le produit pendant des mois.
Une enquête O’Reilly menée auprès de 1 502 professionnels de la technique confirme cette difficulté : la décomposition d’une application monolithique en microservices figure parmi les principaux obstacles cités. C’est juste derrière les freins culturels internes, et la complexité de gestion. Une migration en big bang cumule ces deux risques en une seule opération, sans filet de sécurité.
| Critère | Migration big bang | Strangler Fig Pattern |
|---|---|---|
| Risque business | Élevé : coupure ou régression possible sur tout le produit | Faible : un seul domaine à la fois est exposé |
| Continuité des livraisons | Gelée pendant la réécriture | Maintenue, nouvelles fonctionnalités possibles en parallèle |
| Délai avant premier résultat | Long, tout doit être terminé avant mise en production | Court, chaque service extrait est livré indépendamment |
| Effort de rollback | Très coûteux, retour en arrière difficile | Simple, il suffit de router à nouveau vers le monolithe |
Source : synthèse AquilApp d’après AWS Prescriptive Guidance et Martin Fowler, Strangler Fig Application.
Comment découper votre premier service étape par étape ?
Le choix du premier service à extraire conditionne le succès de toute la migration monolithe microservices. Ne commencez jamais par le module le plus critique.
- Cartographier les domaines métier : identifiez les frontières fonctionnelles du monolithe. Cla peut être le catalogue, les commandes, la facturation ou les utilisateurs. Cette cartographie s’appuie sur les principes du Domain-Driven Design.
- Choisir un candidat à faible risque et à forte valeur : un module peu couplé aux autres, testé, et dont l’extraction apporte un bénéfice visible (montée en charge, vélocité d’équipe).
- Mettre en place une façade de routage : un reverse proxy ou une passerelle API intercepte les requêtes et décide de les envoyer vers le monolithe ou vers le nouveau service.
- Développer le service en parallèle du monolithe : le monolithe continue de servir la fonctionnalité pendant que le nouveau service est construit et testé.
- Basculer le trafic progressivement : redirigez d’abord un petit pourcentage des requêtes, puis augmentez si aucune régression n’apparaît.
- Retirer le code devenu obsolète : une fois le service stabilisé, supprimez la fonctionnalité correspondante dans le monolithe.
Répétez ensuite ce cycle domaine par domaine, jusqu’à ce que le monolithe ne porte plus que les fonctionnalités qui n’ont pas besoin d’être isolées.
Quels sont les trois pièges à éviter lors du premier découpage ?
Le premier piège consiste à choisir un service trop ambitieux pour valider la méthode. Un premier essai doit rester modeste, quitte à sembler peu spectaculaire.
Ensuite, ne négligez pas le monitoring. Sans observabilité dédiée au nouveau service, une régression peut passer inaperçue plusieurs jours.
Enfin, n’oubliez pas de revoir les contrats d’interface avec le reste du système quand vous allez extraire le service. De quoi recréer un couplage fort malgré la séparation technique.
Sur le plan organisationnel, chaque service extrait gagne à avoir un propriétaire clair. Cela peut être une équipe ou un binôme senior. Cette clarté évite qu’un service nouvellement créé retombe dans le même flou de responsabilités que le monolithe d’origine. C’est aussi ce facteur organisationnel qui explique la majorité des migrations réussies.
Consultez aussi notre autre article pour savoir comment conteneuriser vos microservices avec Docker et Kubernetes.
Comment gérer votre base de données pendant la migration ?
La base de données est le point le plus sous-estimé d’une migration vers les microservices. Un monolithe partage en général une seule base entre tous ses modules. Un microservice doit, à terme, posséder ses propres données.
Extraire le code sans prendre les données crée un couplage caché. Donc, le nouveau service et le monolithe continuent d’écrire dans les mêmes tables. Ce qui annule une partie des bénéfices de la migration. Heureusement, trois approches permettent de gérer cette transition :
- Le Change Data Capture (CDC) : les modifications de la base du monolithe sont capturées et propagées vers la base du nouveau service, sans modifier le code applicatif existant.
- Le dual-write temporaire : le service écrit à la fois dans l’ancienne et la nouvelle base pendant la phase de transition, avant de basculer complètement.
- La séparation progressive du schéma : isolez d’abord les tables du domaine concerné dans un schéma distinct, avant de les migrer vers une base physiquement séparée.
Évitez d’extraire un service applicatif tout en laissant sa base de données couplée au monolithe. Le service semble indépendant. Cependant, le reste sera bloqué par les mêmes contraintes de déploiement que l’ancien système. Nous détaillons davantage les techniques pour automatiser le déploiement chaque micro-service dans un autre article.
Prenons un exemple concret. Un module de facturation extrait du monolithe continue de lire la table « clients » directement dans la base partagée. Toute modification du schéma de cette table par l’équipe monolithe casse alors le service de facturation, sans que personne ne l’ait anticipé. Quelle est donc la bonne pratique ? Il suffit d’exposer les données via une API ou un flux d’événements, jamais via un accès direct à la base d’un autre service.
Évidemment, la séparation des données prend souvent plus de temps que l’extraction du code applicatif. Elle mérite d’être planifiée dès la phase de cartographie des domaines, et non traitée comme un correctif de fin de projet.
Pour plus de conseils, lisez aussi notre autre article : refactoring, quand et comment réécrire votre code ?
Comment gérer le timeline de votre migration monolithe microservices ?
Une migration par Strangler Fig Pattern se mesure en mois et pas en semaines. Cela commence dès que le monolithe dépasse quelques dizaines de milliers de lignes de code.
| Taille du monolithe | Délai réaliste | Effort équipe estimé |
|---|---|---|
| Petit (moins de 5 domaines métier) | 3 à 6 mois | 1 à 2 développeurs dédiés |
| Moyen (5 à 10 domaines métier) | 6 à 12 mois | 2 à 4 développeurs dédiés |
| Grand (plus de 10 domaines métier) | 12 à 24 mois | Une équipe dédiée par domaine extrait |
Source : estimations AquilApp basées sur les retours de projets clients et les patterns documentés par AWS et Martin Fowler.
Qu’en est-il alors du retour sur investissement d’une migration ? Il ne se mesure pas uniquement en coûts d’infrastructure. Prenez d’abord en compte la vélocité. Exemple, les équipes qui possèdent l’intégralité du cycle de vie de leur service, du build au déploiement, réussissent leur migration avec un taux 18 % supérieur aux autres, selon l’enquête O’Reilly citée plus haut. Ce chiffre confirme qu’une migration technique réussie repose autant sur l’organisation des équipes que sur l’architecture choisie.
Pour aller plus loin, lisez aussi notre autre article sur la communication event-driven entre microservices.
FAQ sur la migration d'une architecture monolithe vers les microservices
* **Monolithe de taille modeste :** Compter environ **3 à 6 mois** pour extraire quelques domaines fonctionnels ciblés.
* **Système complexe (dizaine de domaines métier) :** La transition s’étale généralement sur **12 à 24 mois**.
* **Principe :** De nouveaux microservices sont développés en périphérie de l’application existante pour prendre en charge des domaines métier spécifiques.
* **Routage du trafic :** Une passerelle (*API Gateway* ou proxy) intercepte les requêtes et redirige progressivement le flux vers les nouveaux microservices au fur et à mesure de leur mise en production, jusqu’à ce que le monolithe soit entièrement « étranglé » et puisse être éteint.
* **Monolithe modulaire (*Modular Monolith*) :** Un monolithe bien structuré avec une séparation claire des domaines métier reste souvent la solution la plus efficace, la plus économique et la plus simple à opérer pour une majorité d’entreprises.
* **Arbitrage :** La bascule vers les microservices ne se justifie que si vous faites face à des enjeux majeurs de scalabilité asymétrique, à des contraintes de déploiement indépendant pour de multiples équipes, ou à des besoins d’isolation forte.
* **Extraction ciblée :** L’équipe identifie et extrait en priorité les modules peu couplés ou ceux nécessitant des évolutions fréquentes.
* **Cœxistence :** Le code historique continue de tourner en production pour les fonctionnalités non encore migrées, ce qui limite considérablement les risques opérationnels et financiers.
Conclusion
Une migration monolithe microservices réussie ne se joue pas sur la technologie choisie. Il est surtout question de méthode. Le Strangler Fig Pattern permet notamment d’avancer domaine par domaine, sans geler les livraisons ni prendre le risque d’un big bang.
Dans tous les cas, le point de départ reste toujours le même. Cartographiez les domaines métier. Ensuite, choisissez un premier candidat à faible risque. Enfin, traitez la base de données comme un sujet à part entière plutôt que comme un détail technique.
Avant de vous lancer, une architecture modulaire peut constituer une étape intermédiaire utile, notamment si votre monolithe n’a pas encore de frontières claires entre ses domaines.
AquilApp accompagne les équipes techniques dans l’audit de leur dette technique et la construction d’un plan de migration réaliste. Demandez un audit de votre architecture.
