Introduction au Service Mesh

La problématique des microservices

De  nos jours, nous assistons à l’essor des microservices et des technologies natives du cloud. Qu’est ce qu’un microservice?

Faire le design d’une architecture de microservices consiste à décomposer les applications en éléments plus simples, indépendants les uns des autres. Ils sont généralement simples à créer et à remplacer, et communiquent généralement avec d’autres services via des requêtes HTTP.

Supposons maintenant, une application sous forme d’une architecture de microservices. La communication entre services est primordiale dans une architecture de microservices. La logique de communication peut être codée au niveau de chaque microservice. Cependant, plus le nombre de microservices augmente, plus les communications se compliquent comme le montre la figure ci-dessous.

  source: https://www.redhat.com/fr/topics/microservices/what-is-a-service-mesh

 

Ceci fait que, le défi le plus complexe dans la réalisation d’une architecture de microservices n’est pas le développement des services eux-mêmes, mais la communication entre les différents services. La conséquence principale qui en découle est que , chaque microservice devra non seulement implémenter la logique métier( fonction de base) mais aussi traiter des fonctions réseau , de la sécurité, la fiabilité,…

Comment régler ce problème 😏 ?

💡On pourrait penser à décharger toutes ces tâches sur une couche différente, afin que la communication inter-services soit indépendante du code de chaque service.

C’est là qu’intervient le Service Mesh!

Du Service Mess au Service Mesh

Un service mesh gère toutes les communications  inter-service au sein d’un système logiciel distribué. Il y parvient généralement via l’utilisation de proxies «sidecar» à travers lesquels tout le trafic est acheminé de manière transparente. Le service mesh, c’est aussi une couche de gestion pour surveiller et contrôler une collection de microservices. La principale différence entre le service mesh et les microservices est que pour le service mesh, la logique de communication entre services réside sur une couche de l’infrastructure (sidecars), et non  au niveau des services individuels.

Comment cela fonctionne-t-il ?

Un Service Mesh est une couche d’infrastructure dédiée qui s’appuie sur un ensemble de proxies. En d’autres termes chaque microservice à son propre proxy, appelé aussi sidecar comme le montre la figure ci-dessous.

L’ensemble des proxies constitue le Service Mesh.

Ces proxies permettent ainsi d’acheminer les requêtes entre les différents microservices. Ainsi, on a un proxy sidecar à côté de chaque microservice et celui-ci achemine les requêtes vers les autres proxies ( Pour plus d’informations sur les sidecars: https://www.beopenit.com/a-la-decouverte-du-modele-sidecar-avec-istio/ ). Tous ensemble, ces sidecars forment un réseau maillé d’où  l’appellation Service Mesh.

On a alors la figure ci-dessous:

                                                                                                                                                                                                  source: https://www.redhat.com/fr/topics/microservices/what-is-a-service-mesh

Tous les proxies du service mesh sont gérés de manière centralisée par un control plane. Ceci est très utile lorsqu’on veut implémenter un contrôle d’accès, une observabilité, un service discovery, etc. 

Les solutions de service mesh les populaires sont Linkerd et Istio

Service Mesh: Pros & Cons

Dans cette partie, nous tenterons de donner les principaux avantages et inconvénients des services meshes.

  • Avantages

    • La commodité des fonctionnalités: Le service mesh ajoute de nombreuses fonctionnalités au système. Toutes ces fonctionnalités ajoutées en dehors des microservices sont réutilisables par des services externes au mesh; (Plus d’informations ici: https://www.beopenit.com/services-entries-istio/)
    • L’observabilité avec la génération de métriques,les logs et les traces distribuées, la résilience à travers les circuits breakers, les retries, les timeouts …. (Plus d’informations ici: https://www.beopenit.com/intro-to-istio-observability/);
    • La sécurité: utilisation du TLS,  gestion des clefs et les politiques d’accès;
    • Service discovery qui est mise en oeuvre dynamiquement par le data plane;
    • Plus de liberté dans le choix d’un langage de programmation pour les microservices.

  • Inconvénients

    • Le nombre d’instances en exécution augmente en cas d’utilisation d’un service mesh (avec les sidecars qui devront également s’exécuter).
    • Ajout d’une latence créée par le fait que chaque appel de service doit d’abord passer par l’intermédiaire d’un sidecar.

 

                       En résumé, le service mesh  répond aux principaux défis liés à la réalisation d’une architecture de microservices. Cela donne plus de liberté dans la sélection de technologies pour la mise en œuvre des microservices. Il permet ainsi de se concentrer davantage sur la logique métier plutôt que d’investir plus de temps sur les fonctions réseau entre les différents services. Cependant les technologies de service mesh sont relativement nouvelles pour être déclarées comme mature pour des déploiements à grande échelle en production. Ce qui fait qu’il y a encore de la place pour de futurs travaux sur celui-ci.

Halima GAYE
Halima GAYEIngénieur Cloud & DevOps