Voyage au coeur d'un "Service Mesh" - 1ère partie

Auteurs :

Yasser Rougui

Architecte expert

Contactez

Avec la collaboration de Sami Hossini et Mario Gabriel Guazzelli

7 minutes

Vers une architecture de système d'information inexorablement hybride

La transition numérique des entreprises a déclenché une revue de modèles d’architecture des systèmes d’information. Les nouveaux écosystèmes et les enjeux concurrentiels actuels mettent l’utilisateur au centre des questionnements et font émerger de nouveaux paradigmes tels que l’Edge Computing.

Ces paradigmes nécessitent généralement de rapprocher les services de leurs utilisateurs, en se reposant notamment sur des architectures logicielles hautement distribuées, et exploitant les capacités des infrastructures des clouds publics. Dans ce contexte, de plus en plus d’entreprises refusent de se limiter à un fournisseur cloud unique, et font le pari d’utiliser des environnements ‘multi-cloud/hybrid cloud’.

C’est ainsi que s’est manifesté le besoin de contrôler le niveau de service global de ces applications distribuées entre plusieurs ‘cloud providers’, tant pour les utilisateurs internes que pour les clients externes. Ce qui implique de disposer d’un moyen simple de gérer et de monitorer un nombre conséquent de services déployés sur différentes infrastructures.

Or le manque d’interopérabilité des offres cloud public, entre elles et avec les offres cloud privé, met la lumière sur le besoin d’une plateforme transverse de gestion des services. Dans ce sens, l’API Management d’entreprise semblait pouvoir être une alternative prometteuse, néanmoins il s’est avéré que ces plateformes, quoique irréprochables pour la gestion de bout en bout des cycles de vie de ces services et de leurs sollicitations de la part d’applications frontend, présentaient des limites dès lors qu’il était question de la gestion et la supervision de (micro)services backend hautement scalables et communicantes.

API Management, mais pas seulement

Les plateformes d'API Management deviennent progressivement un élément incontournable du Système d'Information d'entreprise. Ces plateformes permettent de centraliser la gestion des différentes APIs consommées par des usages internes et écosystème, et se focalisent sur les besoins des consommateurs et les usages "Front Office", avec des échanges majoritairement Nord-Sud (inside-out). Elles permettent aussi, à travers les portails développeurs, de valoriser les APIs en tant que Produits à valeur ajoutée métier (VPI, Value Proposition Interface). L'objectif d'une plateforme d'API Management d'entreprise est globalement de fournir un cadre industriel pour fabriquer et gérer les APIs, leur cycle de vie et les politiques de consommation associés (quota d'appels, throttling...).

Cependant, l’API Management d’entreprise n’adresse pas correctement l’accostage des APIs sur les ressources sous-jacentes, et particulièrement l’APIsation des applications ‘backend’.

A défaut de refactorer les applications monolithiques en un ensemble d'APIs, une approche courante pour APIser les applications est d’utiliser une solution d’ESB d’entreprise pour répondre de façon transverse à l’APIsation des applications locales, avec des limites certaines, comme le manque d’agilité due à une gouvernance centralisée, la difficulté à gérer la scalabilité, et enfin les performances des communications entre services. Une autre approche consiste à utiliser une façade applicative pour répondre de façon locale à l’APIsation d’une application, avec la difficulté à gérer la scalabilité qui peut y être associée.

Du services au micro-services pour toujours plus de modularité

Pour répondre aux enjeux de la transformation digitale, les entreprises ont tendance à faire évoluer l’architecture de leur SI vers des patterns modulaires de type microservices.

Ce modèle d’urbanisation applicative se base sur le principe de découpage d’une application en un ensemble de services unitaires, autonomes et qui travaillent conjointement (microservices). Cela permet de satisfaire des besoins grandissants d'autonomie en choix de technologies et de langage de programmation, d’adopter des modèles d'organisations agiles reposant sur des équipes indépendantes et des processus de développement continus et itératifs, et d’accompagner la transition vers des infrastructures de type ‘cloud’ public, voire ‘multi-clouds’.

Néanmoins, à mesure que l’on découpe les applications en microservices, il devient de plus en plus complexe de gérer les communications entre eux, de les maintenir, de les sécuriser et de les monitorer. Un grand nombre de services à manager, à titre individuel ou de manière distribuée, et la difficulté d'assurer leur fiabilité, observabilité et sécurité ne peuvent être relevés avec les méthodes et paradigmes actuels, avec une plateforme d'API Management d'entreprise par exemple.

Plus particulièrement, et dans le cadre des efforts des entreprises pour « platformiser » leurs SI, il devient de plus en plus fréquent que les programmes nécessitent de déployer ces microservices sur des environnement Cloud de ‘providers’ différents (afin d’exploiter les APIs d’intelligence artificielle ou autres services managés de chacun des ‘providers’ par exemple). La gestion de ce parc applicatif, de plus en plus hétérogène, nécessite de nouveaux modèles de gouvernance basés sur les outils et solutions logiciels adaptés, et notamment les ‘Service Mesh’.

Service mesh : Kezako ?

