Qu'est-ce qu'un service mesh? Mise en réseau de conteneurs plus facile

L'un des changements qui se produisent dans l'informatique sous la bannière de la transformation numérique est la décomposition de grandes applications monolithiques en microservices - de petites unités discrètes de fonctionnalités - qui s'exécutent dans des conteneurs - des progiciels qui incluent tout le code du service et les dépendances qui peuvent être isolé et facilement déplacé d'un serveur à un autre.

Les architectures conteneurisées comme celles-ci sont faciles à mettre à l'échelle et à exécuter dans le cloud, et les microservices individuels peuvent être rapidement déployés et itérés. Cependant, la communication entre ces microservices devient de plus en plus complexe à mesure que les applications deviennent plus volumineuses et que plusieurs instances du même service s'exécutent simultanément. Un maillage de services est une forme architecturale émergente qui vise à connecter dynamiquement ces microservices de manière à réduire les frais administratifs et de programmation.

Qu'est-ce qu'un service mesh?

Au sens le plus large, un maillage de services est, comme le décrit Red Hat, «un moyen de contrôler la manière dont différentes parties d'une application partagent des données entre elles». Cette description pourrait cependant englober beaucoup de choses différentes. En fait, cela ressemble énormément au middleware que la plupart des développeurs connaissent depuis les applications client-serveur.

Ce qui rend un maillage de services unique, c'est qu'il est conçu pour s'adapter à la nature unique des environnements de microservices distribués. Dans une application à grande échelle construite à partir de microservices, il peut y avoir plusieurs instances d'un service donné, s'exécutant sur divers serveurs locaux ou cloud. Toutes ces pièces mobiles empêchent évidemment les microservices individuels de trouver les autres services avec lesquels ils ont besoin de communiquer. Un maillage de services prend automatiquement en charge la découverte et la connexion des services à chaque instant afin que les développeurs humains et les microservices individuels n'aient pas à le faire.

Considérez un maillage de services comme l'équivalent du réseau défini par logiciel (SDN) pour le niveau 7 du modèle de réseau OSI. Tout comme le SDN crée une couche d'abstraction afin que les administrateurs réseau n'aient pas à gérer les connexions réseau physiques, un maillage de services dissocie l'infrastructure sous-jacente de l'application de l'architecture abstraite avec laquelle vous interagissez.

L'idée d'un maillage de services est née de manière organique lorsque les développeurs ont commencé à s'attaquer aux problèmes d'architectures distribuées vraiment énormes. Linkerd, le premier projet dans ce domaine, est né d'un projet interne à Twitter. Istio, un autre réseau de services populaire bénéficiant d'un soutien majeur de l'entreprise, est né à Lyft. (Nous examinerons plus en détail ces deux projets dans un instant.)

Équilibrage de charge de maillage de service

L’équilibrage de charge est l’une des principales fonctionnalités qu’offre un maillage de services . Nous considérons généralement l'équilibrage de charge comme une fonction réseau. Vous voulez éviter qu'un serveur ou une liaison réseau ne soit submergé par le trafic, vous acheminez donc vos paquets en conséquence. Les maillages de service font quelque chose de similaire au niveau de l'application, comme le décrit Twain Taylor, et cette compréhension vous donne une bonne idée de ce que nous entendons lorsque nous disons qu'un maillage de service est comme un réseau défini par logiciel pour la couche application.

En substance, l’une des tâches du maillage de services consiste à suivre les instances de divers microservices distribués sur l’infrastructure qui sont les plus «saines». Il peut les interroger pour voir comment ils font ou suivre les instances qui répondent lentement aux demandes de service et envoyer les demandes suivantes à d'autres instances. Le service mesh peut effectuer un travail similaire pour les routes réseau, en remarquant que les messages mettent trop de temps à arriver à leur destination et en empruntant d'autres routes pour compenser. Ces ralentissements peuvent être dus à des problèmes avec le matériel sous-jacent, ou simplement au fait que les services sont surchargés de demandes ou travaillent à leur capacité de traitement. L'important est que le maillage de services puisse trouver une autre instance du même service et s'y acheminer à la place, faisant ainsi l'utilisation la plus efficace de la capacité globale de l'application.

Service Mesh vs Kubernetes

Si vous êtes un peu familier avec les architectures basées sur des conteneurs, vous vous demandez peut-être où Kubernetes, la plate-forme d'orchestration de conteneurs open source populaire, s'inscrit dans cette image. Après tout, l'intérêt de Kubernetes n'est-il pas de gérer la manière dont vos conteneurs communiquent entre eux? Comme le souligne l'équipe Kublr sur son blog d'entreprise, vous pouvez considérer la ressource «service» de Kubernetes comme un type très basique de maillage de services, car il fournit la découverte de services et l'équilibrage à tour de rôle des demandes. Mais les maillages de service complets offrent beaucoup plus de fonctionnalités, telles que la gestion des politiques de sécurité et du chiffrement, la «coupure de circuit» pour suspendre les demandes aux instances à réponse lente, l'équilibrage de charge comme nous l'avons décrit ci-dessus, et bien plus encore.

Gardez à l'esprit que la plupart des maillages de service nécessitent en réalité la mise en place d'un système d'orchestration tel que Kubernetes. Les maillages de service offrent des fonctionnalités étendues, pas un remplacement.

Service mesh vs passerelles API

