Microservices

menu icon

Microservices

L'architecture de microservices est une approche dans laquelle une application unique est composée de nombreux petits services liés de façon souple et pouvant être déployés de manière indépendante.

Que sont les microservices ?

Les microservices (ou architecture de microservices) sont une approche architecturale native cloud dans laquelle une application unique est composée de nombreux petits composants, ou services, liés de façon souple et pouvant être déployés de manière indépendante. En règle générale, ces services

  • disposent de leur propre pile technologique, y compris la base de données et le modèle de gestion des données,
  • communiquent les uns avec les autres par une combinaison d'API REST, de flux d'événements et de courtiers de messages, et
  • sont organisés par fonctionnalités métier, la ligne séparant les services étant généralement appelée contexte délimité.

Si une grande partie du débat sur les microservices tourne autour des définitions et des caractéristiques architecturales, leur valeur peut être plus communément comprise à travers des avantages commerciaux et organisationnels assez simples :

  • Le code peut être mis à jour plus facilement : de nouvelles fonctions ou fonctionnalités peuvent être ajoutées sans toucher à l'ensemble de l'application.
  • Les équipes peuvent utiliser différentes piles et différents langages de programmation pour les différents composants.
  • Les composants peuvent être mis à l'échelle indépendamment les uns des autres, afin de réduire le gaspillage et les coûts associés à la mise à l'échelle d'applications entières parce qu'une seule fonction pourrait être confrontée à une charge trop importante.

Les microservices peuvent être également compris par ce qu'ils ne sont pas. Les deux comparaisons les plus fréquentes avec l'architecture de microservices sont l'architecture monolithique et l'architecture orientée services (SOA).

La différence entre les microservices et l'architecture monolithique réside dans le fait que les microservices composent une application unique à partir de nombreux services plus petits et couplés de façon souple, par opposition à l'approche monolithique d'une grande application étroitement couplée.

Pour en savoir plus sur les différences entre les microservices et une architecture monolithique, regardez cette vidéo (6:37) :

 

Les différences entre les microservices et l'architecture SOA peuvent être un peu moins évidentes. Bien que l'on puisse établir des contrastes techniques entre les microservices et l'architecture SOA, notamment en ce qui concerne le rôle du bus ESB (Enterprise Service Bus), il est plus facile de considérer la différence comme une question de périmètre d'application. L'architecture SOA constitue un effort à l'échelle de l'entreprise pour normaliser la manière dont tous les services Web d'une organisation communiquent entre eux et s'intègrent les uns aux autres, tandis que l'architecture de microservices est spécifique à une application.

L'article « SOA vs. Microservices: What's the Difference? » fournit plus d'informations.

Les avantages des microservices pour l'organisation

Les microservices sont susceptibles d'être au moins autant plébiscités par les dirigeants d'entreprise et les chefs de projet que par les développeurs. Il s'agit de l'une des caractéristiques les plus inhabituelles des microservices, car l'enthousiasme pour l'architecture est généralement réservé aux équipes de développement de logiciels. La raison : les microservices reflètent mieux la manière dont de nombreux chefs d'entreprise souhaitent structurer et diriger leurs équipes et leurs processus de développement.

En d'autres termes, les microservices sont un modèle architectural qui facilite davantage un modèle opérationnel souhaité. Dans une récente enquête d'IBM réalisée auprès de plus de 1 200 développeurs et responsables informatiques, 87 % des utilisateurs de microservices s'accordent à dire que l'adoption des microservices en vaut la peine, en termes d'investissement et d'efforts. Vous pouvez explorer d'autres perspectives sur les avantages et les défis des microservices en utilisant l'outil interactif ci-dessous :

(Source : « Microservices in the enterprise 2021: Real benefits, worth the challenges »)

Voici quelques-uns des avantages des microservices pour l'entreprise.

Déployables de manière indépendante

La caractéristique la plus importante des microservices est sans doute le fait que, les services étant plus petits et pouvant être déployés indépendamment, une prise de décision venue « d'en haut » n'est plus nécessaire pour modifier une ligne de code ou ajouter une nouvelle fonction dans une application.

Les microservices promettent aux organisations un antidote aux frustrations viscérales associées aux petits changements très chronophages. Il n'est pas nécessaire d'avoir un doctorat en informatique pour voir ou comprendre la valeur d'une approche qui facilite la rapidité et l'agilité.

