Gestion d’applications distribuées micro-services

Contexte

Les micro-services ou architectures orientées micro-services sont un style d’architecture permettant de définir des services modulables et indépendants, dans lequel chaque service exécute un processus unique.

Ces services sont généralement packagés en conteneurs et déployés dans un environnement CaaS (Containers en tant que Service /Containers as a Service). Les CaaS sont une catégorie de services Cloud permettant aux développeurs de logiciels de télécharger, d’organiser, d’exécuter, de gérer, de mettre à l’échelle et d’arrêter des conteneurs en utilisant l’interface web ou l’API d’un fournisseur. Comme c’est généralement le cas pour les services Cloud, les utilisateurs de CaaS payent uniquement pour les ressources qu’ils utilisent.

Les micro-services se définissent comme étant facilement testables et maintenables, peu couplés et axés sur une fonctionnalité. Ce type d’architecture a de nombreux avantages : mise à l’échelle (scalabitilé) granulaire, ré-utilisabilité des composants, déploiement indépendant, faible couplage, interopérabilité du sytème (intégration facilitée de nouvelles technologies), facilite la création de tests unitaires,… Si les micro-services offrent une grande flexibilité, ils génèrent davantage de complexité : comment intégrer et combiner efficacement les services, comment assurer la gestion du trafic/connectivité entre les différents services, comment équilibrer les charges, quid de la confidentialité des communications/échanges, comment s’assurer que l’application fonctionne correctement (tests d’intégration fonctionnels, gestion des pannes) ? comment s’assurer de la résilience du système, comment centraliser les logs du système ?

Le maillage de services ou service mesh permet de répondre à ces problématiques. Les services mesh tels que Istio, permettent de gérer, via un ensemble de règles et de définitions, les communications d’une application micro-service : chaque micro-service d’une application est associé à un proxy (sidecar) qui sera capable d’appliquer des règles préalablement définies : sécurisation des échanges, règles de routage, stratégie de résilience (circuit breaker), intégration avec un API-Gateway… Ces proxy sont orchestrés par un "control pane".

Travail à réaliser

Cette thématique est liée à plusieurs stages qui permettent, chacun à leur manière, d’approfondir le gestion des microservices via les services mesh.

Proposition 1 : Etude de la performance des services mesh :

Challenges & Opportunités : il existe de nombreux services mesh mais tous ne sont pas équivalents en termes de fonctionnalités ou de performance. L’idée du stage est de créer une procédure/outil permettant d’aider l’utilisateur à choisir le service mesh le plus adapté à ses besoins.

Aperçu des tâches pour ce stage :

1. Analyser les besoins des applications en termes de fonctionnalités et dresser une liste de services mesh compatibles. Cette analyse doit se faire suivant un état de l’art (déjà commencé). Le maître de stage apportera de l’aide à l’étudiant pour cet état de l’art.
2. Analyser les performances des services mesh sélectionnés sur base d’un jeu de test. Les spécifications liées à la performance des services mesh sont détaillées sur le site suivant : https://smp-spec.io. Cette analyse des performances peut actualiser l’état de l’art des Service Mesh (cf point 1).
3. Facultatif : les services mesh peuvent gagner en performance avec des technologies “proxyless”. L’idée ici est de tester le “proxyless” sur des implémentations de services mesh compatibles.

Le Cetic proposera un/des cas d’utilisation basés sur des projets de recherche (SamobiGrow, BAM, Flaracc) ou des assets.

Proposition 2 : Etude de l’interconnexion entre services mesh :

Challenges & Opportunities : à l’heure actuelle, il est rare (et même dangereux) qu’une application soit hébergée sur le même datacenter (e.g. incendie, des problèmes politiques, mais aussi pour des soucis de résilience, haute disponibilité, scalabilité). De ce fait, posséder plusieurs sites est intéressant. Lorsqu’une application est déployée sur plusieurs sites, il se peut que toutes les fonctionnalités ne soient pas disponibles sur tous les sites. Il est possible d’utiliser des services mesh pour connecter différents sites. Les services mesh utilisés pourraient également être différents. Il est donc nécessaire de pouvoir permettre de gérer différents services mesh via un meta-service mesh. Ce méta-service mesh est aussi appelé un multi-mesh. Il permet de coordonner différents services mesh en communiquant via des interfaces. La spécification SMI (https://smi-spec.io) permet de définir ces interfaces. L’idée du stage est de déployer une application microservice sur plusieurs sites et de relier ces différents sites avec un multi-mesh.

Aperçu des tâches pour ce stage :

1. Analyser les services mesh compatibles avec les spécifications SMI. Cette analyse doit se faire suivant un état de l’art (déjà commencé). Le maître de stage apportera de l’aide à l’étudiant pour cet état de l’art.
2. Sur base d’un use-case, tester un multi-mesh à partir de service mesh de même type et de types différents.
3. Facultatif : intégration d’un système EDGE dans un multi-mesh

Le Cetic proposera un/des cas d’utilisation basés sur des projets de recherche (SamobiGrow, BAM, Flaracc) ou des assets.

Proposition 3 : Le “progressive delivery” adapté aux services mesh

Challenges et Opportunités : la mise en place d’un système d’intégration continu couplé à un déploiement continu peut être risqué. Avec ces pratiques, il est aisé de pousser un bug en production. Le progressive delivery permet de jouer sur la manière avec laquelle une modification (e.g. une nouvelle version d’un microservice) sera déployée. Le progressive delivery permet de définir une période transitoire où cohabitent 2 versions d’un composant. Le routage vers l’ancienne ou la nouvelle version peut être configuré. Ainsi une migration vers une nouvelle version de l’application peut être faite de manière progressive et la probabilité qu’une panne générale affecte tous les utilisateurs est réduite. Le progressive delivery est donc une technique de mise en production qui peut être mise en place en aval du staging. Cette technique de mise en production contient des tests d’intégration basés sur des données réelles.

Aperçu des tâches pour ce stage :

1. Analyser les techniques de progressive delivery et définir dans quelle mesure un service mesh peut être complémentaire au progressive delivery. Cette analyse doit se faire suivant un état de l’art (déjà commencé). Le maître de stage apportera de l’aide à l’étudiant pour cet état de l’art.
2. Définir les politiques de progressive delivery (canary deployment, blue/green deployment, dark launch,...) et de les implémenter dans un processus gitOps avec et/ou sans des services mesh.
3. Définir une procédure permettant de valider le déploiement d’une nouvelle version d’un composant (test d’intégrations)
4. Facultatif : intégrer une approche DevSecOps dans le cycle

Le Cetic proposera un/des cas d’utilisation basés sur des projets de recherche (SamobiGrow, BAM, Flaracc, Factory-devsecops) ou des assets.

Chaque stage inclut la mise en place d’un démonstrateur et se termine par la rédaction d’un rapport détaillé et une présentation devant les chercheurs du CETIC

Keywords

CaaS, Micro-services, service-mesh, Istio, Kubernetes, API-Gateway, conteneurs, docker, progressive delivery, multimesh, devsecops, edge, SMI, SMP, service mesh performance, proxyless technologies

Encadrement :

L’entièreté du travail sera encadré. La ou le stagiaire utilisera une plateforme de développement permettant le suivi constant de ses progrès. Elle / il devra également faire preuve d’autonomie et d’esprit innovant.

Références

• kubernetes
• Services Mesh
• Construire et gérer une application à base de microservices
• Dynamic management of microservice architecture

Contact

Fabian Steels