Introduction au Service Mesh

Photo by Reynaldo #brigworkz Brigantty from Pexels

TL;DR: Qu'est-ce que c'est ? A quoi ça sert ? Cet article s'intéresse aux Services Mesh et sert d'introduction aux articles à venir consacrés à Istio.

Gérer les connexions entre les composants d'une applications vient avec plusieurs challenges. C'est évident d'une architecture basée sur des services mais pas seulement. Une architecture multi-tiers, une architecture avec plusieurs instances d'un même composant pour assurer de la redondance ou une application qui échange avec d'autres applications font face à des challenges similaires :

  • Comment documenter le fonctionnement ou les dysfonctionnements des communications entre les composants ? Et si les problèmes ne sont pas dans le réseau mais au niveau de l'application ?
  • Comment assurer que les communications entre les composants sont chiffrées, que les composants sont identifiés et que les flux sont controllés ?
  • Comment gérer la surcharge volontaire ou involontaire d'un composant et limiter l'impact d'une panne dans les communications ?

Il existe plusieurs solutions pour répondre à ces questions. Celle qui vient la première consiste souvent, à implémenter une solution locale, dans le composant concerné. Puis le niveau de difficulté augmentant, les composants intègrent des bibliothèques comme Hystrix ou resilience4j s'il s'agit de gérer une tolérance à une panne en Java. Puis vient un framework de communication multi-langages comme gRPC.

Un service mesh est une couche d'infrastructure qui gère les communications entre les composants applicatifs. Il apporte des solutions à ces challenges sans qu'elles soient codées dans l'application. Sa position centrale lui permet d'adresser d'autres problèmes comme la collecte de traces ou les tests de nouvelles versions de composants. Pas toujours évident à mettre en oeuvre car au coeur des services applicatifs, il apporte l'énorme avantage de supprimer le besoin de coder tous ses aspects dans les applications. La plupart des implémentations

Le service mesh apporte des réponses à des problèmes difficiles auxquelles la grande majorité des applications sont confrontées quand leur usage se développe. Cela explique "la mode" du moment. Surtout que le sujet est loin d'être bouclé. De nombreux projets apportent leurs avantages ou se focalisent sur des aspects specifiques de ce type d'infrastructure. Ainsi vous serez intéressé de regarder Linkerd par Buoyant, Istio par Google, Consul Connect par Hashicorp, Maesh par Containous, le petit bijou d'origine française. Les fournisseurs Cloud, quant à eux, commencent à offrir des services qui gèrent ces solutions avec Istio on GCP, AWS App Mesh et Azure Service Fabric Mesh.

Difficile d'anticiper qui sortira vainqueur, s'il y aura un vainqueur ou même s'il faut qu'il y ait un vainqueur. Par exemple, on voit émerger l'idée d'une interface standard sur Kubernetes comme pour le réseau ou le stockage avec Service Mesh Interface. Ce qui est sûr pour l'avoir pratiqué dans plusieurs il y a déjà plusieurs années, d'abord avec des briques plus techniques comme Fabio et Consul puis avec Istio, c'est que gérer les communications est à la fois pas si simple et magique.

Le cadre est posé. Les articles qui suivent illustreront quant à eux les capacités d'Istio. Si dans l'intervalle vous voulez en savoir plus, les articles foisonnent sur le sujet et vous serez peut-être intéressé de regarder les enregistrements du first ever Service Mesh Con

Published under  on .

Easyteam DevOps

Easyteam DevOps