Guide Ultime Des Services Mesh : Gestion Des Communications De Service À Service

Vers 2016, le terme «service mesh» est apparu de nulle part dans les domaines des microservices, du cloud computing et de DevOps. Cependant, comme pour de nombreux concepts informatiques, il existe en fait une longue histoire du pattern et de la technologie associés.

L'arrivée des services mesh est largement due à une tempête dans le paysage informatique. Les développeurs ont commencé à créer des systèmes distribués à l'aide d'une approche multilingue (polyglotte) et avaient besoin d'une découverte de service dynamique. Les opérateurs ont commencé à utiliser une infrastructure éphémère et souhaitaient gérer avec élégance les inévitables échecs de communication et appliquer les stratégies réseau. Les équipes de la plate-forme ont commencé à adopter des systèmes d'orchestration de conteneurs tels que Kubernetes, et souhaitaient acheminer dynamiquement le trafic à l'intérieur et autour du système à l'aide de proxys réseau basés sur des API modernes, tels que Envoy.

Cet article vise à répondre à des questions pertinentes pour les architectes logiciels et les leaders techniques, telles que : qu'est-ce qu'un service mesh ?, Ai-je besoin d'un service mesh ?, Et comment évaluer les différentes offres de service mesh ?

Vous pouvez utiliser le menu Table des matières en bas de la page pour parcourir rapidement ce guide.

Le pattern service mesh

Le pattern service mesh se concentre sur la gestion de toutes les communications de service à service au sein d'un système logiciel distribué.

Le contexte

Le contexte du pattern est double : premièrement, les ingénieurs ont adopté le modèle d'architecture de microservice et construisent leurs applications en composant ensemble plusieurs services (idéalement à but unique et déployables indépendamment). Deuxièmement, l'organisation a adopté les technologies de plate-forme cloud native telles que les conteneurs (par exemple, Docker), les orchestrateurs (par exemple, Kubernetes) et les proxys/passerelles (par exemple, Envoy).

Intention

Les problèmes que le pattern service mesh tente de résoudre sont les suivants :

• Élimination de la nécessité de compiler dans des services individuels une bibliothèque de communication spécifique au language pour gérer la découverte de services, les routages et les exigences de communication non fonctionnelles au niveau de l'application (couche 7).
• Externalisation de la configuration des communications de service, y compris les emplacements réseau des services externes, les informations d'identification de sécurité et les objectifs de qualité de service.
• Assurer une surveillance passive et active des autres services.
• Décentraliser l'application de la stratégie dans un système distribué.
• Fournir des valeurs par défaut d'observabilité et standardiser la collecte des données associées. 
  • Activation de la journalisation des requêtes
  • Configuration du suivi distribué
  • Collecte de statistiques

Structure

Le pattern service mesh se concentre principalement sur la gestion traditionnelle de ce qui a été appelé "est-ouest", le trafic basé sur l'appel de procédure distante (RPC) : communication de type requête/réponse qui émet en interne dans un datacenter et se déplace de service à service. Cela contraste avec une API Gateway ou un edge proxy, qui est conçu pour gérer un trafic "nord-sud" : communication provenant de l'extérieur et entrant vers un endpoint ou un service dans le datacenter.

Les caractéristiques d'un service mesh

Une implémentation d'un service mesh offrira généralement une ou plusieurs des fonctionnalités suivantes :