Mais la rapidité n'est pas le seul avantage de cette méthode de conception des services. Un modèle organisationnel émergent courant consiste à rassembler des équipes interfonctionnelles autour d'une problématique métier, d'un service ou d'un produit. Le modèle des microservices s'inscrit parfaitement dans cette tendance, car il permet à une organisation de créer de petites équipes interfonctionnelles autour d'un service ou d'un ensemble de services et de les faire fonctionner de manière agile.

Le faible couplage des microservices permet également d'isoler les défauts et d'améliorer la résilience des applications. De plus, la petite taille des services, associée à leurs limites et à leurs modèles de communication clairs, permet aux nouveaux membres de l'équipe de comprendre plus facilement le codebase et d'y contribuer rapidement, un avantage évident en termes de rapidité et de moral pour les employés.

L'outil adapté au travail

Dans les modèles d'architecture multi-niveaux traditionnels, une application partage généralement une pile commune et une grande base de données relationnelle prenant en charge l'ensemble de l'application. Cette approche présente plusieurs inconvénients évidents, dont le plus important est que chaque composant d'une application doit avoir en commun une pile, un modèle de données et une base de données, même s'il existe un outil clairement plus efficace pour la tâche pour certains éléments. Cela donne une mauvaise architecture, et c'est frustrant pour les développeurs qui savent qu'il existe une meilleure façon, plus efficace, de créer ces composants.

En revanche, dans un modèle de microservices, les composants sont déployés de manière indépendante et communiquent par une combinaison REST, de diffusion en flux d'événements et de courtiers de messages, de sorte que la pile de chaque service peut être optimisée pour le service. La technologie évolue en permanence, et une application composée de plusieurs petits services est beaucoup plus facile et moins coûteuse à faire évoluer vers une technologie plus souhaitable dès qu'elle est disponible.

Une mise à l'échelle précise

Avec les microservices, les services peuvent être déployés individuellement, mais également mis à l'échelle individuellement. L'avantage qui en résulte est évident : Correctement mis en œuvre, les microservices nécessitent moins d'infrastructure que les applications monolithiques, car ils permettent une mise à l'échelle précise des seuls composants qui le nécessitent, au lieu de l'application entière dans le cas des applications monolithiques.

Il existe aussi des défis

Les avantages considérables des microservices s'accompagnent de défis importants. Passer d'un système monolithique à des microservices est synonyme d'une plus grande complexité de gestion : beaucoup plus de services, créés par beaucoup plus d'équipes, déployés dans beaucoup plus d'endroits. Des problèmes dans un service peuvent causer, ou être causés par, des problèmes dans d'autres services. Les données de consignation (utilisées pour la surveillance et la résolution des problèmes) sont plus volumineuses et peuvent être incohérentes entre les services. Les nouvelles versions peuvent causer des problèmes de rétrocompatibilité. Les applications impliquent davantage de connexions réseau, ce qui peut entraîner un plus grand de problèmes de latence et de connectivité. Une approche DevOps (comme nous le verrons ci-après) peut résoudre bon nombre de ces problèmes, mais l'adoption de DevOps comporte ses propres défis.

Néanmoins, ces défis n'empêchent pas les non-adoptants d'adopter les microservices ou les adoptants d'approfondir leur engagement envers les microservices. Une nouvelle enquête d'IBM révèle que 56 % des non-utilisateurs actuels sont susceptibles ou très susceptibles d'adopter les microservices dans les deux prochaines années, et que 78 % des utilisateurs actuels des microservices augmenteront probablement le temps, les investissements et les efforts dévoluent aux microservices (voir la figure 1).

Trois graphiques circulaires représentant 56 pour cent, 78 pour cent et 59 pour cent

Figure 1 : Les microservices sont là pour rester. Au cours des deux prochaines années, 56 % des non-utilisateurs adopteront probablement les microservices, 78 % des utilisateurs augmenteront leurs investissements dans les microservices, et 59 % des applications seront créées avec des microservices. (Source : « Microservices in the enterprise 2021: Real benefits, worth the challenges »)

Les microservices mettent en œuvre et nécessitent DevOps

L'architecture de microservices est souvent décrite comme optimisée pour DevOps et l'intégration continue/la distribution continue (CI/CD), et dans le contexte de petits services pouvant être déployés fréquemment, il est facile de comprendre pourquoi.