Chaque microservice fournira une interface de programmation d'application (API) qui sert de moyen par lequel d'autres services communiquent avec lui. Cela soulève la question des différences entre un maillage de services et d'autres formes plus traditionnelles de gestion d'API, comme les passerelles d'API . Comme l'explique IBM, une passerelle API se situe entre un groupe de microservices et le monde «extérieur», acheminant les demandes de service si nécessaire afin que le demandeur n'ait pas besoin de savoir qu'il a affaire à une application basée sur des microservices. Un maillage de services, quant à lui, assure la médiation des requêtes «à l'intérieur» de l'application des microservices, les différents composants étant pleinement conscients de leur environnement.

Une autre façon d'y penser, comme l'écrit Justin Warren dans Forbes , est qu'un maillage de service est destiné au trafic est-ouest au sein d'un cluster et qu'une passerelle API est destinée au trafic nord-sud entrant et sortant du cluster. Mais toute l'idée d'un maillage de services est encore précoce et en évolution. De nombreux maillages de service, y compris Linkerd et Istio, offrent désormais également une fonctionnalité nord-sud.

Architecture de maillage de service

L'idée d'un maillage de services n'a émergé que ces dernières années, et il existe un certain nombre d'approches différentes pour résoudre le problème du «maillage de services», c'est-à-dire la gestion des communications pour les microservices. Andrew Jenkins d'Aspen Mesh identifie trois choix possibles concernant l'emplacement de la couche de communication créée par le maillage de service:

  • Dans une bibliothèque que chacun de vos microservices importe
  • Dans un agent de nœud qui fournit des services à tous les conteneurs sur un nœud particulier
  • Dans un conteneur side - car qui fonctionne avec votre conteneur d'application

Le modèle basé sur side-car est l'un des modèles de maillage de service les plus populaires, à tel point qu'il est à certains égards devenu synonyme de maillage de service en général. Bien que ce ne soit pas vrai à proprement parler, l'approche side-car a tellement gagné en popularité que c'est l'architecture que nous allons examiner plus en détail.

Sidecars dans un maillage de service

Qu'est-ce que cela signifie de dire qu'un conteneur side-car «court à côté» de votre conteneur d'application? Red Hat a une assez bonne explication. Chaque conteneur de microservices dans un maillage de services de ce type a un autre conteneur proxy qui lui correspond. Toute la logique requise pour la communication de service à service est extraite du microservice et placée dans le side-car.

Cela peut sembler compliqué - après tout, vous doublez effectivement le nombre de conteneurs dans votre application! Mais vous utilisez également un modèle de conception qui est essentiel pour simplifier les applications distribuées. En plaçant tout ce code de mise en réseau et de communication dans un conteneur séparé, vous l'avez intégré à l'infrastructure et vous avez libéré les développeurs de l'implémentation dans le cadre de l'application.

En substance, il vous reste un microservice qui peut être axé sur sa logique métier. Le microservice n'a pas besoin de savoir comment communiquer avec tous les autres services dans l'environnement sauvage et fou où ils opèrent. Il lui suffit de savoir communiquer avec le side-car, qui s'occupe du reste.

Maillages de service: Linkerd, Envio, Istio, Consul

Alors, quels sont les maillages de service disponibles? Eh bien, il n'y a pas vraiment de produits commerciaux prêts à l'emploi. La plupart des mailles de services sont des projets open source qui nécessitent quelques précautions à mettre en œuvre. Les grands noms sont:

  • Linkerd (prononcé «linker-dee») - Sorti en 2016, et donc la plus ancienne de ces offres, Linkerd a été dérivé d'une bibliothèque développée sur Twitter. Un autre gros frappeur dans cet espace, Conduit, a été intégré au projet Linkerd et constitue la base de Linkerd 2.0.
  • Envoy: créé chez Lyft, Envoy occupe la partie «plan de données» d'un maillage de service. Pour fournir un maillage complet, il doit être associé à un «plan de contrôle», comme ...
  • Istio - Développé en collaboration par Lyft, IBM et Google, Istio est un plan de contrôle pour desservir des proxys tels que Envoy. Alors qu'Istio et Envoy sont une paire par défaut, chacun peut être associé à d'autres plates-formes.
  • HashiCorp Consul - Introduit avec Consul 1.2, une fonctionnalité appelée Connect a ajouté un chiffrement de service et une autorisation basée sur l'identité au système distribué de HashiCorp pour la découverte et la configuration de services, le transformant en un maillage de services complet.

Quel service mesh vous convient le mieux? Une comparaison dépasse le cadre de cet article, mais il convient de noter que tous les produits ci-dessus ont fait leurs preuves dans des environnements vastes et exigeants. Linkerd et Istio ont les ensembles de fonctionnalités les plus étendus, mais tous évoluent rapidement. Vous voudrez peut-être consulter la répartition par George Miranda des fonctionnalités de Linkerd, Envoy et Istio, tout en gardant à l'esprit que son article a été écrit avant que Conduit et Linkerd ne joignent leurs forces.

Gardez également à l'esprit que cet espace est nouveau et que de nouveaux concurrents pourraient émerger à tout moment. Par exemple, en novembre 2018, Amazon a commencé à proposer un aperçu public d'un maillage de services AWS. Compte tenu du nombre de boutiques utilisant le cloud public d'Amazon, AWS App Mesh devrait avoir un impact majeur.