CIO

Le Service Mesh, une solution d’intégration technique distribuée pas comme les autres.

Share this post:

L’émergence des architectures Cloud et des patterns microservices dans les systèmes d’information ces dernières années a intensifié les défis d’intégration dans des environnements de plus en plus distribués. L’intégration technique est historiquement associée à l’utilisation d’outils centralisées de type Enterprise Bus Service (ESB) ou API Gateway afin de gérer entre autres les transformations protocolaires, le routage et l’observabilité des échanges. Historiquement ces outils proposaient une architecture très centralisée, ce qui ne faisait pas bon ménage avec les prémisses des architectures microservice prônant la distribution des unités d’exécution. C’est alors que des sociétés comme Google, Netflix ou Twitter ont commencé à mettre en place des bibliothèques de gestion de routage afin de masquer aux développeurs certaines problématiques liées aux appels entre services. Au fil des années avec l’avènement des conteneurs et leurs orchestrateurs, ces bibliothèques ont évolué vers des proxies indépendants beaucoup plus facile à exploiter, c’est ainsi que les solutions de Services Mesh sont apparues.

À ce stade nous pouvons nous demander comment les solutions de Services Mesh ont réussi à conserver l’approche distribuées indispensable aux architecture microservice, quelles sont les capacités offertes par ces nouveaux outils et comment les positionner vis-à-vis des traditionnels ESB?

Anatomie d’un Service Mesh

Afin de comprendre le positionnement d’un Service Mesh il est important d’ouvrir le capot et de jeter un œil à son fonctionnement technique. Je ne rentrerai pas dans l’ensemble des détails techniques qui peuvent varier en fonction des solutions de Service Mesh, si vous souhaitez poursuivre dans cette voie je vous conseille la documentation du produit communautaire Opensource ISTIO disponible ici : https://istio.io/latest/about/service-mesh/.

Comme son nom le laisse penser, les solutions de Service Mesh fédèrent un ensemble de services applicatifs dans un réseau maillé. Pour réaliser cela, 2 principaux composants sont utilisés :

  • Le Control Plane, centre de pilotage du maillage.
  • Le Data Plane, contenant l’ensemble des services du maillage.

Le Control Plane est le centre de pilotage du maillage permettant de centraliser les configurations et collecter l’ensemble des métriques du maillage.

Le Data Plane lui contient les éléments d’exécution de l’architecture. On y retrouve les services du maillage auxquels sont injectés des proxies permettant d’intercepter les flux entrant/sortant de chaque service. Les échanges entre services passent alors systématiquement par les proxies qui s’occupent d’effectuer les actions/transformations nécessaires en fonction des configurations injectées par le Control Plane.

Illustration des Proxy et leur interaction avec le Control Plane

Les proxies peuvent être configurer afin de répondre à des problématiques autours des 3 axes suivants :

  • La sécurité, en permettant de gérer les échanges sécurisés (TLS ou mTLS) entre services ainsi que la distribution et le renouvellement automatique des certificats associés à chaque Proxy.
  • L’observabilité, en permettant de générer des traces distribuées des échanges ainsi que des logs HTTP.
  • La gestion des flux, en permettant de router des requêtes en fonction de leur contenu, ou encore d’introduire de la latence entre services dans le cadre de chaos testing.

Pour illustrer concrètement un cas d’usage du Mesh nous allons nous intéresser au routage progressif des flux aussi appelé Canary ou A/B Testing.

Partons du principe qu’un service A consomme un service B. Le service B ayant un cycle de vie propre, une nouvelle version vient d’être développée, testée en recette et donc maintenant doit être déployée en production. Or comme vous le savez surement si vous avez déjà eu la charge de ce type d’opération, il existe toujours un risque non nul (même si on l’espère réduit par la phase de recette) d’introduire par ce déploiement une régression applicative ou encore d’oublier un composant de configuration qui rendrait le nouveau service non opérationnel. Pour réduire ces risques, la méthode Canary, ou A/B Testing, consiste à déployer les deux versions du service B en même temps et de router les utilisateurs progressivement vers la nouvelle version. Il est ainsi possible de s’assurer du bon fonctionnement du service via un nombre réduit d’utilisateur sélectionné judicieusement.

Les solutions de Service Mesh permettent de réaliser ce routage progressif par simple configuration.

Illustration du principe de routage dynamique via les Proxies du Service Mesh.

  1. Au démarrage du proxy Service A, la configuration est injectée dans le proxy (règles de routages, certificats TLS, nombre maximum de retry, quotas…)
  2. Lorsque le Service A fait un appel au Service B, le flux est intercepté par le proxy
  3. Le proxy route alors la requête vers le proxy correspondant au ServiceB en suivant les règles de sa configuration (règles de routage, négociation TLS, Retry…).
  4. Le proxy réceptionne la requête, effectue les contrôles nécessaires en fonction de sa configuration (terminaison TLS, contrôle d’habilitation, contrôle des quotas…) et la transmet au ServiceB.
  5. Les proxies collectent l’ensemble des données d’observabilité (traces distribuées, codes retours http, temps de traitement des requêtes…) et les envoient au Control Plane.

Il faut tout de même noter que la donnée source du critère de routage doit être portée dans les headers http des requêtes afin de pouvoir être accessible par les proxies. Il faut donc anticiper à minima les informations nécessaires au routage.

