Microservices
Fond bleu et noir
Définition des 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.

Les microservices (ou architecture de microservices) sont une approche architecturale cloud native 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 sur une combinaison d'API REST, de streaming d'événements et de courtiers de messages ; et
sont organisés par fonctionnalité métier, la ligne séparant les services étant souvent 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 fonctionnalités peuvent être ajoutées sans impacter 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.

Pour comprendre les microservices, il est également possible de définir ce qu'ils ne sont pas. L'architecture de microservices est le plus fréquemment comparée à l'architecture monolithique et l'architecture orientée services (SOA).

La différence entre l'architecture de microservices et l'architecture monolithique est que les microservices créent une application unique à partir de nombreux petits services liés de façon souple, par opposition à l'approche monolithique consistant en une application volumineuse liée de façon étroite.

Les différences entre les microservices et le SOA peuvent être un peu moins évidentes. S'il est possible de définir des différences techniques entre les microservices et l'architecture SOA, notamment autour du rôle du bus de service d'entreprise, il est plus facile de les différencier au niveau de la portée. L'architecture SOA constitue un effort à l'échelle de l'entreprise pour normaliser la manière dont tous les services Web d'une entreprise communiquent entre eux et s'intègrent les uns aux autres, tandis que l'architecture de microservices est spécifique à une application.

Le post "Architecture SOA et architecture de microservices : quelle différence ? " donne plus de détails.

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

Microservices dans l'entreprise, 2021 - Une nouvelle recherche d'IBM révèle les avantages et les défis de l'adoption des microservices.

S'inscrire pour télécharger l'e-book


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 enquête récente d'IBM auprès de plus de 1200 développeurs et cadres IT, 87 % des utilisateurs des 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.

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 de 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. 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'une approche monolithique aux microservices implique une complexité de gestion accrue, beaucoup plus de services créés par un bien plus grand nombre d'équipes, déployés dans beaucoup plus d'emplacements. 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 de nouvelles adoptions des microservices ni un engagement accru de ceux qui les ont déjà adoptés. Les données d'une nouvelle enquête d'IBM révèlent 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évolus aux microservices.

Modernisez vos applications pour l'interopérabilité et le retour sur investissements - Valorisez vos applications existantes et réduisez le coût de leur maintenance.

En savoir plus


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 requièrent le 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 :

Produits à la une

Red Hat OpenShift on IBM Cloud

IBM Cloud Kubernetes Service

IBM Cloud Code Engine


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 clés d'un microservice est qu'il est généralement assez petit. (Il n'y a pas de volume arbitraire de code qui détermine si l'on a à faire ou non à un microservice, mais ce nom comporte bel et bien le terme "micro".)

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. Sans système d'exploitation propre, les conteneurs individuels sont plus petits et plus légers que les machines virtuelles traditionnelles et peuvent démarrer et s'arrêter plus rapidement ; ils sont donc parfaitement adaptés aux services plus petits et plus légers des 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, une plateforme d'orchestration de conteneurs open source, s'est imposée comme l'une des solutions d'orchestration les plus populaires en raison de son extrême performance à ce niveau.

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.

Par contre, 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 pilotée par les événements, 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 FaaS (Functions-as-a-Service 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 forcément 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 :

  • Le 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égat :  Une entité est un objet distingué 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 détection de service :  Ils permettent aux applications et aux services de 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 la 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 de microservices d'adaptateur :  les modèles d'adaptateur doivent être considérés comme des adaptateurs de prise que vous utilisez lorsque vous allez 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èle 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.

Vous pouvez en savoir plus à propos de ces modèles dans "Comment utiliser des modèles de développement avec des microservices (partie 4)." IBM Developer fournit également beaucoup d'informations si vous souhaitez en savoir plus sur les 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 :

  • La première règle des microservices est de ne pas créer de microservices :plus précisément,ne démarrez pas avec des 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 vous commencez à vous rendre compte des difficultés et de la complexité de l'application monolithique qu'il peut s'avérer utile de réfléchir à la manière dont vous pourriez restructurer cette application en services plus petits. Tant que vous ne ressentez pas cette difficulté, il n'est pas vraiment nécessaire de la restructurer.
  • Ne créez pas de microservices sans DevOps ni services cloud : Créer des microservices signifie créer des systèmes distribués, or ces derniers sont complexes (ils le sont d'autant plus si vous faites des choix qui les complexifient 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 trop de microservices de trop petite taille : Si vous allez trop loin dans l'aspect "micro" au niveau des microservices, vous pourriez facilement générer des frais et une complexité qui vont l'emporter sur 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 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 tentez pas d'être 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.

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 les bénéfices de la modernisation de vos applications avec l'aide d'IBM.

Pour aller plus loin :

Commencez dès aujourd'hui avec un  compte IBM Cloud.   


Solutions connexes

Solutions de modernisation des applications

Créez, modernisez et gérez avec confiance les applications de façon sécurisée dans tous les clouds


Solutions cloud natives

Une plateforme native cloud, évolutive et fortement sécurisée


Red Hat OpenShift

D'un clic, déployez des clusters hautement disponibles et entièrement gérés


Kubernetes Service

Déployez des clusters sécurisés haute disponibilité dans un environnement Kubernetes natif.


Code Engine Solutions

Exécutez votre conteneur, votre code de l'application ou votre travail par lots sur un environnement d'exécution de conteneur entièrement géré .


DevOps Services

Créez, déployer et gérez des applications cloud natives hautement sécurisées sur plusieurs dispositifs, environnements et clouds avec les meilleures pratiques DevOps.