Microservices

Qu'est-ce qu'un Service Mesh ?

Un Service Mesh est un moyen de contrôler la façon dont différents éléments d'une application partagent des données les uns avec les autres. Contrairement à d'autres systèmes de gestion des communications, un Service Mesh est une couche d'infrastructure dédiée, créée directement dans l'application. Cette couche d'infrastructure visible peut indiquer la manière dont les différents éléments d'une application interagissent entre eux. Il devient dès lors plus facile d'optimiser les communications et d'éviter les temps d'arrêt lorsque l'application évolue.

Chaque élément, ou « service », d'une application dépend d'autres services pour satisfaire les attentes des utilisateurs. Prenons l'exemple d'une application de vente en ligne. Avant d'acheter un article, l'utilisateur a besoin de savoir s'il est en stock. Le service qui communique avec la base de données de l'inventaire doit alors communiquer avec la page Web du produit, laquelle doit communiquer à son tour avec le panier en ligne de l'utilisateur. Le revendeur peut aussi décider d'intégrer un service de recommandation de produits au sein de l'application pour guider les utilisateurs. Ce nouveau service devra communiquer avec une base de données de balises de produit pour générer des recommandations, mais aussi avec la base de données de l'inventaire avec laquelle la page produit devait déjà communiquer. Cela représente beaucoup d'éléments mobiles réutilisables.

Les applications modernes se décomposent souvent ainsi, sous la forme d'un réseau de services assurant chacun une fonction métier particulière. Pour assumer sa fonction, un service peut avoir besoin de demander des données à plusieurs autres services. Mais que se passe-t-il lorsque certains services, comme la base de données de l'inventaire du revendeur, sont surchargés de demandes ? C'est ici qu'intervient le Service Mesh : ce système achemine les demandes d'un service au suivant, de manière à optimiser le fonctionnement des éléments mobiles.


N'est-ce pas déjà le rôle des microservices ?

Dans une architecture de microservices, les développeurs peuvent modifier les services d'une application sans être obligés de la redéployer entièrement. Contrairement à ce qui se passe dans d'autres architectures, les différents microservices proviennent d'équipes de développement réduites qui sont libres de choisir leurs outils et leurs langages de programmation. En résumé, les microservices sont créés séparément et communiquent les uns avec les autres. Chacun peut subir une défaillance sans pour autant provoquer l'arrêt complet de l'application.

La communication entre services constitue le fondement des microservices. Sa logique peut être codée au niveau du service, sans couche de Service Mesh. Cependant, plus les communications se compliquent, plus le Service Mesh devient un atout. Pour les applications natives pour le cloud développées dans une architecture de microservices, cette couche offre la possibilité de regrouper un grand nombre de services distincts dans une application fonctionnelle.


Comment fonctionne un Service Mesh ?

Un Service Mesh n'ajoute pas de fonctionnalités à l'environnement d'exécution d'une application. Dans toute architecture, les applications ont toujours eu besoin de règles pour définir l'acheminement d'une requête d'un point A à un point B. L'unique différence est que la logique de communication entre services réside sur une couche de l'infrastructure, et non plus au niveau des services individuels.

En pratique, un Service Mesh est créé dans une application sous la forme d'un ensemble de proxies réseau. Le proxy est un concept familier dans l'univers de l'informatique d'entreprise. Si vous consultez cette page Web sur un ordinateur professionnel, vous venez sans doute d'en utiliser un :

  1. Votre demande d'accès à cette page a d'abord été reçue par le proxy Web de votre entreprise…
  2. Une fois les contrôles de sécurité du proxy passés, votre demande a été transmise au serveur qui héberge cette page…
  3. Puis la page a été renvoyée au proxy et soumise à nouveau aux contrôles de sécurité…
  4. Pour finir, le proxy vous a envoyé la page.

Avec un Service Mesh, l'acheminement des requêtes entre les microservices s'effectue via des proxies situés sur leur propre couche d'infrastructure, d'où l'emploi du terme « sidecars » pour désigner les proxies qui composent un Service Mesh, car ils s'exécutent à côté de chaque service, et non dans les services. Ensemble, les proxies « sidecars » de chaque service forment un réseau maillé.

Un proxy sidecar se situe à côté d'un microservice et achemine les requêtes aux autres proxies. Tous ensemble, ces sidecars forment un réseau maillé.

L'absence de Service Mesh oblige les développeurs à coder chaque microservice selon la logique de communication entre services. Ces derniers perdent ainsi de vue les objectifs de l'entreprise et ont plus de difficultés à diagnostiquer les problèmes de communication, car la logique de communication entre les services est cachée dans chaque service.


Comment un Service Mesh optimise-t-il les communications ?

Chaque fois qu'un service est ajouté dans une application ou dans une nouvelle instance d'un service existant exécuté dans un conteneur, l'environnement de communication se complexifie et de nouveaux points de défaillance peuvent apparaître. Dans une architecture de microservices complexe, parvenir à localiser les problèmes sans Service Mesh relève quasiment de l'impossible.

Un Service Mesh fournit également des statistiques de performances sur chacun des aspects de la communication entre les services. Au fil du temps, les données ainsi révélées peuvent être appliquées aux règles de communication entre les services, ce qui améliore l'efficacité et la fiabilité des requêtes de service.

Par exemple, si un service ne parvient pas à répondre à une requête, le Service Mesh peut savoir au bout de combien de temps une nouvelle tentative a réussi. À mesure que les données sur les périodes de défaillance de ce service s'accumulent, des règles peuvent être établies pour déterminer le délai optimal avant de réinterroger ce service. Cela évite ainsi d'engorger le système avec des tentatives superflues.


Préparer l'avenir

Si vous avez commencé à créer des microservices, il est probable que vous ayez anticipé certains besoins tels que la capacité à évoluer rapidement et l'ajout de fonctions pour répondre aux exigences futures de l'entreprise. Votre architecture de microservices sera sans doute bien différente un an après son lancement. Au départ, les bibliothèques intégrées dans les microservices sauront gérer la communication entre services sans perturber l'exploitation, ou presque. Cependant, cela ne durera pas très longtemps si vous décidez d'exploiter tout le potentiel de cette technologie en développant les microservices et en les enrichissant de fonctions. En effet, les services seront alors surchargés de demandes et les développeurs passeront de plus en plus de temps à coder la logique de requête pour chaque service, ce qui pourra causer des problèmes.

Avec un Service Mesh :

  • les développeurs se concentrent sur l'ajout de valeur à l'entreprise, et non sur la connexion des services ;
  • la logique de requête forme une couche d'infrastructure visible à côté des services, ce qui facilite l'identification et la résolution des problèmes ;
  • les applications résistent mieux aux temps d'arrêt, car le Service Mesh peut rediriger les demandes sans transiter par les services défaillants ;
  • la communication dans l'environnement d'exécution peut être optimisée d'après les statistiques de performances.

Vous ne savez pas encore tout sur les Service Mesh…