Microservices et architecture de microservices (MSA)
Découvrez les avantages et les inconvénients des microservices et en quoi ils diffèrent des monolithes.
Il n'y a pas si longtemps, les développeurs d'apps logicielles privilégiaient une architecture monolithique, qui se composait d'une seule unité autonome. Cette approche a bien fonctionné pour beaucoup d'entre eux jusqu'à ce que les apps gagnent en complexité. Lorsque vous modifiez une petite section de code dans un système monolithique, vous devez reconstruire l'ensemble du système, effectuer des tests sur l'ensemble du système et déployer une toute nouvelle version de l'app.
C'est alors que sont apparus les microservices : une approche qui décompose les systèmes logiciels en unités plus petites développées et déployées de manière autonome. L'architecture de microservices est propulsée par le mouvement DevOps qui cherche à livrer fréquemment des mises à jour, comme de nouvelles fonctionnalités, des corrections de bugs et des améliorations de sécurité. Dans de nombreux cas, les microservices sont également devenus un moyen pour les entreprises de réécrire des apps héritées à l'aide de langages de programmation modernes et de mises à jour d'une stack technique.
Les microservices sont un ensemble de petites unités qui livrent et déploient en permanence de grandes apps complexes.
Qu'est-ce que les microservices ?
Une architecture de microservices, également appelée simplement « microservices », est une approche permettant de créer une app sous la forme d'une série de services déployables indépendamment, décentralisés et développés de manière autonome. Ces services à couplage lâche sont déployables indépendamment et facilement maintenables. Alors qu'une app monolithique est conçue comme une unité unique et indivisible, les microservices divisent cette unité en un ensemble d'unités indépendantes qui contribuent à l'ensemble global. Ils font partie intégrante de DevOps, car c'est sur eux que reposent les pratiques de livraison continue qui permettent aux équipes de s'adapter rapidement aux exigences des utilisateurs.
Un microservice est un service web responsable d'un élément de la logique de domaine. Plusieurs microservices se combinent pour créer une app, chacun fournissant une fonctionnalité pour un domaine. Les microservices interagissent entre eux à l'aide d'API, telles que REST ou gRPC, mais n'ont pas connaissance du fonctionnement interne des autres services. Cette interaction harmonieuse entre les microservices constitue une architecture de microservices.
Dans une architecture de microservices, les développeurs peuvent ensuite s'organiser en équipes plus petites spécialisées dans différents services, avec différents stacks et déploiements découplés. Par exemple, Jira est alimenté par plusieurs microservices, chacun offrant des fonctionnalités spécifiques, notamment la recherche de tickets, l'affichage des informations sur les tickets, les commentaires, les transitions de tickets, et bien plus encore.
Caractéristiques des microservices
Il n'existe pas de définition formelle d'une architecture de microservices, mais il est important de connaître certains modèles ou caractéristiques communs.
Composants autonomes
Le composant constitue la base d'une architecture de microservices. Il peut s'agir d'un ensemble de logiciels, de services web ou de ressources, d'une app ou d'un module contenant une série de fonctions connexes. Ou, plus simplement, comme l'explique Martin Fowler : « Les composants logiciels sont des éléments indépendamment remplaçables et évolutifs ».
Dans une architecture de microservices, chaque composant peut être développé, déployé, exploité, modifié et redéployé sans compromettre le fonctionnement des autres services ou l'intégrité d'une app.
Les composants sont utilisés avec d'autres éléments pour offrir une expérience client ou une valeur métier. Les plus courants sont les services et les bibliothèques, mais ils peuvent encapsuler des outils d'interface de ligne de commande (CLI), des apps mobiles, des modules front-end, des pipelines de données, des modèles d'apprentissage machine et de nombreux autres concepts pouvant être appliqués dans une architecture de microservices.
Interfaces propres
Une fois que les composants individuels sont établis, ils nécessitent une quantité importante de logique pour communiquer entre eux via un mécanisme comme RPC, REST sur HTTP ou un système basé sur des événements. Ces mécanismes peuvent être des méthodes synchrones ou asynchrones, et les microservices peuvent utiliser une combinaison des deux.
L'aspect le plus important ? Chaque microservice doit fournir un contrat clair et intuitif décrivant comment un consommateur de ce service peut l'utiliser. Cela se fait généralement par le biais d'une API publiée à côté du service.
Vous l'avez conçu, vous en êtes responsable
La philosophie DevOps selon laquelle « Vous l'avez conçu, vous en êtes responsable » souligne que vous ne pouvez pas transformer une architecture en microservices sans réfléchir à la structure des équipes. DevOps réaligne la motivation au sein des rôles fonctionnels (développement, assurance qualité, ingénierie des versions, opérations) au sein d'une seule équipe ayant pour objectif commun de développer des logiciels de haute qualité. Les pratiques DevOps telles que la CI/CD, les tests automatisés et les feature flags accélèrent le déploiement et contribuent à maintenir la stabilité ainsi que la sécurité du système. De plus, chaque équipe peut développer et déployer les microservices dont elle est propriétaire sans affecter les autres équipes.
L'évolution du cloud a simplifié le développement, le déploiement et l'exploitation des microservices. Les techniques d'automatisation de l'infrastructure telles que l'intégration continue, la livraison continue et les tests automatisés aident les équipes.
Architecture orientée service et microservices
L'architecture orientée service (SOA) et les microservices sont deux types d'architectures de service web. À l'instar des microservices, une SOA comprend des composants spécialisés réutilisables qui fonctionnent indépendamment les uns des autres. La distinction entre les deux types d'architecture est la classification bureaucratique des types de services.
Une SOA comporte quatre types de services de base :
- Business
- Enterprise
- Application
- Services d'infrastructure
Ces types définissent la responsabilité spécifique du domaine connexe des services sous-jacents. En comparaison, les microservices n'ont que deux types de services : Fonctionnel et Infrastructure.
Les deux architectures partagent le même ensemble de normes à différentes couches d'une entreprise. L'existence d'une architecture de microservices découle de la réussite d'un modèle SOA. Par conséquent, le modèle d'architecture de microservices est un sous-ensemble de l'architecture SOA. Ici, l'accent est mis sur l'autonomie d'exécution de chaque service.
Avantages des microservices
Agilité
Étant donné que les petites équipes indépendantes développent généralement un service au sein de microservices, cela encourage les équipes à adopter des pratiques Agile. Les équipes sont habilitées à travailler de manière autonome et à agir rapidement, ce qui réduit les temps de cycle de développement.
Une évolutivité flexible
Étant donné que les microservices sont distribués par design et peuvent être déployés dans des clusters, ils permettent une mise à l'échelle horizontale dynamique à travers les limites de service. Si un microservice atteint sa capacité de charge, de nouvelles instances de ce service peuvent être rapidement déployées sur le cluster attenant afin de réduire la pression.
Livraisons fréquentes
L'un des principaux avantages des microservices est la fréquence et la rapidité des cycles de livraison. En tant qu'élément clé de l'intégration continue et de la livraison continue (CI/CD), les microservices permettent aux équipes de tester de nouvelles fonctionnalités et de revenir en arrière en cas de problème. Cela facilite la mise à jour du code et accélère la commercialisation de nouvelles fonctionnalités.
Flexibilité technologique
Les architectures de microservices ne suivent pas nécessairement une approche définie avec une chaîne d'outils, mais donnent aux équipes la liberté de sélectionner les outils qu'elles souhaitent.
Privilégier la qualité
La séparation des préoccupations métier en microservices indépendants implique que l'équipe de service propriétaire de ce service se concentre entièrement sur la qualité du livrable.
Fiabilité élevée
En séparant les fonctionnalités, les microservices réduisent le risque de rompre toute une app ou une base de code lors de la livraison de mises à jour. Il est facile d'isoler et de corriger les pannes ainsi que les bugs des services individuels. Vous pouvez déployer des changements uniquement pour un service spécifique, sans interrompre l'ensemble de l'app, ce qui améliore la fiabilité.
Défis liés aux microservices
Développement tentaculaire
Lorsque vous migrez un monolithe vers des microservices, vous augmentez la complexité. En effet, vous avez plus de services dans un plus grand nombre d'emplacements créés par plusieurs équipes. Par conséquent, il est difficile de voir comment les différents composants sont liés les uns aux autres, à qui appartient un composant spécifique et comment éviter les répercussions négatives sur des composants dépendants. Si cette multiplication n'est pas gérée, elle freine le développement et dégrade les performances opérationnelles. À mesure qu'un système se développe, il nécessite une équipe opérationnelle expérimentée pour gérer les redéploiements constants et les changements fréquents dans l'architecture.
Manque de responsabilité claire
Une architecture de microservices ajoute de la confusion quant aux différentes responsabilités. Une équipe DevOps peut exécuter une combinaison d'API, de bibliothèques de composants, d'outils de surveillance et d'images Docker pour permettre aux utilisateurs de déployer une app. Il est important d'avoir un aperçu des informations sur les composants, y compris leurs propriétaires, leurs ressources et l'évolution des relations entre les autres composants. La communication et la coordination entre de nombreuses équipes doivent être précises afin que toutes les personnes impliquées puissent facilement trouver les connaissances nécessaires à la compréhension d'un produit.
Coûts d'infrastructure exponentiels
Chaque nouveau microservice ajouté au déploiement en production entraîne son propre coût en termes de suite de tests, de playbooks de déploiement, d'infrastructure d'hébergement, d'outils de surveillance, et bien plus encore.
Frais organisationnels supplémentaires
Un niveau supplémentaire de communication et de collaboration est nécessaire à la coordination des mises à jour et des interfaces entre les équipes d'architecture de microservices.
Débogage
Il peut être difficile de déboguer une app qui contient plusieurs microservices, chacun ayant son propre ensemble de journaux. Un seul processus métier peut s'exécuter sur plusieurs machines à différents moments, ce qui complique encore le débogage.
Réponse aux incidents
Il est important de disposer d'informations sur la réponse aux incidents de microservices, notamment qui utilise le microservice, où et comment le microservice a été déployé, et qui contacter en cas de problème.
Microservices et DevOps : du pareil au même
Compte tenu de la complexité et des dépendances croissantes des microservices, les pratiques DevOps de déploiement, de surveillance et d'automatisation du cycle de vie sont considérées comme faisant partie intégrante des architectures de microservices. C'est pourquoi les microservices sont souvent considérés comme la première étape vers l'adoption d'une culture DevOps, assurant les avantages suivants :
- Automatisation
- Évolutivité supérieure
- Facilité de gestion
- Agilité
- Livraison et déploiement plus rapides
Technologies et outils clés pour une architecture de microservices
Conteneurs, Docker et Kubernetes
Un conteneur désigne simplement l'empaquetage d'une app et de toutes ses dépendances, ce qui permet des déploiements faciles et cohérents. Étant donné que les conteneurs n'ont pas la charge de leur propre système d'exploitation, ils sont plus petits et plus légers que les machines virtuelles traditionnelles. Ils peuvent être mis en place et supprimés plus rapidement, ce qui en fait une solution idéale pour les petits services que l'on trouve dans les architectures de microservices.
Avec la prolifération des services et des conteneurs, il est essentiel d'orchestrer et de gérer de grands groupes de conteneurs. Docker est une plateforme de conteneurisation populaire et un environnement d'exécution qui permet aux développeurs de créer, de déployer et d'exécuter des conteneurs. Cependant, l'exécution et la gestion des conteneurs à grande échelle constituent un défi avec Docker seul. Kubernetes et d'autres solutions comme Docker Swarm, Mesos, HashiCorp Nomad aident à gérer la conteneurisation à grande échelle.
La conteneurisation et le déploiement de conteneurs constituent un nouveau modèle d'infrastructure distribuée. Docker et Kubernetes intègrent un service dans un conteneur complet qui peut être rapidement déployé et supprimé. Ces nouveaux outils d'infrastructure sont complémentaires à l'architecture de microservices. Les microservices peuvent être conteneurisés, facilement déployés et gérés à l'aide d'un système de gestion de conteneurs.
Passerelles d'API
Dans une architecture de microservices, les services individuels communiquent entre eux par le biais d'API bien définies. Une passerelle d'API agit en tant que proxy inverse en acceptant les appels d'API, en collectant les services pour les exécuter et en renvoyant les résultats. Les passerelles d'API fournissent une abstraction desservant un seul point de terminaison d'API, même si les API sont gérées par plusieurs microservices. Les passerelles d'API peuvent également consolider des préoccupations telles que la limitation du débit, la surveillance, l'authentification, l'autorisation et le routage vers le microservice approprié.
Messages et diffusion d'événements
En raison de la nature distribuée des microservices, les équipes ont besoin d'un moyen pour partager les changements d'état et d'autres événements. Les systèmes de messagerie communiquent entre les microservices, ce qui permet à certains microservices de traiter des événements dans le cadre de leur interface principale. Par exemple, les changements apportés aux pages Confluence entraînent un événement qui déclenche une réindexation des recherches et l'envoi de notifications aux personnes qui suivent la page.
Journalisation et surveillance
Les microservices compliquent l'identification d'un problème et sa résolution dans plusieurs services. Il est important de disposer d'outils d'observabilité pour la journalisation, la surveillance et le suivi. Cela permet de comprendre le comportement des microservices, d'identifier les problèmes potentiels, de les résoudre et de corriger les défaillances.
Intégration et livraison continues
L'un des principaux avantages des microservices est la fréquence et la rapidité des cycles de livraison. En tant qu'élément clé de la CI/CD, les microservices permettent aux équipes de tester de nouvelles fonctionnalités et de revenir en arrière en cas de problème. Cela facilite la mise à jour du code et accélère la commercialisation de nouvelles fonctionnalités.
Portail des développeurs
À mesure que les architectures distribuées gagnent en complexité, les équipes de développement peuvent bénéficier d'un outil qui consolide les informations sur les résultats d'ingénierie et la collaboration des équipes en un seul et même endroit. Par exemple, Atlassian Compass a été conçu pour aider à maîtriser la prolifération des microservices en fournissant des données et des informations sur l'ensemble des chaînes d'outils DevOps.
L'avenir des microservices
La conteneurisation et le déploiement de conteneurs constituent désormais un modèle d'infrastructure distribuée courant. Des outils comme Docker et Kubernetes intègrent un service dans un conteneur complet qui peut être rapidement déployé et supprimé. Ces nouveaux outils d'infrastructure sont complémentaires à l'architecture de microservices, car les microservices peuvent être conteneurisés, facilement déployés et gérés à l'aide d'un système de gestion de conteneurs.
L'adoption des microservices doit être considérée comme un parcours plutôt que comme un objectif immédiat pour une équipe.
Il peut être utile de commencer petit pour comprendre les exigences techniques d'un système distribué et mettre à l'échelle des composants individuels. Ensuite, vous pouvez progressivement extraire plus de services à mesure que vous gagnez de l'expérience et des connaissances.
Naviguez dans vos microservices grâce à Compass
Lorsque vous travaillez avec une architecture de microservices, Atlassian Compass gère la complexité d'une architecture distribuée évolutive. Il s'agit d'une plateforme de partage d'expériences extensible qui rassemble des informations déconnectées sur tous les résultats d'ingénierie et la collaboration des équipes dans un emplacement central et interrogeable. En plus de vous aider à limiter la prolifération de vos microservices grâce au catalogue de composants, Compass peut vous aider à établir des bonnes pratiques et à évaluer l'intégrité de votre logiciel à l'aide de cartes de performance, et vous fournir des données ainsi que des analyses sur l'ensemble de votre chaîne d'outils DevOps à l'aide d'extensions basées sur la plateforme Atlassian Forge.
