Voilà le billet que j'essaie d'écrire depuis six mois. La plateforme sur laquelle je travaille à la banque ship à 300 000 transactions par heure, tient sous la pression réglementaire, et survit au genre de pannes qui auraient mis l'ancien système hors-ligne pour la journée. Elle a aussi 70+ microservices, et je pense que c'est une erreur.
Je veux être prudent ici. L'équipe a construit le bon système. La décomposition n'a pas été faite à l'aveugle. Chaque service correspond à une notion bancaire réelle : souscriptions, rachats, règlement, calcul de NAV, reporting de conformité, accrual de frais, registre des actionnaires. Chaque service se justifiait sur le papier. Mais « justifié sur le papier » n'est pas « porteur ».
Ce que les microservices achètent vraiment
Les microservices répondent à un problème de couplage. C'est tout le pitch. Quand deux morceaux de logique métier changent pour des raisons différentes, à des moments différents, par des équipes différentes, on ne les veut pas dans le même livrable. On les sépare. Déploiements indépendants, modes de panne indépendants, scaling indépendant.
C'est un vrai gain quand le couplage est réel. Le problème, c'est que le couplage est souvent imaginé. Une équipe dessine des frontières de domaine au tableau, s'attache au schéma, et livre sept services là où deux auraient fait le boulot. Chacun de ces services demande ensuite sa pipeline de déploiement, sa base de données, son observabilité, son runbook d'astreinte, sa version légèrement différente de la même logique de retry.
Le coût opérationnel n'est pas linéaire dans le nombre de services. Il est pire que linéaire. Le tracing distribué n'est pas négociable au-delà d'une dizaine de services. La coordination de schémas entre services produit des réunions qui n'existeraient pas dans un monolithe. La complexité CI/CD croît parce qu'on a maintenant des dépendances d'ordre sur les déploiements (« le nouveau service de souscriptions a besoin du nouveau contrat d'accrual d'abord »). Tout ça, c'est de l'ingénierie réelle, et rien de tout ça ne livre du produit.
Ce qui a marché sur la plateforme bancaire
Les contextes bornés autour des opérations bancaires réelles étaient corrects. Souscriptions et rachats ont vraiment des exigences de cohérence, des SLA, des parties prenantes différentes. Les séparer était juste.
Les déploiements indépendants ont réduit le lead time substantiellement. Sans la séparation on serait sur des trains de release hebdomadaires en attendant l'équipe la plus lente. Avec, on déploie quand on est prêt, plusieurs fois par jour sur certains services.
L'isolation des pannes fonctionne. Un service conformité dégradé ne stoppe pas le trading. Ça vaut beaucoup.
Ce qui n'a pas marché
La plupart des découpages à l'intérieur de chaque contexte borné étaient prématurés. Le traitement des souscriptions seul est devenu environ une douzaine de services. Avec le recul, peut-être quatre devaient l'être. Le reste aurait pu rester des modules dans un service souscriptions plus gros, avec la même séparation logique et le quart de l'overhead opérationnel.
On avait des services qui appelaient exactement un autre service, dans une pipeline un-à-un, sans autre consommateur. C'est un appel de fonction qui porte un réseau. On avait des services à moins de 300 lignes de code avec une pipeline de déploiement plus longue à écrire que le service lui-même.
La taxe cachée a été le pire. Ajouter un champ à un événement métier signifiait mettre à jour cinq services dans le bon ordre, coordonner deux équipes, et rouler à travers des états de compatibilité. Dans un monolithe avec le même domaine en modules, c'est une PR.
Ce que je ferais aujourd'hui
Je livrerais le même système avec environ 15 à 20 services. Les contextes bornés restent. Les découpages à l'intérieur s'effondrent. Un service souscriptions contient la pipeline de souscriptions en modules. Un service rachats fait pareil. Le calcul de NAV reste séparé parce que son modèle de cohérence est vraiment différent. La conformité reste séparée parce que le régulateur le veut comme ça.
La leçon se généralise. « Microservices » est une réponse au couplage, pas un style architectural. Par défaut, moins de services, plus gros. On découpe quand la douleur du couplage l'exige, pas quand le tableau a l'air joli.
L'heuristique la plus propre que j'ai trouvée : un service doit être assez petit pour qu'une personne tienne ses responsabilités dans sa tête, et assez gros pour qu'on n'ait pas besoin de coordonner une release sur plusieurs services pour changer un seul comportement métier. À ce test, la moitié de ce qu'on a livré était trop petit.
Si je recommençais demain, je n'aurais aucune honte à livrer un système à 15 services pour la même charge. L'équipe serait plus rapide. La facture serait plus petite. Le système atteindrait toujours 300 000 transactions par heure. On passerait juste moins de temps à garder la lumière allumée.