Fil de DHH (@dhh)

Les microservices constituent la plus grande arnaque de confiance du secteur du logiciel. Ils persuadent les petites équipes qu'elles « voient grand », tout en les privant systématiquement de toute capacité d'action. Ils flattent l'ambition en instrumentalisant l'insécurité : si vous ne gérez pas une constellation de services, êtes-vous vraiment une entreprise ? Qu'importe que cette architecture ait été inventée pour pallier les dysfonctionnements organisationnels à l'échelle planétaire. Aujourd'hui, elle est prescrite à des équipes qui partagent encore un canal Slack et une table pour déjeuner. Les petites équipes fonctionnent grâce à un contexte partagé. C'est leur atout majeur. Chacun peut raisonner de bout en bout. Chacun peut tout modifier. Les microservices anéantissent cet avantage dès le premier contact. Ils remplacent la compréhension partagée par une ignorance distribuée. Plus personne ne possède l'ensemble. Chacun possède une partie. Le système devient quelque chose qui arrive à l'équipe, plutôt qu'un élément qu'elle comprend activement. Ce n'est pas de la sophistication. C'est de l'abdication. S'ensuit une véritable farce opérationnelle. Chaque service exige son propre pipeline, ses secrets, ses alertes, ses indicateurs, ses tableaux de bord, ses autorisations, ses sauvegardes et ses rituels d'apaisement. On ne « déploie » plus, on synchronise une flotte. Un simple bug nécessite désormais une analyse approfondie de plusieurs services. La mise en production d'une nouvelle fonctionnalité devient un exercice de coordination transfrontalière, franchissant des frontières artificielles que vous avez inventées sans raison. Vous n'avez pas simplifié votre système ; vous l'avez détruit et vous avez baptisé ce chaos « architecture ». Les microservices ont aussi le don d'enfermer l'incompétence. On est contraint de définir des API avant même de maîtriser son propre métier. Les suppositions deviennent des contrats. Les mauvaises idées se transforment en dépendances permanentes. Chaque erreur initiale se propage à travers le réseau. Dans une architecture monolithique, une erreur de raisonnement est corrigée par une refactorisation. Dans les microservices, une erreur de raisonnement devient infrastructure. On ne se contente pas de la regretter : on l'héberge, on la versionne et on la surveille. L'affirmation selon laquelle les architectures monolithiques ne sont pas évolutives est l'un des plus gros mensonges du folklore de l'ingénierie moderne. Ce qui ne l'est pas, c'est le chaos. Ce qui ne l'est pas non plus, c'est le déguisation des processus. Ce qui ne l'est pas, c'est de se prendre pour Netflix en livrant une application CRUD améliorée. Les architectures monolithiques s'adaptent parfaitement lorsque les équipes font preuve de discipline, de tests et de retenue. Mais la retenue n'est pas à la mode, et l'ennui n'est pas propice aux conférences. Les microservices pour les petites équipes ne constituent pas une erreur technique, mais un échec philosophique. Ils révèlent clairement que l'équipe ne se fait pas confiance pour comprendre son propre système. Ils substituent des protocoles à la responsabilité et des intergiciels à la dynamique. Au lieu d'assurer la pérennité de votre projet, vous vous retrouvez avec un ralentissement permanent. Et lorsque vous atteindrez enfin la taille critique qui justifierait ce cirque, votre rapidité, votre clarté et votre intuition produit auront déjà disparu.