Que sont les microservices ?

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 :

Un déploiement indépendant

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é à l’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 organisation 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.

L’outil idéal pour chaque tâche

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 individuel 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.

Une mise à l’échelle précise

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 microservices présentent également des défis :

Les avantages considérables des microservices s’accompagnent de défis 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 rétrocompatibilité. 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, et que 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 les DevOps et l’intégration continue ou la distribution 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 les DevOps est que les architectures de microservices ont en fait besoin des 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 :

Les microservices ne sont pas nécessairement liés exclusivement au cloud computing, mais 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 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 :

Modèle services Backend pour le Frontend (BFF)

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.

Les modèles d’entité et d’agrégat

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.

Modèles de découverte de services

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

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.

Le modèle d’application d’étranglement

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 » :

Ne créez pas de microservices

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.

Ne faites pas de microservices sans DevOps ni services cloud

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. 

Ne créez pas un trop grand nombre de microservices en les rendant trop petits

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.

Ne transformez pas les microservices en architecture orientée services (« Service-oriented Architecture » ou SOA)

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.

N’essayez pas d’être Netflix

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 :

• Introduction aux microservices
  
• Laboratoire rapide : créer des microservices d’applications web hautement évolutifs avec Node.js
• À la découverte des microservices Java avec Spring Boot et Cloudant
  
• Créer, exécuter et déployer des microservices Spring en cinq minutes
  
• Microservices, SOA et API : amis ou ennemis ?