Service Mesh : en quoi ça consiste ?

Le service mesh, aussi appelé maillage de services, est la couche d’infrastructure dédiée qui contrôle la communication de service à service sur un réseau. Cette méthode, qui permet aux parties distinctes d’une application de communiquer entre elles, est utilisée sur des sites tels que Twitter, Amazon, Airbnb, Netflix et même pour le moteur de recherche Google. En effet, la plupart des applications modernes sont conçues comme des collections distribuées de microservices. Chacun de ces microservices exécute une fonction métier spécifique. Le service Mesh va faciliter la communication de service à service et ajouter des fonctionnalités telles que l’observabilité, la gestion du trafic et la sécurité, sans avoir besoin de les intégrer directement dans le code. Découvrez, dans cet article, en quoi consiste concrètement le service mesh.

Définition et architecture de Service Mesh

Le service mesh désigne d’abord l’infrastructure qui permet de simplifier la communication entre plusieurs services. Cependant, ce terme est également employé pour désigner le programme utilisé pour implémenter ce modèle. Les plus connus sont Linkerd, Buoyant, Istio, Maesh ou Zuul un proxy reverse Java. Enfin, par extension, le service mesh représente aussi le réseau de sécurité créé lors de l’utilisation de ce pattern..

En effet, avec l’essor des architectures microservices et des services distribués qui remplacent l’approche monolithique traditionnelle, les objectifs et fonctions des services mesh se sont élargis. En plus de simplifier la communication, ils doivent désormais répondre à des exigences opérationnelles et sécuritaires plus complexes comme :

la découverte des services ;
les métriques, le monitoring et la surveillance du réseau ;
les déploiements ;
le load balancing ou équilibrage de charge qui est une technique permettant de répartir la charge de travail de manière uniforme entre les serveurs ou les autres ressources de calcul pour optimiser la fiabilité, la stabilité et la capacité du réseau ;
les tests A/B ;
les déploiements Canary qui mettent à disposition la nouvelle version d’une application à certains utilisateurs avant les autres ;
la disponibilité avec l’utilisation de logiciels contrôlés par des API plutôt que par le matériel ;
les contrôles d’accès ;
le chiffrement et l’authentification de bout en bout ;
la récupération après une défaillance.

Pour remplir ces fonctions, le service mesh offre généralement une flexibilité de gestion de réseau supérieure aux capacités des passerelles API traditionnelles.

Comment fonctionne le maillage de services ?

L’architecture service mesh repose sur une ou plusieurs instances de proxy appelées side-car. Ce nom provient de leur position par rapport à l’application. À la manière d’un side-car attaché à une moto, le proxy side-car est attaché à un programme parent pour ajouter ou étendre des fonctionnalités.

Dans le cas du service mesh, les proxys side-car sont utilisés au niveau des Data Plane et Control Plane du maillage de services.

Le Data plane et le Control plane sont les deux composants de haut niveau que l’on retrouve dans les architectures de service mesh.
Le Data Plane (DP) ou plan de données est responsable de la communication des services au sein du maillage et peut fournir les fonctionnalités d’équilibrage de charge, de reprise après incident et de chiffrement au travers d’une couche d’infrastructure dédiée. Il est composé d’un ensemble de proxys side-car stateless qui vont intercepter tout le trafic réseau et offrir un large éventail de fonctionnalités selon leur configuration.

Le Control Plane (CP) ou plan de contrôle supervise ces proxys individuels et les transforme en un système distribué. Les proxys du Data Plane sont donc également attachés au plan de contrôle qui gère et configure chaque side-car en fonction du service auquel il est lié. Ainsi, le CP permet aux développeurs de configurer facilement tous les Data Plane en cours d’exécution dans le mesh. Les Control Plane peuvent aussi se connecter à une interface CLI ou GUI pour simplifier la gestion des applications.

Quand utiliser un service mesh ?

Pour les DevOps et application reposant sur de nombreux microservices

Le fonctionnement du service Mesh met en avant son avantage majeur : la centralisation.

Les applications structurées avec une architecture de microservices peuvent comprendre plusieurs dizaines de services possédant chacun leur propre instance et interagissant dans leur environnement. La gestion de cette organisation avec notamment la surveillance de l’état et des performances de chaque service de l’application peut donc devenir rapidement complexe pour les développeurs.

Le maillage de services va leur permettre d’isoler et de gérer les communications entre les services dans une couche d’infrastructure séparée et centralisée. Le pattern service mesh devient donc particulièrement avantageux à mesure que le nombre de microservices d’une application augmente.

Pour les équipes DevOps qui disposent d’un pipeline CI/CD de production établi, le service mesh peut aussi être très utile pour déployer par programmation des applications grâce à une infrastructure d’applications (Kubernetes). Il leur permet aussi de gérer les politiques de mise en réseau et de sécurité directement dans du code.

Avantages et inconvénients du maillage de services

Le service mesh a pour objectif de faciliter la gestion de la communication de service à service, mais il ne résout pas tous les problèmes.

Les avantages du service mesh

une communication simplifiée entre les services ;
un diagnostic plus facile des erreurs de communication qui se produisent désormais dans une couche d’infrastructure dédiée
un développement et des déploiements plus rapides ;
des tests plus concrets avec notamment la possibilité d’injecter une latence ou une défaillance pour simuler leurs effets en situation réelle
une meilleure résistance aux temps d’arrêt, car le service mesh peut rediriger les demandes en évitant les services défaillants ;
la prise en charge de fonctionnalités de sécurité (chiffrage, fiabilité, authentification, etc.). Le service mesh fournit également une autorité de certification qui génère un certificat par service pour la communication TLS entre les services.

Les inconvénients du maillage de service

une augmentation du nombre d’instances d’exécution avec le risque d’ajouter une latence à l’architecture ;
pas de prise en charge de l’intégration avec d’autres systèmes et services ;
une complexité de la gestion du réseau centralisée, mais pas supprimée ;
une configuration qui demande une prise en main et des compétences dans les équipes de développement.

Malgré ces inconvénients, les avantages et le fonctionnement des services mesh font qu’ils restent très utilisés dans les grandes applications et celles s’exécutant sur Kubernetes. Et vous, travaillez-vous avec ce pattern ? Que pensez-vous de ses avantages et inconvénients ? N’hésitez pas à nous partager vos retours d’expérience avec le service mesh sur le forum !

Les principaux fournisseurs et plateformes de service Mesh