Vers Istio et au-delà: l'interface de maillage de service d'Azure

Le développement d'applications modernes axées sur le cloud, du moins sur Azure, est devenu presque dépendant de Kubernetes. Des technologies telles que Virtual Kubelets, AKS (Azure Kubernetes Service) et Azure Service Fabric Mesh sont essentielles pour créer des applications distribuées évolutives sur Azure, en utilisant des conteneurs pour déployer et gérer des microservices.

En regardant les outils Kubernetes d'Azure, il est clair que Microsoft fait beaucoup de travail dans et autour de la Cloud Native Computing Foundation, travaillant sur tous les aspects du framework open source. Nous ne devrions pas être surpris; Microsoft a embauché l'un des fondateurs du projet Kubernetes, puis a acquis Deis, un fournisseur important. L'équipe Deis est à l'origine de l'une des dernières contributions Azure à l'écosystème Kubernetes, la Service Mesh Interface (SMI).

Présentation des maillages de service

Il est peut-être préférable d'expliquer d'abord ce qu'est un service mesh et pourquoi il est important pour toute application basée sur Kubernetes.

Les architectures informatiques modernes sont toutes basées sur l'abstraction. Avec les services cloud, nous n'avons plus besoin de penser au matériel sous-jacent. Si nous utilisons IaaS, nous définissons des machines virtuelles pour héberger notre code. Avec PaaS, nous sommes encore plus éloignés du matériel, en utilisant les services et les API que nous avons choisis, en choisissant un niveau de performance approprié pour nos applications et nos budgets. Avec des architectures basées sur des conteneurs telles que Kubernetes, nous en sommes quelque part entre les deux: en utilisant des services comme AKS, nous pouvons définir les machines virtuelles sous-jacentes, qui hébergent ensuite nos pods de conteneurs et évoluent avec les changements de calcul et de mémoire maintenant avec KEDA (autoscaling basé sur les événements basé sur Kubernetes), à la réception des événements).

Ce n'est qu'un aspect de l'abstraction. Les microservices Kubernetes sont, au fond, sans état; ils utilisent un stockage externe et se trouvent au-dessus de réseaux physiques ou virtuels. C'est l'aspect réseau de l'exécution de Kubernetes qui est probablement le plus délicat: à mesure que les services évoluent et diminuent, vous devez modifier votre réseau pour qu'il corresponde aux modifications de votre application. Mais comment garder les services connectés quand un front-end et un back-end d'application peuvent évoluer à des taux différents?

C'est là qu'interviennent les maillages de service. Ils constituent une nouvelle couche d'abstraction, qui éloigne votre code du réseau sous-jacent en tirant parti des capacités d'un réseau moderne défini par logiciel. En agissant comme un ensemble de proxys réseau qui sont déployés avec votre code, un maillage de services gère la communication de service à service sans que votre code n'ait besoin de connaître le réseau sous-jacent. Vous pouvez considérer un maillage de services comme un plan de contrôle automatisé pour la mise en réseau de votre application, gérant le plan de contrôle sous-jacent à mesure que Kubernetes fait évoluer votre code de haut en bas.

Un réseau défini par logiciel pour les microservices

Peut-être mieux considéré comme un moyen d'implémenter un équilibrage de charge intelligent, évolutif et sensible à la latence parallèlement à la découverte de services, un maillage de services est essentiellement un routeur distribué avec des règles de routage dynamiques qui sont gérées dans le cadre d'un déploiement Kubernetes. Vous pouvez définir des règles supplémentaires; par exemple, séparer les systèmes de production et de test, ou gérer le déploiement d'une nouvelle version et le changement entre les versions de conteneur. Chaque pod d'une application possède une instance de maillage de service s'exécutant en tant que side-car, avec la découverte de services et d'autres éléments avec état s'exécutant en dehors de vos services.

Avec un maillage de services, vous insérez l'intelligence dans une nouvelle couche réseau, vous n'avez donc pas à la mettre dans vos microservices. Besoin de crypter une connexion? C'est un travail pour votre maillage de services. Besoin d'autoriser des clients? Une autre tâche pour le maillage de service.

Trop de mailles

Combiner un déploiement Kubernetes avec un service mesh a beaucoup de sens. Cependant, il y a un autre gros problème: lequel utilisez-vous? Envoyé? Istio? Linkerd? Aspen Mesh? Si vous en avez choisi un, qu'est-ce qui empêche une équipe de développement d'une autre partie de votre entreprise d'en choisir un autre? Alors que se passe-t-il si votre entreprise décide de standardiser sur une plateforme spécifique?

C'est le problème que Microsoft se propose de résoudre avec l'interface Service Mesh. Au lieu que chaque maillage de services ait son propre ensemble d'API, le SMI est un moyen d'implémenter des API communes qui fonctionnent sur différents maillages de services, en gérant ce nouveau réseau intelligent. Au lieu de verrouiller votre code dans un maillage de service spécifique et ses API, vous pouvez écrire du code qui répond aux cas d'utilisation les plus courants via une API commune. Si vous avez besoin d'échanger un maillage de services - si vous changez de fournisseur ou si vous en trouvez un qui fonctionne mieux - il n'est pas nécessaire de changer votre code, tant que le maillage de services implémente le SMI. Tout ce que vous avez à faire est de changer vos sidecars de maillage de service et de redéployer votre code.

SMI: API de maillage de service commun

En collaboration avec des entreprises de l'écosystème Kubernetes telles que Hashicorp et Buoyant, Microsoft a défini les principales fonctionnalités de SMI qui prennent en charge les demandes courantes de ses clients. Dans la version initiale, il s'est concentré sur trois domaines: la politique de trafic, la télémétrie du trafic et la gestion du trafic. Ces trois zones sont contrôlées par la plupart des maillages de service, et l'intention est d'en faire une spécification facile à implémenter sans changer l'application sous-jacente.

En faisant de SMI un ensemble d'API standard, rien n'empêche les fournisseurs de maillage de services de continuer à proposer leurs propres API ou des fonctionnalités supplémentaires en dehors de celles spécifiées. Sinon, ils n'ont pas besoin de faire de changements; des tiers peuvent créer des couches de traduction situées entre les API SMI et les API de service propriétaires. Vous n'aurez pas non plus besoin d'une nouvelle version de Kubernetes, car les API SMI sont implémentées en tant que serveurs d'API d'extension et définitions de ressources personnalisées. Vous pouvez continuer et les installer dans n'importe quel cluster, en utilisant les outils de gestion existants. Cela devrait permettre à Azure et aux autres services Kubernetes hébergés dans le cloud de les intégrer facilement dans leurs services Kubernetes gérés existants.

Que vous souhaitiez utiliser Linkerd ou Aspen Mesh ou NSX Service Mesh de VMware, avec SMI, vous pourrez choisir celui que vous préférez, améliorant la portabilité du code et évitant le verrouillage de services cloud spécifiques. Ensuite, il y a la possibilité de changer de maillage de service sans affecter votre code. Si un nouveau maillage de services offre de meilleures performances, tout ce que vous avez à faire est de modifier votre pipeline de construction pour utiliser le nouveau maillage, puis de déployer une application mise à jour.

Il est intéressant de voir Microsoft prendre les devants sur un projet comme celui-ci, en travaillant avec un large éventail de la communauté Kubernetes. En adoptant une approche qui n'est explicitement pas axée sur la création d'un maillage de services, Azure peut proposer différents maillages de services dans le cadre de la configuration d'AKS, vous permettant de choisir l'outil de votre choix sans avoir à modifier le code.