Coordination trop chère
Certaines features demandaient plusieurs pull requests, plusieurs releases séquencées et des contrats inter-services à surveiller.
Étude de cas
Retail : réduire un système distribué avant qu'il ne ralentisse la delivery
Une équipe de quatre développeurs maintenait sept microservices, plusieurs pipelines, un broker et trop de coordination pour le niveau réel de trafic et d'organisation.
La mission a transformé une architecture distribuée disproportionnée en monolithe modulaire exploitable : une CI, un backend déployable, le frontend servi en assets statiques, et une migration progressive sans big bang.
Contexte
Une architecture devenue plus lourde que le produit
Le choix microservices avait été fait avant que le produit, le trafic et l'organisation ne le justifient. Chaque feature traversait plusieurs services, plusieurs logs, plusieurs pipelines et plusieurs jeux de variables.
Contraintes principales
Footprint runtime disproportionné
Avec staging, UAT et production, la règle des 3 pods minimum par service multipliait le coût et l'exploitation.
Migration sans interruption
Le produit était live. La cible devait être atteinte sans freeze, sans big bang et avec un chemin de rollback clair.
Décisions
Les choix qui ont rendu la simplification possible
Le but n'était pas de nier les microservices. Le but était de remettre la distribution au bon niveau pour la taille de l'équipe et les contraintes produit.
- 01
Migrer par groupes de routes
Les préfixes HTTP existants ont servi d'unité de migration. Une route pouvait basculer vers le handler local sans changer l'interface externe.
- 02
Garder un rollback opérationnel
Chaque bascule était protégée par feature flag : trafic local si le flag était actif, service externe sinon.
- 03
Conserver des frontières internes
La cible était un monolithe modulaire, pas un bloc opaque. Les responsabilités métier devaient rester lisibles dans le code.
- 04
Réduire le déploiement au strict utile
Le frontend a été servi comme assets statiques depuis le backend, avec une seule CI et un seul artefact à opérer.
Delivery
Une migration progressive, une route à la fois
La trajectoire a été pensée pour que l'équipe continue à livrer pendant la transformation. Le travail combinait architecture, implémentation, exploitation et décommissioning.
Réimplémentation locale
La logique du service était ramenée dans l'application principale derrière la même interface HTTP.
Bascule contrôlée
Le flag permettait de tester en production, d'observer, puis de rendre la bascule permanente.
Decommissioning
Une fois le flux stabilisé, l'appel réseau était supprimé, la queue drainée, puis le service retiré.
Impact
Ce que la simplification a changé
L'effet principal a été de retirer une taxe distribuée que l'organisation ne récupérait pas en autonomie ou en scalabilité.
- 7 -> 1
- Les changements multi-services sont revenus vers un seul flux de pull request et de déploiement.
- 21 -> 3
- Le minimum de pods par environnement a été réduit, avec staging, UAT et production concernés.
- 1 setup
- Le développement local est passé d'une orchestration de plusieurs processus à un setup principal.
- Moins de coût
- Le runtime, la coordination et l'exploitation ont été ramenés à un niveau proportionné au trafic.
Stack
Technologies et sujets couverts
La valeur ne venait pas d'une technologie unique, mais de l'alignement entre architecture applicative, runtime et delivery.
Leçon
La distribution doit payer son loyer.
Un système distribué est justifié quand il résout un vrai problème d'organisation, de charge ou d'isolation. Sinon, il transforme chaque feature en coordination inutile.