Les microservices, ou architecture de microservices, sont une approche architecturale cloud native dans laquelle une seule application est composée de nombreux composants ou services plus petits, faiblement couplés et déployables indépendamment.
Généralement, les microservices:
Bien qu’une grande partie du débat sur les microservices ait tourné 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 :
Les microservices peuvent également être compris en contraste avec les deux architectures d’application précédentes : l’architecture monolithique et l’architecture orientée services (« Service-oriented Architecture » ou 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 faiblement couplés, par opposition à l’approche monolithique d’une grande application étroitement couplée.
Les différences entre les microservices et l’architecture SOA sont moins évidentes. Bien que des contrastes techniques existent entre les deux, notamment en ce qui concerne le rôle de l’Enterprise Service Bus, il est plus facile de considérer la différence comme une question de champ d’application.
L’architecture SOA était un effort global pour uniformiser la façon dont tous les services Web d’une entreprise communiquent et s’intègrent les uns aux autres, alors que l’architecture des microservices est spécifique à une application.
Restez au fait des tendances les plus étonnantes du secteur dans le domaine de l’IA, de l’automatisation, des données et bien d’autres avec la newsletter Think. Consultez la Déclaration de confidentialité d’IBM.
Les microservices sont susceptibles d’être au moins aussi populaires auprès des dirigeants et des chefs de projet que des 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. En effet, les microservices reflètent mieux la façon dont de nombreux chefs d’entreprise souhaitent structurer et gérer leurs équipes et leurs processus de développement.
En d’autres termes, les microservices sont un modèle architectural qui facilite mieux le modèle opérationnel souhaité. Dans une enquête IBM réalisée en 2021 auprès de plus de 1 200 développeurs et responsables informatiques, 87 % des utilisateurs de microservices ont reconnu que l’adoption des microservices justifiait les dépenses et les efforts consentis.
Voici quelques-uns des avantages des microservices pour les entreprises :
La caractéristique la plus importante des microservices est peut-être le fait que, les services étant plus petits et pouvant être déployés de manière indépendante, les implications légales pour modifier une ligne de code ou ajouter une nouvelle fonctionnalité à une application sont désormais bien moindres.
Les microservices promettent aux organisations un antidote contre les frustrations associées aux petits changements qui prennent énormément de temps. Personne n’a besoin d’un doctorat en informatique pour comprendre la valeur d’une approche qui facilite la vitesse et l’agilité.
Mais la rapidité n’est pas le seul atout de cette conception des services. Un modèle organisationnel émergent courant consiste à réunir des équipes transversales autour d’un enjeu commercial, d’un service ou d’un produit.
Le modèle des microservices s’inscrit parfaitement dans cette tendance, car il permet à une entreprise de créer de petites équipes transversales autour d’un service ou d’un ensemble de services et de les faire fonctionner de manière agile.
Le couplage lâche des microservices permet également d’isoler les pannes dans les applications et de rendre ces dernières plus résilientes. Enfin, la petite taille des services, combinée à leurs limites et à leurs modèles de communication clairement définis, permet aux nouveaux membres de l’équipe de comprendre plus facilement la base de code et d’y contribuer rapidement, ce qui constitue un avantage évident pour l’efficacité et le moral des employés.
Dans les modèles d’architecture traditionnels à x niveaux, une application partage généralement une pile commune, avec une grande base de données relationnelle qui prend 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 partager une pile, un modèle de données et une base de données communs, même s’il existe un outil manifestement plus adapté pour certains éléments. Cela crée une mauvaise architecture et contrarie les développeurs qui savent qu’il existe un moyen meilleur et plus efficace de créer ces composants.
En revanche, dans un modèle de microservices, les composants sont déployés indépendamment et communiquent par une combinaison de REST, de transmission d’événements en continu et de courtiers de messages. Il est donc possible d’optimiser la pile de chaque service pour ce service.
La technologie évolue en permanence, et il est beaucoup plus facile et moins coûteux de faire évoluer une application composée de plusieurs petits services en y incorporant la technologie souhaitée à mesure que celle-ci devient disponible.
Avec les microservices, les services individuels peuvent être déployés individuellement, mais ils peuvent également être mis à l’échelle individuellement. L’avantage qui en résulte est évident : bien mis en œuvre, les microservices nécessitent moins d’infrastructure que les applications monolithiques, car ils permettent une montée en charge précise des seuls composants qui en ont besoin, au lieu de l’ensemble de l’application dans le cas d’applications monolithiques.
Les avantages considérables des microservices s’accompagnent d’inconvénients importants. Passer d’un système monolithique à des microservices signifie une gestion beaucoup plus complexe : beaucoup plus de services, créés par beaucoup plus d’équipes, déployés dans beaucoup plus d’endroits.
Les problèmes d’un service peuvent provoquer ou être provoqués par des problèmes dans d’autres services.
Utilisées pour la surveillance et la résolution des problèmes, les données de journalisation sont plus volumineuses et peuvent être incohérentes d’un service à l’autre. Les nouvelles versions peuvent entraîner des problèmes de compatibilité avec une version antérieure.
Les applications exigent davantage de connexions réseau, ce qui multiplie les risques de latence et de difficultés de connectivité. Une approche DevOps peut résoudre bon nombre de ces problèmes, mais son adoption comporte ses propres défis.
Néanmoins, ces obstacles n’empêchent pas les novices d’adopter les microservices, ni les utilisateurs actuels de renforcer leur engagement en la matière. Les données de l’enquête IBM mentionnée ci-dessus révèlent que 56 % des non-utilisateurs actuels sont susceptibles ou très susceptibles d’adopter les microservices au cours des deux prochaines années.
Par conséquent, 78 % des utilisateurs actuels augmenteront probablement le temps, l’argent et les efforts investis dans les microservices.
L’architecture de microservices est souvent décrite comme optimisée pour le DevOps et l’intégration continue ou la livraison continue, et dans le contexte de petits services qui peuvent être déployés fréquemment, il est facile de comprendre pourquoi.
Mais une autre façon d’envisager la relation entre les microservices et le DevOps est que les architectures de microservices ont besoin du DevOps pour fonctionner.
Bien que les applications monolithiques présentent une série d’inconvénients (abordés plus haut dans cet article), elles présentent l’avantage de ne pas être un système distribué complexe, avec des pièces mobiles multiples et des piles technologiques indépendantes.
À l’inverse, étant donné l’augmentation massive de la complexité, des pièces mobiles et des dépendances qui accompagnent les microservices, il serait imprudent d’aborder ces derniers sans investir de façon significative dans le déploiement, la surveillance et l’automatisation du cycle de vie.
Découvrez une analyse plus approfondie du DevOps par Rosalind Radcliffe dans cette vidéo :
Bien que pratiquement tous les outils ou langages modernes puissent être utilisés dans une architecture de microservices, il existe une poignée d’outils fondamentaux qui sont devenus très importants, voire indispensables, pour les microservices :
L’un des éléments essentiels d’un microservice est qu’il est assez petit. Il n’y a pas de quantité arbitraire de code qui détermine si quelque chose est ou n’est pas un microservice, mais le préfixe « micro » est sans ambiguïté.
Lorsque Docker a inauguré l’ère moderne des conteneurs en 2013, il a également lancé le modèle informatique qui allait être le plus étroitement associé aux microservices. Comme les conteneurs individuels 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 et peuvent se mettre en marche 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 vastes groupes de conteneurs sont rapidement devenues l’un des principaux défis. Kubernetes, une plateforme d’orchestration de conteneurs open source, s’est imposée comme l’une des solutions les plus populaires pour son efficacité.
Les microservices communiquent souvent par le biais d’API, en particulier lors de l’établissement de leur état. S’il est vrai que les clients et les services peuvent communiquer directement entre eux, les passerelles d’API constituent souvent une couche intermédiaire utile, en particulier lorsque le nombre de services d’une application augmente au fil du temps.
Une passerelle d’API fait office de proxy inverse pour les clients en acheminant les demandes, en les diffusant sur plusieurs services et en fournissant une sécurité et une authentification supplémentaires.
De nombreuses technologies peuvent être utilisées pour implanter des passerelles d’API, notamment des plateformes de gestion des API. Mais si l’architecture des microservices est mise en œuvre à l’aide de conteneurs et de Kubernetes, la passerelle est généralement implantée par l’intermédiaire d’Ingress ou, plus récemment, d’Istio.
Même si les bonnes pratiques préconisent la conception de services sans état, l’état est néanmoins une réalité et les services doivent en être conscients. Et si un appel API est souvent un moyen efficace d’établir initialement l’état d’un service particulier, ça l’est moins pour rester à jour. L’approche consistant à interroger en permanence les services pour savoir s’ils sont à jour se révèle peu pratique.
Il est donc nécessaire de coupler les appels API d’établissement de l’état avec la messagerie ou la transmission d’événements en continu afin que les services puissent transmettre les changements d’état. De cette façon, les autres parties intéressées peuvent capter ces changements et s’adapter en conséquence.
Ce travail convient probablement mieux à un courtier de messages polyvalent, mais une plateforme de transmission d’événements en continu, telle qu’Apache Kafka, pourrait être appropriée dans certains cas. En alliant les microservices à l’architecture pilotée par les événements, les développeurs peuvent créer des systèmes distribués, hautement évolutifs, résistants aux pannes et adaptables, capables de consommer et de traiter de grandes quantités d’événements ou d’informations en temps réel.
Les architectures sans serveur reprennent certains des principaux modèles de cloud et de microservices et les poussent jusqu’à leur conclusion logique. Dans le cas du sans serveur, l’unité d’exécution n’est pas seulement 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 que les microservices.
Si les architectures sans serveur et les plateformes de fonctions en tant que service partagent des affinités avec les microservices, c’est qu’elles entendent toutes deux créer des unités de déploiement plus petites et effectuer la montée en charge de façon précise en fonction de la demande.
Les microservices ne sont pas nécessairement liés exclusivement au cloud computing. Cependant, quelques raisons importantes expliquent pourquoi ils vont si souvent de pair. Ces raisons vont au-delà du fait que les microservices sont un style architectural populaire pour les nouvelles applications et que le cloud est une destination d’hébergement très prisée pour les nouvelles applications.
Les principaux avantages de l’architecture de microservices sont le déploiement et la montée en charge des composants de manière individuelle, ainsi que les avantages en matière d’utilisation et de coûts qui en découlent.
Bien que ces avantages soient toujours présents dans une certaine mesure avec l’infrastructure sur site, la combinaison de petits composants évolutifs indépendamment associés à une infrastructure à la demande et facturée à l’utilisation permet de parvenir à une véritable optimisation des coûts.
Deuxièmement, et peut-être plus important encore, un autre avantage de taille des microservices est que chaque composant peut adopter la pile la plus adaptée à sa tâche spécifique. La prolifération des piles peut entraîner une complexité et des frais importants lorsque vous la gérez vous-même, mais l’utilisation de la pile de soutien en tant que services cloud peut considérablement minimiser les problèmes de gestion.
En d’autres termes, s’il n’est pas impossible de déployer votre propre infrastructure de microservices, cela n’est pas conseillé, surtout lorsque vous débutez.
Les architectures de microservices comportent de nombreux modèles de conception, de communication et d’intégration courants et utiles qui permettent de relever certains défis et de saisir certaines opportunités, notamment :
Ce modèle insère une couche entre l’expérience utilisateur et les ressources sollicitées par cette expérience. Par exemple, une application utilisée sur un ordinateur de bureau aura une taille d’écran, un affichage et des limites de performance différents de ceux d’un appareil mobile.
Le modèle BFF (Backend pour le Frontend) 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 qui peut avoir un impact négatif sur les performances du frontend.
Une entité est un objet qui se distingue par son identité. Par exemple, un article sur un site de commerce électronique peut être identifié par son nom, son type et son prix. Un agrégat est une collection d’entités connexes qui doivent être traitées comme une seule unité.
Ainsi, pour le site de commerce électronique, une commande serait une collection (agrégat) d’articles (entités) commandés par un acheteur. Ces modèles servent à classer les données avec pertinence.
Ils aident les applications et les services à communiquer entre eux. Dans une architecture de microservices, les instances de service changent de manière dynamique en raison de la mise à l’échelle, des mises à niveau, des défaillances de service et même de son arrêt.
Ces modèles fournissent des mécanismes de découverte pour faire face à cette transition. L’équilibrage de charge peut faire appel à des modèles de découverte de services en utilisant les contrôles de santé et les défaillances de services comme déclencheurs pour rééquilibrer le trafic.
Les modèles d’adaptateurs sont comme les adaptateurs de prise de courant employés lors d’un voyage à l’étranger. Leur but est d’aider à traduire les relations entre des classes ou des objets autrement incompatibles. Une application qui s’appuie sur des API tierces peut avoir besoin d’un modèle d’adaptateur pour s’assurer que l’application et les API peuvent communiquer.
Ces modèles aident à gérer la transformation d’une application monolithique en applications microservices. Le nom coloré fait référence à la façon dont une vigne (microservices) envahit lentement et progressivement un arbre (application monolithique) et l’étrangle.
Bien qu’il existe de nombreux modèles pour gérer correctement les microservices, il existe un nombre tout aussi important de modèles qui peuvent rapidement causer des ennuis à n’importe quelle équipe de développement. Voici quelques-uns d’entre eux, qui ont été reformulés comme « pratiques à éviter » :
En d’autres termes, ne commencez pas par les microservices. Ces derniers permettent de gérer la complexité une fois que les applications sont devenues trop volumineuses et trop lourdes pour être mises à jour et maintenues facilement. Ce n’est que lorsque vous commencez à ressentir les difficultés et la complexité du monolithique que vous pouvez envisager de refondre l’application en services plus petits. Avant cela, aucun remaniement n’est vraiment nécessaire.
Développer des microservices signifie créer des systèmes distribués, ce qui est particulièrement difficile si vous ne faites pas les bons choix. Tenter de mettre en place des microservices sans une automatisation adaptée du déploiement et de la surveillance, ou 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. Évitez-les et consacrez-vous à l’état de l’infrastructure.
Si vous prenez le préfixe « micro » de façon trop littérale dans les microservices, vous risquez de vous retrouver avec des frais généraux et une complexité qui dépassent les gains globaux d’une architecture de microservices.
Il est préférable de s’orienter vers des services plus importants et de ne les fractionner que lorsqu’ils commencent à développer des caractéristiques que les microservices résolvent, à 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 système ont des exigences différentes en matière de charge/d’échelle.
Les microservices et l’architecture SOA sont souvent confondus, étant donné qu’à leur niveau le plus élémentaire, ils visent tous deux à construire des composants individuels réutilisables qui peuvent être consommés par d’autres applications.
La différence entre les microservices et l’architecture SOA réside dans le fait que les projets de microservices impliquent généralement le remaniement d’une application afin d’en faciliter la gestion, tandis que l’architecture SOA modifie la manière dont les services informatiques fonctionnent à l’échelle de l’entreprise. Un projet de microservices qui devient un projet SOA risque de crouler sous son propre poids.
Netflix a été l’un des premiers pionniers de l’architecture microservices en créant et en gérant une application qui représentait un tiers de l’ensemble du trafic Internet.
Ce parfait concours de circonstances l’a obligé à créer un grand nombre de codes et de services personnalisés qui ne sont pas nécessaires pour une application ordinaire. Il est préférable de commencer à un rythme réaliste, d’éviter la complexité et d’utiliser le plus grand nombre possible d’outils prêts à l’emploi.
Si vous souhaitez en savoir plus sur l’utilisation des microservices, ou si vous avez besoin de renforcer vos compétences en la matière, essayez l’un de ces tutoriels :
Exploitez le pouvoir de l’IA et de l’automatisation pour résoudre de manière proactive les problèmes de la pile d’applications.
Utilisez les logiciels et outils DevOps pour construire, déployer et gérer des applications cloud natives sur plusieurs appareils et environnements.
Renforcez l’agilité et la croissance de votre entreprise. Modernisez en continu vos applications sur n’importe quelle plateforme grâce à nos services de conseil cloud.