Quand un monolithe est la bonne réponse

La question qui sous-tend le chapitre

Les styles de ce chapitre se déploient tous comme une seule unité. Le chapitre 6 pose les mêmes questions à travers un réseau, où chaque appel peut échouer, être lent ou arriver deux fois. Avant de franchir cette ligne, il vaut la peine de se demander directement : quand un monolithe est-il la bonne réponse ? Pendant une bonne partie des années 2010, la réponse par défaut du secteur était « rarement », et de nombreuses équipes ont découpé de jeunes systèmes en microservices parce que de grandes entreprises célèbres l’avaient fait. Une décennie d’expérience a produit une vision plus équilibrée, que présente cette section.

Le mot monolithe demande de la prudence. Comme l’a expliqué la section 5.1, il décrit le déploiement (une seule unité construite, testée et publiée d’un bloc), pas la qualité interne. Un monolithe peut être un système modulaire bien structuré ou une grosse boule de boue, et il en va de même d’un ensemble de services. Beaucoup des problèmes imputés aux monolithes sont en réalité des problèmes de mauvaise modularité, et découper en services un système mal modularisé produit une grosse boule de boue distribuée, ce qui est pire.

MonolithFirst et le surcoût des microservices

En mai 2015, Martin Fowler a décrit le surcoût des microservices (microservice premium) : les microservices entraînent des coûts réels qui leur sont propres (déploiement automatisé de nombreuses unités, supervision, gestion des défaillances partielles, cohérence à terme, API versionnées entre équipes), et ces coûts ralentissent une équipe, sauf si le système est assez complexe pour que les microservices les remboursent. Son conseil était de partir par défaut d’un monolithe unique et bien modularisé, et de ne passer aux microservices que lorsque la complexité l’exige.

Un mois plus tard, dans un article intitulé MonolithFirst (juin 2015), il a ajouté deux observations tirées des projets qu’il avait vus : presque tous les systèmes de microservices réussis avaient commencé comme un monolithe devenu trop gros, puis découpé, et presque tous les systèmes construits en microservices dès le départ avaient fini en grande difficulté. L’une des raisons est qu’il est difficile de trouver de bonnes frontières entre services avant d’avoir compris le domaine, et qu’une mauvaise frontière entre services coûte bien plus cher à déplacer qu’une mauvaise frontière entre modules. Il a décrit plusieurs voies : construire un monolithe et en détacher plus tard des services par les bords ; construire un monolithe délibérément jetable ; ou commencer avec quelques services à gros grain et les découper davantage une fois les frontières stabilisées.

Le monolithe majestueux, et le point de vue opposé

En février 2016, David Heinemeier Hansson, créateur de Ruby on Rails, a publié « The Majestic Monolith » sur le blog Signal v. Noise. Il y décrivait Basecamp, alors construit par une équipe d’une douzaine de programmeurs, comme une application intégrée unique servant des clients web, mobiles, de bureau et e-mail, et soutenait que les petites équipes devraient adopter un monolithe bien conçu plutôt que copier l’architecture d’organisations comptant des milliers d’ingénieurs. Sa phrase clé était Ne distribuez pas vos traitements !, sauf si vous y êtes vraiment obligé.

Les praticiens ne sont pas tous d’accord. Également en juin 2015, Stefan Tilkov a soutenu sur le site de Fowler, dans « Don’t start with a monolith », qu’il est souvent plus difficile que prévu de découper un monolithe après coup, parce que ses parties deviennent fortement couplées au travers des bibliothèques partagées, des objets du domaine et de la base de données. Si le système est manifestement assez grand pour justifier des parties séparées et que le domaine est bien compris, il recommandait de concevoir des sous-systèmes séparés dès le départ. Les deux positions sont moins éloignées qu’il n’y paraît : toutes deux disent que la partie difficile, ce sont les frontières, et un monolithe dont les modules sont imposés dès le premier jour (section 5.3) répond à l’essentiel de la préoccupation de Tilkov.

