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

Un Service Mesh est une couche d'infrastructure comprise dans une application logicielle qui gère la communication entre les différents services. Il se charge des fonctions de routage de trafic, de sécurité, d'observabilité et de résilience, évitant ainsi qu'elles ne soient intégrées à chaque service individuel.

Les applications modernes s'appuient sur des services qui communiquent entre eux. Lorsqu'un potentiel acheteur consulte un site de vente en ligne, il est fort probable qu'il utilise la barre de recherche du site pour parcourir la liste des produits disponibles. Cette fonction de recherche constitue un service. S'il voit des recommandations de produits similaires ou ajoute un article au panier, il s'agit également de services. Le service qui communique avec la base de données de l'inventaire doit communiquer avec la page web du produit, laquelle doit communiquer à son tour avec le panier en ligne de l'utilisateur. Le distributeur peut également disposer d'un service qui recommande des produits aux utilisateurs directement dans l'application. Ce service devra communiquer avec une base de données de balises de produit pour générer des recommandations, ainsi qu'avec la base de données de l'inventaire avec laquelle la page produit devait déjà communiquer.

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 précise. Pour assumer sa fonction, un service peut avoir besoin de demander des données à plusieurs autres services. 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 gérant la communication entre les services, de manière à optimiser le fonctionnement des différents modules entre eux.

Le Service Mesh est un élément des architectures de microservices. Le terme microservice désigne un type d'architecture d'applications composée d'un ensemble de services indépendants qui communiquent par l'intermédiaire d'interfaces de programmation d'application (API) légères. L'architecture de microservices est une approche cloud-native du développement de logiciels qui implique que chaque fonction principale d'une application peut exister de manière indépendante. Ces différents microservices peuvent provenir d'équipes réduites qui sont libres de choisir leurs outils et leurs langages de programmation, ce qui n'est pas le cas dans les autres architectures. Les microservices sont créés séparément, mais communiquent les uns avec les autres. Chacun peut subir une défaillance sans pour autant provoquer l'arrêt complet de l'application.

Si les différents services ne pouvaient pas communiquer entre eux, il n'y aurait pas de microservices. À mesure que leur architecture grandit, elle devient plus complexe à gérer. Les applications contenant des dizaines, voire des centaines, de services qui interagissent les uns avec les autres présentent de nombreux défis, notamment en cas de pannes ainsi qu'au niveau de la surveillance et du traçage du réseau, de l'équilibrage des charges de trafic et de la sécurisation des communications entre les différents microservices. Il serait inefficace de traiter ces problèmes uniquement à l'aide de code personnalisé. Un Service Mesh offre une solution cohérente pour relever ces défis sans avoir à modifier le code de chaque service.

Un Service Mesh gère la communication entre les services à l'aide d'un plan de données et d'un plan de contrôle. 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 intégré aux applications sous la forme d'un ensemble de proxies réseau. Le proxy est un composant très répandu. Si vous consultez cette page web sur un ordinateur professionnel, vous venez sans doute d'en utiliser un Il fonctionne de la manière suivante :

1. La demande d'accès à cette page a d'abord été reçue par le proxy web de l'entreprise.
2. Une fois les contrôles de sécurité du proxy passés, la 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 renvoie la page à l'utilisateur.

Dans un Service Mesh, chaque instance de service est associée à un proxy sidecar qui s'exécute en parallèle de chaque service et intercepte l'ensemble du trafic entrant et sortant. Chaque proxy sidecar se situe à côté d'un microservice et assure le routage des requêtes depuis et vers les autres proxies. Le proxy gère des tâches telles que le routage du trafic, l'équilibrage de charge, l'application des politiques de sécurité et la collecte de données de télémétrie. Au lieu de communiquer directement entre eux, les services envoient des requêtes via leur sidecar, dont la mission est de gérer la communication interservices. Tous ces éléments constituent le plan de données.

Le plan de contrôle gère la configuration et la distribution des politiques au sein du plan de données. Il distribue également les règles de routage du trafic, gère les certificats de sécurité entre les services, configure les composants pour appliquer les politiques et collecte les données de télémétrie.

