Les microservices ne sont pas une solution universelle. Avant de découper votre application en dizaines de services, posez-vous les bonnes questions sur votre contexte, votre équipe et votre horizon.
La tendance microservices a envahi la profession au point que commencer un projet en monolithe est presque devenu honteux. C'est une erreur de perspective. Amazon, Netflix, Uber ont migré vers les microservices après des années de croissance — pas au départ. Leur complexité opérationnelle est massive : orchestration, latence réseau, cohérence distribuée, observabilité. Pour une équipe de cinq développeurs, c'est souvent contre-productif.
Un monolithe bien structuré — ce que Martin Fowler appelle le Modular Monolith — offre le meilleur des deux mondes en phase de démarrage. Les modules sont découplés logiquement, testables indépendamment, mais déployés ensemble. Quand une partie du système doit scaler différemment des autres, on peut extraire ce module en service autonome via le Strangler Fig Pattern : on construit le nouveau service en parallèle et on redirige progressivement le trafic.
Le vrai critère de choix n'est pas technique, il est organisationnel. La loi de Conway s'applique ici parfaitement : votre architecture ressemblera à la structure de votre équipe. Si vous avez des équipes autonomes, chacune owner d'un domaine métier, les microservices ont du sens. Si vous avez une seule équipe polyvalente, un monolithe modulaire sera plus efficace.
→ À lire aussi : Domain-Driven Design · Communication entre microservices · Architecture event-driven