Ai-je besoin d’un service Mesh?

Yann
Yann
Dec 2 · 5 min read
Photo by Denys Nevozhai on Unsplash

Le terme “service mesh” est sur toutes les lèvres en ce moment. Pour cause, on tombe sur beaucoup d’articles sur le sujet, principalement sur les journaux de veille numérique. Dans ces écrits, les points suivants sont souvent évoqués:

  • Qu’est-ce qu’un service mesh
  • Qui l’a développé et pourquoi
  • Les fonctionnalités principales
  • Des retours d’expériences très sommaires

De manière générale, tout le monde s’inspire des géants de l’industrie comme Google ou Netflix pour faire évoluer ses infrastructures, ses applications ou ses façons de procéder. D’une part car ils incarnent la réussite ultime en matière de scalabilité, sécurité et optimisation. D’autre part car leur technologies sont accessibles librement et sont extrêmement plébiscités par leurs créateurs et partisans (blogs, annonces, trending github, etc.).

Quand l’or est dans toutes les mains, a-t-il vraiment la même valeur pour tout le monde?

Dans cet article, nous allons essayer d’aborder une vision différente de la frénésie médiatique autour des services mesh sans se focaliser sur une implémentation en particulier. Il n’aura pas vocation à expliquer ce qu’est un service mesh, vous n’aurez pas de mal à trouver des informations sur internet.

1. Un dispositif complexe pour un usage spécifique

Sauf si votre plateforme est une exception de part le trafic que vous générez, les contraintes du domaine d’activité ou l’organisation de vos multiples équipes, très peu d’entreprises ont fait le choix d’utiliser des services mesh en production pour le moment. Ces exceptions sont principalement :

  • Les géants du web
  • Les banques
  • Les early-adopters

Même si ce n’est pas une statistique sans failles, il n’y a qu’à regarder les hits de recherche sur Google trends pour se rendre compte qu’on est encore loin d’une adoption massive comme Kubernetes en 2019.

En bleu, les recherches concernant Kubernetes, en rouge les recherches concernant Istio

En règle générale, avoir une “infrastructure exceptionnelle” est le résultat d’une architecture complexe et c’est loin d’être un atout. Maîtriser la complexité est le véritable intérêt d’un service mesh mais ce n’est pas parce qu’il existe une solution que l’on ne doit pas lutter contre.

2. La simplicité est votre plus grand allié

A force d’admirer les géants du web, l’industrie du numérique dont nous faisons tous parti redéfinit ses propres standards continuellement sans discrimination concernant la taille ou le métier des entreprises du secteur. Sans faire de la résistance au changement, il est primordial d’assainir et de raffermir ce qui est déjà en place avant d’ajouter un étage supplémentaire. Chaque nouvel ajout technique dans une plateforme va être accompagné de:

  • La formation des équipes qui la maintienne
  • La documentation annexe liée au contexte de votre implémentation
  • L’observabilité de cette brique
  • Montées de versions
  • Un temps non négligeable de maîtrise et d’expérience en condition réelle de production

Les points relevés ci-dessus ne sont pas exhaustifs et se répètent pendant toute la vie de la plateforme, d’où la nécessité de rester simple le plus longtemps possible.

C’est facile de trouver des solutions complexe, c’est compliqué de trouver une solution simple.

La complexification va rendre les plateformes plus vulnérables aux erreurs de configuration et les erreurs humaines.

3. Le service mesh n’est pas votre première option

Les fonctionnalités d’un service mesh sont nombreuses et répondent principalement aux problématiques de sécurité, d’observabilité et de routage. Hors, il existe déjà de multiples solutions sur les couches inférieures de votre infrastructure qu’il va falloir de toute façon implémenter et maîtriser. Si vous êtes déjà sur un cluster Kubernetes et que l’on parle de sécurité, il existe par exemple des politiques de sécurisation réseau (NetworkPolicy) qui permettent de limiter les interactions entre les pods. Pour ce qui est de l’observabilité, sauf si vous n’avez pas aimé les services proposés par votre Cloud Provider, un Prometheus avec une stack de logging (ELK ou Loki), voire un APM seront tout de même nécessaires avant de chercher du côté des services mesh. Pour le routage, Kubernetes est déjà extrêmement bien fourni avec les “Ingresses” notamment avec son contrôleur nginx-ingress qui permet de faire tout ce que vous souhaitez en terme de protocole HTTP, même du canary release.

4. Aucune implémentation n’est encore devenue la norme

Et c’est peut être le point le plus important… On assiste en ce moment même au combat que se livraient les orchestrateurs de conteneurs il y a 3 ans. Entre Kubernetes, Nomad, Swarm et Mesos, la guerre faisait rage et il ne pouvait en rester qu’un pour déclencher une adoption massive des conteneurs en production. La communauté a finalement tranché en faveur de Kubernetes, mais toutes les implémentations avaient leur mot à dire. Même si Google avait la notoriété suffisante pour gagner un combat comme celui-ci, il a fallu néanmoins une fondation d’industriels, la CNCF, pour décider de manière indépendante et objective la direction à suivre.

Concernant les implémentations de service mesh, il va falloir passer par cette même étape de sélection du public, c’est une bonne approche mais qui peut prendre du temps. Il existe actuellement une multitude “d’outils” pour intégrer un service mesh dans sa plateforme. Les plus connus sont Istio, Linkerd mais il y a d’autres alternatives très intéressantes comme Consul, Maesh ou encore Kuma. On peut cependant faire le pari qu’Istio va sortir du lot car, à l’instar de Kubernetes, Google en est le géniteur. De plus, Envoy (le composant principal du data plane d’Istio) est déjà gradué dans la CNCF…Mais pour l’instant, rien n’est joué.

Alors que dois-je faire?

Si vous vous êtes posé la question de l’utilisation ou non d’un service mesh, c’est que vous en avez probablement pas l’usage. Les services mesh sont déjà utilisés en production par des équipes qui ont un réel intérêt à ajouter une abstraction supplémentaire, mais elles sont rares. Il est évident que les services mesh vont prendre une part de plus en plus grande dans nos infrastructures mais il va falloir du temps pour laisser mûrir les consciences et peaufiner l’implémentation qui sortira du lot. Comme toutes les révolutions informatiques, celle-ci ne se fera pas hâtivement mais il est certain que Google a placé Istio comme le fer de lance de son offre Kubernetes managé et sa volonté de rendre accessible les plateformes hybrides (cloud et on-premise) avec Anthos.

Comme toujours, il faut continuer à s’informer (voire se former) car la place de ces nouveaux patterns va se préciser au cours des mois à venir. Ce qui est sûr, c’est qu’on à pas fini d’entendre parler de services mesh, bien au contraire…

Merci pour votre lecture. Si cet article vous a plu, merci de le partager et de clicker sur “les claps” 👏

Yann

Written by

Yann

Head of innovation @SKALE-5. #Kubernetes #Golang

skale-5

skale-5

Infogéreur 100 % DevOps de vos applications sur les Cloud AWS, GCP et AZURE. Nous sommes aussi certifiés KUBERNETES. Nous migrons les applications (Move2cloud), nous concevons les architectures Cloud natives, nous assurons la disponibilité 24/7 en intégrant réellement le DevOps.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade