Les réécritures big-bang finissent rarement. Le motif « strangler fig » garde le monolithe en ligne pendant que de nouvelles capacités poussent en périphérie, routées par une façade fine (API gateway, reverse proxy ou routeur de fonctionnalités) qui envoie le trafic vers l’ancien ou le nouveau.
Commencez par une couture déjà isolée logiquement—reporting, notifications, tarification—même si le code vit encore dans un seul dépôt. Extrayez derrière une interface que le monolithe appelle en synchrone, puis basculez vers HTTP ou des événements asynchrones une fois le service stable.
Les données sont le point dur. Préférez les réplicas en lecture et la capture de changements pour les lectures lourdes ; pour les écritures, anticipez transactions de compensation et clés d’idempotence. Les phases de double écriture sont risquées—gardez-les courtes et instrumentées.
Gardez un rythme de déploiement : chaque extraction doit être livrable derrière des drapeaux. Lancez en obscurité les nouveaux chemins, comparez latence et budgets d’erreur, puis augmentez progressivement le pourcentage de trafic.
La topologie des équipes suit : une équipe slice verticale possède le service extrait de bout en bout pendant que l’équipe monolithe maintient les adaptateurs de compatibilité jusqu’au basculement. Standards de code et observabilité partagés réduisent les surprises d’intégration.
Sachez arrêter d’étrangler : tout module ne mérite pas un service. Parfois des frontières de monolithe modulaire et une propriété claire suffisent jusqu’à ce que la charge ou l’échelle organisationnelle impose une séparation plus fine.
À lire aussi : conseil DevOps, études de cas et ressources.