Points clés
- Une architecture microservices découpe une application en services distincts et indépendants, chacun prenant en charge une fonction métier précise.
- Contrairement aux systèmes monolithiques, les microservices permettent un déploiement indépendant, une mise à l’échelle ciblée et une tolérance aux pannes isolée entre les composants.
- Les principaux avantages des microservices : évolutivité facilitée, travail en parallèle entre les équipes, souplesse technologique et résilience applicative.
- Définir des frontières de service claires est essentiel : des services mal délimités produisent des monolithes distribués, qui cumulent la lourdeur des microservices sans en offrir tous les bénéfices.
- Les microservices conviennent surtout aux systèmes vastes et complexes, aux besoins d’évolutivité et de disponibilité variables, tandis qu’une architecture monolithique suffit aux systèmes plus simples.
Les charges de travail actuelles exigent des applications capables d’absorber un trafic imprévisible, des mises à jour fréquentes et un nombre croissant de fonctions. L’architecture microservices répond à ce besoin en répartissant chaque microservice dans un codebase indépendant, déployable et évolutif séparément.
Ce guide explique ce que sont les microservices, en quoi ils diffèrent des systèmes monolithiques et comment déterminer si cette architecture convient à votre environnement.
Comprendre l’architecture microservices
Une architecture microservices est une approche de conception logicielle qui découpe les applications en services plus petits, fonctionnant de façon autonome. Plutôt que de regrouper toutes les fonctions dans une seule unité, chaque capacité applicative est maintenue comme un service à part entière.
En règle générale, chaque microservice :
- prend en charge un service unique et bien défini, et reste cantonné à cette fonction ;
- gère sa propre base de données, au lieu de partager une base centrale avec le reste du système ;
- communique via des API afin que chaque application indépendante fonctionne de manière cohérente ;
- fonctionne de façon autonome, ce qui permet aux équipes de mettre à jour, redémarrer ou faire évoluer un service sans redéployer l’application entière.
Cette architecture applicative permet aux équipes informatiques de bâtir un environnement applicatif distribué, dans lequel les composants évoluent séparément. Les différentes équipes peuvent ainsi travailler en parallèle et adapter les services à la demande, tout en empêchant les pannes de se propager d’un codebase à l’autre.
Microservices et systèmes monolithiques : quelles différences ?
Pour y voir plus clair, comparons-les point par point :
| Points de comparaison | Systèmes monolithiques | Microservices |
| Structure | Toutes les fonctionnalités résident dans un codebase unique et s’exécutent comme une seule unité. | Les fonctionnalités sont réparties entre des services indépendants qui s’exécutent séparément. |
| Stratégie de déploiement | Déploiement initial simple, mais toute modification impose de redéployer l’application entière. | Chaque service peut recevoir des mises à jour de façon ciblée, sans incidence sur l’ensemble du système. |
| Couplage des composants | Les composants partagent le code, la mémoire et la base de données. | Les services communiquent uniquement via des API bien définies. |
| Évolutivité | La mise à l’échelle suppose de modifier l’application entière. | Chaque service peut être mis à l’échelle indépendamment, en fonction de la demande. |
| Tolérance aux pannes | Une seule défaillance peut faire tomber l’application entière. | Les défaillances restent isolées au sein d’un service, le reste du système conservant ses fonctionnalités. |
| Stack technologique | Verrouillée sur un seul langage et un seul framework pour tout le codebase. | Chaque service peut utiliser le langage, le framework ou la base de données les mieux adaptés à sa fonction. |
| Organisation du travail des équipes | Plusieurs équipes doivent intervenir dans le même codebase, ce qui impose une collaboration transverse à chaque mise en production. | Chaque équipe est responsable de ses propres services et peut développer, tester et livrer en parallèle. |
Les microservices sont généralement adoptés pour soutenir l’évolutivité et répondre aux exigences propres aux systèmes en évolution. Cette architecture aide également les équipes à travailler en parallèle, avec des langages ou des frameworks différents, ce qui accélère les cycles de développement. La meilleure tolérance aux pannes des microservices évite en outre que les incidents ne se propagent d’un composant à l’autre.
Cela dit, les atouts qui font la force des microservices s’accompagnent aussi d’une complexité supplémentaire non négligeable. Les microservices ne reposent pas sur des bases de données partagées, par exemple, ce qui complique la cohérence des données, sans compter les défaillances de composants susceptibles de survenir en plusieurs points de l’environnement.
Définir les frontières de service dans une architecture microservices
Les frontières délimitent le périmètre d’un microservice : le service dont il a la charge, les données dont il est propriétaire et la limite de cette responsabilité. Un service de paiement, par exemple, se limite au traitement des transactions et des enregistrements de paiement ; son périmètre ne doit pas empiéter sur les flux liés à la logistique.
Des frontières bien définies alignent les microservices sur les capacités qu’ils assurent réellement, réduisent au minimum les dépendances entre services et facilitent la mise à l’échelle indépendante.
À l’inverse, des frontières mal définies génèrent du bruit : les services s’appellent en permanence, ce qui multiplie le trafic réseau et la latence. De plus, cela peut créer des goulets d’étranglement et accroître la complexité du système.
Pour tirer le meilleur parti d’une architecture microservices, les équipes doivent définir dès le départ des frontières alignées sur le métier, puis les affiner à mesure que les systèmes évoluent. Sans frontières correctement définies, les entreprises se retrouvent avec un monolithe distribué qui cumule la lourdeur des microservices sans la souplesse.
Les microservices sont-ils faits pour vous ?
Avant de vous engager dans les microservices, il faut évaluer où ils ont leur place dans votre environnement, où ils n’en ont pas, et quelles alternatives existent en dehors d’une architecture microservices.
Quand les microservices s’imposent
Les microservices apportent le plus de valeur dans les environnements dont les besoins dépassent ce qu’un système monolithique peut offrir. Ils constituent généralement le bon choix lorsque votre entreprise répond aux critères suivants :
- Systèmes vastes et complexes : envisagez les microservices si votre application a atteint un stade où un codebase unifié devient difficile à maintenir ou à livrer en toute sécurité.
- Les équipes doivent travailler en parallèle : plusieurs équipes contribuent au même système et le codebase partagé est devenu un goulet d’étranglement en matière de coordination.
- Besoins d’évolutivité variables : certaines fonctions supportent des charges bien plus lourdes que d’autres et doivent pouvoir évoluer indépendamment.
- La livraison continue est une priorité : optez pour les microservices si votre entreprise livre fréquemment et ne peut pas se permettre d’interruption lors des nouvelles mises en production.
Quand les microservices ne conviennent pas
Dans certains cas, une architecture plus simple donne de meilleurs résultats, sans la charge opérationnelle inhérente aux microservices. Évitez-les si votre environnement correspond aux situations suivantes :
- Applications simples : un monolithe assure des fonctionnalités simples avec beaucoup moins d’infrastructure et de complexité.
- Équipes sans expérience : sans compétences en orchestration de services, en supervision et en gestion des pannes, cette architecture crée plus de problèmes qu’elle n’en résout.
- Ressources d’infrastructure limitées : les microservices exigent des outils et des capacités dont les environnements de taille modeste ne disposent pas toujours.
- Aucun besoin de mise à l’échelle indépendante : si les composants d’une application évoluent ensemble à un rythme maîtrisable, les séparer engendre des coûts inutiles.
Quelques alternatives à l’architecture microservices
Le choix des équipes informatiques ne se limite pas aux microservices et aux applications monolithiques. Plusieurs modèles architecturaux se situent entre les deux et peuvent mieux correspondre aux besoins et aux moyens de votre environnement.
Architecture monolithique modulaire
Une architecture monolithique modulaire consiste en une unité déployable unique, organisée en modules internes distincts. Elle permet aux équipes informatiques d’associer la séparation interne claire des microservices à la simplicité opérationnelle d’un monolithe. En revanche, cette architecture évolue comme un tout, ce qui peut limiter la souplesse de chaque module.
Architecture orientée services
Une architecture orientée services (SOA) organise différentes fonctionnalités en services partagés, souvent coordonnés par un bus de services d’entreprise (ESB). Ce modèle favorise la réutilisation des services et peut soutenir des intégrations à l’échelle de l’entreprise. Il offre une bonne interopérabilité entre services, mais les ralentissements, modifications ou pannes de l’ESB se répercutent sur tous les services connectés.
Bien comprendre l’architecture microservices avant de l’adopter
Les microservices favorisent l’évolutivité et offrent une grande souplesse de gestion, mais ils s’accompagnent d’une charge importante. C’est en confrontant les besoins de votre environnement à ces compromis que vous saurez si un système plus simple vous servira mieux, ou si le passage aux microservices en vaut la peine.
