Voyage au coeur d'un "Service Mesh" - 2ième partie

Auteurs :

Sami Hossini

Consultant expert

Contactez

Avec la collaboration de Yasser Rougi et Mario Gabriel Guazzelli

7 minutes

Comprendre les composantes fondamentales

Dans la première partie de cet article nous avons introduit le concept de ‘Service Mesh’ ainsi que les problématiques auxquelles il pourrait apporter des réponses.

Dans cette seconde partie, nous plongerons au cœur d’un ‘Service Mesh’ afin de mieux appréhender les rôles et fonctionnalités de ses principaux composants (‘Data Plane’ et ‘Control Plane’). Nous aborderons également son articulation avec le reste du système d’information, notamment avec l’API Management d’Entreprise et l’ESB. Nous soulèverons enfin certains inconvénients ou limites que l’on reproche aujourd’hui à cette technologie, tout en ouvrant le sujet à d’autres concepts tout aussi prometteurs.

Ça plane à tous les niveaux

Comme expliqué dans la partie I, l'architecture logique d’un ‘Service Mesh’ est divisée en deux parties, ‘Control Plane’ et ‘Data Plane’.

Le ‘Data Plane’ est la partie responsable de la traduction, du transfert et de l'observabilité de chaque paquet réseau qui circule vers et depuis une instance de (micro)service. Elle repose principalement sur les capacités du ‘Sidecar Proxy’ que l’on peut résumer à :

  • ‘Service Discovery’ : capacité à lister l’ensemble des instances de services ‘upstreams/backend’ disponibles
  • ‘Health checking’ : capacité à vérifier l’état de santé des instances de services disponibles (retournées par le Service Discovery) avant d’y router des appels. Cela peut inclure à la fois une vérification de l'état de santé de façon active (ex. des pings vers un Endpoint/healthcheck) mais aussi passive (ex. en utilisant 3 retours 5xx consécutifs comme indication d'un service malsain)
  • ‘Routing’ : capacité à identifier à quel ‘upstream service’ la requête d’un appel HTTP pour un service doit être transmise
  • ‘Load balancing’ : capacité à assurer la disponibilité du service ciblé lors du routage et à réagir dans le cas d’un échec d’appel (Circuit Breaking, Failover …)
  • ‘Authentification & Authorisation’ : capacité à authentifier une application appelante par cryptographie (ex. mTLS) puis vérifier si cette dernière est autorisée à accéder à la ressource sous-jacente (en se basant sur le protocole OAuth2 par exemple)
  • ‘Observability’ : capacité à rattacher et générer pour chaque requête des statistiques, logs et tout autre élément de traçabilité permettant aux administrateurs de comprendre la distribution des flux et de mieux réagir face aux incidents rencontrés

Il va sans dire que le ‘Data Plane’ et le ‘Sidecar Proxy’ offrent une excellente abstraction réseau et masquent la complexité des communications inter et intra microservices. Cependant, comment le ‘Sidecar Proxy’ sait exactement router /moncompte au service PERSONAL_ACCOUNT par exemple ? Comment le ‘Service Discovery’ est-il alimenté ? Comment sont configurées les capacités de ‘Load Balancing’, ‘Timeout’, ‘Circuit Breaking’, etc. ? Comment les déploiements de type ‘Blue/green’ ou ‘Canary’ sont-ils réalisés ? Comment les capacités d’authentification et d’autorisation sont-elles configurées ?

La réponse à toutes ces questions est le ‘Control Plane’ !

Toutes les capacités ainsi évoquées sont du ressors du ‘Control Plane’ du ‘service mesh’. C’est la brique centrale qui permet de configurer l’ensemble des ‘Data Planes’ et de veiller à ce que chaque ‘Sidecar Proxy’ dispose de ce dont il a besoin pour communiquer avec les autres. Le ‘Control Plane’ prend également en charge l’administration et le ‘monitoring’ de l’ensemble du système distribué.

En résumé, le ‘Data Plane’ agit sur chaque paquet réseau/requête entrants dans la ‘mesh’. Il est responsable du ‘Service Discovery’, ‘Health Checking’, ‘Routing’, ‘Load Balancing’, ‘Authentification/Authorisation’ et de l’Observability. Tandis que le ‘Control Plan’ fournit et applique politiques et configurations sur l’ensemble des ‘Data Planes’. Il n’agit pas sur les requêtes, mais fait en sorte de transformer les ‘Data Planes’ en un système distribué formant ainsi le ‘service mesh’.

ESB, API Management, Service Mesh : entre concurrence et complémentarité

Service Mesh vs Enterprise API Management Platform

Le Service Mesh, dans la mesure où c’est le composant responsable de la gestion des communications inter-services (Est-Ouest), est fondamentalement complémentaire aux plateformes API Management d’entreprise, qui s’occupent d’exposer les services du SI à la frontière de celui-ci (Nord-Sud).

L’API Management fournit une couche sémantique au-dessus des services exposés (Documentation, identification et souscription, gestion du cycle de vie des APIs, plans de consommation, facturation, etc.), tandis que le ‘Service Mesh’ fournit des fonctionnalités de plus bas niveau telles que les ‘timeouts’, les rejeux de requête ou encore les ‘circuit breakers’, et qui sont tout aussi cruciales lorsqu’il s’agit de consommer des APIs à l’échelle.

