Quand les microservices font plus de mal que de bien
Pourquoi les petites équipes perdent en vitesse avec des microservices prématurés, et quand un monolithe modulaire est une meilleure architecture.
Les microservices sont souvent présentés comme la voie par défaut vers l’échelle, si bien que les équipes early-stage copient l’architecture d’entreprises opérant dans des conditions totalement différentes. En pratique, cela signifie souvent hériter de la complexité des systèmes distribués bien avant d’avoir l’organisation nécessaire pour la gérer.
Les microservices résolvent autant des problèmes de scalabilité organisationnelle que des problèmes purement techniques. Si une équipe de cinq personnes découpe un MVP en dix services, elle crée des pipelines de déploiement, des contrats inter-services, des exigences d’observabilité et des modes de panne qu’une petite équipe devra maintenir au quotidien.
Les coûts cachés apparaissent vite. Les appels de fonction deviennent des appels réseau, avec latence, retries et risques de panne. La cohérence des données devient plus difficile parce que les transactions atomiques ne vivent plus dans une seule frontière de base de données. Et le debugging ralentit parce qu’il faut suivre la requête à travers plusieurs services.
La surcharge opérationnelle augmente aussi. Les équipes ont besoin de meilleurs logs, de tracing distribué, de service discovery, de gestion des secrets et de pratiques de réponse aux incidents juste pour maintenir le niveau actuel. Les factures cloud montent parce que la plateforme paie de la coordination, pas uniquement de la valeur métier.
Pour la plupart des équipes, un monolithe bien structuré constitue un meilleur point de départ. Une base de code modulaire guidée par le Domain-Driven Design permet de séparer les responsabilités sans transformer chaque frontière logique en frontière réseau.
Un service ne devrait être extrait que lorsqu’il a réellement des besoins de déploiement, d’ownership ou de scalabilité différents du reste de l’application. Tant que ce n’est pas le cas, l’architecture la plus rapide est souvent celle qui garde le système simple, et non celle qui paraît la plus distribuée sur un schéma.