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

Un Service Mesh, à l'instar du projet Open Source Istio, est un moyen de contrôler la manière dont les différentes parties d'une application partagent des données entre elles. Contrairement aux autres systèmes de gestion de cette communication, un Service Mesh est une couche d'infrastructure dédiée et intégrée à une application. Cette couche visible montre les interactions (qu'elles soient positives ou négatives) entre les différentes parties de l'application, ce qui permet d'optimiser les communications et d'éviter les temps d'arrêt plus facilement 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. Ce processus implique beaucoup d'éléments mobiles réutilisables.

Les applications modernes sont souvent décomposées de la sorte, sous la forme d'un réseau de services qui remplissent chacun une fonction métier donnée. Pour assumer sa fonction, un service peut avoir besoin de demander des données à plusieurs autres services. Alors que se passe-t-il si certains services sont surchargés de demandes, comme la base de données d'inventaire du distributeur ? C'est à ce moment que le Service Mesh entre en jeu, en acheminant les requêtes d'un service au suivant, de manière à optimiser le fonctionnement des éléments mobiles entre eux.

Dans une architecture de microservices, les équipes de développement peuvent modifier les services d'une application sans être obligées de la redéployer entièrement. Contrairement à ce qui se passe dans d'autres architectures, les différents microservices proviennent d'équipes réduites qui sont libres de choisir leurs outils et leurs langages de programmation. En résumé, les microservices sont créés séparément et communiquent les uns avec les autres. Chacun peut subir une défaillance sans pour autant provoquer l'arrêt complet de l'application.

C'est grâce à la communication de service à service qu'il est possible de crééer des microservices. Sa logique peut être codée au niveau du service, sans couche de Service Mesh. Cependant, plus les communications se compliquent, plus le Service Mesh devient un atout. Pour les applications cloud-native créées dans une architecture de microservices, le Service Mesh offre la possibilité de regrouper un grand nombre de services distincts dans une application fonctionnelle.

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 :

• les développeurs se concentrent sur l'ajout de valeur à l'entreprise, et non sur la connexion des services ;
• le traçage distribué des requêtes par le biais de Jaeger forme une couche d'infrastructure visible à côté des services, ce qui facilite l'identification et la résolution des problèmes ;
• les applications résistent mieux aux temps d'arrêt, car le Service Mesh peut rediriger les demandes sans transiter par les services défaillants ;
• la communication dans l'environnement d'exécution peut être optimisée d'après les statistiques de performances.

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.