Service Mesh, pour une intégration optimale des Microservices

Article

Sécurisation transparente des communications inter-Microservices, fiabilité des communications, gestion efficace des accès pour un utilisateur final, résilience des systèmes, le Service Mesh permet de simplifier au maximum la conception des Microservices.

A l’heure où la mise en œuvre des Architectures Microservices se multiplie dans les DSI, le panel des solutions techniques ne cessent de s’enrichir. Complément aux plateformes de conteneurisation basées sur Kubernetes, les Services Mesh proposent une vision innovante de l’intégration des Microservices. Les plateformes de conteneurisation laissent beaucoup de points techniques ouverts lors de la mise en œuvre d’une Architecture Microservices :
  • Comment sécuriser les communications inter-Microservices ?
  • Comment fiabiliser ces communications ?
  • Comment identifier et autoriser l’utilisateur final ?
Il est évidemment possible de traiter tous ces points manuellement dans le code source, mais n’est-ce pas l’un des objectifs premiers d’éliminer toute problématique technique du Microservice ? C’est là que rentrent en jeu les Services Mesh : apporter une solution clé en main répondant à toutes ces questions, sans polluer le code applicatif.

Sans Services Mesh, chaque Microservice embarque une lourde charge technique

Netflix est l’un des grands précurseurs des Architectures Microservices. Sa suite Netflix OSS a dès sa publication été considérée comme une référence pour mettre en œuvre une telle Architecture. Eureka, Zuul ou Hystrix sont effectivement des solutions intéressantes mais se présentent sous forme de librairies à incorporer et à utiliser dans les sources des applications. Les développeurs sont contraints d’utiliser des librairies particulières et de respecter certaines règles de développement. Progressivement ces particularités prennent l’aspect d’un anti-pattern, alourdissant le code source et complexifiant sa maintenabilité, tout en augmentant la quantité de bonnes pratiques techniques à tester et valider.

Le sidecar : la simplification des Services Mesh

Après quelques tentatives passées (notamment par Linkerd dans sa première version), les Services Mesh ont aujourd’hui construit une solution élégante pour contourner ces écueils : externaliser l’ensemble des configurations et du runtime des échanges interapplicatifs dans une brique appelée « sidecar ». Ce sidecar se trouve placé en front de chaque Microservice et s’impose en passage obligé pour l’ensemble des appels entrants et sortants de ce service. Une brique centrale se charge de diffuser la configuration du cluster à travers tous les sidecars, tout en centralisant leurs statistiques et logs.

Conteneurisation Orientée Microservices

Grâce aux Services Mesh et au concept de sidecar, le développement d’un microservice se fait sans se préoccuper d’un certain nombre de sujets clefs :

  • L’authentification des appels reçus par les Microservices
  • La gestion des droits des utilisateurs
  • La gestion des quotas d’accès
  • La télémétrie et la surveillance des échanges

En prenant la responsabilité de la gestion des échanges, le Services Mesh permet de déplacer les questions d’accès – authentification et gestion du trafic – de l’applicatif vers la configuration. C’est un gain en souplesse ; les Microservices en eux-mêmes ne sont plus impactés par les évolutions de Gouvernance.

Dans les Services Mesh basés sur Kubernetes, le sidecar est un conteneur instancié automatiquement avec le conteneur applicatif dans un pod qui leur est dédié. L’isolation du Microservice est assurée par le passage obligatoire de toute communication entrante ou sortante du pod par le sidecar. Le dialogue entre le sidecar et le Microservice s’effectue à l’intérieur du pod.

Au sein du Service Mesh, l’identification et l’authentification sont laissés au soin d’un serveur compatible OAuth2 et/ou OpenID Connect, ce qui permet de réutiliser les systèmes de sécurité déjà en place au sein d’un SI.

De par leur position centrale dans la communication inter-Microservices, les Services Mesh offrent tout un panel d’outils et de fonctionnalités particulièrement précieux. On peut citer :

  • la mise en place d’un système de « circuit-breaker » permettant d’isoler des services en défaut le temps de leur correction ;
  • la « fault-injection », allant du retour aléatoire d’un code d’erreur à l’injection de temps de latence, qui permet aux développeurs et aux concepteurs de s’assurer du bon fonctionnement en mode dégradé de leurs Microservices dès les phases de test.

Services Mesh et Microservices : un couple gagnant

Aujourd’hui l’utilisation des Services Mesh se généralise. En atteste l’usage fait par les solutions d’API Management dans l’implémentation du concept de microgateway (sécurisation au plus près des APIs exploitées par les applications Microservices).

Simples à intégrer dans un SI, respectueux des pratiques, des tendances et technologies actuelles, les Services Mesh font figure de solutions particulièrement crédibles aux problématiques soulevées par la mise en place d’une Architecture Microservice.

Auteur

  • onepoint

    beyond the obvious

Ces contenus peuvent vous intéresser…