Sans Service Mesh, il est nécessaire de coder chaque microservice selon la logique de communication entre les services. Il est alors plus difficile de diagnostiquer les problèmes de communication, car la logique de communication entre les services est cachée dans chaque service.

En savoir plus sur les microservices

Istio est une plateforme Open Source de Service Mesh qui permet de gérer le partage des données entre les microservices. Elle contrôle le flux du trafic, applique les politiques et surveille les communications dans un environnement de microservices. Elle comprend des API qui facilitent l'intégration d'Istio à tout système de journalisation, d'application de politiques ou de télémétrie. De plus, cette plateforme s'exécute dans divers environnements conteneurisés, virtualisés, sur site et dans le cloud.

L'architecture d'Istio repose sur deux plans : le plan de données et le plan de contrôle. La plateforme utilise des proxies Envoy performants et déployés en tant que sidecars, qui gèrent le trafic de tous les services au sein du Service Mesh. Dans le plan de données, les équipes de développement peuvent ajouter la prise en charge d'Istio à un service en déployant un proxy sidecar au sein de l'environnement.

Le Service Mesh d'Istio inclut un nouveau mode ambiant qui remplace les proxies sidecar par des proxies au niveau du nœud et des passerelles intermédiaires appelées « waypoints ». Ces proxies waypoint s'exécutent en dehors des pods d'applications et sont gérés indépendamment des applications.

En savoir plus sur Istio sur Red Hat Developer

Chaque fois qu'un service est ajouté à une application ou à 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.

L'utilisation d'un Service Mesh présente plusieurs avantages :