Comparaison des Services Mesh et des ESB

Le premier élément différenciant entre un ESB et un Service Mesh réside dans l’architecture des deux approches. Les ESB proposent historiquement des architectures techniques centralisées permettant de concentrer les flux sur un point de passage unique. Les Services Mesh quant à eux sont décentralisés par le déploiement de proxy sur chaque membre du maillage. La résilience à l’exécution d’un Service Mesh dépend donc de la résilience de chaque service et de son proxy de référence. Seule la modification de la configuration et la remontée des métriques sont centralisées dans le Control Plane. L’approche ESB permet donc de simplifier la gestion des flux en les centralisant mais par la même occasion peut créer un point de passage obligatoire dont l’indisponibilité peut avoir un impact sur plusieurs applications. Le Service Mesh favorisant les appels de services à services via ses proxies permet d’améliorer la résilience du système dans sa globalité. Cependant il est important de garder une vue sur les performances globales du maillage car plus on augmente le nombre de services plus le Control Plane doit pouvoir assurer d’injections de configurations et assimiler des métriques.

D’un point de vue fonctionnalités, les ESB et les Services Mesh peuvent paraitres similaires car ils interviennent autour des 3 mêmes axes : la sécurité, l’observabilité et la transformation des requêtes. Cependant leur philosophie est très différente. Les ESB sont souvent utilisés comme des couches d’abstraction et de transformation des services qu’ils encadrent, ils ont pour objectif de masquer les services qu’ils gèrent. Le Service Mesh lui joue un rôle d’intercepteur de flux lié aux couches transport et se veut le plus transparent possible vis-à-vis des services de son maillage. Son rôle n’est pas de masquer ou transformer l’exposition d’un service mais de travailler sur les requêtes qu’il intercepte. Cette approche peut être à double tranchant. Elle permet de décharger les développeurs d’implémenter un certain nombre de fonctionnalités prises en charge par les Mesh mais elle demande d’accorder un niveau de confiance important dans la plateforme elle-même (l’application étant déchargée de ces fonctions) et de s’assurer que les applications sont bien déployées dans un Mesh correctement configuré.

Service Mesh et ESB une combinaison gagnante

Les outils de type ESB doivent être vus comme des portes d’entrée sur une zone du système d’information. Il est ainsi possible d’y appliquer les contrôles d’accès nécessaires pour entrer dans la zone, de garantir l’observabilité des requêtes entrantes et de pouvoir abstraire les services exposés hors de la zone (exemple de zones : DMZ/Intranet, domaines métiers différents).

Les Services Mesh quant à eux jouent un rôle de fédération des services d’une zone du système d’information, permettant d’assurer la sécurité, l’observabilité et les communications des échanges entre services d’une même zone. Ce qui est d’autant plus important que l’adoption des microservices démultiplie les échanges et complexifie l’exploitation de ces derniers.

Les deux outils ne sont donc pas à opposer mais bien à voir comme complémentaires afin de pouvoir garantir la sécurité, l’observabilité et la communication sur l’ensemble du système d’information.

Segmentation de deux zones du système d’information par ESB et fédération des services via                          Service Mesh à l’intérieur de chaque zone.

Si vous souhaitez vous lancer dans l’intégration d’une solution de Service Mesh il faut cependant garder en tête un point important : ces outils sont récents et se basent souvent sur des composants OpenSource qui évoluent rapidement comme Envoy ou ISTIO. Il est donc primordial de rester agile et en veille régulière sur le sujet afin de pouvoir anticiper les évolutions et nouvelles fonctionnalités qui peuvent apporter des changements majeurs.

Senior Cloud Architect IBM Consulting - Hybrid Cloud Transformation

More CIO stories
2 mai 2024

IBM et AWS offrent aux clients français de nombreuses technologies IBM sur la marketplace d’AWS pour répondre aux enjeux d’hybride Cloud et d’IA

Dans un monde de plus en plus complexe, qui ne souhaite pas un peu de simplicité ? IBM et AWS permettent aux clients français d’acheter, de déployer et d’utiliser plus facilement les logiciels IBM achetés sur la marketplace d’AWS. Avec un portefeuille de 44 solutions IBM (dont 29 en mode SaaS) désormais disponibles et en […]

Continue reading

28 février 2024

L’intelligence artificielle et l’analytique avancée dans le système de santé français (Partie 2)

Face aux défis auxquels sont confrontés les systèmes de soins de santé, l’analytique avancée (AA) et l’intelligence artificielle (IA) sont des technologies à haut potentiel d’impact. Ces technologies peuvent équiper les systèmes de santé d’outils avancés pour renforcer les soins des patients et améliorer l’efficacité opérationnelle. La deuxième partie de cet article reprend le fil […]

Continue reading

15 février 2024

L’Intelligence Artificielle et l’Analytique avancée dans les systèmes de santé français (Partie 1)

Dans le paysage complexe de la Santé, les systèmes médicaux du monde entier sont confrontés à une multitude de défis. Ceux-ci vont de la gestion délicate des maladies chroniques jusqu’à la quête d’accès égaux aux services de santé. Dans ce contexte spécifique, l’émergence de l’Analytique avancée et de l’Intelligence Artificielle (IA) joue un rôle de […]

Continue reading