Mais il existe une autre façon d'envisager la relation entre les microservices et DevOps : les architectures de microservices ont en fait besoin de DevOps pour être efficaces. Si les applications monolithiques présentent toute une série d'inconvénients qui ont été évoqués plus haut dans cet article, elles ont l'avantage de ne pas être un système réparti complexe comportant de multiples pièces mobiles et des piles technologiques indépendantes. En revanche, compte tenu de l'augmentation massive de la complexité, des pièces mobiles et des dépendances qui accompagnent les microservices, il serait imprudent d'aborder les microservices sans investir massivement dans le déploiement, le contrôle et l'automatisation du cycle de vie.

Dans la vidéo suivante, Andrea Crawford propose de s'immerger d'avantage dans le DevOps :

Principaux outils et technologies habilitants

Si pratiquement tous les outils ou langages modernes peuvent être utilisés dans une architecture de microservices, il existe quelques outils de base qui sont devenus essentiels et presque incontournables pour les microservices :

Conteneurs, Docker et Kubernetes

L'un des éléments essentiels d'un microservice est qu'il est généralement assez petit (il n'existe pas de quantité arbitraire de code qui détermine si quelque chose est ou n'est pas un microservice, mais « micro » est bien là dans le nom).

Lorsque Docker a inauguré l'ère moderne des conteneurs en 2013, il a également introduit le modèle de calcul qui allait devenir le plus étroitement associé aux microservices. Comme les conteneurs individuels n'ont pas la surcharge de leur propre système d'exploitation, ils sont plus petits et plus légers que les machines virtuelles traditionnelles et peuvent démarrer et s'arrêter plus rapidement, ce qui les rend parfaitement adaptés aux services plus petits et plus légers que l'on trouve dans les architectures de microservices.

Avec la prolifération des services et des conteneurs, l'orchestration et la gestion de grands groupes de conteneurs sont rapidement devenues l'un des défis majeurs. Kubernetes, plateforme open source d'orchestration de conteneurs, s'est imposée comme l'une des solutions d'orchestration les plus prisées parce qu'elle remplit très bien cette fonction.

Dans la vidéo « Kubernetes Explained », Sai Vennam donne une vue d'ensemble de tout ce qui concerne Kubernetes :

 

Passerelles API

Les microservices communiquent souvent par l'intermédiaire d'une API, notamment lors de l'établissement initial de l'état. S'il est vrai que les clients et les services peuvent communiquer directement entre eux, les passerelles API constituent souvent une couche intermédiaire utile, surtout lorsque le nombre de services d'une application augmente au fil du temps. Une passerelle API agit comme un proxy inverse pour les clients en acheminant les demandes, en répartissant les demandes entre plusieurs services et en renforçant la sécurité et l'authentification.

Plusieurs technologies peuvent être utilisées pour mettre en œuvre des passerelles API, y compris des plateformes de gestion d'API, mais si l'architecture de microservices est implémentée à l'aide de conteneurs et de Kubernetes, la passerelle est généralement mise en œuvre à l'aide d'Ingress ou, plus récemment, d'Istio.

Messagerie et diffusion en flux des événements

Même si la meilleure pratique consiste à concevoir des services sans état, l'état existe néanmoins, et les services doivent le savoir. Et si un appel API constitue souvent un moyen efficace d'établir initialement l'état d'un service donné, ce n'est pas un moyen particulièrement efficace de rester à jour. En effet, il n'est pas pratique de maintenir les services à jour en procédant constamment à des interrogations et en se demandant si l'on a atteint le but.

En revanche, il est nécessaire de coupler les appels API d'établissement d'état avec la messagerie ou la diffusion en flux des événements, afin que les services puissent diffuser les changements d'état et que les autres parties intéressées puissent écouter ces changements et s'adapter en conséquence. Cette tâche est probablement mieux adaptée à un courtier de messages polyvalent, mais il existe des cas de figure où une plateforme de diffusion en flux des événements, telle qu'Apache Kafka, pourrait convenir. En combinant les microservices avec une architecture événementielle, les développeurs peuvent construire des systèmes répartis hautement évolutifs, tolérants aux pannes et extensibles, capables de consommer et de traiter de très grandes quantités d'événements ou d'informations en temps réel.

Sans serveur

Les architectures sans serveur poussent jusqu'à leur conclusion logique certains des principaux modèles de cloud et de microservices. Dans le cas d'une architecture sans serveur, l'unité d'exécution n'est pas un petit service, mais une fonction qui peut souvent se résumer à quelques lignes de code. La frontière entre une fonction sans serveur et un microservice est floue, mais les fonctions sont généralement considérées comme étant encore plus petites qu'un microservice.

