Toutefois ce découpage en multiples micro-services,oblige également à connecter et sécuriser beaucoup plus de composants que par le passé.
La gestion de ces services de communication entre micro-service est complexe :
- le trafic et son routage
- l'équilibrage de charge
- l'application de couche de sécurité ( authentification et autorisation )
Au point où, pour moi, cette problématique est devenue le plus gros frein à l'intégration des technologies dites de "Cloud privés" au sein des PME.
Cet espace d’interaction entre les services d'un cluster, généralement Kubernetes, est appelé : services mesh.
Avant-propos
Tout comme lors de mon article sur la découverte de l'installation de K3S, j'assume également dans les lignes qui suivent ne pas être un expert de Kubernetes. Cette notion de service Mesh, qui n'a pas du tout la même importance dans l'univers Docker Swarm, est donc une nouveauté pour moi.
Mais comme il a bien fallu découvrir ce qu'était un service Mesh et à quoi cela pouvait bien servir, il m'a semblé naturel de vous faire profiter du retour de mes recherches.
Fonctionnement d'un service Mesh :
Un service Mesh est donc un moyen de contrôler la communication entre différentes couches d'une application découpée en micro-services.
Le service Mesh ne va pas s'intégrer dans votre code applicatif, il s'agit d'une couche d'abstraction supplémentaire, visible, qui se trouve directement dans la couche infrastucture de votre cloud.
Au contraire de bon nombre de solutions déjà existantes :
- Netflix avec Hystrix pour les "circuit breakers",
- Eureka pour la découverte de services,
- Ou encore Ribbon pour l'équilibrage de charge.
Toutes ces solutions demandent à être configurées au sein du code de votre application. Et en fonction du langage utilisé, l'implémentation variera forcément.
Chaque fois que ces composants externes seront mis à jour, vous devrez mettre à jour votre application. La vérifier et déployer vos modifications. Autrement dit, les problèmes vont commencer ...
Le service Mesh va donc permettre d'indiquer la manière dont les différents éléments de votre application vont pouvoir interagir entre eux et vous permettre de ne pas utiliser d'éléments externes directement dans votre code.
Exemples
Le besoin de communication entres services d'une même application n'est pas nouveau. L'affichage d'un site par exemple nécessite généralement une communication entre :
- Le serveur Web qui reçoit la requête HTTP,
- Votre code applicatif qui va générer le contenu,
- Une base de données pour le stockage d'informations.
La différence provient ici du fait que la logique de communication entre service ne réside plus sur le service lui même, mais sur l'infrastructure.
Exemple de communication entre différents services pour générer une page Web, au travers de l'affichage d'une de ce blog :
- L'utilisateur demande une page internet, exemple la page d'accueuil.
- Mon proxy, Traefik, reçoit la demande et la transfère à Ghost.
- Ghost interroge sa base de données pour construire la page d'accueuil.
- La base de données renvoie les éléments à Ghost.
- Ghost envoie sa réponse à Traefik.
- Traefik répond à mon internaute.
Pas moins de 6 étapes de communication sont donc nécessaires à la génération d'une simple page. Imaginez donc le nombre de communications que peut représenter l'affichage de services plus complexes !
Et si je souhaite répartir la charge entre différentes instances de Ghost ? Et la charge sur mes bases de données ? Comment faire communiquer tout cela ?
Le service Mesh est là pour répondre à ce besoin.
Think for yourself
Finalement l'ajout d'un tel service tend à vouloir répondre à la complexité de la communication entre services au sein d'un cluster.
Cette complexité doit-elle être gérée par le développement ? Est-ce que je dois faire communiquer mes services directement entre eux ? Ou est ce que je dois passer par un nouveau service pour gérer cela ?
Il existe des points positifs à l'utilisation d'un service dédié :
- Les applications conçues autour d'un service Mesh vont mieux résister aux coupures car le service Mesh peut rediriger les demandes sans transiter par les services défaillants.
- La maintenance de la communication entre service sera facilitée, les services Mesh possèdent leurs systèmes de metrics qui vont permettre d'intervenir afin d'optimiser votre flux de données.
Mais encore une fois, il n'existe pas une réponse unique à ces questions. Tout dépend de vos besoins et de votre projet, de sa complexité , son besoin d'évolution, etc.
Au premier abord, j'avais un a priori sur l'utilisation d'un tel service. Mais mon expérience dans le domaine du Web et le besoin de haute disponibilité des services ( corosync si tu passes par là ... ) me poussent à vouloir aller plus loin dans la découverte d'un tel outil, notamment en essayant prochainement un service Mesh.
Je ne sais pas pourquoi, mais il pourrait s'agir de Maesh ! 😍