Cette conférence a lieu à Lille tous les ans depuis 5 ans. Cette année, la session se déroule dans les amphis de la Bibliothèque Universitaire de la grande Université Catholique de Lille, surnommée “la Catho”. Le bâtiment principal de la Catho est tout simplement magnifique, on se croirait dans un campus anglais ! La BU se trouve dans un bâtiment plus moderne.
C’est une conférence qui se déroule sur une seule journée, avec 2 sessions en parallèle. Je vous présente donc ici la moitié des talks disponibles. Si vous voulez voir la totalité du programme, rendez vous sur le site de Cloud Nord.
Rafraîchis ta prod avec Kro – Tony Jarriault, Laurent Grangeau
L’idée derrière KRO est de corriger le problème de “réutilisation” de code par un mécanisme de “template”. C’est un peu le même mécanisme que les modules Terraform, l’idée étant de standardiser les groupes de ressources et de pouvoir les réutiliser dans chaque application du cluster.
A la différence de Helm ou d’autres moteurs de template, KRO utilise du YAML natif dans le même format que les fichiers de déploiement traditionnels Kubernetes.
On est plus proche ici du produit Crossplane, mais qui serait applicable à n’importe quelle ressource, pas seulement GCP.
KRO va encore plus loin, car il propose également de décrire les ressources Cloud qui ne sont pas dans le cluster Kubernetes, mais par exemple dans AWS ou GCP. Pour cela il utilise le pattern “Controler” pour piloter la création de ressources.
Au final, KRO propose de supprimer la stack multi-outil, comme Terraform ou Helm, pour proposer un seul langage unifié pour maintenir l’ensemble des applications du cluster.
Mon avis : Kro est aujourd’hui toujours en Alpha, et j’ai l’impression que tous les cas d’usages n’ont pas encore été prévus. Que se passe-t-il lorsque la template est mise à jour par exemple? Beaucoup de questions mais le principe est clair, et c’est une grande avancée pour Kubernetes, c’est un projet à suivre de près
Simplifier les tests d’applications cloud natives dans tous les environnements avec Dapr et Microcks – Laurent Broudoux
Lors de ce talk, il est question de DAPR et Microcks, deux outils bien distincts, mais dont la complémentarité est intéressante pour écrire des tests métier simplement.
DAPR est un framework un peu hybride qui permet à un développeur de décrire tous les échanges avec des “middlewares”, comme une base Postgres ou Mysql, un cache Redis ou Memcached ou un topic Kafka. Il est constitué d’un SDK disponible dans plusieurs langages, et d’un binaire autonome qui contient toute la logique de connexion au middleware. Le SDK transfère les appels au binaire DAPR qui s’occupe ensuite de se connecter réellement au middleware.
Lorsqu’il est utilisé avec Kubernetes, le binaire DAPR est automatiquement embarqué dans le POD de chaque microservice. Le binaire DAPR gère automatiquement le TLS, les secrets, l’observabilité, etc…
Le SDK DAPR fournit aussi une suite de pattern de programmation destiné à faciliter le développement, comme par exemple un gestionnaire de tâche programmée ou un gestionnaire de workflow.
Mon avis: Encore une nouvelle tentative de faire de l’abstraction des middlewares comme Postgres ou Kafka. L’architecture pose plein de questions, en particulier en termes de performance! Cependant le concept est très séduisant et on sent que les développeurs de DAPR ont pensé à tout, ce qui donne confiance. À tester d’urgence!
Microks est un framework de test qui lit des spécifications OpenAPI (ex-Swagger) et OpenAsync, le nouveau format équivalent à OpenAPI mais pour les échanges de messages. A partir de ces spécifications, il apporte plusieurs fonctionnalités permettant au développeur d’écrire les tests autour de ces appels :
- Mock/Stub automatique des appels vers l’API
- Génère une image Docker pour Testcontainer pour simuler un service distant
- Contract Testing automatisé (voir les articles de Martin Fowler sur le sujet) afin de s’assurer à tout moment que les contrats d’API sont respectés.
En couplant DAPR et Microks, on dispose d’une formule permettant d’avoir une couche d’abstraction très haute des appels aux middlewares et aux autres services, permettant au développeur de se concentrer sur le développement métier.
Mon avis : l’aspect “auto-magique” me pose question, est-ce qu’on peut réellement tout déduire d’un simple Swagger ? Quid des cas limites? La promesse est belle, mais je parie que tout n’est pas aussi simple. Même si tout n’est pas aussi magique, rien que de pouvoir simplifier l’écriture des tests d’API est déjà une grande avancée !
Construire des flux d’IA agentique robustes avec Dapr : scalabilité, sécurité et agnosticité cloud – john dennison
Encore un talk sur DAPR, ce framework est décidément la star de cette conférence !
Ici on se focalise sur la partie LLM offerte par le framework.
Comme attendu, DAPR crée de l’abstraction entre le code et divers fournisseurs de LLM (ex: Bedrock), mais c’est une autre facette de DAPR qui est présentée : DAPR fourni des “pattern” de programmation d’agent clef en main:
- Augmented LLM : le LLM appelle d’autres agent
- Prompt Chaining : le résultat d’un prompt est envoyé dans un autre prompt
- Routing : on envoie le prompt à plusieurs LLM et un algorithme sélectionne le meilleur
- etc…
Encore une fois, DAPR nous évite de réinventer des roues en capitalisant sur des patterns connus. Et bien sûr, on profite des pattern middleware habituels, en particulier le pattern pub/sub, qui remplace avantageusement les appels API synchrones dans le cas des appels d’agent LLM.
Mon avis : Encore une fois, Dapr est utilisé pour la facilité de ses abstractions. A force de tout “Dapr-iser”, est-ce qu’on gagne ou on perd en complexité? J’ai l’impression que DAPR s’exprimera parfaitement dans les couches “infra” d’un code, et j’éviterais de mettre trop de code métier dedans…
Pulumi Automation, pour piloter votre infrastructure depuis votre code – Mazlum Tosun
Je suis un fanboy Terraform, depuis le jour où j’ai commencé à l’utiliser pour scripter mon infrastructure AWS ou Azure. Mais j’ai souvent entendu parler de Pulumi comme concurrent direct. Donc j’attendais cette présentation de pied ferme !
Le conférencier commence par détailler les similitudes avec Terraform, et elles sont nombreuses,comme l’utilisation d’un fichier “State” ou dépendances entre ressources. A la différence de Terraform, qui utilise un langage spécialement conçu pour l’infrastructure, Pulumi utilise un langage de programmation traditionnel, par exemple Python.
Même si Terraform est plus efficace que Pulumi grâce à son langage dédié HCL, Pulumi a l’énorme avantage de pouvoir être embarqué directement dans le code de production. Cela ouvre des possibilités intéressantes comme:
- Création d’élément d’infrastructure à la demande directement depuis le code : le speaker fait une démo de création d’index Big Table directement depuis l’application
- Création d’un CLI spécialisé qui créer un groupe d’éléments d’infrastructure
- Création et suppression à la volée lors de l’exécution de tests unitaires
Mon avis : Je ne suis toujours pas convaincu d’utiliser Pulumi à la place de Terraform. Par contre, l’idée du test unitaire qui crée de l’infrastructure temporaire m’a séduit et je garde ce cas en mémoire.
Le CDC pour ne pas DCD – Ludovic Dussart, Quentin Burg
Ce talk présente un projet de réarchitecture réussi d’une architecture legacy, à savoir un progiciel qui pousse des événements dans un topic Kafka. Le topic est ensuite consommé par plusieurs consommateur, mais également par le consommateur de “reconstruction” qui met à disposition une database avec l’état “actuel” (snapshot). Le problème de cette architecture est que le snapshot est également consulté en lecture par les consommateurs et qu’il existe des “races conditions” entre le moment où un second message arrive alors que le premier n’a pas encore été ingéré par le snapshot.
La réarchitecture consiste donc à n’envoyer uniquement que dans la base de données “snapshot” et ensuite de répliquer cette base de données “snapshot” aux autres consommateurs. Grâce à ce mécanisme, on a la garantie d’ordonnancement.
Pour cela les deux développeurs ont utilisé un CDC (Change Data Capture) avec Debezium. Debezium est un outil libre qui se met en écoute des fichiers WAL de Postgres (les fichiers qui servent normalement à répliquer une instance à l’autre) et qui envoie l’événement dans un topic Kakfa dans un format JSON.
L’utilisation d’outils libres du marché ont considérablement facilité la réarchitecture qui a pu être livrée en temps record !
Mon avis : Bon retour d’expérience, même si les slides étaient un peu chargées et pas toujours faciles à suivre. S’il y a une morale à cette histoire, c’est qu’il ne faut pas avoir peur de refactorer des architectures plutôt que de vivre avec les problèmes.
Tester vos conteneurs Docker : plus qu’un choix, une nécessité – Hakim Lakrout
Voici un petit talk rapide sur 2 outils libres combinés pour mettre en place des tests unitaires sur la conception d’image Docker.
- Container Structure Test : Un outil d’inspection d’image basé sur des assertions
- BATS : Un petit outil qui permet de mettre en forme des tests écrit en Bash
La démonstration se base sur l’ajout d’un fichier dans une image Docker, puis un test est écrit pour s’assurer que le fichier est bien présent.
Mon avis : Le talk ne montre pas vraiment les possibilités de cet outil de testing. La démo montre l’exemple d’un test “tautologique”, mais ne donne pas d’exemple de tests de comportement. En revanche, on devine qu’il serait un outil puissant pour standardiser la création d’image, par exemple pour s’assurer que toutes les images créées par l’équipe possèdent les labels standards, des images de bases obligatoires, etc…
D’Azure à AWS : récit d’une migration ambitieuse et réussie – Michka Popoff
Suite à un partenariat commercial conclu entre Total et AWS, l’entreprise s’est trouvée dans l’obligation de migrer l’intégralité de son infrastructure Azure existante vers l’écosystème Amazon Web Services.
Cette transformation d’envergure et non prévue a nécessité un accompagnement des compétences : formation ou remplacement des consultants.
Dans un premier temps, un consultant spécialisé en rétro-ingénierie a analysé l’architecture Azure en place afin de produire une solution équivalente et optimisée dans AWS, tout en étant compatible avec les requirements de sécurité très forts imposés par TOTAL.
Parmi les décisions techniques majeures, le choix d’ECS Fargate au lieu de EKS s’est révélé particulièrement judicieux : l’équipe a gagné en sérénité par rapport à leur ancienne stack AKS, qui était difficile à maintenir.
La standardisation entre équipes a été assurée par l’utilisation massive de modules Terraform, garantissant une écriture homogène entre équipes, et surtout qui permet de respecter les requirement de sécurité imposé par TOTAL.
Heureusement, le responsable de la migration a réussi à obtenir un Feature Freeze pendant le temps de la migration, ce qui a vraisemblablement sauvé le projet…
Mon avis : Un super talk qui parle de la vraie vie. Parmi les éléments surprenants, le choix de ECS Fargate par rapport au standard du marché Kubernetes m’a fait beaucoup réfléchir, En effet, nous sommes en ECS Fargate sur ma mission actuelle, et les développeurs militent pour passer sur Kubernetes, ce qui est très tentant, mais est-ce que la complexité apportée en vaut vraiment la chandelle ?
WASM Components are a FaaS Best Friend – Laurent Doguin
Bon, pour ce talk, il fallait être bien réveillé car on allait taper “dans le code”.
Tout d’abord nous voyons les grands principes du FaaS (Function As A Service) et de la grande problématique qu’il apporte : Une fonction déportée doit être rapide à répondre, et parfaitement scalable si les appels augmentent.
WASM et toute la technologie qui gravite autour semble être le meilleur moyen d’arriver à faire du FaaS parfaitement.
Tout d’abord WASM (Web Assembly), est un moyen efficace de compiler vers du bytecode rapide et sécurisé par désign. Il est également très rapide à démarrer, bien plus qu’une image Docker ou une VM par exemple.
Autour de ce processus gravitent des composants qui vont permettre de mettre en place une architecture distribué et scalable :
- WASM Cloud qui permet le déploiement et l’exécution de code WASM
- WASI est un protocole de message standardisé bas niveau permettant de typer les variables même lorsque le client et le serveur sont codés dans des langages différents
- NATS permet d’avoir un bus de message universel pour connecter les processus WASM entre eux
- Lattice est un réseau virtuel au dessus de NATS
- Des providers dédié pour “sortir” de WASM afin de se connecter à des middleware externe (SGBD par exemple)
L’orateur donne l’exemple d’une implémentation d’une fraiseuse dans une usine de fabrication de pièces en métal, qui arrive à être monitorée au travers de processus WASM embarqué dans la machine !
Mon avis : Que s’est-il passé depuis la première idée de WASM, qui était à l’origine destiné à faire exécuter du code nativement dans le navigateur (Javascript compilé en quelque sorte), jusqu’à aujourd’hui en faire une galaxie de langage côté back, voire même IoT, voire même une infrastructure complète efficiente et scalable. La promesse est énorme, mais la complexité finale est inquiétante. Soit le produit s’écroulera sur lui-même, soit c’est le prochain Kubernetes. On lui souhaite le même succès !
Conclusion
Tout d’abord, Lille est une ville extrêmement dynamique et agréable. Un grand bravo pour les organisateurs pour cette conférence de qualité. En ce qui concerne les technos en vogue, on constate toujours l’omniprésence de Kubernetes, mais la partie n’est pas terminée, il reste encore des technologies à inventer, pour permettre aux développeurs de coder et déployer toujours plus facilement.
A l’année prochaine !