Là où les architectures sans serveur et les plateformes de fonctions sous forme de service (FaaS) ont des affinités avec les microservices, c'est qu'elles cherchent toutes deux à créer de petites unités de déploiement et à les adapter précisément à la demande.

Microservices et services cloud

Les microservices ne sont pas nécessairement exclusivement pertinents pour le cloud computing, mais il existe plusieurs raisons importantes pour lesquelles ils vont si souvent de pair, des raisons qui vont au-delà du fait que les microservices sont un style architectural courant pour les nouvelles applications et que le cloud est une destination d'hébergement largement utilisée pour les nouvelles applications.

Les avantages en termes d'utilisation et de coûts associés au déploiement et à la mise à l'échelle de composants individuels font partie des avantages de l'architecture de microservices. Bien que ces avantages existent toujours, dans une certaine mesure, avec une infrastructure sur site, la combinaison de petits composants évolutifs de manière indépendante et d'une infrastructure à la demande et facturée à l'utilisation permet réellement d'optimiser les coûts.

Ensuite, et c'est peut-être plus important, un autre avantage majeur des microservices est que chaque composant individuel peut adopter la pile la mieux adaptée à sa tâche spécifique. La prolifération de piles peut entraîner une complexité et une surcharge importantes si vous la gérez vous-même, mais la consommation de la pile sous-jacente sous forme de services cloud peut réduire considérablement les problèmes de gestion. En d'autres termes, même s'il n'est pas impossible de déployer votre propre infrastructure de microservices, ce n'est pas conseillé, surtout au début.

Modèles communs

Dans les architectures de microservices, il existe de nombreux modèles communs de conception, de communication et d'intégration qui sont utiles et permettent de répondre à certains des défis et opportunités les plus courants, notamment :

  • Modèle BFF (backend-for-frontend) : Ce modèle insère une couche entre l'expérience utilisateur et les ressources auxquelles cette expérience fait appel. Par exemple, une application utilisée sur un ordinateur de bureau aura des limites de taille d'écran, d'affichage et de performance différentes de celles d'un appareil mobile. Le modèle BFF permet aux développeurs de créer et de prendre en charge un type de backend par interface utilisateur en utilisant les meilleures options pour cette interface, plutôt que d'essayer de prendre en charge un backend générique qui fonctionne avec n'importe quelle interface mais peut avoir un impact négatif sur les performances du frontend.
  • Modèles d'entité et d'agrégation : Une entité est un objet qui se distingue par son identité. Par exemple, sur un site de commerce électronique, un objet Produit peut se distinguer par son nom, son type et son prix. Un agrégat est une collection d'entités associées qui doivent être traitées comme une seule unité. Ainsi, pour le site de commerce électronique, une commande est une collection (agrégat) de produits (entités) commandés par un acheteur. Ces modèles sont utilisés pour classer les données de manière significative.
  • Modèles de reconnaissance de service : Ils aident les applications et les services à se trouver. Dans une architecture de microservices, les instances de service changent dynamiquement en raison de la mise à l'échelle, des mises à niveau, des défaillances de service, et même de l'arrêt du service. Ces modèles fournissent des mécanismes de reconnaissance pour faire face à cette situation transitoire. L'équilibrage de charge peut utiliser des modèles de reconnaissance de service en se servant des contrôles d'état et des défaillances de service comme de déclencheurs pour rééquilibrer le trafic.
  • Modèles d'adaptateurs de microservices : Les modèles d'adaptateur s'apparentent à ces adaptateurs électriques que vous utilisez lorsque vous vous rendez dans un autre pays. La fonction des modèles d'adaptateur est de traduire les relations entre des classes ou des objets qui sont incompatibles. Une application qui repose sur des API tierces peut nécessiter un modèle d'adaptateur pour garantir la communication entre l'application et les API.
  • Modèles d'application Strangler : Ces modèles permettent de gérer la restructuration d'une application monolithique en applications de microservices. Le nom pittoresque (étrangleur) fait référence à la façon dont, au fil du temps, une plante grimpante (microservices) envahit lentement un arbre (une application monolithique) et l'étrangle.

Pour en savoir plus sur ces modèles, consultez la section « Comment utiliser des modèles de développement avec les microservices (partie 4) ». IBM Developer fournit également beaucoup d'informations si vous souhaitez découvrir d'autres modèles de code de microservices.

