DEVOXX FRANCE 2025 - DAY 2

Devoxx France is a French event based in Paris with almost all content in French, so exceptionally, I post in French. I apologize to my non-French speaking readers.

https://www.devoxx.fr/

Du 16 au 18 avril 2025, j'ai eu la chance de participer aux 3 journées de Devoxx 2025 France à Paris. Une conférence passionnante et enrichissante à laquelle je prends toujours beaucoup de plaisir.

Lors de cette édition, en plus des différents échanges avec d'autres participants, j'ai aussi pu assister à 24 talks, aux keynotes et à des rencontres avec des communautés.

Dans cette série d'article, je vais vous partager mes principaux enseignements de 22 des 24 talks auxquels j'ai assisté. En effet, il y a 2 talks dont je n'ai pas compris le message donc je ne les aborderais pas.

Dans le deuxième épisode de cette série, je vais vous partager les principaux enseignements que j’ai retenus des 7 talks auxquels j'ai assisté le deuxième jour.

• Stephane Derosiaux - Conduktor

Le premier constat exposé pendant le talk a été que le réseau n'est pas fiable, il faut donc tenir compte de cela dans tout système distribué.
Le deuxième constat a été que la majorité des problèmes liés à Kafka sont sur les applications (producer et consumer) et non pas sur les brokers.

Ensuite, j’ai noté une liste de conseils données pendant ce talk :

• La version 4.0.0 de Kafka est compatible avec GraalVM et apporte donc la compilation native.

• Il est important de bien nommer les choses dès le début : du scope le plus large au plus petit ; en effet, souvent l’ajout d’un Kafka dans l’architecture est avant tout un projet d’urbanisation.

• Il faut faire attention aux configurations par défaut qui ne sont pas bonnes surtout avant la V3, il est possible de regarder ce qui change version par version grâce au Kafka options explorer : https://learn.conduktor.io/kafka/kafka-options-explorer/ ; il est important d’être toujours à jour dans les versions. pour les configurations et les CVE.

• Lorsque l’on utilise des messages au format JSON, il est conseillé d’utiliser la compression avec zstd.

• Be idempotent : producer only, à faire soit même côté client.

• Il est conseillé d’utiliser la “forward compatibility” qui permet les nouveaux champs non optionnels plutôt que la “backward compatibility”.

• Dead Letter Queue (DLQ) : ajouter la raison et le topic d'origine dans les headers du message pour être en mesure de comprendre pourquoi le message a été rejeté.

• Pas le même algorithme de hashing suivant les langages qui peut induire qu’un message avec la même clé n’arrive pas dans la même partition en fonction du langage utilisé pour le client.

• Lorsqu’il y a un besoin de Dual Write, il est conseillé d’utiliser un Change Data Capture (CDC) avec Debeziul. Le two-phase commit (2PC) dans Kafka pour le Dual Write en cours d'implémentation.

• Kim-Adeline Miguel - GitHub

• Tugdual Grall - GitHub

Ce talk m’a permis de mieux comprendre comment fonctionne Github Copilot.

Les équipes de Github Copilot se fixe comme limite une latence de 150ms pour un cycle de complétion.
Ils utilisent un modèle GPT-4o fine tune.
Pour le context, Github Copilot utilise les onglets ouverts, il est important de garder uniquement les onglets pertinents à la tâche en cours pour améliorer la qualité des réponses. Lorsque l’on discute avec Github Copilot, il est conseillé de faire une discussion par sujet. Les prompts envoyés ne sont pas gardés par Github Copilot.
Github Copilot ajoute une couche de sécurité avec la possibilité de filtrer du code public ou encore d’exclure certains contenus.

• Stéphane Philippart - OVHcloud

Dans le monde Java, nous sommes habitués à initialiser un projet avec de nombreux fichiers et répertoires. A tel point que des CLI ont vu le jour pour nous aider à créer les projets SpringBoot ou Quarkus par exemple. Vient ensuite le choix du "package manager" : Maven ou Gradle ? Et c'est seulement à partir de là que l'on peut commencer à développer puis exécuter son code 😅.

Toutes ces étapes fastidieuses expliquent pourquoi, lorsque que l'on a besoin de faire un développement rapide de quelques lignes pour automatiser une action, on préfère d'autres langages à Java : Python par exemple.

Et si je vous disais, qu'avec JBang, vous allez pouvoir rester avec votre langage préféré, Java, et développer une classe toute simple (avec des dépendances externes) en quelques secondes !

C'est le pari (spoiler : réussi) de JBang que je vous propose de découvrir durant une session de live coding.

A vous les joies du scripting en Java !

Ce talk m’a permis de découvrir le fonctionnement de JBang.
Depuis jdk11, possible de faire du scripting en natif avec un shebang; mais c’est “single file only”.
JBang pour le scripting avec Java plus loin et permet d'ajouter des dépendances. JBang crée un jar à la volée et l’exécute.

• Yannick Lambruschi - Mirakl

• Luis Blanche - Mirakl

