Microservices vs Monolithe : est-ce une erreur en 2024 ?

Totalement d'accord. Le syndrome du "Google-scale" est réel. Les gens déploient du Kubernetes et du Kafka dès le premier jour pour un CRUD basique. C'est du suicide financier.

Je nuance : le monolithe peut devenir un enfer de déploiement si tu as 50 devs dessus. Le découplage par service permet d'isoler les cycles de release. C'est une question d'organisation humaine plus que technique.

Le problème, c'est la dette technique. Dans un monolithe, tout le monde touche à tout. Dans les microservices, tu forces les contrats d'API avec du protobuf ou du json, ce qui impose une discipline.

Le vrai souci est le déploiement. Si tu veux tester une feature isolée, c'est l'enfer sur un gros monolithe. Sur des microservices, tu peux tester ton module indépendamment.

Justement, avec des outils comme docker-compose ou des environnements éphémères, tu peux tester ton monolithe sans problème. La complexité des microservices ne vaut le coup que si tu as des besoins de scalabilité distincts par composant.

Et la gestion des transactions ? C'est le cauchemar absolu. Passer de ACID à l'eventual consistency, c'est un saut de complexité que beaucoup sous-estiment.

On oublie aussi le monitoring. Gérer 50 services avec des logs éparpillés, c'est impossible sans une stack ELK massive. Le monolithe, c'est un seul point d'entrée pour les logs.

Il y a un juste milieu : le monolithe distribué. Tu sépares par domaine mais tu gardes une plateforme commune pour éviter la duplication de code.

La plupart des startups que je vois font du "distributed monolith" sans le savoir. Elles ont tous les inconvénients de la latence réseau sans aucun avantage de déploiement indépendant.

On en revient toujours au même point : la maturité de l'équipe. Si ton équipe ne sait pas gérer un monolithe propre, elle ne saura jamais gérer des microservices.

Le monolithe modulaire est une excellente transition. Si tu ne peux pas découper ton code en modules clairs, ne touche pas aux microservices.

Clairement, avant de splitter, demandez-vous : est-ce que mon équipe est prête à gérer l'observabilité sur 20 services différents ?

La réponse est presque toujours non au début. Commencez simple, scalez quand la douleur devient insupportable.