Comment éviter les déceptions liées à l'usage intensif des microservices

< Vers plus de modularité avec les microservices

Selon un récent rapport de Gartner, le nombre de mentions du terme "architecture de microservices" a diminué de 42% entre janvier 2019 et septembre 2020. Cette tendance suggère que beaucoup commencent à être désabusés par l'architecture microservices. Il semble que nous soyons entrés dans la fameuse période de désillusion suivant celle de l'excitation dans le Hype Cycle de Gartner.

Alors comment adopter un modèle d'architecture microservices sans être victime de cette désillusion - et ainsi atteindre plus rapidement le plateau de productivité ? L'une des approches consiste à tirer les leçons des réussites et des échecs des autres, et à bien comprendre les complexités et les coûts que cela implique.

Ce que vous devez savoir sur les microservices

Nous examinerons ci-dessous 6 faits bien connus concernant les microservices, ainsi que certaines questions importantes à se poser avant de franchir le pas.

1. L'architecture microservices améliore l'agilité : en décomposant les fonctionnalités en petits composants indépendants, les microservices permettent un déploiement plus rapide des nouvelles fonctionnalités. Des entreprises à la pointe de la technologie, comme Netflix et Amazon, en profitent pour investir dans des capacités DevOps.
2. L'architecture microservices est complexe : comme chaque composant doit être développé, testé, déployé, mis à l'échelle et mis à jour de manière indépendante, les microservices nécessitent une conception rigoureuse. Il est essentiel de bien comprendre les limites entre chaque composant et d'utiliser des modèles d'intégration connus.
3. Les microservices ne vous feront pas économiser d'argent ; cependant, si une architecture monolithique est plus simple et plus rentable, elle n'offre pourtant pas le même niveau d'évolutivité et de disponibilité que les microservices.
4. Les microservices ne sont pas la même chose que les API : l'architecture microservices est une façon de mettre en œuvre la fonctionnalité derrière une API, mais ce n'est pas la même chose. Il est d'ailleurs possible de composer des données en agglomérant les données de différentes API, ou de faire reposer une API unique sur plusieurs microservices.
5. Les microservices ne doivent pas être partagés entre plusieurs domaines : afin d'atteindre les objectifs d'agilité des microservices, chaque composant doit être indépendant.
6. Les microservices ne sont pas la même chose que les conteneurs : le déploiement de microservices dans des conteneurs est courant, mais cela ne suffit pas à garantir l'indépendance des composants ; notamment si l'on tient compte des systèmes de stockage derrière eux, comme une base de données.

Les questions à se poser avant de passer aux microservices

Avant de décider de passer aux microservices, il est important de se poser les questions suivantes :

• Disposez-vous d'un mécanisme de déploiements continus ?
• Les déploiements partiels sont-ils une option ?
• Existe-t-il une procédure uniforme de gestion des versions au sein de l'entreprise ?
• Existe-t-il un pool d'ingénieurs DevOps qualifiés pour gérer la mise à l'échelle ?
• Disposez-vous d'une capacité mature de gestion des alertes et des défaillances ?

Si les réponses à ces questions ne sont pas favorables, il est préférable de se concentrer sur le renforcement de votre capacité DevOps avant de passer aux microservices. Le sujet de la supervision, en particulier, s'est avéré maintes fois décisif pour l'exploitation de cette architecture ; le concept de "service mesh" en est issu. En outre, il est important d'avoir un plan clair pour la maintenance du code et le passage d'une frontière à l'autre, et de disposer d'une équipe bien formée.