Les différents cas d’usages de modèles d’IA et de GenAI en production sont sujets à des contraintes de déploiement spécifiques qui nécessitent des approches adaptées. Par exemple, pour un cas d’usage e-commerce basse latence, nous avons déployé nos modèles sur KServe, une solution cloud-native qui exploite Kubernetes pour permettre une colocalisation efficace et optimiser les coûts. À l’opposé, pour un cas d’usage de transformation de catalogues avec des modèles LLM fine-tunés, nous avons réussi à intégrer une architecture Multi-LoRA sur Anyscale grâce à RayLLM, répondant à des besoins de traitement à haut volume avec coût maîtrisé.
Cette présentation abordera ces deux approches distinctes en mettant en lumière les défis techniques, les critères de choix des solutions et les enseignements tirés pour optimiser le déploiement et l’orchestration de modèles d’IA selon leurs contraintes spécifiques en production

Deux challenges concernant l’IA en production ont été évoqués :

• Inférence basse latence

• LLM

• transformation et extraction

• enrichissement

• traduction

• réécriture des descriptions

• utiliser des solutions managées pour aller plus vite puis internaliser pour optimiser

• s'appuyer sur l'open source

• Nicolas Wlodarczyk - Aerospike

• Peter Goron - Criteo

Venez découvrir Aerospike et comment Criteo planifie et opère sa plateforme de distribution de données temps-réel pour servir ses applications business à fort trafic en utilisant Aerospike et sans avoir besoin d’ajouter de cache.

Dans ce talk, Peter, responsable de l’équipe NoSQL à Criteo, présentera les enjeux de cette plateforme, ainsi que les méthodes et outils utilisés au quotidien pour garantir la performance. Une attention particulière sera portée sur les activités de capacity planning, sur les caractéristiques de l’infra sous-jacentes, ainsi que sur le monitoring de la performance.

J’ai découvert à l’occasion de ce talk aerospike (https://aerospike.com/) que je ne connaissais pas.
Il s’agit d’une base de données temps réel supportant différents data models open source.
Pour le clé / valeur temps réel elle propose les opérations : get / set / delete + TTL.
Criteo l’utilise comme un cache au dessus d'hadoop, du catalogue de données pour l'ad serving et au dessus des services tiers pour limiter les appels à ces derniers.

Pourquoi Criteo a choisi aerospike :

• performance

• densification enabler (division par 3.5 du nombre de machines vs memcached + couchbase)

• reliability (pas de dégradation de perf pendant les maintenances + comportement prédictif)

Elle propose un stockage hybride :

• index primaire en mémoire (partionned red black trees)

• data sur NVME + linux page cache

• strong data distribution model (pas de repair)

Criteo l’a installé sur un cluster kubernetes dédié sur du barre métal dans leurs datacenters. Le capacity planning a été primordiale pour optimiser l’utilisation des ressources.

• Yves Brissaud - Dagger

Ça fait quelques temps maintenant que les conteneurs et leurs images sont partout. Que ce soit sur les machines de développement, sur les systèmes de production, ou comme moyen de packaging.

Mais d'ailleurs, une image OCI (Open Container Initiative), qu'est-ce que c'est exactement ?

Dans cette session, nous allons voir, de la manière la plus interactive possible, ce qu'est réellement une image :

• qu'est ce qui fait d'une image, une image ?

• comment on pull ou push une image ?

• un blob, un manifest c'est quoi ?

• et les tags, les digests ?

• mon image fonctionne sur amd64 et arm64, comment est-ce possible ?

• est-ce qu'on peu aller plus loin ? Stocker autre chose dans une image ? Ou l'étendre ?

Partons à la découverte des images, étape par étape : créons une image à partir des outils existant, puis disséquons la.

Et à la fin, peut-être même que cela vous donnera des idées sur de nouveaux outils à créer pour exploiter ce format plus souple qu'il n'y parait au premier abord.

Ce talk m’a permis de mieux comprendre comment était composé une image OCI et l’avantage d’une registry qui permet la déduplication des layers pour économiser de l’espace de stockage et le versionning.
Il est possible voir le contenu d’une image et de l’explorer en récupérant l’image via la commande “docker save …”. Pendant ce talk, on a pu voir en détail les différents layers d’une image et leur composition.
OCI permet d'être étendu et de stocker autre chose que des images (par exemple des modèles ai).

• David Pilato - Elastic

Dans cette session sans slides, nous découvrirons par la pratique ce qu'apporte le nouveau language ES|QL pour aller fouiller dans nos données indexées dans Elasticsearch et ce, de façon interactive et visuelle.

ES|QL et surtout le nouveau moteur derrière l'API _query apportent à la fois une syntaxe simplifiée permettant d'affiner vos résultats, étape par étape et ajouter de nouvelles fonctionnalités comme par exemple l'enrichissement de données et la transformation à la volée, directement dans votre requête, mais également des performances inégalées.

Ce talk était une démo du nouveau langage ES|QL pour requêter les données indexées dans Elastic. Il s’agit d’un nouveau endpoint qui utilise la méthode POST (vs GET pour le endpoint search). Ce nouveau langage est inspiré de la pipe syntax (les instructions sont séparées par des | comme en bash par exemple).
Il est possible de choisir le format de sortie et Kibana est même capable de proposer de lui même une représentation des données sélectionnées en fonction de leur format.
Ce langage est traité par un moteur plus performant qui apporte le mutli thread par shard et aussi un query optimizer (Résolution logique + résolution physique (query plan)).
Attention : l'ordre des keywords est important. Ce qui a attiré ma curiosité car dans ce cas le query optimizer est limité par l’ordre ? J’espère trouver le temps de tester ce point pour pouvoir écrire un article sur le sujet.