Monolithe ou microservices : décider sans casser le produit

Commencez par un monolithe bien organisé. Les microservices résolvent un problème d’équipes, trop de monde sur le même code, bien avant de résoudre un problème d’échelle. Avec une équipe de cinq personnes, l’architecture distribuée vous coûtera plus qu’elle ne vous apportera.

La conversation sur les microservices démarre généralement du mauvais côté. Quelqu’un lit que Netflix exploite des centaines de services indépendants et en conclut que le système de l’entreprise devrait faire de même. Sauf que Netflix y est arrivé poussé par un problème que la plupart des entreprises n’ont pas : des milliers d’ingénieurs qui ne peuvent pas s’attendre les uns les autres pour livrer une modification.

Le coût que le schéma ne montre jamais

Sur la diapositive, les microservices sont des boîtes nettes reliées par des flèches. En production, chaque flèche est un appel réseau qui peut échouer, traîner ou répondre à moitié.

Quand vous découpez un système en services, vous gagnez l’indépendance de déploiement et vous payez avec :

• Des transactions distribuées. Ce qui était un BEGIN ... COMMIT devient une chorégraphie de compensations. Commande créée, paiement refusé, stock déjà réservé. Et maintenant ?
• Du débogage en plusieurs endroits à la fois. Une requête lente traverse quatre services. Sans traçage distribué, vous cherchez dans le noir.
• L’environnement local. Le nouveau développeur doit démarrer sept services pour tester un écran.
• Le versionnement des contrats. Modifier un champ de réponse cesse d’être un commit et devient une négociation entre équipes.

Ce coût devient rentable lorsque vous avez assez d’équipes pour que le véritable goulot d’étranglement soit la coordination humaine. Avant cela, c’est un impôt pur.

Le monolithe modulaire, que presque personne n’essaie

Il existe une marche entre « tout emmêlé » et « tout séparé », et c’est là que la plupart des systèmes devraient vivre longtemps. Un seul processus, une seule base, mais avec des frontières internes prises au sérieux.

Concrètement, cela veut dire trois choses. Chaque domaine (facturation, catalogue, utilisateurs) vit dans son propre module, avec sa propre couche d’accès aux données. Les modules dialoguent par des interfaces explicites, sans fouiller dans les tables les uns des autres. Et pas de JOIN entre des tables de domaines différents : si vous en avez eu besoin, la frontière est au mauvais endroit.

Construit ainsi, le jour où un module doit devenir un service à part entière, il le peut. Les dépendances sont déjà cartographiées et l’extraction devient l’affaire de quelques jours, pas d’un trimestre.

Les signes concrets que le moment est venu

Pas une impression. Des preuves :

1. Des déploiements qui se bloquent mutuellement. Deux équipes qui attendent régulièrement la file de livraison de l’autre.
2. Des profils de charge très différents. Le module de reporting consomme huit fois plus de processeur que le reste, et vous dimensionnez toute l’application rien que pour lui.
3. Des exigences de disponibilité différentes. Le paiement ne peut pas tomber. Le panneau d’administration interne peut rester dix minutes hors ligne sans le moindre drame.
4. Une technologie incompatible. Une partie du système exige un calcul lourd que le langage principal ne gère pas bien.

Un seul élément de cette liste justifie d’extraire ce morceau précis. Aucun élément de la liste ne justifie de tout réécrire.

Extrayez-en un, pas trente

Le moment venu, le chemin sûr est toujours le même. Choisissez le module à la frontière la plus nette et au couplage le plus faible. Publiez-le comme service. Laissez le monolithe l’appeler. Puis observez ce qui casse, car quelque chose cassera, et il vaut bien mieux le découvrir avec un service qu’avec quinze.

Si la première extraction se passe bien, la deuxième aussi. Si c’est un cauchemar, vous venez d’apprendre quelque chose de précieux au prix le plus bas possible.

Ce qui rapporte davantage avant d’en arriver là

La plupart des systèmes qui « ont besoin de microservices » ont en réalité besoin de choses beaucoup moins prestigieuses.

Des index en base, pour commencer. Je suis sérieux : la majorité des goulots d’étranglement qui deviennent des arguments d’architecture sont une requête sans index. Ensuite du cache au bon endroit, avec une invalidation réfléchie. Une file d’attente pour le travail lourd, qui retire l’envoi d’e-mails, la génération de rapports et le traitement d’images du chemin de la requête utilisateur. Et, en dernier recours, un serveur plus puissant. La montée en charge verticale est démodée, elle est bornée, et elle résout bien plus de cas que la littérature ne veut l’admettre.