Qu'est-ce que Service Mesh ?

Bonjour à nouveau!.. À l'approche du lancement du cours « Architecte Logiciel » nous avons préparé une autre traduction utile.

Le Service Mesh est un niveau d'infrastructure configurable à faible latence, nécessaire pour gérer un grand volume de communications inter-processus réseau entre les interfaces de programmation d'application (API). Le Service Mesh assure une communication rapide, fiable et sécurisée entre les services conteneurisés et souvent éphémères de l'infrastructure des applications. Le Service Mesh fournit des fonctionnalités telles que la découverte de services, l'équilibrage de charge, le cryptage, la transparence, le traçage, l'authentification et l'autorisation, ainsi que le support d'un modèle de coupure automatique (disjoncteur).
Le Service Mesh est généralement implémenté en fournissant à chaque instance de service une instance de proxy, appelée Sidecar. Le Sidecar gère les communications entre les services, effectue la surveillance et résout les problèmes de sécurité, c'est-à-dire tout ce qui peut être abstrait des services individuels. Ainsi, les développeurs peuvent écrire, maintenir et gérer le code de l'application dans les services, tandis que les administrateurs système peuvent travailler avec le Service Mesh et exécuter l'application.

Istio de Google, IBM et Lyft est actuellement l'architecture de Service Mesh la plus connue. Kubernetes, qui a été développé à l'origine par Google, est maintenant le seul framework d'orchestration de conteneurs soutenu par Istio. Les fournisseurs tentent de créer des versions commerciales supportées d'Istio. Il est intéressant de voir ce qu'ils pourront apporter de nouveau au projet open source.

Cependant, Istio n'est pas la seule option, d'autres implémentations de Service Mesh étant en cours de développement. Le modèle sidecar proxy est la réalisation la plus populaire, comme en témoignent les projets Buoyant, HashiCorp, Solo.io et d'autres. Il existe également des architectures alternatives : l'outillage de Netflix est l'une des approches où la fonctionnalité du Service Mesh est réalisée grâce aux bibliothèques Ribbon, Hysterix, Eureka, Archaius, ainsi qu'à des plateformes telles qu'Azure Service Fabric.

Le Service Mesh a également sa propre terminologie pour les composants de services et les fonctions :

• Framework d'orchestration de conteneurs. Au fur et à mesure que de plus en plus de conteneurs sont ajoutés à l'infrastructure de l'application, il devient nécessaire de disposer d'un outil séparé pour surveiller et gérer les conteneurs – un cadre d'orchestration de conteneurs. Kubernetes a fortement occupé cette niche, au point que même ses principaux concurrents Docker Swarm et Mesosphere DC\/OS proposent une intégration avec Kubernetes comme alternative.
• Services et instances (pods Kubernetes). Une instance est une seule copie d'un microservice en cours d'exécution. Parfois, une instance correspond à un conteneur. Dans Kubernetes, une instance se compose d'un petit groupe de conteneurs indépendants, appelé pod. Les clients ne s'adressent que rarement directement à une instance ou un pod, ils s'adressent plutôt à un service, qui représente un ensemble d'instances ou de pods (répliques) identiques, évolutifs et tolérants aux pannes.
• Proxy Sidecar. Le Proxy Sidecar fonctionne avec une seule instance ou un pod. L'idée du Proxy Sidecar est de diriger ou de proxy le trafic entrant d'un conteneur avec lequel il travaille, ainsi que le trafic sortant. Le Sidecar interagit avec d'autres Proxies Sidecar et est géré par le cadre d'orchestration. De nombreuses implémentations de Service Mesh utilisent le Proxy Sidecar pour intercepter et gérer tout le trafic entrant et sortant d'une instance ou d'un pod.
• Découverte de services. Lorsque qu'une instance doit interagir avec un autre service, elle doit trouver (découvrir) une instance fonctionnelle et accessible de ce service. En général, l'instance effectue une recherche DNS. Le cadre d'orchestration de conteneurs maintient une liste d'instances prêtes à recevoir des requêtes et fournit une interface pour les requêtes DNS.
• Équilibrage de charge. La plupart des cadres d'orchestration de conteneurs assurent une répartition de la charge au niveau 4 (transport). Le Service Mesh met en œuvre une répartition de la charge plus complexe au niveau 7 (application), riche en algorithmes et plus efficace en ce qui concerne la gestion du trafic. Les paramètres de répartition de la charge peuvent être modifiés via l'API, permettant ainsi d'orchestrer des déploiements bleu-vert ou canari.
• Chiffrement. Le Service Mesh peut chiffrer et déchiffrer les requêtes et les réponses, allégeant ce fardeau pour les services. Le Service Mesh peut également améliorer les performances en priorisant ou en réutilisant des connexions persistantes existantes, ce qui réduit la nécessité de calculs coûteux pour créer de nouvelles connexions. La mise en œuvre la plus courante du chiffrement du trafic est mutual TLS (mTLS), où l'infrastructure à clé publique (PKI) génère et distribue des certificats et des clés pour les utiliser dans le Sidecar Proxy.
• L'authentification et l'autorisation. Le Service Mesh peut autoriser et authentifier les requêtes faites depuis l'extérieur ou à l'intérieur de l'application, en n'envoyant aux instances que des requêtes validées.
• Support du modèle de coupure automatique. Le Service Mesh prend en charge le modèle de coupure automatique, qui isole les instances non saines avant de les ramener progressivement dans le groupe des instances saines si nécessaire.

La partie de l'application Service Mesh qui gère le trafic réseau entre les instances s'appelle le Data Plane. La création et le déploiement de la configuration qui gère le comportement le Data Plane, se fait grâce à un Control Plane. Control Plane qui inclut généralement ou est conçu pour se connecter à l'API, à la CLI ou à la GUI pour gérer l'application.

Le Control Plane dans le Service Mesh distribue la configuration entre le Sidecar Proxy et le Data Plane.

Souvent, l'architecture Service Mesh est utilisée pour résoudre des tâches opérationnelles complexes à l'aide de conteneurs et de microservices. Les pionniers dans ce domaine microservices sont des entreprises telles que Lyft, Netflix et Twitter, qui fournissent des services fiables à des millions d'utilisateurs dans le monde entier. (Ici, vous pouvez découvrir une description détaillée de certaines des tâches architecturales auxquelles Netflix a été confronté). Pour des tâches applicatives moins exigeantes, il sera probablement suffisant d'utiliser des architectures plus simples.

L'architecture Service Mesh ne sera probablement jamais la réponse à toutes les questions liées à l'opération des applications et à leur livraison. Les architectes et les développeurs disposent d'un énorme arsenal d'outils, et un seul d'entre eux est un marteau, qui parmi de nombreuses tâches, doit en résoudre une seule - enfoncer des clous. Architecture de référence des microservices de NGINX, par exemple, comprend plusieurs modèles différents qui offrent un éventail continu d'approches pour résoudre des problèmes à l'aide de microservices.

Les éléments qui se combinent dans l'architecture Service Mesh, tels que NGINX, les conteneurs, Kubernetes et les microservices en tant qu'approche architecturale, peuvent être tout aussi efficacement utilisés dans des implémentations sans Service Mesh. Par exemple, Istio a été conçu comme une architecture Service Mesh complète, mais sa modularité signifie que les développeurs peuvent choisir et appliquer uniquement les composants technologiques dont ils ont besoin. En gardant cela à l'esprit, il est essentiel de former une compréhension claire du concept de Service Mesh, même si vous n'êtes pas sûr de pouvoir un jour le réaliser pleinement dans une application.

Monolithes modulaires et DDD

Source : habr.com