Anti-modèles

S'il existe de nombreux modèles qui permettent de gérer efficacement les microservices, il en existe tout autant qui peuvent rapidement mettre en difficulté une équipe de développement. Voici une liste de choses à ne pas faire en matière de microservices :

  • Première règle des microservices : ne créez pas de microservices : Plus précisément, ne commencez pas par les microservices. Les microservices constituent un moyen de gérer la complexité lorsque les applications sont devenues trop volumineuses et trop lourdes pour être mises à jour et gérées facilement. Ce n'est que lorsque la difficulté et la complexité du monolithe commencent à apparaître qu'il convient de réfléchir à la façon dont vous pouvez restructurer l'application en services plus petits. Tant que vous ne ressentez pas cette difficulté, vous n'avez pas vraiment de monolithe à restructurer.
  • Ne créez pas de microservices sans DevOps ou sans services cloud : Créer des microservices signifie créer des systèmes répartis, et ces systèmes sont compliqués (particulièrement si vous faites des choix qui les compliquent encore davantage). Tenter de créer des microservices sans a) une automatisation adéquate du déploiement et de la surveillance ou b) des services cloud gérés pour prendre en charge votre infrastructure hétérogène et tentaculaire, c'est s'exposer à de nombreux problèmes inutiles. Épargnez-vous ces problèmes pour vous consacrer à l'état de l'infrastructure.
  • Ne créez pas un trop grand nombre de microservices en les rendant trop petits : Si vous allez trop loin avec le « micro » dans les microservices, vous pouvez facilement vous retrouver avec une surcharge et une complexité qui dépassent les gains globaux d'une architecture de microservices. Il est préférable d'opter pour des services de plus grande taille et de ne séparer ceux-ci que lorsqu'ils commencent à développer des caractéristiques auxquelles les microservices répondent, à savoir qu'il devient difficile et lent de déployer des changements, qu'un modèle de données commun devient trop complexe ou que différentes parties du service ont des exigences différentes en termes de charge et d'échelle.
  • Ne transformez pas les microservices en architecture SOA : Les microservices et l'architecture orientée services (SOA) sont souvent confondus dans la mesure où, à leur niveau le plus élémentaire, ils s'intéressent tous deux à la construction de composants individuels réutilisables qui peuvent être consommés par d'autres applications. La différence entre microservices et SOA réside dans le fait que les projets de microservices consistent généralement à restructurer une application pour en faciliter la gestion, tandis que l'architecture SOA vise à modifier le fonctionnement des services IT à l'échelle de l'entreprise. Un projet de microservices qui se transforme en projet SOA risque de céder sous son propre poids.
  • Ne vous prenez pas pour Netflix : Netflix a été l'un des premiers pionniers de l'architecture de microservices en créant et gérant une application qui représentait un tiers de l'ensemble du trafic Internet, une sorte de grande tempête qui a nécessité la création d'une importante quantité de code et de nombreux services personnalisés inutiles pour une application moyenne. Il est préférable de commencer à un rythme que vous pouvez gérer, d'éviter la complexité et d'utiliser autant d'outils prêts à l'emploi que possible.

Tutoriels : Développer ses compétences en microservices

Si vous voulez en savoir plus sur l'utilisation des microservices, ou si vous devez renforcer vos compétences dans ce domaine, essayez l'un de ces tutoriels :

Microservices et IBM Cloud

Les microservices permettent un développement innovant au rythme de l'entreprise moderne. Apprenez à tirer parti de l'évolutivité et de la flexibilité du cloud en déployant des microservices indépendants dans des environnements cloud. Découvrez comment moderniser vos applications avec l'aide d'IBM. 

Pour aller plus loin :

  • Libérez vos équipes de développement en vous appuyant sur l'itération automatisée à l'aide d'outils de développement IBM cloud natifs.
  • Découvrez-en plus sur Kubernetes géré en vous initiant à Red Hat OpenShift on IBM Cloud ou IBM Cloud Kubernetes Service. En outre, consultez IBM Cloud Code Engine pour plus d'informations sur le calcul sans serveur.
  • Les microservices concernent tout autant le processus et l'organisation de l'équipe que la technologie. Planifiez stratégiquement votre approche DevOps avec IBM DevOps.

Démarrez avec un compte IBM Cloud dès aujourd'hui.