Les microservices ne constituent pas un modèle d'optimisation de la performance.
Ils représentent un compromis architectural.
Lorsque vous divisez un monolithe en services interconnectés, vous ajoutez :
- sérialisation et désérialisation
- sauts réseau
- logique de nouvelle tentative
- surcharge de l'observabilité
- davantage de modes de défaillance
C'est un coût réel. Prétendre le contraire n'est pas une architecture sérieuse.
## Pourquoi les équipes les choisissent-elles encore ?
Le bénéfice se trouve généralement ailleurs :
- autonomie de l'équipe
- cadence de déploiement séparée
- propriété de service renforcée
- montée en charge de différentes charges de travail de manière indépendante
Ainsi, le bon cadrage n'est pas "les microservices sont bons" ou "les monolithes sont bons".
C'est :
"Quel problème payons-nous cette taxe pour résoudre ?"
## Quand le monolithe est-il préférable ?
Un monolithe modulaire est souvent le bon choix lorsque :
- l'équipe est encore petite
- les frontières de domaine sont encore en évolution
- la latence entre les composants est importante
- la simplicité opérationnelle est précieuse
Ce n'est pas une architecture de compromis. C'est souvent le choix mature.
## Quand les microservices commencent-ils à avoir du sens ?
Le compromis devient plus facile à justifier lorsque :
- l'organisation est suffisamment grande pour nécessiter des frontières plus strictes
- certaines parties du système nécessitent réellement des profils de montée en charge différents
- les domaines de défaillance indépendants sont précieux
- l'équipe peut gérer la complexité opérationnelle
Les microservices peuvent être la bonne réponse. Ils ne sont simplement que rarement la réponse la plus rapide en termes de chemin de requête brut.
## Lectures complémentaires
- [Martin Fowler : Monolith First](https://martinfowler.com/bliki/MonolithFirst.html)
- [Martin Fowler : Microservices](https://martinfowler.com/articles/microservices.html)