Jump to section

Un Service Mesh, qu'est-ce que c'est ?

Copier l'URL

Un Service Mesh, tel que le projet Open Source Istio, est un moyen de contrôler la façon dont différents éléments d'une application partagent des données les uns avec les autres. Contrairement à d'autres systèmes de gestion des communications, un Service Mesh est une couche d'infrastructure dédiée, créée directement dans l'application. Cette couche d'infrastructure visible peut indiquer la manière dont les différents éléments d'une application interagissent entre eux. Il devient dès lors plus facile d'optimiser les communications et d'éviter les temps d'arrêt lorsque l'application évolue.

Chaque élément, ou « service », d'une application dépend d'autres services pour satisfaire les attentes des utilisateurs. Prenons l'exemple d'une application de vente en ligne. Avant d'acheter un article, l'utilisateur a besoin de savoir s'il est en stock. Le service qui communique avec la base de données de l'inventaire doit alors communiquer avec la page web du produit, laquelle doit communiquer à son tour avec le panier en ligne de l'utilisateur. Le revendeur peut aussi décider d'intégrer un service de recommandation de produits au sein de l'application pour guider les utilisateurs. Ce nouveau service devra communiquer avec une base de données de balises de produit pour générer des recommandations, mais aussi avec la base de données de l'inventaire avec laquelle la page produit devait déjà communiquer. Cela représente beaucoup de variables réutilisables.

Les applications modernes se décomposent souvent ainsi, sous la forme d'un réseau de services assurant chacun une fonction métier particulière. Pour assumer sa fonction, un service peut avoir besoin de demander des données à plusieurs autres services. Mais que se passe-t-il lorsque certains services, comme la base de données de l'inventaire du revendeur, sont surchargés de demandes ? C'est là qu'intervient le Service Mesh : ce système achemine les demandes d'un service au suivant, de manière à optimiser le fonctionnement des éléments mobiles.

Un Service Mesh n'ajoute pas de fonctionnalités à l'environnement d'exécution d'une application. Dans toute architecture, les applications ont toujours eu besoin de règles pour définir l'acheminement d'une requête d'un point A à un point B. L'unique différence est que la logique de communication entre services réside sur une couche de l'infrastructure, et non plus au niveau des services individuels.

En pratique, un Service Mesh est créé dans une application sous la forme d'un ensemble de proxies réseau. Le proxy est un concept familier dans l'univers de l'informatique d'entreprise. Si vous consultez cette page web sur un ordinateur professionnel, vous venez sans doute d'en utiliser un :

  1. Votre demande d'accès à cette page a d'abord été reçue par le proxy web de votre entreprise…
  2. Une fois les contrôles de sécurité du proxy passés, votre demande a été transmise au serveur qui héberge cette page.
  3. La page a ensuite été renvoyée au proxy et soumise à nouveau aux contrôles de sécurité.
  4. Pour finir, le proxy vous a envoyé la page.

Avec un Service Mesh, l'acheminement des requêtes entre les microservices s'effectue via des proxies situés sur leur propre couche d'infrastructure, d'où l'emploi du terme « sidecars » pour désigner les proxies qui composent un Service Mesh, car ils s'exécutent à côté de chaque service, et non dans les services. Ensemble, les proxies « sidecars » de chaque service forment un réseau maillé.

Un proxy sidecar se situe à côté d'un microservice et achemine les requêtes aux autres proxies. Tous ensemble, ces sidecars forment un réseau maillé.

L'absence de Service Mesh oblige les développeurs à coder chaque microservice selon la logique de communication entre services. Ces derniers perdent ainsi de vue les objectifs de l'entreprise et ont plus de difficultés à diagnostiquer les problèmes de communication, car la logique de communication entre les services est cachée dans chaque service.

Chaque fois qu'un service est ajouté dans une application ou dans une nouvelle instance d'un service existant exécuté dans un conteneur, l'environnement de communication se complexifie et de nouveaux points de défaillance peuvent apparaître. Dans une architecture de microservices complexe, il est quasiment impossible de localiser les problèmes sans Service Mesh.

Un Service Mesh fournit également des statistiques de performances sur chacun des aspects de la communication entre les services. Au fil du temps, les données ainsi révélées peuvent être appliquées aux règles de communication entre les services, ce qui améliore l'efficacité et la fiabilité des requêtes de service.

Par exemple, si un service ne parvient pas à répondre à une requête, le Service Mesh peut savoir au bout de combien de temps une nouvelle tentative a réussi. À mesure que les données sur les périodes de défaillance de ce service s'accumulent, des règles peuvent être établies pour déterminer le délai optimal avant de réinterroger ce service. Cela évite ainsi d'engorger le système avec des tentatives superflues.

Si vous avez commencé à créer des microservices, il est probable que vous ayez anticipé certains besoins tels que la capacité à évoluer rapidement et l'ajout de fonctions pour répondre aux exigences futures de l'entreprise. Votre architecture de microservices sera sans doute bien différente un an après son lancement. Au départ, les bibliothèques intégrées dans les microservices sauront gérer la communication entre services sans perturber l'exploitation, ou presque. Cependant, cela ne durera pas très longtemps si vous décidez d'exploiter tout le potentiel de cette technologie en développant les microservices et en les enrichissant de fonctions. En effet, les services seront alors surchargés de demandes et les développeurs passeront de plus en plus de temps à coder la logique de requête pour chaque service, ce qui pourra causer des problèmes.

Avec un Service Mesh :

Pensez dès maintenant à l'avenir en testant l'utilisation d'un Service Mesh avec Red Hat® OpenShift® Service Mesh. Découvrez une façon uniforme de se connecter, de gérer et d'observer des applications basées sur des microservices avec des informations sur le comportement des microservices en réseau au sein de votre Service Mesh, ainsi que des fonctions de contrôle. La solution OpenShift Service Mesh est disponible (sans frais) pour Red Hat OpenShift.

Le composant Automation Mesh de Red Hat Ansible Automation Platform offre un framework simple et fiable de Service Mesh pour la mise à l'échelle de l'automatisation. Grâce à une couche de communication flexible et multidirectionnelle, Automation Mesh améliore la capacité d'une entreprise à opérer à l'échelle mondiale. Ce composant réduit la sensibilité à la latence et aux interruptions de connexion, et fournit des capacités de peering natives, ce qui vous permet d'aller plus loin tout en bénéficiant d'une fiabilité encore inégalée. Grâce aux fonctions de sécurité de Red Hat Ansible Automation Platform, telles que le chiffrement et l'authentification TLS, et aux contrôles d'accès supplémentaires, repoussez les limites du possible dans l'ensemble du parc informatique de votre entreprise.

Pour aller plus loin

ARTICLE

Les microservices comme technologie d'intégration dans le secteur de la santé

Les microservices permettent aux développeurs, notamment ceux du secteur de la santé, de créer des applications qui sont constituées de services faiblement couplés, ce qui facilite les étapes de développement, de test, de déploiement et de mise à niveau.

ARTICLE

Les microservices, qu'est-ce que c'est ?

Les microservices désignent une approche architecturale du développement d'applications selon laquelle les différentes parties d'une application fonctionnent en synergie tout en étant séparées.

ARTICLE

Un Service Mesh, qu'est-ce que c'est ?

Un Service Mesh est une couche d'infrastructure comprise dans une application qui permet de documenter les interactions entre les services, pour simplifier l'optimisation des communications et réduire les temps d'arrêt.