Les cas réels vont dans les deux sens, mais partagent une leçon. Segment a décrit en 2018 comment l’entreprise avait regroupé plus de 140 petits services en un seul service, après que la charge d’exploitation et la divergence des bibliothèques partagées avaient ralenti la livraison ; Amazon Prime Video a fait passer en 2023 une charge de travail de supervision de composants serverless distribués à un processus unique (voir la section 1.3). À l’inverse, des organisations comptant des centaines d’équipes, comme les cas à grande échelle de la section 6.3, tirent des services une réelle indépendance. La leçon est l’adéquation : le style de déploiement doit correspondre à l’organisation, à la maturité du domaine et aux qualités requises.

Quand un monolithe est la bonne réponse

Une petite équipe. Avec une à quelques équipes, le coût de communication que suppriment les microservices est faible, alors que leur coût d’exploitation est le même que pour une grande organisation. Un monolithe permet à chacun de comprendre et de modifier l’ensemble du système.

Un domaine incertain ou un produit à ses débuts. Tant que vous découvrez encore ce qu’est le produit, les frontières vont bouger. Déplacer une frontière entre modules est une refactorisation ; la déplacer entre services est une migration, avec des données, des API et des déploiements.

De forts besoins de cohérence. Une seule transaction de base de données couvrant les commandes, les paiements et les stocks est simple et correcte dans un monolithe. Entre services, il faut des sagas, des outbox et de la compensation (section 6.7).

Une capacité d’exploitation limitée. Chaque service a besoin de son propre pipeline, de sa supervision, de ses alertes, de ses règles de passage à l’échelle et de connaissances pour l’astreinte. Une équipe sans plateforme pour cela passera son temps sur la tuyauterie.

Des interactions sensibles aux performances. Les appels internes au processus prennent de quelques nanosecondes à quelques microsecondes ; les appels réseau prennent des millisecondes et peuvent échouer. Des interactions bavardes entre parties du domaine coûtent bien moins cher à l’intérieur d’un seul processus.

Dans tous ces cas, la forme recommandée est un monolithe modulaire, et non un monolithe non structuré. Il garde ouverte la possibilité d’extraire des services, comme l’explique la section 5.3.

Faire passer un monolithe à l’échelle

Une croyance répandue veut que les monolithes ne puissent pas passer à l’échelle. Ils vont plus loin que ce dont la plupart des systèmes auront jamais besoin, grâce à l’axe X du cube de scalabilité (scale cube) décrit par Martin Abbott et Michael Fisher (exécuter de nombreuses copies identiques), associé à quelques tactiques classiques. Le chapitre 9 traite chacune en profondeur (section 9.1).

Des répliques horizontales derrière un équilibreur de charge. Exécutez de nombreuses copies identiques de l’application et répartissez les requêtes entre elles. Cela ne fonctionne que si l’application est sans état : les sessions, les fichiers envoyés et les caches doivent se trouver dans des stockages partagés, pour que n’importe quelle réplique puisse servir n’importe quelle requête (section 9.2). Cela apporte aussi de la redondance : la défaillance d’une réplique n’arrête plus le service.

Des répliques en lecture. La plupart des systèmes lisent bien plus qu’ils n’écrivent. Les répliques en lecture de la base de données copient les modifications du primaire et servent des lectures comme l’historique des commandes et les rapports, au prix d’un retard de réplication : une réplique peut avoir une fraction de seconde de retard (section 7.4).

La mise en cache. Les cartes, les pages produits et la configuration changent rarement et sont lues en permanence ; les mettre en cache en mémoire ou dans un cache partagé supprime l’essentiel de la charge sur la base de données (section 7.6). Les ressources statiques vont sur un CDN.

Des processus d’arrière-plan. Le travail lent ou irrégulier (e-mails, factures PDF, imports, versements) est placé dans une file et traité par des processus d’arrière-plan (workers). Les workers exécutent généralement la même base de code avec une commande de démarrage différente : le système reste une seule base de code, mais les rôles web et worker passent à l’échelle séparément (section 9.3).

