Points clés
- Vous pouvez faire évoluer certaines parties de votre application indépendamment les unes des autres pour suivre la demande, ce qui permet d’économiser sur les coûts et les ressources serveur.
- Si un élément de votre système tombe en panne, le reste de l’application continue généralement de fonctionner, ce qui évite une interruption totale.
- Gérer de nombreux petits services est complexe : il vous faut des outils automatisés capables de les démarrer, de les arrêter et de les relier entre eux de façon fiable.
- Comme les services sont répartis et redémarrent fréquemment, des outils de surveillance centralisés sont indispensables pour suivre les performances et repérer rapidement les erreurs.
- Cette approche convient parfaitement aux projets vastes et complexes, mais la configuration et la maintenance supplémentaires la rendent superflue pour la plupart des petites entreprises.
- Vous devez stocker les données importantes séparément de vos services et recourir à des systèmes automatisés pour les sauvegarder et signaler les erreurs.
Une architecture en microservices profite aux applications qui doivent être hautement évolutives, résilientes et disponibles. Elle répond aussi aux cas d’utilisation où la latence pose problème, puisqu’elle permet de répartir les composants au plus près des utilisateurs finaux. Les microservices ne servent pas uniquement à héberger des applications grand public et SaaS : ils peuvent également être déployés pour l’infrastructure et les outils internes lorsque la fiabilité est prioritaire.
Ce guide explique comment faire évoluer des microservices, en quoi cette approche diffère des architectures applicatives traditionnelles et ce que cela implique pour la gestion, la surveillance et la maintenance des systèmes en microservices par les équipes informatiques.
Que sont les microservices ?
Les microservices (ou architecture en microservices) désignent une manière de développer des applications à partir de services indépendants, chacun encapsulant une fonctionnalité précise. Ces composants sont faiblement couplés et communiquent via des API (généralement en HTTP), de sorte que si un service tombe en panne, les autres continuent de fonctionner. Les microservices sont le plus souvent déployés pour des applications et services hébergés en mode client-serveur, et non pour des applications exécutées localement sur vos appareils (même s’ils peuvent être conteneurisés à cette fin).
Comme chaque service est indépendant, il peut être mis à l’échelle individuellement. Prenons une application e-commerce simple, découpée en composants pour le traitement des paiements, l’envoi d’e-mails et l’affichage des pages web. En cas de pic soudain de trafic (sans que personne ne valide réellement son panier, donc sans déclencher de paiements ni d’e-mails), seul le microservice de serveur web aurait besoin d’être mis à l’échelle. C’est à la fois économe en ressources et rentable, tout en garantissant une capacité toujours suffisante pour absorber la demande.
Microservices et architectures monolithiques
Les microservices constituent une alternative à l’architecture monolithique, où tout réside dans un seul codebase, généralement hébergé sur un unique serveur puissant.
Le principal atout d’une approche en microservices est l’évolutivité. Pour faire évoluer une application monolithique, vous pouvez soit augmenter les ressources qui lui sont allouées (plus de mémoire, plus de processeur : c’est la mise à l’échelle verticale), soit exécuter une autre instance de l’application et répartir la charge entre elles (mise à l’échelle horizontale).
Faire évoluer un monolithe peut se révéler très inefficace selon la taille et la nature de votre application, car cela revient parfois à allouer des ressources à l’ensemble alors qu’un seul petit composant est fortement sollicité. Avec les microservices, chaque composant pouvant être mis à l’échelle horizontalement, l’utilisation globale des ressources s’en trouve optimisée.
La haute disponibilité bénéficie elle aussi des microservices. Dans un monolithe, si l’application plante, tout plante. À l’inverse, si un microservice isolé plante, les autres continuent de tourner le temps qu’il se rétablisse (par exemple, si votre microservice d’envoi d’e-mails plante, les clients peuvent continuer leurs achats et subiront tout au plus un retard dans la réception d’une mise à jour de commande, plutôt que de ne plus pouvoir acheter du tout).
Comment les microservices modifient les interactions entre systèmes
Lorsque les microservices sont mis à l’échelle horizontalement, des conteneurs ou des instances sont créés puis détruits au gré de la demande. Tout ce qui se trouve en mémoire ou en stockage local est donc perdu. Concevoir une application en microservices évolutive suppose de gérer ce point avec du stockage persistant, des bases de données et des mécanismes de partage d’état (comme les magasins clé-valeur).
Les microservices reposent aussi fortement sur les performances réseau : les composants doivent communiquer en permanence, avec une faible latence et sans interruption.
De nouveaux schémas de défaillance dans les systèmes distribués en microservices
Si l’un des avantages des microservices est que certains composants continuent de fonctionner quand d’autres tombent en panne, ce n’est pas toujours réalisable : tout dépend de votre cas d’utilisation et des choix de conception effectués pendant le développement.
Les composants dépendront inévitablement de la disponibilité des autres, et certaines opérations doivent s’exécuter dans un ordre précis. Les défaillances se propagent donc en cascade, et la gestion des erreurs doit prendre en charge les pannes partielles, et pas seulement les pannes totales.
La mise à l’échelle fonctionne autrement dans les environnements distribués (et cela a des effets de bord)
La mise à l’échelle, combinée à des composants isolés pouvant être mis à jour individuellement (tant que leurs API restent cohérentes), aboutit à des nœuds fréquemment créés et détruits selon l’allocation des ressources à la demande. Dans certains cas, un conteneur ou une instance d’un service donné ne vit que le temps de traiter une seule requête.
Cela nuit fortement à la visibilité, car l’état de chaque composant disparaît avec lui, y compris les journaux d’erreurs nécessaires au diagnostic.
Les défis de coordination entre services
Les microservices doivent rester coordonnés et accessibles les uns aux autres, et les dépendances entre services doivent être prises en compte dans les configurations. Cela passe par des outils comme Kubernetes, ou par les fonctionnalités natives de plateformes cloud telles qu’Azure et AWS, pour gérer les conteneurs et machines virtuelles.
En cas de latence ou de problèmes de connexion, les architectures en microservices peuvent devenir peu fiables, voire indisponibles.
Les performances dépendent de la finalité des microservices et de leurs relations
Dans une architecture en microservices, les performances peuvent être priorisées composant par composant. Un serveur web, par exemple, doit répondre le plus vite possible pour offrir la meilleure expérience aux utilisateurs finaux, tandis qu’un serveur de notifications par e-mail peut mettre quelques secondes à envoyer un message sans que cela n’affecte l’activité.
Dans certains cas, un microservice peut en réalité être une API externe (par exemple une API de communication pour l’envoi de SMS), dont les attentes en matière de performances diffèrent de celles d’un service hébergé dans le même datacenter que votre application.
L’optimisation des performances s’en trouve plus complexe : elle ne se résume pas à une question de chiffres bruts.
Comment la complexité augmente avec le temps dans les systèmes en microservices
Bien qu’ils paraissent plus complexes, les microservices peuvent en réalité simplifier les opérations informatiques lorsqu’ils sont bien exploités : il est souvent plus simple de dépanner un service isolé qu’un stack applicatif monolithique entier.
La configuration initiale comporte certes des difficultés, mais l’orchestration et l’automatisation rendent le déploiement des applications en microservices de plus en plus simple pour les équipes DevOps. Les outils CI/CD et les outils d’infrastructure-as-code comme Terraform éliminent une grande partie du travail fastidieux et des risques de mauvaise configuration.
Surveillance des performances et de la sécurité des microservices : différences et défis
La clé du succès de tout système informatique réside dans la visibilité et dans une approche proactive de la résolution des problèmes. Les équipes informatiques et DevOps qui passent leur temps à « éteindre des incendies » ne peuvent pas fournir des services informatiques stables et durables. Si vous hébergez des applications en microservices, vous devez être en mesure de surveiller et dépanner les machines virtuelles et les conteneurs.
Le Containers as a service (CaaS) permet également de s’affranchir de la gestion directe de l’infrastructure. Ces services proposent des interfaces simplifiées pour administrer les applications conteneurisées et prennent en charge une grande partie des contraintes de configuration, de maintenance et de sécurité liées à la gestion des plateformes d’orchestration de conteneurs.
Les sauvegardes représentent un autre défi pour les microservices : les instances en cours d’exécution ne devraient pas contenir de données durables nécessitant une sauvegarde, tandis que les magasins clé-valeur, les bases de données et le stockage objet utilisés pour la persistance des données peuvent tous exiger une solution de sauvegarde adaptée, autorisant un retour arrière ou une restauration complète, avec l’immuabilité pour se protéger des menaces malveillantes.
Quand les microservices apportent le plus de valeur
Les applications en microservices apportent le plus de valeur lorsque :
- les composants doivent être mis à l’échelle indépendamment ;
- les applications sont vastes et complexes ;
- les équipes de développement doivent travailler de façon autonome ;
- le changement continu est une nécessité.
Pour les utilisateurs finaux et les décideurs, la valeur des microservices tient à la fiabilité, à la rapidité et à l’optimisation des coûts. Pour les équipes techniques, elle réside dans la cohérence et dans une évolutivité immédiatement disponible.
Cela dit, inutile de vous précipiter pour demander à vos développeurs de migrer votre code existant vers une architecture en microservices. La plupart des petites et moyennes entreprises ont peu de chances de tirer profit du travail supplémentaire qu’implique la reconstruction de codebases bien établis, ni des coûts opérationnels liés à la maintenance de systèmes distribués.
En revanche, si vous concevez et mettez en place un nouveau système, évaluez les bénéfices opérationnels à long terme d’une approche en microservices, en particulier si vous prévoyez de servir un grand nombre d’utilisateurs.
Supervision et performances de toute votre infrastructure informatique
Obtenir de la visibilité sur le fonctionnement d’une infrastructure éphémère et auto-évolutive n’a rien d’évident. De nombreux outils permettent de gérer les erreurs depuis les conteneurs et les instances spot, mais ils s’adressent le plus souvent aux développeurs.
Les équipes informatiques qui pilotent au quotidien des applications en microservices ont tout intérêt à choisir des outils de signalement d’erreurs compatibles avec leur codebase et intégrables à une plateforme informatique unifiée. Les alertes de vos applications en microservices sont ainsi centralisées et regroupées avec les notifications de surveillance de vos terminaux, de votre sécurité et de votre réseau.
Vous pouvez également mettre en place une surveillance des performances applicatives pour évaluer chaque microservice et les performances globales, et utiliser l’automatisation du Helpdesk (service d’assistance) pour faire remonter les incidents ou les anomalies de coûts au bon technicien, en vue d’un diagnostic immédiat.
