Microservices & Service mesh : le retour des frameworks d'entreprise - Compte rendu du talk de Désiré Atanga & Borémi Toch à la Duck Conf 2019
Anatomie d'un framework d'entreprise
Cela peut paraître curieux mais on peut voir les technologies qui standardisent les déploiements de microservices comme des frameworks d'entreprises.
Les frameworks d'entreprise étaient très à la mode il y a environ 10 ans, ils rappelleront sans doute des souvenirs à certains de nos lecteurs. Une définition pourrait être : "un ensemble cohérent d'éléments permettant de bâtir des logiciels d'entreprise avec des objectifs essentiels : plus vite, mieux et moins cher dans la durée".
On pense évidemment à des solutions techniques telles que serveurs d'applications, ETL ou ESB. Mais pas que : CMMI et TOGAF sont aussi valides au regard de cette définition.
On pense également aux douleurs qui ont accompagné l'utilisation de tels frameworks il y a quelques années :
- évolutions plus lentes que n'importe quelle librairie disponible sur internet,
- équipes en charge de ces frameworks confrontées à des difficultés pour faire entrer de nouvelles idées (fonctionnement en vase clos)
- organisation en mode "centre de services" (tickets etc.)
- couplage des cycles de vie entre le framework et les applications qui l'utilisent
- performance et garanties de haute disponibilité souvent médiocres
Les frameworks de service mesh répondent aux besoins des Géants du Web de standardiser, à leur échelle, des fonctionnalités telles que : service discovery, circuit breaker, routing ou throttling.
Les deux familles de service meshes
A l'origine : des frameworks applicatifs
Une première manière de réaliser les fonctionnalités citées ci-dessus à l'échelle de dizaines/centaines/milliers d'applications est, comme on l'a vu, de packager une librairie commune avec toutes les applications.
La stack Netflix OSS en est l'exemple canonique :
Ces librairies vont permettre aux applications qui les embarquent de modifier leur comportement dynamiquement en fonction d’informations partagées : statut d’un service, modification automatique d’un DNS après un déploiement, augmentation du nombre d’instances d’un service suite à un pic de charge etc.
Cette approche est séduisante mais en pratique, si vous n’êtes pas Netflix, et le nombre de microservices déployés croissant, il devient de plus en plus compliqué de tracer le parcours d’un client à travers les services, de debugger et d’avoir une représentation mentale (même incomplète) de ce qui existe et en quelle version, ralentissant le développement de nouvelles fonctionnalités.
La V2 : conteneurisation et applications cloud native
L’autre manière de faire consiste à déployer ses applications sur des plateformes qui proposent toutes les fonctionnalités d’un service mesh nativement. On pense évidemment ici à Kubernetes.
Les implémentations de service mesh pour cette plateforme ne sont pas nombreuses, on peut citer notamment Istio, Conduit et Linkerd. Nous allons expliquer rapidement leur fonctionnement en nous basant sur Istio.
Sur une plateforme k8s (kubernetes) où Istio est installé, toutes vos applications sont packagées sous forme de conteneurs et voyagent avec un autre conteneur appelé s_idecar_. Tous les flux réseaux entrants et sortant de votre application vont passer par lui :
Les sidecars ne sont pour autant pas des composants intelligents : ils constituent ce qu’on appelle le Data Plane, par opposition au Control Plane (termes issus des pratiques du SDN : Software Defined Networking). Le Control Plane contient la vue à un instant T de la configuration de votre service mesh, il donne des ordres au Data Plane qui va se charger de la mettre en oeuvre localement :
Ainsi outillé, les déploiement ont l’air très simples : un fichier yaml de 20 à 100 lignes et un client kubectl suffisent :
Mais c’est une fausse impression ! Kubernetes est un système complexe à prendre en main et à manager en production, qui nécessite des profils aux compétences plus larges qu’un sysadmin.
Retrouvez la présentation complète sur Slideshare
Conclusion
Les microservices font petit à petit leur entrée dans les grandes entreprises. Par nature, ils sont moins faciles à déployer que des applications plus monolithiques.
Adhérer à un service mesh standard du marché permet de ne pas payer le surcoût d’une solution maison :
- vous n’avez pas besoin d’une équipe spécialisée qui va la développer et la maintenir dans la durée
- attention ! Suivre les patterns cloud native en est la condition sine-qua-non
Déployer un framework de service mesh peut se faire de manière progressive, cela vous permet de vous donner le temps de tester, observer et maîtriser sa potentielle complexité et son coût dans la durée.
Enfin, si vous maîtrisez déjà une stack complète telle que Kubernetes, le ticket d’entrée est est assez minime et nous vous encourageons à expérimenter !