Le débat microservices versus monolithe a produit plus de mauvaises décisions architecturales que toute autre discussion en ingénierie logicielle. Non pas parce que l'une ou l'autre réponse est mauvaise, mais parce que les équipes continuent de poser la mauvaise question. La question n'est pas quelle architecture est la meilleure. C'est quelle architecture est la bonne pour où vous êtes réellement.
La mythologie des microservices
Les microservices sont devenus dominants dans la culture d'ingénierie à l'ère de Netflix, Uber et Amazon — des entreprises opérant à une échelle massive avec des centaines d'ingénieurs travaillant sur la même base de code. Les patterns architecturaux qu'ils ont développés étaient des réponses à des problèmes spécifiques et extrêmes.
“Un monolithe modulaire avec des frontières de domaine claires surpassera une architecture microservices mal conçue sur chaque dimension importante : vitesse de livraison, fiabilité du système, et satisfaction des ingénieurs.”
Ce qu'un monolithe vous apporte vraiment
Un monolithe bien structuré est plus simple à développer, à tester, à déboguer et à opérer qu'une architecture microservices équivalente. Chaque système distribué introduit une catégorie de problèmes qui n'existe pas dans un monolithe : latence réseau, découverte de services, traçage distribué, authentification inter-services.
Le cadre de décision
- Commencez avec un monolithe. Construisez-le de manière modulaire avec des frontières de domaine claires. Déployez-le comme une unité.
- Extrayez des services lorsque vous avez un besoin spécifique et démontré — pas théorique. Raisons valides : un module spécifique doit s'adapter indépendamment, une équipe spécifique a besoin d'une autonomie de déploiement complète.
- N'extrayez jamais un service parce qu'une tendance technologique dit que vous devriez, ou parce qu'un framework le facilite.