Dans une architecture complexe et distribuée de microservices, et lors de chaque appel invoquant un service défini, il faut assurer un routage rapide vers les microservices et versions adéquats ; monitorer et gérer toutes les exécutions sous-jacentes à l’appel avec du ‘catching’ d’erreurs et du ‘retry’ ; assurer la sécurité des ‘Endpoints’ ; gérer les logs ; vérifier fréquemment l’état de santé de l’ensemble des microservices…

D’où la nécessité d’une plateforme de médiation et d’intégration capable de gérer toutes les spécificités des communications entre applications « micro-servicées », dites communications Est-Ouest. Ces plateformes sont connues sous le nom de ‘Service Mesh’.

Un Service Mesh est une plateforme qui permet d’assurer le routage rapide, l’observabilité, la fiabilité et la sécurité des communications entre applications « micro-servicées ». Il capitalise sur les évolutions récentes des architectures API Management (Microgateway, Hybrid Gateway…) pour étendre leurs capacités aux communications Est-Ouest, tant au niveau local d’une application qu’au niveau global entre applications.

Le Service Mesh peut aussi être vu comme un réseau décentralisé et autoorganisé d’instances de microservices, qui masque la complexité des échanges. Il les décharge de l’implémentation des fonctionnalités réseaux requises pour les communications inter-microservices, en prenant en charge les capacités de ‘Load Balancing’, ‘Service Discovery’, ‘Security’, ‘Healthcheck, Monitoring’, ‘Scalability’, ‘Tracing’, etc.

Pour cela, il se base sur le principe d’attacher à chaque instance un petit agent, appelé ‘sidecar proxy’. Ce dernier est en charge d’assurer principalement la médiation de trafic, l’enregistrement de l’instance au niveau du référentiel de découverte de services (Service Discovery), la collecte de métriques et la maintenance. L’ensemble des instances et leurs ‘sidecars’ constituent ce que l’on appelle un ‘Data Plane’.

Bien que conceptuellement décentralisés, la plupart des ‘services Mesh’ comportent un ou plusieurs composants centraux permettant d’appliquer des règles au ‘Data Plane’, de collecter des données sur l’ensemble du réseau ou encore de fournir des interfaces d'administration & configuration. Ils sont regroupés dans ce que l’on appelle un ‘Control Plane’.

Le ‘Control Plane’ ainsi que les ‘Sidecar proxies’ se présentent sous forme d’un ensemble de microservices, déployés sur la même plateforme d’orchestration et d’exécution de containers (Kubernetes par exemple) que les instances de microservices qu’ils gèrent.

Une offre émergente, mais déjà bien étoffée

Le marché des ‘Service Mesh’ n’est pas encore à maturité, il connait pourtant l’émergence de quelques premières solutions pionnières qui arrivent petit à petit dans les environnements de production des entreprises. Depuis les premiers projets open source développés par les instigateurs des architectures microservices complexes (Netflix, Google, Twitter, etc), les solutions ‘Service Mesh’ ont beaucoup évolué, et se rapprochent aujourd’hui du niveau d’industrialisation nécessaire à une adoption plus large dans les entreprises et les organisations. La solution la plus en vue aujourd’hui est Istio, développée conjointement par Google, IBM, et Lyft. C’est le plus abouti et le plus utilisé des ‘services mesh’ actuellement, et les retours des premières organisations à l’adopter sont concluants.

Des offres de ‘Service Mesh’ managé commencent aussi à apparaître chez les ‘cloud providers’ majeurs, avec « App Mesh » chez AWS et « Google Cloud Service Mesh », une version managée de Istio, chez GCP pour n’en citer qu’eux.

En même temps, certains éditeurs vont encore plus loin, et proposent de laisser aux équipes de développement d’application la possibilité de choisir leur propre solution de service mesh, et de mettre en place une solution transverse de fédération de ‘services mesh’, offrant à son tour des capacités de gestion et de monitoring, ainsi que la mise en place de politiques d’intermédiation globales, propagées ensuite à l’ensemble des ‘services mesh’. C’est le cas notamment de SuperGloo, édité par Solo.io.

Service mesh + API management : Duo Gagnant ?

Il clair que l’API Management et le ‘Service Mesh’ jouent des rôles indépendants et contribuent séparément aux processus d’échanges entre consommateurs et producteurs de services, ou plus concrètement de microservices.

L’API Management excelle dans les fonctions de gestion de cycle de vie et la sécurité des APIs et (micro)services à la frontière entre le SI et son écosystème. Un ‘Service Mesh’ quant à lui, se focalise davantage sur la gestion et supervision des communications inter-(micro)services au sein du SI.

Toutefois, malgré l'importance de la distinction entre les domaines de responsabilité de chacune de ces deux technologies, cela ne les empêche pas de collaborer afin d’apporter de nouvelles solutions, encore plus élégantes, aux problématiques et enjeux qu’impose la transformation digitale aux SI des entreprises.

Dans la seconde partie de cet article, nous aborderons plus en détail l’articulation entre le ‘Service Mesh’ et le reste du SI et nous présenterons plus en profondeur les principaux composants d’un ‘Service Mesh’ (‘Data Plane’ et ‘Control Plane’) ainsi que leurs rôles et fonctionnalités.