• Normalise la dénomination et ajoute un routage logique (par exemple, mappe le nom au niveau du code "user-service" à l'emplacement spécifique à la plate-forme "AWS-us-east-1a/prod/users/v4")
• Fournit les fonctionnalités traffic shaping et traffic shifting
• Maintient l'équilibrage de charge, généralement avec des algorithmes configurables
• Fournit un contrôle de la livraion des services (par exemple, release de type canary et répartition du trafic)
• Offre un routage par requête (par exemple, traffic shadowing, l'injection de pannes et le débogage du re-routage)
• Ajoute la fiabilité de base, comme les health checks, les timeouts/deadlines, les coupes circuit et les retentatives (budgets)
• Augmente la sécurité, via une utilisation transparente de Transport Level Security (TLS) et des politiques telles que les listes de contrôle d'accès (Access Control Lists ACL)
• Fournit une observabilité et une surveillance supplémentaires, telles que des mesures de premier plan (volume de demandes, taux de réussite et latences), la prise en charge du traçage distribué et la possibilité d' "exploiter" et d'inspecter la communication de service à service en temps réel
• Permet aux équipes de la plateforme de configurer des "valeurs par défaut saines" pour protéger le système contre les mauvaises communications

Architecture de service mesh : regarder sous le capot

Un service mesh se compose de deux composants de haut niveau : un data plane et un control plane. Matt Klein, créateur du Envoy Proxy, a écrit un excellent deep-dive le sujet "service mesh data plane versus control plane. "

D'une manière générale, le data plane "fait le travail" et est responsable de "la traduction conditionnelle, le transfert et l'observation de chaque paquet réseau qui circule vers et depuis un endpoint réseau". Dans les systèmes modernes, le data plane est généralement implémenté en tant que proxy (tel qu'Envoy), qui est exécuté hors processus en même temps que chaque service en tant que «sidecar». Matt Klein déclare que dans un service mesh, le data plane "touche chaque paquet/demande dans le système, et est responsable de la découverte du service, de la vérification de l'intégrité, du routage, de la répartition de charge, de l'authentification/autorisation et de l'observabilité".

Un control plane «supervise le travail» et prend toutes les instances individuelles du data plane - un ensemble de proxys sidecar isolés sans état - et les transforme en un système distribué. Le control plane ne touche aucun paquet/demande dans le système, mais à la place, il permet à un opérateur humain de fournir une politique et une configuration pour tous les data planes en cours d'exécution dans le mesh. Le control plane permet également de collecter et de centraliser la télémétrie du data plane, prête à être consommée par un opérateur; Red Hat a travaillé sur Kiali uniquement pour ce cas d'utilisation.

Le diagramme ci-dessous est tiré de la documentation d'architecture d'Istio, et bien que les technologies étiquetées soient spécifiques à Istio, les composants sont généraux à toutes les implémentations de services mesh.

Architecture Istio, montrant comment le control plane et le proxy data plane interagissent (avec l'aimable autorisation de la documentation Istio)

Les cas d'utilisation

Il existe une variété de cas d'utilisation qu'un service mesh peut activer ou prendre en charge.

La découverte et le routage de services dynamiques

Un service mesh permet la découverte dynamique de services et la gestion du trafic, y compris le filtrage du trafic (duplication) pour les tests, et la répartition du trafic pour les releases de type  canary et l'expérimentation de type A / B.

Les proxys utilisés dans un service mesh sont généralement compatibles avec la "couche d'application" (fonctionnant au niveau de la couche 7 dans la pile de mise en réseau OSI). Cela signifie que les décisions de routage du trafic et l'étiquetage des métriques peuvent s'appuyer sur les données des en-têtes HTTP ou d'autres métadonnées de protocole de la couche application.

La fiabilité des communications de service à service

Un service mesh prend en charge la mise en œuvre et l'application des exigences de fiabilité transversales, telles que les retentatives de requêtes, les délais d'expiration (timeout), la limitation de débit (rate limiting) et la coupure de circuit (circuit-breaking). Un service mesh est souvent utilisé pour compenser (ou encapsuler) le traitement des huit erreurs de l'informatique distribuée. Il convient de noter qu'un service mesh ne peut offrir qu'une prise en charge de la fiabilité au niveau wire (comme une nouvelle tentative de requête HTTP), et en fin de compte, le service devrait être responsable de tout impact business connexe, comme éviter plusieurs requêtes HTTP de type POST (non idempotentes).

L'observabilité du trafic

Comme un service mesh est sur le chemin critique pour chaque requête traitée dans le système, il peut également fournir une "observabilité" supplémentaire, comme le suivi distribué d'une demande, la fréquence des codes d'erreur HTTP, la latence globale et de service à service. Bien qu'il s'agisse d'une expression beaucoup trop utilisée dans l'espace de l'entreprise, les services mesh sont souvent proposés comme méthode pour capturer toutes les données nécessaires à la mise en œuvre d'une vue "single pane of glass" du trafic circulant dans l'ensemble du système.

La sécurité des communications

Un service mesh prend également en charge la mise en œuvre et l'application d'exigences de sécurité transversales, telles que la fourniture d'un service d'identité (via des certificats x509), permettant la segmentation du service/réseau au niveau application (par exemple "service A" peut communiquer avec "service B", mais pas avec "service C") garantissant que toutes les communications sont chiffrées (via TLS), et garantissant la présence de jetons d'identité valides au niveau de l'utilisateur ou de "passports".

Les antipatterns

C'est souvent le signe d'une technologie qui arrive à maturité lorsque des antipatterns émergent. Les services mesh ne font pas exception.

Trop de couches de gestion du trafic (Turtles All the Way Down)

Cet antipattern se produit lorsque les développeurs ne se coordonnent pas avec la plate-forme ou l'équipe d'exploitation et dupliquent la logique de gestion des communications existante dans du code qui est maintenant implémenté via un service mesh. Par exemple, une application implémentant une stratégie de nouvelle tentative dans le code en plus d'une stratégie de nouvelle tentative fournie par la configuration du service mesh. Cet antipattern peut entraîner des problèmes tels que des transactions en double.

Service Mesh comme solution miracle

Il n'y a pas de «solution miracle» en informatique, mais les fournisseurs sont parfois tentés de consacrer de nouvelles technologies avec cette étiquette. Un service mesh ne résoudra pas tous les problèmes de communication avec les microservices, les orchestrateurs de conteneurs comme Kubernetes ou les réseaux cloud. Un service mesh vise à faciliter la communication de service à service (est-ouest) uniquement, et il y a un coût opérationnel clair pour le déploiement et l'exécution d'un service mesh.

Enterprise Service Bus (ESB) 2.0

Durant l'ère de l'architecture orientée services (SOA) pré-microservice, les ESB (Enterprise Service Buses) ont implémenté un système de communication entre les composants logiciels. Certains craignent que bon nombre des erreurs de l'ère ESB se répètent avec l'utilisation de service mesh.

Le contrôle centralisé de la communication offert via les ESB avait clairement une valeur. Cependant, le développement des technologies a été mené par les fournisseurs, ce qui a entraîné de nombreux problèmes, tels que : un manque d'interopérabilité entre les ESB, l'extension sur mesure des normes de l'industrie (par exemple, l'ajout d'une configuration spécifique au fournisseur au schéma conforme à WS- *), et un coût élevé. Les fournisseurs d'ESB n'ont également rien fait pour décourager l'intégration et le couplage étroit de la logique métier dans le bus de communication.

Déploiement Big Bang

Il y a une tentation au sein de l'informatique dans son ensemble de croire qu'une approche big bang du déploiement est l'approche la plus facile à gérer, mais comme le montrent les recherches d'Accelerate et du rapport State of DevOps , ce n'est pas le cas. Étant donné que le déploiement complet d'un service mesh signifie que cette technologie est sur le chemin critique pour gérer toutes les requêtes des utilisateurs finaux, un déploiement de type big bang est très risqué.

Implémentations et produits de type service mesh

Voici une liste non exhaustive des implémentations de services mesh actuelles :

• Linkerd
• Istio
• Consul
• Kuma
• Maesh
• AWS App Mesh

Comparaisons des services mesh : quel service mesh ?

L'espace des services mesh évolue extrêmement rapidement et toute tentative de création d'une comparaison risque donc de devenir rapidement obsolète. Cependant, plusieurs comparaisons existent. Il faut prendre soin de comprendre le biais de la source (le cas échéant) et la date à laquelle la comparaison a été effectuée.

• https://layer5.io/landscape
• https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/ (à jour en mai 2019)
• https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/ (à jour en octobre 2019)
• https://servicemesh.es/ (dernière publication en novembre 2019)

InfoQ recommande toujours aux adopteurs de services mesh d'effectuer leur propre diligence raisonnable et d'expérimentation sur chaque offre.

Les tutoriels sur les services mesh

Pour les ingénieurs ou les architectes souhaitant expérimenter plusieurs services mesh, les didacticiels, terrains de jeux et outils suivants sont disponibles :

• Layer 5 Meshery - un plan de gestion multi services mesh.
• SuperGloo de Solo - une plate-forme d'orchestration de services mesh
• Tutoriel sur Istio de KataCoda
• Tutoriel sur le service mesh Consul
• Tutoriel sur Linkerd

Histoire des services mesh

InfoQ suit le sujet que nous appelons maintenant service mesh depuis la fin de 2013, lorsque Airbnb a publié SmartStack , qui offrait un mécanisme de découverte de service hors processus (utilisant HAProxy) pour le style d'architecture émergente "microservices". Beaucoup d'organisations «licornes» précédemment étiquetées travaillaient sur des technologies similaires avant cette date. Au début des années 2010, Twitter a commencé à travailler sur Finagle propulsé par Scala à partir de laquelle le service mesh Linkerd est né. À partir du début des années 2000, Google développait son framework Stubby RPC qui est devenu gRPC, et Google Frontend (GFE) et Global Software Load Balancer (GSLB), dont les traits peuvent être vus dans Istio.

Fin 2014, Netflix a publié une suite complète d'utilitaires basés sur la JVM, y compris Prana , un processus «side-car» qui permettait aux services d'application écrits dans n'importe quelle language de communiquer via HTTP aux instances autonomes des bibliothèques. En 2016, l'équipe NGINX a commencé à parler de « The Fabric Model », qui était très similaire à un service mesh, mais nécessitait l'utilisation de leur produit commercial NGINX Plus pour la mise en œuvre.

Parmi les autres faits marquants de l'histoire des services mesh, citons les releases d'Istio en mai 2017, Linkerd 2.0 en juillet 2018, Consul Connect et SuperGloo en novembre 2018, le service mesh interface (SMI) en mai 2019 et Maesh et Kuma en septembre 2019.

Même les services mesh qui ont émergé en dehors des startups Licornes, comme Consul de HashiCorp, se sont inspirés de la technologie susmentionnée, visant souvent à mettre en œuvre le concept inventé par CoreOS de " GIFEE "; Google infrastructure for everyone else.

Pour une revue approfondie dans l'histoire de l'évolution du concept de service mesh moderne, Phil Calçado a écrit un article complet " Pattern: Service Mesh ".

Explorer l'avenir (possible) des services mesh

Comme la technologie de service mesh est encore en phase d'adoption précoce [early adoption], il y a beaucoup de place pour les travaux futurs. D'une manière générale, il existe quatre domaines d'intérêt particulier : l'ajout de la prise en charge des cas d'utilisation au-delà du RPC, la normalisation de l'interface et des opérations, la poussée plus en avant des services mesh dans la structure de la plateforme de fabrication et la construction de control planes efficaces pour les humains concernant la technologie service mesh.

Kasun Indrasiri a exploré " Le potentiel d'utilisation d'un service mesh pour la messagerie événementielle ", dans lequel il a discuté de deux principaux modèles architecturaux émergents pour la mise en œuvre de la prise en charge de la messagerie dans un service mesh : le protocole proxy sidecar et le pont HTTP sidecar. Il s'agit d'un domaine de développement actif au sein de la communauté des services mesh, le travail de soutien à Apache Kafka au sein d'Envoy attirant une attention considérable.

Christian Posta a déjà écrit sur les tentatives de standardisation de l'utilisation des services mesh dans « Vers une API standard unifiée pour consolider les services mesh ». Cet article traite également de Service Mesh Interface (SMI) qui a été récemment annoncé par Microsoft et ses partenaires à KubeCon EU. Le SMI définit un ensemble d'API communes et portables qui vise à fournir aux développeurs une interopérabilité entre différentes technologies de service mesh, notamment Istio, Linkerd et Consul Connect.

Le sujet de l'intégration des services mesh à la structure de la plate-forme peut être divisé en deux sous-sujets.

Premièrement, des travaux sont en cours pour réduire les surcoûts de mise en réseau introduits par un data plane de service mesh. Cela comprend le data plane development kit (DPDK) , qui est une application de l'espace utilisateur qui "contourne les couches lourdes de la pile de mise en réseau du noyau Linux et parle directement au matériel réseau", et le travail de l'équipe Cilium qui utilise la fonctionnalité Berkley Packet Filter (eBPF) dans le noyau Linux pour «une mise en réseau très efficace, une application des politiques et une fonctionnalité d'équilibrage de charge». Une autre équipe met en correspondance le concept d'un service mesh avec des charges utiles L2/L3 avec le Network Service Mesh, dans le but de «réimaginer la virtualisation de la fonction réseau (network function virtualization ou NFV) d'une manière native dans le cloud».

Deuxièmement, il existe plusieurs initiatives pour intégrer plus étroitement les services mesh aux plates-formes de cloud public, comme en témoigne l'introduction d'AWS App Mesh, GCP Traffic Director et Azure Service Fabric Mesh.

L'équipe de Buoyant mène le développement de control planes efficaces centrés pour l'humain pour la technologie service mesh. Ils ont récemment lancé Dive , un «team control plane» basé sur le SaaS pour les équipes de plates-formes exploitant Kubernetes. Dive ajoute des fonctionnalités de niveau supérieur axées sur l'hommain au-dessus de service mesh Linkerd et fournit un catalogue de services, un journal d'audit des versions des applications, une topologie de service globale, etc.

FAQ

Qu'est-ce qu'un service mesh ?

Un service mesh gère tout le trafic de service à service, «est-ouest», dans un système logiciel distribué (potentiellement basé sur des microservices). Il fournit à la fois des opérations fonctionnelles axées sur l'entreprise, telles que le routage et une assistance non fonctionnelle, par exemple, l'application des politiques de sécurité, la qualité de service et la limitation de débit. Il est généralement (mais pas exclusivement) mis en œuvre à l'aide de proxys side-cars par lesquels tous les services communiquent.

En quoi un service mesh diffère-t-il d'API gateway ?

Une API gateway gère tout le trafic entrant, «nord-sud», dans un cluster et fournit une prise en charge supplémentaire pour les exigences de communication interfonctionnelles. Il agit comme le point d'entrée unique dans un système et permet à plusieurs API ou services d'agir de manière cohérente et de fournir une expérience uniforme à l'utilisateur.

Si je déploie des microservices, ai-je besoin de service mesh ?

Pas nécessairement. Un service mesh ajoute une complexité opérationnelle à la pile technologique et, par conséquent, il n'est généralement déployé que si l'organisation rencontre des problèmes pour faire évoluer la communication de service à service ou a un cas d'utilisation spécifique à résoudre.

Ai-je besoin de services mesh pour implémenter la découverte de services avec des microservices?

Non. Un service mesh fournit un moyen d'implémenter la découverte de service. D'autres solutions incluent des bibliothèques spécifiques aux langages (telles que Ribbon et Eureka , ou Finagle )

Un service mesh ajoute-t-il une surcharge/latence à ma communication de service à service ?

Oui, un service mesh ajoute au moins deux sauts de réseau supplémentaires lorsqu'un service communique avec un autre service (le premier provient du proxy qui gère la connexion sortante de la source et le second provient du proxy qui gère la connexion entrante de la destination). Cependant, ce saut réseau supplémentaire se produit généralement sur l'interface réseau localhost ou loopback , et n'ajoute qu'une petite quantité de latence (de l'ordre des millisecondes). Expérimenter et comprendre s'il s'agit d'un problème pour le cas d'utilisation cible devrait faire partie de l'analyse et de l'évaluation d'un service mesh.

Un service mesh ne devrait-il pas faire partie de Kubernetes ou de la «plate-forme cloud native » sur laquelle les applications sont déployées ?

Potentiellement. Il existe un argument pour maintenir la séparation des préoccupations au sein des composants de la plate-forme cloud native (par exemple, Kubernetes est responsable de la fourniture de l'orchestration des conteneurs et un service mesh est responsable de la communication de service à service). Cependant, des travaux sont en cours pour intégrer la fonctionnalité de type service mesh dans les offres modernes de Platform-as-a-Service (PaaS).

Comment implémenter, déployer ou désengager un service mesh ?

La meilleure approche serait d'analyser les différents produits de type service mesh (voir ci-dessus) et de suivre les directives de mise en œuvre spécifiques au service mesh choisi. En général, il est préférable de travailler avec toutes les parties prenantes et de déployer progressivement toute nouvelle technologie en production.

Puis-je créer mon propre service mesh ?

Oui, mais la question la plus pertinente est devriez-vous ? Le développement de services mest est-elle une compétence essentielle de votre organisation ? Pourriez-vous apporter de la valeur à vos clients de manière plus efficace ? Êtes-vous également déterminé à maintenir votre propre service mesh, à le corriger pour des problèmes de sécurité et à le mettre à jour constamment pour tirer parti des nouvelles technologies ? Avec la gamme d'offres de services mesh open source et commerciaux qui sont maintenant disponibles, il est probablement plus efficace d'utiliser une solution existante.

Quelle équipe détient les services mesh au sein d'une organisation de livraison de logiciels ?

Généralement, la plate-forme ou l'équipe d'exploitation est propriétaire du service mesh, ainsi que Kubernetes et l'infrastructure du pipeline de livraison continue. Cependant, les développeurs configureront les propriétés du service mesh, et les deux équipes doivent donc travailler en étroite collaboration. De nombreuses organisations suivent l'exemple de l'avant-garde du cloud, telles que Netflix, Spotify et Google, et créent des équipes de plates-formes internes qui fournissent des outils et des services à des équipes de développement axées sur les produits tout au long du cycle.

Envoy est-il un service mesh ?

Non. Envoy est un proxy cloud native qui a été initialement conçu et construit par l'équipe Lyft. Envoy est souvent utilisé comme data plane avec un service mesh. Cependant, pour être considéré comme un service mesh, Envoy doit être utilisé en conjonction avec un control plane afin que cet ensemble de technologies devienne un service mesh. Le control plane peut être aussi simple qu'un référentiel de fichiers de configuration centralisé et un collecteur de métriques, ou un système complet/complexe comme Istio.

Les mots «Istio» et «service mesh» peuvent-ils être utilisés de manière interchangeable ?

Non. Istio est un type de service mesh. En raison de la popularité d'Istio lorsque la catégorie service mesh émergeait, certaines sources confondaient Istio et service mesh. Ce problème de confusion n'est pas propre au service mesh - le même défi s'est produit avec Docker et la technologie de conteneur.

Quel service mesh dois-je utiliser ?

Il n'y a pas de réponse unique à cette question. Les ingénieurs doivent comprendre leurs exigences actuelles, ainsi que les compétences, les ressources et le temps disponibles pour leur équipe pour la mise en œuvre. Les liens de comparaison de services mesh ci-dessus fourniront un bon point de départ pour l'exploration, mais nous recommandons fortement aux organisations d'expérimenter au moins deux services mesh afin de comprendre quels produits, technologies et workflows leur conviennent le mieux.

Puis-je utiliser un service mesh en dehors de Kubernetes ?

Oui. De nombreux services mesh permettent l'installation et la gestion de proxys de data plane et du control plane associé sur diverses infrastructures. Consul d'HashiCorp en est l'exemple le plus connu, et Istio est également utilisé expérimentalement avec Cloud Foundry .

• Page d'accueil InfoQ sur les services Mesh
• InfoQ eMag - Service Mesh : passé, présent et futur
• Les services mesh : ce que tout ingénieur logiciel doit savoir sur la technologie la plus surestimée au monde
• Comparaison de service mesh
• Services mesh

Glossaire

API gateway : gère tout le trafic entrant (nord-sud) dans un cluster et fournit des informations supplémentaires. Il agit comme le point d'entrée unique dans un système et permet à plusieurs API ou services d'agir de manière cohérente et de fournir une expérience uniforme à l'utilisateur.

Consul : un service mesh écrit en Go par HashiCorp.

Control plane : prend toutes les instances individuelles du data plane (proxy) et les transforme en un système distribué qui peut être visualisé et contrôlé par un opérateur.

Data plane : proxy qui traduit, transfère et observe conditionnellement chaque paquet réseau qui circule vers et depuis un endpoint réseau d'un service.

Trafic Est-Ouest : trafic réseau au sein d'un data center, d'un réseau ou d'un cluster Kubernetes. Les diagrammes de réseau traditionnels ont été dessinés avec le trafic de service à service (inter-data center) circulant de gauche à droite (d'est en ouest) dans les diagrammes.

Envoy Proxy : proxy de service et de périphérie open source, conçu pour les applications cloud natives. Envoy est souvent utilisé comme data plane dans une implémentation de service mesh.

Trafic entrant : trafic réseau provenant de l'extérieur du data center, du réseau ou du cluster Kubernetes.

Istio : service mesh écrit en C ++ (data plane) et en Go (control plane) créé à l'origine par Google

Kubernetes : un framework d'orchestration et de planification de conteneurs hébergé par la CNCF provenant initialement de Google.

Kuma : un service mesh écrit en Go de Kong.

Linkerd : un service mesh ecrit en Rust (data plane) et en Go (control plane), dérivé d'un premier framework de communication basé sur la JVM de Twitter.

Maesh : un service mesh écrit en Go de Containous, les responsables de l'API gateway Traefik.

MOSN: un proxy écrit en Go par l'équipe Ant Financial qui implémente les API (Envoy) xDS.

Trafic Nord-Sud : trafic réseau entrant dans un data center, un réseau ou un cluster Kubernetes. Les diagrammes de réseau traditionnels ont été dessinés avec le trafic entrant dans le data center en haut de la page et descendant (du nord au sud) dans le réseau.

Proxy : système logiciel qui sert d'intermédiaire entre les endpoints de composants.

Segmentation : division d'un réseau ou d'un cluster en plusieurs sous-réseaux.

Service mesh : gère tout le trafic de service à service (est-ouest) dans un système logiciel distribué (potentiellement basé sur des microservices). Il fournit à la fois des opérations fonctionnelles, telles que le routage, et un support non fonctionnel, par exemple, l'application de politiques de sécurité, la qualité de service et la limitation de débit.

Service Mesh Interface (SMI) : interface standard en cours de développement pour les services mesh déployés sur Kubernetes.

Service mesh policy : spécification de la manière dont une collection de services/endpoints est autorisée à communiquer entre eux et avec d'autres endpoints du réseau.

Sidecar : pattern de déploiement, dans lequel un processus, un service ou un conteneur supplémentaire est déployé parallèlement à un service existant (pensez au moto de type side-car).

Single pane of glass : une interface utilisateur (UI) ou une console de gestion qui présente les données de plusieurs sources dans un affichage unifié.

Traffic shaping : modification du flux de trafic sur un réseau, par exemple, limitation de débit ou délestage.

Traffic shifting : la migration du trafic d'un endroit à un autre.

Le rôle d'un architecte logiciel moderne est en constante évolution. Abonnez-vous à la newsletter Software Architects d'InfoQ pour rester informé.

A propos de l'auteur

Daniel Bryant dirige le changement au sein des organisations et de la technologie. Son expertise technique actuelle se concentre sur les outils «DevOps», les plates-formes cloud/conteneurs et les implémentations de microservices. Daniel est, un leader au sein de la London Java Community (LJC), contribue à plusieurs projets open source, écrit pour des sites Web techniques connus tels que InfoQ, DZone et Voxxed, et présente régulièrement à des conférences internationales telles que QCon, JavaOne et Devoxx.