• Renforcement de la sécurité. Un Service Mesh utilise le protocole Transport Layer Security (mTLS) pour garantir le chiffrement et la sécurité des communications entre les services, ainsi que la protection des données des utilisateurs. Il ajoute un niveau de sécurité supplémentaire, sans intervention manuelle pour assurer le chiffrement au niveau de chaque service. Un Service Mesh peut également améliorer le contrôle d'accès basé sur les rôles (RBAC) ainsi que les politiques de sécurisation des API, et peut automatiser la gestion des certificats et la rotation des clés.
• Application des politiques. Un Service Mesh centralise la configuration des politiques de services telles que les quotas, la limitation du débit, l'authentification et l'autorisation. Il contrôle les interactions entre les services par le biais de politiques d'accès, qui sont appliquées au niveau du proxy, ce qui assure la cohérence entre les services.
• Gestion du trafic.Un Service Mesh aide les applications à gérer le trafic vers les services individuels en fonction de conditions de charge, de versions et de règles spécifiques aux utilisateurs. Par exemple, lors du lancement d'une nouvelle version d'un service d'inventaire, il est possible d'effectuer un déploiement canary afin de n'envoyer que 5 % du trafic vers le nouveau service (un canary est un déploiement test à petite échelle). En cas de réussite, le trafic peut être augmenté.
• Contrôles d'intégrité et observabilité. Il est souvent difficile de visualiser en temps réel les interactions entre les microservices. Un Service Mesh permet toutefois de mettre en œuvre des outils d'observabilité intégrés tels que le traçage distribué et la collecte d'indicateurs de mesure. Les sidecars d'un Service Mesh collectent des indicateurs de mesure (nombre de requêtes, latence, taux d'erreur), puis les envoient au plan de contrôle ou aux outils de surveillance.
• Tolérance aux pannes et renforcement de la résilience. En cas de panne de microservice, le Service Mesh peut automatiser les nouvelles tentatives et les mécanismes de secours. Il tente à nouveau d'interagir avec le microservice défaillant en suivant un ensemble de règles prédéfinies et redirige, si nécessaire, le trafic vers d'autres services. En cas d'indisponibilité d'un service, l'application peut ainsi gérer la panne sans nuire à l'expérience utilisateur. Par ailleurs, le Service Mesh enregistre le temps écoulé entre la panne et l'aboutissement d'une nouvelle tentative d'interaction. Cette information indique le temps d'attente optimal entre deux tentatives, ce qui permet d'ajuster les règles et d'éviter une surcharge du système.

Avec un Service Mesh, les équipes de développement et d'exploitation sont plus à même de gérer la migration depuis des applications monolithiques vers des applications cloud-native, qui regroupent un ensemble de microservices indépendants et faiblement couplés. 

La mise en œuvre d'un Service Mesh comprend son lot de difficultés. En voici quelques exemples :

• Complexité et intégration avec les systèmes existants. Un Service Mesh peut être difficile à configurer, gérer et intégrer à d'autres systèmes, en particulier pour certaines entreprises. C'est le cas notamment pour celles qui opèrent au sein d'un vaste environnement distribué, avec des systèmes sur site et multicloud, et celles qui n'ont encore jamais utilisé de Service Mesh dans leur environnement.
• Exigences en matière de ressources et coûts liés à l'exploitation. Les Service Mesh peuvent augmenter les coûts d'exploitation associés à la gestion des applications, car chaque instance de service dispose désormais d'un proxy sidecar qui accroît l'utilisation du processeur et de la mémoire. La gestion et la résolution des problèmes peuvent devenir complexes, en particulier dans le cadre de déploiements à grande échelle, ce qui complique le maintien des performances et la mise à échelle.
• Déficits de compétences. Les équipes ont besoin d'être formées pour comprendre les fonctions, la configuration et les meilleures pratiques d'un Service Mesh. Le débogage des pannes peut s'avérer délicat, notamment lorsque des problèmes sont dus à des règles de routage complexes ou à des erreurs de configuration mTLS. De nombreuses entreprises estiment que leurs équipes actuelles manquent d'expertise concernant les Service Mesh. Elles ont donc plus de difficultés à adopter cette technologie et à l'utiliser efficacement.

Une passerelle d'API est un outil de gestion des API qui se positionne entre un client et un ensemble de services back-end. Dans ce contexte, le client est une application exécutée sur l'appareil d'un utilisateur et les services back-end sont ceux qui s'exécutent sur le serveur d'une entreprise. L'utilisation d'une passerelle d'API permet de dissocier l'interface client de la mise en œuvre back-end. Lorsqu'un client envoie une demande, la passerelle d'API la segmente en plusieurs demandes qu'elle achemine vers les services appropriés, produit une réponse et conserve une trace de toutes ces opérations.

Un Service Mesh sécurise la communication interne entre les services tout en autorisant le trafic externe via la passerelle d'API. Ensemble, une passerelle d'API et un Service Mesh garantissent l'application uniforme des politiques entre les services internes. 

En savoir plus sur Red Hat 3scale API Management

Red Hat offre des produits intégrés de gestion des API, de Service Mesh et de plateforme d'infrastructure pour aider les entreprises à construire une architecture de gestion des services complète.La solution Red Hat® OpenShift® Service Mesh fournit un outil unique pour connecter, gérer et surveiller les applications basées sur des microservices. Elle offre une excellente visibilité et un bon niveau de contrôle sur le comportement des microservices en réseau dans un Service Mesh.

Basée sur le projet Open Source Istio, la solution OpenShift Service Mesh propose des fonctionnalités supplémentaires grâce à l'inclusion d'autres projets Open Source tels que Kiali (console Istio) et Jaeger (traçage distribué), ce qui favorise la collaboration avec les principaux membres de la communauté Istio. OpenShift Service Mesh permet aux équipes de développement d'augmenter leur productivité en intégrant des politiques de communication sans changer le code de l'application ni intégrer les bibliothèques spécifiques à un langage.

La solution Red Hat OpenShift Service Mesh est préinstallée, testée et optimisée pour Red Hat OpenShift. Elle est compatible avec des fonctions propres à OpenShift, telles que les opérateurs ainsi que les pipelines d'intégration et de distribution continues. Elle bénéficie de l'assistance adaptée aux entreprises de Red Hat et profite de mises à jour et de correctifs réguliers pour plus de sécurité et de stabilité. Enfin, elle fonctionne dans plusieurs clusters Red Hat OpenShift, ce qui favorise la cohérence entre les environnements de cloud hybride et multicloud.