Services mesh, le nouveau défi des architectures cloud
En découpant les applications en services indépendants, les architectures orientées micro-services contribuent à simplifier leur développement, leur mise à jour et leur passage à l'échelle en vue d'encaisser les hausses de trafic. Elles introduisent aussi de la complexité quand il s'agit d'interconnecter et de sécuriser les différents composants ou de gérer le trafic réseau. Face à ces problématiques, les développeurs sont contraints d'embarquer manuellement des librairies pour gérer le contrôle de la charge serveur et la sécurisation des flux (via SSL, par exemple). Résultat : le code source s'alourdit, pose des problèmes de maintenabilité, voire introduit de potentielles failles. Un service mesh, ou maillage de services, est conçu pour répondre à ces enjeux. Il gère l'équilibrage de charges entre serveurs, les authentifications et autorisations ou encore le routage des services. "Plus généralement, un service mesh gère la qualité de service d'une application, sa disponibilité", résume Stéphane Chaillon, architecte chez Nexworld. En donnant la possibilité d'effectuer des simulations en amont, il évitera par ailleurs des erreurs d'architecture.
"Un service mesh assure le pilotage réseau des architectures de micro-services qu'il s'agisse de contrôler le trafic, d'améliorer la sécurité ou encore de superviser les transactions", complète Yann Provost, consultant cloud chez Objectif Libre. Si le premier service mesh est apparu en 2016 sous l'impulsion de la start-up Linkerd, ce technologie a conquis ses lettres de noblesses en mai 2017 avec la version bêta d'Istio, un projet open source porté par Google, IBM et le vétéciste Lyft.
"Un service mesh assure le pilotage réseau des architectures de micro-services"
Un service mesh s'organise, dans la plupart des cas, autour de deux éléments principaux. Le control plane rassemble les composants centraux pour gérer les différents paramètres réseau de l'architecture. Le data plane assure, lui, le maillage entre les applications. Un de ses composants-clés est le sidecar qui communique avec les composants du control plane et pilote les flux réseau selon les règles fixées. "Sidecar joue un rôle de proxy", précise Tom Lechaux, architecte chez Nexworld. Embarqué dans un container applicatif placé devant d'autres containers, il va prendre le pas sur eux."
Sommaire, l'interface d'un service mesh se rapproche de celle de Kubernetes et permet de changer certaines options. Il faudra passer par des fichiers de configuration YAML pour décrire les règles de routage ou de sécurisation des échanges. "Ces règles peuvent être associées à tous les ports d'une application, à des réponses http, concerner tout le cluster ou quelques applications", poursuit Tom Lechaux. "En fonction du nombre de règles, les fichiers seront plus ou moins volumineux."
Ce travail revient aux opérationnels tels les architectes cloud ou administrateurs systèmes mais, dans un esprit DevOps, les développeurs doivent être, selon Tom Lechaux, également impliqués, les protocoles de test applicatif ou les remontées d'erreurs les concernant en premier chef.
Istio, le service mesh le plus populaire
Mis au point par des ingénieurs de Twitter, le pionnier Linkerd remplit son office. Mais il pâti désormais de l'avance prise par Istio. D'après Yann Provost, ce dernier est devenu de loin le service mesh le plus populaire, et c'est aussi celui qui affiche le plus grand nombre de retours d'expérience. Par ailleurs, Istio est très présent, selon lui, dans la communauté open source, notamment Kubernetes. Il bénéficie aussi du soutien d'acteurs du marché comme Red Hat qui a bâti un service mesh pour pour sa plateforme OpenShift en se basant en partie sur lui. Enfin, Istio s'appuie sur le sidecar proxy de référence, à savoir Envoy.
Reposant également sur Envoy, Consul Connect d'Hashicorp, lancé en juillet 2018, fait figure d'outsider. Ce service de maillage est une extension de Consul, système de stockage clé-valeur développé par le même éditeur.
De leur côté, Amazon Web Services (AWS) et Microsoft proposent tous deux une offre de maillage de services. Il s'agit d'App Mesh pour le premier, et de Service Mesh Interface (SMI) pour le second. Parmi les services mesh qui montent, Yann Provost évoque également SuperGloo, qui se révèle "facile à mettre en œuvre et à paramétrer" ainsi que Maesh de la start-up française Containous. "Des fournisseurs plus importants regardent s'il y a un intérêt de se positionner sur marché. De nouvelles offres payantes devraient certainement voir le jour dans les mois qui viennent", estime-t-il.
"Il y a encore beaucoup de promesses non tenues"
Les technologies de service mesh étant encore émergentes, les entreprises restent frileuses à s'engager sur ce terrain. "Elles se contentent d'expérimentations. Il y a peu de services mesh en production", observe Yann Provost. "La réflexion est toutefois engagée et les déploiements pourraient se multiplier." Le niveau d'adoption par les entreprises devrait aussi croître avec l'enrichissement des solutions existantes. "Il y a encore beaucoup de promesses non tenues", estime Stéphane Chaillon chez Nexworld. "Sur le papier, les services mesh peuvent tourner hors des environnements Kubernetes, mais je n'en ai pas encore vu hors de cette infrastructure."
L'architecte évoque d'autres axes de progrès comme la possibilité de rediriger un flux si un service ne répond pas, ou bien la capacité à isoler un service arrivé à saturation afin de ne plus lui soumettre de requêtes. "Les services mesh pourraient aller plus loin dans la gestion des accès et proposer la génération de tokens. Ce qui éviterait de dépendre d'un serveur d'authentification", ajoute Stéphane Chaillon.
Quant à son collègue Tom Lechaux, il déplore le manque de traçabilité des requêtes auxquelles un service n'a pas pu répondre. "Pouvoir rejouer ces requêtes permettrait de mieux comprendre la cause du dysfonctionnement", pointe-t-il. A plus long terme, il espère que les services mesh puissent être utilisés pour gérer des applications en dehors de tout environnement de containerisation.