Cette année les Services Mesh sont de toutes les conférences : istio, linkerd, kubeflix, zuul même ?.... Les outils sont nombreux à surfer sur cette vague. De quoi s’agit-il exactement ?

En confrontant nos différentes visions nous avons le sentiment à chaque nouvel outil d’un déjà-vu ou d’une superposition avec l’un des précédents. Comme si on nous disait un jour : dans un monde de microservices nous avons besoin de sécurité, de traçabilité, et de routage intelligent. Nous avons une solution de reverse-proxy HTTP pour répondre à ces enjeux - avec la  photo du haut en guise d’illustration. Puis quelques jours plus tard : dans un monde de conteneurs où l’orchestration est de plus en plus dynamique nous avons besoin de routage intelligent, de traçabilité et de sécurité à l’intérieur de l’orchestrateur. Et pour cela nous avons la solution qui s’intègre à notre orchestrateur de conteneurs - en nous présentant la photo du bas. Essayons d’y voir plus clair à travers cette série d’articles. Le premier tentera de positionner les enjeux qui conduisent à envisager le Service Mesh dans l’écosystème des microservices. Le second proposera une radiographie des fonctionnalités que proposent les outils se revendiquant d’un Service Mesh et des fonctionnalités connexes de l’écosystème microservices et conteneurs. Puis, nous aborderons différentes solutions qui implémentent ces fonctionnalités, par exemple une implémentation applicative en Java.

Microservices, conteneurs et plateformes

L’enjeu est aujourd’hui de concevoir des architectures modulaires et évolutives pour répondre aux enjeux du monde digital. Le principe de single responsibility s’est aujourd’hui largement imposé dans l’état de l’art pour répondre à ces enjeux. Il consiste à décomposer une application en un ensemble de composants, de services, qui répondent chacun à un besoin précis.

Les microservices sont l’implémentation la plus courante de ce principe.  Si on reprend la définition de Sam Newman dans “Building Microservices”, « les microservices sont de petits services autonomes qui travaillent conjointement ». En cible, le développeur se concentre uniquement, avec le maximum de liberté (choix de la technologie, faible couplage aux autres services, etc.) et de responsabilité possible (déploiement en continu, you build it you run it), sur l’implémentation d’une fonctionnalité métier élémentaire.

De façon indissociable, les principes DevOps se sont imposés pour fournir aux développeurs un socle - une plateforme nous y reviendrons - qui offre liberté et responsabilité jusqu’à la production. L’implémentation de ce principe repose notamment sur l’infrastructure as code et sur des solutions cloud caractérisées par l’instanciation et le paiement à la demande de différentes ressources informatiques. Les conteneurs et les orchestrateurs de conteneurs sont l’une des solutions qui est la plus mise en avant aujourd’hui pour mettre en oeuvre ces principes. Ils packagent les applicatifs  - et donc les services - sous forme d’images composables et immuables ce qui les rend portables et relativement indépendants de la plateforme.

En tant que développeur, je vais donc me concentrer sur l’écriture des fonctionnalités métier. Celles-ci seront exposées sous la forme d’une API, seront ensuite packagées dans des conteneurs puis déployées dans le cloud. Mais est-ce que cela suffit à faire une application ? Non, car de nombreuses autres fonctionnalités sont requises pour transformer un ensemble de composants logiciels en une application. Comment les coordonner pour qu’ils interagissent entre eux ? Comment assurer la sécurité ? Comment rendre l’API utilisable par les applications front-end (les écrans JavaScript qui s’exécutent dans le navigateur) ? Comment monitorer leur fonctionnement ?

Depuis longtemps déjà ces problématiques transverses sont le ressort de plateformes. En anglais une plateforme désigne un quai, quelque chose de plat, d’homogène, afin de permettre la standardisation, de favoriser une activité industrielle. Une plateforme portuaire va ainsi être construite autour des standards des conteneurs et du connaissement maritime (Bill of lading). Ainsi toute la complexité du transport est transparente pour l’expéditeur et le destinataire.

De façon figurative dans le monde des microservices et des conteneurs, la plateforme sert de fondation pour favoriser la réutilisation et pour libérer le développeur de l’implémentation de fonctionnalités transverses non différenciantes pour le métier implémenté. De quelles plateformes parle-t-on ? Dans le monde du cloud, le terme Plateforme As A Service est apparu très tôt. Ces plateformes - dont la technologie docker est indirectement issue - ont pour objectif de gérer de façon transparente l’infrastructure et le déploiement d’une application.  Dans le monde applicatif, les serveurs d’applications ont été par le passé la plateforme offrant composants logiciels, sécurisation et  exposition de ces composants. Plus récemment les outils d’API management ont apporté des solutions réutilisables pour gérer le cycle de vie des API et leur sécurisation en self-service.

Aujourd’hui, le caractère de plus en plus évolutif des architectures microservices rend caduque la vision centralisée de ces différentes approches. De nouvelles plateformes émergent donc pour proposer un socle qui épouse le principe décentralisé des microservices. Là où les PaaS se focalisent sur le déploiement, l’API Management sur l’API, le Service Mesh se focalise sur la communication entre les microservices.

Notre définition sera donc la suivante :

Différentes implémentations existent comme l’indique Thoughworks dans son radar. Mais l’implémentation des solutions les plus connues ont tendance à masquer d’autres solutions possibles.

Alors s’agit-il simplement d’une amélioration d’un outil existant à l’image de cette brouette à 2 roues ? Ou s’agit-il d’une approche réellement différenciante comme le passage de la hache à la tronçonneuse qui nécessite d’utiliser le nouvel outil de façon complètement différente ? Les prochains articles essaieront de vous donner les clés pour comparer le Service Mesh par rapport à votre existant et à vos besoins.

Sources des illustrations : https://pixabay.com/