Publié le 22 mai 2016 par Nicola Rizhikov
Tout le monde parle des microservices comme de l'approche privilégiée pour structurer des systèmes d'information complexes.
Voici quelques raisons couramment invoquées :
- Notre application monolithique est devenue trop volumineuse et complexe, alors nous allons la décomposer en services
- Nous avons atteint les limites de performance de notre monolithe ; en le divisant en services, nous espérons les améliorer
- Notre système sera très imposant, alors nous partons d'une architecture en microservices afin de pouvoir évoluer à l'avenir
- Les entreprises qui réussissent utilisent les microservices ; nous voulons simplement suivre les meilleures pratiques du secteur.
De mon point de vue, ces motivations n'ont pas de lien direct avec ce patron architectural et peuvent vous entraîner dans de véritables difficultés ou gaspillages. La décision d'adopter un style architectural en microservices doit être réfléchie et fondée sur une compréhension de toutes les conséquences et des compromis à accepter.
Voici quelques pénalités sérieuses que vous devrez payer pour les microservices :
Cohérence et gestion des dépendances
Lorsque vous divisez votre système en services qui évoluent indépendamment, ces parties ont toujours des dépendances logiques entre elles et le système dans son ensemble doit rester cohérent. Dans une application monolithique, ces dépendances sont explicitement codées en dur dans votre code, mais en le découpant en morceaux, les dépendances deviennent « implicites » et vous devez fournir des efforts supplémentaires (versions, contrats, tests, etc.) pour vous assurer qu'elles sont satisfaites. Votre système devient plus fragile et imprévisible. Cela ressemble en quelque sorte au choix entre les options ACID et BASE. Dans le cas d'ACID, à chaque instant vous n'avez qu'une seule version fiable du monde ; dans un monde BASE, plusieurs galaxies parallèles peuvent coexister et vous devez gérer la cohérence manuellement. Dans le pire des cas, vous pourriez vous retrouver face au problème bien connu de l'enfer des dépendances. Ainsi, sans des compétences et des outils solides en « gestion des dépendances », vous vous engagez sur une route dangereuse.
La « bonne » décomposition
La préoccupation la plus difficile dans l'approche en microservices (en programmation en général :) — comment décomposer l'ensemble en parties ? Comme le savent de nombreux architectes chevronnés, la décomposition initiale est presque toujours incorrecte. Faire cela « correctement » signifie que vous êtes capable de prédire l'avenir. Plutôt que de vous renvoyer à des conseils théoriques, examinons les conséquences d'une décomposition « incorrecte ».
Fonctionnalité transversale : il est facile de recevoir une demande de nouvelle fonctionnalité qui nécessite d'apporter des modifications à de nombreux services, puis de la livrer de manière cohérente. Parfois, cette fonctionnalité prendrait quelques minutes dans un monolithe et des heures ou des jours dans un environnement en microservices. Il en va de même pour les bogues transversaux.
Recomposition — si vous trouvez une meilleure façon de structurer votre système, vous devez recomposer votre architecture. Dans un monolithe, c'est simplement le bien connu « refactoring », qui peut être effectué de manière relativement sûre. Avec les microservices, une telle transformation n'est souvent pas une tâche triviale.
Coûts opérationnels
C'est un coût relativement connu — chaque nouveau composant apporte une surcharge opérationnelle de façon non linéaire. Les systèmes distribués requièrent une infrastructure, des outils et des experts qualitativement plus complexes pour fonctionner de manière fiable.
Avantages des microservices
Faire croître votre entreprise et votre système correctement n'est pas facile. Vous devez gérer deux entités interdépendantes — l'organisation et le système. L'argument le plus important en faveur des microservices, à mon avis, est l'alignement des deux conformément à la loi de Conway. Les (micro)services permettent de confier un service à une équipe interfonctionnelle — de rendre les équipes aussi indépendantes que possible. La contrainte essentielle à ne pas négliger est que l'équipe doit être en mesure de concevoir, développer et livrer une « valeur réelle » à l'utilisateur final avec un chevauchement et des conflits minimaux avec les autres équipes. « Faire évoluer votre système et votre organisation » est un objectif qui vaut le prix des microservices. La formule simple se résume ainsi :
- une équipe → plusieurs services → incorrect (surcharges)
- plusieurs équipes → un service → incorrect (conflits)
- une équipe → un service → correct
Dans ces conditions, la taille du service ne devrait pas être « trop micro », mais définie uniquement par la taille et les compétences de vos équipes. Comme nous le savons, une équipe peut évoluer dans un intervalle très limité — 2 à 7 personnes — mais les compétences peuvent varier de plusieurs ordres de grandeur.
Un autre argument valable pour moi est le « changement technologique » : la situation où votre technologie actuelle ne peut pas offrir les caractéristiques techniques requises, par exemple en matière de performance, et où vous devez « écrire en C » une portion critique de votre système.
Conclusion
Ces défis et leurs dérivés consommeront la majeure partie de votre temps au début, vous ralentissant considérablement dans les phases critiques. C'est pourquoi l'approche « microservices d'abord » me semble très suspecte. La plupart des applications en microservices qui ont réussi ont été réalisées en refactorisant des monolithes en production en plusieurs parties. Dans ces cas, les ingénieurs avaient une compréhension approfondie des rouages internes du système et de ses problèmes.
Dans la plupart des cas, je vote pour « Monolithe d'abord ».