Des machines plus grosses et le partitionnement. La scalabilité verticale de la base de données est souvent l’étape suivante la plus simple. Pour les très grands systèmes, les données peuvent être partitionnées par client (tenant) ou par région, avec une copie complète du monolithe par partition (l’axe Z du cube de scalabilité). Stack Overflow est un exemple bien connu de la distance que peut parcourir une conception largement monolithique : selon le compte rendu de ses propres ingénieurs, un jour de février 2016, ses équilibreurs de charge ont traité environ 209 millions de requêtes HTTP, l’application principale de questions-réponses (une application multi-tenant unique pour tous ses sites de questions-réponses) tournant sur neuf serveurs web principaux, avec quatre machines SQL Server au service de tout le réseau.

Les signes qu’il est temps de découper

Le découpage doit répondre à des preuves, pas à la mode. Les signes qu’une unité de déploiement est devenue la contrainte sont surtout organisationnels et opérationnels :

La contention entre équipes. Plusieurs équipes modifient le même code et s’attendent les unes les autres ; les conflits de fusion, les réunions de coordination et les builds cassés par d’autres équipes se multiplient à mesure que l’organisation grandit. Si les modules sont déjà bien délimités et que la contention persiste, c’est peut-être l’indépendance de déploiement qui manque.

Les files d’attente de déploiement. Les mises en production sont regroupées en trains parce que chaque modification exige de retester tout le système ; un petit correctif attend des jours derrière des travaux sans rapport ; la modification ratée d’une équipe bloque la mise en production de tout le monde.

Des besoins de passage à l’échelle ou de disponibilité radicalement différents. Un module (par exemple, le suivi des livreurs en temps réel) a besoin de cinquante fois la capacité du reste au moment du pic, ou doit rester disponible quand tout le reste est en panne. Faire passer tout le monolithe à l’échelle pour les besoins d’un seul module devient coûteux.

Un périmètre de sécurité ou de conformité différent. Les données de carte bancaire ou les dossiers médicaux peuvent justifier une unité séparée et étroitement contrôlée, afin de garder le reste du système hors du périmètre d’audit.

Des besoins technologiques différents. Par exemple, un modèle d’apprentissage automatique qu’il vaut mieux servir depuis Python au sein d’un monolithe Java.

Certaines raisons ne sont pas de bonnes raisons à elles seules : « les monolithes, c’est du legacy », l’envie d’utiliser une nouvelle technologie, ou un code lent (qui est un problème de conception que le découpage ne résoudra pas et risque d’aggraver en ajoutant des appels réseau).

Comment découper le moment venu

Découpez de façon incrémentale, un module à la fois, en commençant par celui qui a à la fois la frontière la plus claire et la meilleure raison de partir. Modularisez d’abord si le code n’est pas encore modulaire : extraire un service d’un enchevêtrement entraîne l’enchevêtrement avec lui. Ensuite, extrayez en suivant les contextes délimités (section 5.7) : placez une API réseau devant l’API existante du module, déplacez ses données dans sa propre base de données, remplacez les événements internes au processus par un courtier de messages (message broker) et remplacez toute transaction partagée par des sagas explicites. Dirigez progressivement le trafic vers le nouveau service et conservez l’ancien chemin jusqu’à ce que le nouveau ait fait ses preuves.

C’est l’approche strangler fig (figuier étrangleur) et ses variantes, traitées à la section 11.6. La destination n’est souvent pas « tout en microservices », mais un monolithe avec quelques services extraits là où les preuves l’exigeaient ; l’architecture à base de services de la section 6.2 est un état final courant et pragmatique.

Les évaluations résument les jugements portés dans chaque section et supposent des implémentations typiques. La conception pilotée par le domaine n’apparaît pas comme colonne, car c’est une méthode pour trouver des frontières, que n’importe lequel de ces styles peut utiliser. Les systèmes réels combinent les styles : un monolithe modulaire dont les modules sont hexagonaux à l’intérieur, avec une tâche d’import en tubes et filtres et un micronoyau pour les règles fiscales, est tout à fait normal.