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 est que 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 portant sur plus de 1 200 développeurs et responsables informatiques, 87 % des utilisateurs de microservices s'accordent à dire que l'adoption des microservices offre des avantages en termes d'investissement et d'efforts. 

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

Déployables de manière indépendante

Ce qui caractérise principalement les microservices est sans doute le fait que les services étant plus petits et peuvent être déployés indépendamment. Aucune prise de décision venue « d'en haut » n'est plus nécessaire pour modifier une ligne de code ou ajouter une 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 transversales 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 transversales sur un service ou 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 à 3 niveaux traditionnels, une application partage généralement une pile commune, avec 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. Il en résulte une architecture de mauvaise qualité, ce qui est frustrant pour les développeurs qui savent qu'il existe une meilleure façon, plus performante, 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 en continu 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'ensemble de l'application 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. Une récente 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évolus aux microservices.

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'existe pas de volume arbitraire de code qui détermine si l'on a affaire 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. 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 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 prisées parce qu'elle remplit très bien cette fonction.

Passerelles API

Les microservices communiquent généralement 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 fait office de 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, Istio.

Messagerie et diffusion de flux d'événements en continu

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 d'API d'établissement d'état avec la messagerie ou la diffusion d'événements en continu, 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 où une plateforme de diffusion d'événements en continu, 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érance des 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

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 comme service 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.

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 peut adopter la pile la mieux adaptée à sa tâche. 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 clouds 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.

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 :

Masque BFF (Backend-for-frontend) (masque). Ce modèle insère une couche entre l'environnement utilisateur et les ressources auxquelles cet environnement 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 back-end par interface utilisateur en utilisant les meilleures options pour cette interface, plutôt que d'essayer de prendre en charge un back-end générique qui fonctionne avec n'importe quelle interface mais, peut avoir un impact négatif sur les performances du front-end.

Modèles d'entité et d'agrégat. 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 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 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èle d'application strangler. Ces modèles permettent de gérer la restructuration d'une application monolithique en applications de microservices. Le nom pittoresque (strangler (é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.

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 avec les microservices :

La première règle des microservices est de ne pas créer de microservices. Plus précisément, ne démarrer pas avec 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 vous lancez pas dans les microservices sans DevOps ou services clouds. 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 clouds 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 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 tempête parfaite 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.

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 :

• Présentation des microservices
  
  
• Exercice rapide : Créer des microservices d'application Web hautement évolutifs avec Node.js
  
  
• Initiation aux microservices Java à l'aide de Spring Boot et Cloudant
  
  
• Créer, exécuter et déployer des microservices Spring en cinq minutes
  
  
• Microservices, architecture orientée services et API : amis ou ennemis ?