Cependant, les fonctionnalités des ‘services Mesh’ et celles des plateformes d’API management sont en recouvrement en termes de définition et de mise en œuvre des politiques de médiation, des quotas, rate limiting, ou encore des règles d’accès. Une approche holistique serait de permettre aux producteurs de services de définir des politiques au niveau de la plateforme API et de les propager par la suite à l’ensemble des ‘middlewares’ impliqués dans chaque appel, ‘API Gateway’ et ‘Sidecar Proxy’ compris.

Service Mesh vs Enterprise Service Bus

Une plateforme ESB standard propose la plupart des fonctionnalités réseau aujourd’hui disponibles sur les ‘Service Mesh’ du marché, à la seule différence que ces derniers sont nativement adaptés à des architectures hautement distribuées type ‘Cloud’.

Toutefois, une différence fondamentale entre ces deux systèmes est l’implémentation sur l’ESB de processus d’intermédiation liés à l’urbanisation fonctionnelle ou applicative, tandis que l’architecture des ‘Services Mesh’ fait de la relégation de la logique métier au niveau microservice un principe très fort.

De ce fait, dans un système d’information alliant webservices composites exposés sur un ESB et microservices interconnectés via un « service Mesh », il convient de considérer les services composites comme des ‘endpoints’ de plus haut niveau consommables de manière « Nord-Sud » ou « Est-Ouest » indifféremment, i.e. déclarés auprès du registre de services du ‘Service Mesh’ ainsi qu’au niveau de l’API Gateway.

Une adoption encore erratique

En dépit de leur montée en puissance et des capacités attrayantes vues précédemment, les ‘Services Mesh’ ne sont pas adoptés aussi largement que prévu. Cela vient sans doute de la nouveauté du concept, mais pas uniquement. Voici ce que l’on reproche généralement au ‘Service Mesh‘ :

Implémenter un ‘Service Mesh’ nécessite des investissements significatifs tant au niveau du ‘Build’ qu’au niveau de ‘Run’ qu’il est difficile de justifier.

En effet, mettre en place un ‘Service Mesh’ suppose d’une part, que le SI et les ressources de l’entreprise disposent des compétences et de la maturité nécessaires sur les concepts et technologies de conteneurisation. D’autre part, tirer profit des capacités d’un ‘Service Mesh’ nécessite d’évoluer vers une architecture microservice et/ou hybride (les deux allants souvent de pair) et donc de reconstruire toutes les applications monolithiques en les décomposant en microservices.

De plus, un ‘Service Mesh’ n’est pas aussi facile à mettre en place et à gérer qu’il n’y parait. Bien que le fait d’injecter un ‘Sidecar’ dans un conteneur peut sembler assez simple, la démultiplication des instances de microservices, la gestion des erreurs, la supervision et le maintien de la haute disponibilité sont quant à elles des capacités beaucoup plus complexes et qui impliquent un grand effort d’ingénierie et de mise en œuvre.

Par ailleurs, les solutions de ‘Service Mesh’ sont relativement nouvelles et ont encore besoin de gagner en maturité. Il serait plus judicieux d’attendre que l’ensemble des technologies du marché soient déclarées comme étant ‘production ready’ et fassent leurs preuves dans le cadre de déploiements à grande échelle.

Enfin, le ‘Service Mesh’ ne résout que les problèmes de communication inter (micro)services. De nombreux problèmes tous aussi complexes comme les problématiques de routage complexe, de transformation/mapping, d’intégration à d'autres services et systèmes, etc. restent en suspens et de la responsabilité du (micro)service à défaut d’avoir une brique d’intégration complémentaire pour y répondre.

Un composant indispensable des architectures multi-clouds

Le principe fondamental des architectures ‘Service Mesh’ est de permettre aux développeurs de services de se concentrer uniquement sur le développement de logique métier et l’implémentation de fonctionnalités, et de les décharger des problématiques d’interconnexions et de logique de communication inter-services. Pour autant, les ‘Service Mesh’ ne portent en aucun cas de logique métier d’intégration de services comme le ferait un ESB, et ne sont donc pas des « ESB distribués » comme il peut être commun d’entendre. Ces systèmes nécessitent d’être complétés par des ‘frameworks’ d’intégration compatibles avec les architectures natives du ‘Cloud’ (Containers, Kubernetes, etc.).

En ce sens, deux projets se distinguent. Le premier, nommé Ballerina et développé par WSO2, permet à partir d’un langage déclaratif, de définir des logiques d’intégration, déployables facilement sous forme de ‘container’ dans un ‘cluster’ Kubernetes. Le deuxième est lui développé au sein de la fondation Apache et se nomme Apache Camel, et permet de définir des politiques d’intermédiation et des règles d’intégration à l’aide d’une API Java. Il est compris dans le projet d’ESB distribué porté également par Apache et qui s’appelle Apache ServiceMix.

Ainsi un ‘Service Mesh’ rend possible la gestion, l’observabilité, et l’intégration de microservices containerisés, et déployés sur des infrastructures modernes de type cloud voire multi-cloud ou hybrid-cloud. Cela représente une brique importante des plateformes qui a l’avenir permettront l’abstraction d’un même environnement cloud homogène au-dessus d’architectures hybrides (Anthos par exemple).

Par ailleurs les nouveaux paradigmes d’architecture ‘multi-cloud/hybrid-cloud’ soulèvent des problématiques de gestion des services managés en plus des microservices, de la maîtrise des couts et leur optimisation (FinOps). Ces problématiques sont adressées par des plateformes spécialisées dites de Hybrid Cloud Management (exemple, Rightscale ou Morpheus).

1ère partie : Comprendre la problématique des architectures cloud hybrides et le concept de 'service mesh'