Près de 3000 participants ont participé à la 11ème édition de la Devoxx.
La thématique principale de cette année était l’intelligence artificielle, mais Java, Web, Cloud, devOps, architecture et sécurité étaient également au programme.
Plusieurs de nos collaborateurs ont eu l’occasion d’assister à l’événement, dont l’un d’entre eux en tant que speaker du talk « Où va la Data Science ?”.
Leurs attentes étaient variées :
Oscar : Il s’agissait de ma toute première participation à la Devoxx. En tant que Data Engineer, j’étais particulièrement intéressé par la conférence sur ChatGPT, ainsi que celle sur FoundationDB — Il s’agit d’un outil que j’ai découvert récemment — Et enfin le multy-tenancy sur Kafka. Sans oublier bien évidemment la conférence de mon collègue Daoud : “Où va la Data Science ?”.
Frédéric : C’était également ma première participation à la Devoxx France. Mon objectif était de découvrir et de réapprendre certaines technologies ou pratiques liées aux technologies devOps, telles que Kubernetes & Terraform. J’opère en effet une transition professionnelle de développeur back à devOps.
Jeason : Première participation aussi pour ma part, et j’avais repéré plusieurs conférences intéressantes en amont de ma venue. J’avais le souhait de découvrir de nouvelles technologies et d’approfondir des connaissances sur des sujets front-end ou web en général.
Thibaut : Il s’agit de ma première participation à la Devoxx. En tant que développeur Java back-end, j’étais intéressé de voir les conférences autour des bonnes pratiques de code, de Java et des nouvelles technologies.
Data, Cloud, DevOps : 19 conférences Tech de la Devoxx 2023 résumées pour vous
Frédéric, Jeason, Nicolas, Thibault et Oscar partagent ce qu’ils ont appris et retenu des principales conférences auxquels ils ont assisté.
Le thème principal de la Devoxx était axé sur l’IA, avec notamment l’arrivée de ChatGPT. Beaucoup d’entre vous, l’ont probablement déjà testé et mis à l’épreuve.
Deux conférences étaient centrées sur ce sujet :
Résoudre AdventOfCode avec Github Copilot et OpenAI ChatGPTP
ChatGPT est-il capable de résoudre des problèmes de code avec un énoncé ? Eh bien oui et non ! Car il peut se tromper, mais il peut également se remettre en question de lui-même.
ChatGPT n’a pas la vérité absolue et se trompe souvent, mais il peut réaliser lui-même qu’il s’est trompé.
ChatGPT ne fonctionne pas du tout sur certains problèmes, mais il peut être utile pour gagner du temps à un instant T, en validant bien le code qu’il génère.
Aussi, la composition GitHub Copilot et ChatGPT peut s’avérer intéressante.
Conversations avec ChatGPT : Illusion ou réalité ?
Pourquoi ChatGPT a connu un tel engouement ? Et quelles sont les idées reçues qui circulent ?
Une excellente conférence pour prendre de la hauteur sur l’outil.
ChatGPT est loin d’être le seul modèle pré-entraîné disponible. En revanche c’est probablement le premier à être disponible gratuitement et avec une UX agréable. C’est sans aucun doute la première raison de son succès.
Mais bien qu’il donne l’impression de tout savoir, il est conçu pour répondre à quelque chose de plausible, et non pas quelque chose de vrai. C’est pour cela qu’il peut répondre très sérieusement quelque chose d’incorrect. Par exemple : Demandez-lui comment ramasser des œufs de vache. Il répond à partir de ce qu’il sait, après avoir appris beaucoup de choses, mais ne vérifie pas ses sources. Et surtout il ne sait pas quand il ne sait pas.
Il a aussi un garde-fou pour filtrer les sujets sensibles, tels que les sujets complotistes, mais ce garde-fou a ses limites. Il peut être contourné, d’où le danger d’utilisation (ex : Il est possible d’écrire un malware fonctionnel).
Est-ce révolutionnaire dans nos métiers ? Finalement pas tant que ça pour le moment. On a déjà de plus en plus d’IA dans nos outils (ex : GitHub Copilot), mais ChatGPT est un peu plus puissant et simple. L’outil fait plutôt parti d’une évolution technologique.
Il faut également savoir que les vidéos et images de la Devoxx ont été générées par l’IA. Impressionnant n’est-ce pas ?
Sur d’autres sujets Data, on retrouve également :
Où va la Data Science ?
Avec l’émergence de nouveaux termes au sein des écosystèmes data et devOps, tel que ‘Machine Learning Engineer’, il convient de se questionner sur l’évolution de ces métiers.
Daoud, data scientist à Positive Thinking Company, analyse et tente d’apporter une réponse sur l’évolution du métier de Data Scientist.
Le rôle du Data Scientist est, à l’origine, de produire des modèles de machine learning. Et donc d’avoir la connaissance business nécessaire au développement du feature engineering.
Les data scientists voyaient alors leur métier définit par un diagramme de Venn, qui posait le Data scientist comme quelqu’un qui avait à la fois des compétences en développement, en mathématiques et statistiques, et en expertise business. Aujourd’hui, on voit de plus en plus de diagrammes qui comparent les métiers data entre eux : Data Engineer, MLE, Data Scientist, Data Analyst. Avec un Data Scientist capable de faire (presque) tout.
Il reste toutefois encore facile d’expliquer les différences entre le métier de Data Scientist et celui de Data Engineer ou Data Analyst. En revanche, la complexité est bien supérieure quand il s’agit de le comparer au Machine Learning Engineer.
Le Machine Learning Engineer a surtout pour rôle d’automatiser des modèles de machine learning, et est en charge du déploiement de ces derniers.
Cette différence va notamment se retrouver dans les offres d’emploi. On demande surtout au Data scientist des compétences en expertise business, ce qui n’est pas du tout le cas du Machine Learning Engineer, à qui on demande systématiquement une expertise Ops.
Pour conclure, le métier de Data Scientist n’est probablement pas amené à disparaître au profit du Machine Learning Engineer. Qui est finalement un métier plus orienté devOps mais avec une expertise spécifique sur le déploiement de modèles de machine learning. Le Data Scientist, à l’inverse, à qui on demandait de plus en plus à savoir “tout faire”, comme pour un développeur full-stack, pourrait potentiellement revenir aux bases de son métier, celui de produire des modèles de ML.
En termes d’outils et de bonnes pratiques d’utilisation, nos collaborateurs ont également retenu ces conférences :
Le multi-tenancy chez Apache Kafka, navigation dans un sujet majeur
Florent et François ont travaillé sur une solution multi-tenancy avec Apache Kafka. Ils détaillent, de manière très ludique, le processus de réflexion qu’ils ont eu pour produire cette solution.
Kafka se retrouve presque partout. Dans une même organisation, on peut même retrouver plusieurs instances Kafka, avec plusieurs clients différents, sur plusieurs environnements, dans plusieurs équipes, et pour plusieurs besoins différents.
Comment mutualiser cela ? Peut-on les réunir sous un même cluster ?
Plusieurs solutions peuvent être envisagées :
– Convenir d’une convention collective
Le défaut majeur de cette solution étant que cela demande un contrat social.
– Fournir une librairie
Ce qui peut être très coûteux et demande aux utilisateurs de tous se familiariser à cette nouvelle solution.
– Faire de la “magie” entre les clients et le cluster Kafka
Cette magie sera un gateway qui communiquera avec les brokers Kafka. Le gateway réécrit les métas datas, et fait de l’assertion de messages. Le multi-tenancy est maintenant transparent, ce gateway est accessible et répond de la même manière qu’un cluster kafka, mais adapte et change sa réponse en fonction du client.
Cette solution permet de gérer le multi-tenancy, d’ajouter de la sécurité, et donc également, de n’utiliser qu’un seul cluster par organisation, et donc d’optimiser les coûts. Ce gateway permet de “repenser” Kafka en fonction de son organisation.
Storybook, une vraie bonne idée ?
Storybook est un outil à destination des designers et des développeurs.
Il permet de fournir un design system et d’éviter la multiplication des différents composants d’un site. Il permet aussi d’éviter les effets de bord de la modification des composants existants. Avoir une cohérence des boutons ou autres composants, permet d’ailleurs aussi une meilleure expérience utilisateur.
Storybook impose malgré tout quelques contraintes : Il demande une maintenance régulière pour rester utile et pour ne pas alourdir et rendre le code confus.
Mais pour citer Sara Attallah : “StoryBook : Essayer c’est l’adopter.”
Revisiting Design Patterns after 20
Un design pattern est une solution réutilisable, pour un problème récurrent, dans un contexte donné.
Ses principes de conception sont :
– La composition est préférable à l’héritage, car elle est plus flexible.
– Les petites interfaces sont préférables aux grandes interfaces, car elles sont plus stables.
– La réutilisation d’interface est préférable à la création d’interface.
Avant le jdk20, plusieurs classes et/ou interfaces étaient nécessaires pour implémenter un design pattern. Grâce à l’approche fonctionnelle, il est maintenant possible d’attribuer moins d’interfaces, et même dans certains cas une seule interface, à un design pattern.
L’implémentation devient alors plus facile et plus maintenable. La programmation fonctionnelle a en effet significativement simplifié l’implémentation des design patterns en Java 20.
Java 19 & 20 : What’s new and noteworthy ?
Outre une simplification de l’implémentation des design patterns, retrouver les principales nouveautés marquantes de Java 19 et Java 20 :
– Ce n’est pas parce qu’une version de Java n’est pas LTS qu’il ne faut pas l’utiliser.
– La nouveauté la plus marquante, depuis les lambdas et streams en Java 8, concerne la gestion des threads « virtuels ».
– D’autres nouveautés importantes sont à noter, telles que le pattern matching, le record matching, le code natif…
Des secrets dans les pixels ! À la découverte de la stéganographie
Comment des images peuvent-elles cacher des données secrètes dans leur encodage ?
– Une image PNG contient plusieurs sections. Il est possible de rajouter des informations après la fin de l’image, voire même des scripts.
– Deux encodages distincts en base 64 peuvent représenter le même texte. Ceci est dû au regroupement des bits par groupe de 6. Il est donc possible de cacher des informations dans une chaîne en base 64.
– Il est également possible de cacher des informations dans les pixels d’une image en s’appuyant sur l’encodage RGB.
Rendons le DDD aux devs
Comment refactorer un code peu lisible et peu maintenu au travers de petites étapes, pour ensuite s’intéresser à la conception afin de découpler le domaine de la partie technique ?
– Avant de refactorer, vérifier la couverture de tests. Elle permet de s’assurer que le refactoring n’engendre pas de régression.
– Pendant le refactoring, à chaque modification, même mineure, rejouer les tests et commiter. Cela permet de s’assurer que rien n’est cassé et de pouvoir revenir en arrière dans le cas contraire.
– Déclarer et initialiser les variables au plus proche de leur utilisation
– Utiliser le pattern « sandwich » pour que les parties techniques et métier ne soient pas entrelacées.
– Appliquer l’architecture hexagonale afin de libérer le domaine de toute dépendance technique.
Container Builders : Which is the best image builder ?
Pour cette conférence, une application de génération de labyrinthe a été développée. Elle est containérisée avec plusieurs outils différents.
Le but est, dans un premier temps, de comparer la taille de chaque image produite. Dans un second temps, il s’agit de comparer le temps de démarrage, le débit et le temps de latence de l’application.
L’environnement technique est : Java 17, Spring boot 3, image docker OCI compliant.
En comparaison des tailles des différentes images produites :
– Docker + Jdk : 380 mb / Docker + Jre : 190 mb / Docker + Custom Jre : 113 mb
– Jib : 289 Mb
– Cnb : 278 mb
– GraalVM : 98 mb
En comparaison des temps de démarrage, débit, latence et taille d’image :
Les solutions basées sur JIT compilation (Docker + jdk, Docker + Jre, Docker + custom Jre, Jib) ont un meilleur débit et un meilleur temps de latence.
Les solutions basées sur AOT compilation (GraalVM, Spring3 + GraalVM) ont une taille plus petite et temps de démarrage plus court.
Il n’y a finalement pas de solution magique, tout est une question d’environnement, de contrainte et de compromis.
Alice au pays d’OpenTelemetry
OpenTelemetry désigne à la fois un standard de données, une convention de désignation de ressources et l’implémentation d’instrumentation applicative optionnelle.
OpenTelemetry résout l’absence ou le manque d’observabilité pour une application et affine l’observabilité, en couvrant toutes les couches d’une application.
Il permet cela grâce à la définition des collecteurs. Un collecteur est composé de plusieurs pipelines. Un pipeline est composé d’une chaîne de receivers, processus et exporters.
Pour l’appliquer, certaines bonnes pratiques sont à retenir :
– En termes de métriques, OpenTelemetry n’est pas un data back-end. Il faut donc penser à définir ses data back-end (Prometheus ou Grafana par exemple). Et pour une meilleure corrélation, il faut aussi bien annoter ses ressources. Pour cela, il est possible d’utiliser le processeur K8s Attributes qui annote automatiquement vos ressources
Afin d’avoir plus de flexibilité, on peut également utiliser des sidecars qui jouent le rôle d’intermédiaires entre ses ressources et le collecteur. Les receivers sont interopérables. Ils implémentent les protocoles HTTP et gRPC.
– Concernant les logs, ils sont envoyés aux collecteurs par des daemon Set installés dans le cluster. Donc pour plus de sécurité, vous devez bien gérer les privilèges de vos pods dans le cluster. Pour plus de performance vous pouvez également utiliser des opérations spéciales dans les receivers pour inclure/exclure/recombiner/filtrer des logs.
Vous pouvez aussi utiliser des processeurs spéciaux comme le ‘search and replace’.
– Enfin, la corrélation n’est pas gérée nativement. Des configurations customisées sont donc à prévoir.
CRAC VM vs GRaal VM : Pour un démarrage rapide
Le déploiement d’applications Java a évolué au fil du temps avec : Les archives Java, les serveurs d’application, les micro-services, les serveurs embarqués et les fonctions serverless.
L’objectif de la JVM reste, entre autres, d’améliorer la performance d’une application en général, et son temps de démarrage et d’exécution de requête en particulier. La JVM utilise le profilage JIT compiler pour y arriver.
Mais certaines opérations sont gourmandes, comme le chargement des classes, la gestion des annotations, l’initialisation des blocs statiques et l’initialisation du complexe applicatif (Container Sping, CDI, etc.).
Pour cela, nous retrouvons les solutions GRAAL VM et CRAC VM.
CRAC VM est incubé par OpenJDK tandis que Graal VM est incubé par OracleLabs.
Graal VM utilise l’AOT compiler. Ce dernier compile le bytecode en code natif pour accélérer le démarrage de l’application. Toutefois cette solution présente certains inconvénients, tels que :
– La réflexivité est perdue au runtime.
– La JVM est remplacée par la substrate VM, moins performante que la première.
– Le Garbage collector est remplacé par le Serial GC, moins performant que le premier.
– L’optimisation dynamique est remplacée par l’optimisation statique, moins performante que la première.
Pour exemple, durant la démo, un simple ‘helloworld’ a mis 5mn28 de temps de build. Il a démarré en 0.038 s.
Crac VM utilise un système de checkpoint/restore. Il sauvegarde la JVM dans un état optimal et la restaure ultérieurement. Les options ‘jcmd XX checkpointTo’ et ‘XX restoreFrom’ assurent les opérations de restauration et de sauvegarde.
Pour exemple, durant la démo, une application de vérification de nombre premier a été sauvegardée puis restaurée en 0 ms (temps de démarrage quasi nul).
À retenir : CRAC VM est préférable à GRAALVM, car il réutilise les composants natifs du JDK et donc présente une meilleure compatibilité.
Cloud Native Security for the rest of us
Retrouvez une liste de bonnes pratiques et recommandations à appliquer avec Cloud Native Security :
– Sécuriser le trafic vers votre cluster, par exemple avec TLS checker.
– Protéger vos nodes de vos pods en contrôlant et en configurant des security context adéquats.
– Mettre à jour votre cluster régulièrement.
– Isoler vos réseaux virtuels en usant d’ingress et de network policies, et de service mesh et cillium pour des network policies plus complexes.
– Protéger vos données sensibles dans un Vault externe, tel que HashiCorp Vault, Sealed Secrets.
– Sécuriser vos communications en appliquant l’Encryption at Rest.
– Définir la méthode d’authentification adéquate : Human Token, Robot Service Account, etc.
– Définir la politique de contrôle d’accès adéquate : Role Base Access Control, Attribute Bases Access Controls, Webhook, etc.
– Appliquer le DevSecOps en protégeant votre supply chain : Signer vos assets avec Sigstore, scanner et corriger les CVE, contrôler la conformité avec Open Policy Agent, …
– Appliquer religieusement les OWASP.
– Mettre en place une observabilité solide de votre cluster et de vos déploiements avec Prometheus et Grafana par exemple.
FoundationDB : Le secret le mieux gardé des nouvelles architectures distribuées !
FoundationDB est une base de données open-source. Elle peut, à elle seule, résoudre de nombreuses problématiques rencontrées lorsque l’on travaille sur ce genre d’outil.
Trop de bases de données ont des usages différents. La première question à se poser est donc : Peut-on mutualiser ?
FoundationDB n’est d’ailleurs pas concrètement une BDD, mais simplement un socle qui permet cette mutualisation. Ce socle est principalement constitué d’un moteur transactionnel de stockage. Il est donc ensuite possible de produire des couches sur ce moteur en fonction des usages.
Avec une architecture en modèle Acteur, chaque problématique est représentée par des acteurs. Cela permet de rendre l’architecture plus scalable. Il suffit ensuite d’augmenter ou de réduire le nombre d’acteurs sur un type de tâche pour optimiser ses performances et son coût. Ce qui résout la plupart des problèmes de tuning.
Seul défaut, l’outil garde en mémoire 5 secondes de mutation (ce qu’on appelle des resolver). Le temps maximal d’une transaction est donc de 5 secondes également.
SQL (le retour) : Démystifions les idées préconçues et utilisons la DB efficacement
La Devoxx proposait d’autres conférences sur les bases de données relationnelles. Ces bases de données sont, non pas oubliées, mais de moins en moins utilisées avec l’émergence des bases NoSQL et de leur publicité assez agressive. Néanmoins les bases de données SQL sont probablement plus prometteuses dans l’avenir, car elles sont et restent très performantes. Elles peuvent répondre à des besoins multiples, auxquels on n’aurait pas forcément pensé, comme le démontre cette conférence.
30 index sur une table PG de 6To : Défis et solutions
Une autre conférence, sur le SQL également, était présentée par Doctolib. Il s’agissait d’un retour d’expérience sur la problématique : Comment réduire et optimiser une table postgreSQL de plus de 5To ?
Avec en solutions : Suppression d’index non utilisé, merge d’index et création d’index partiel, et développement et mise à disposition d’un outil open source (basé sur les transactions) pour recetter cette mise à jour.
De Chroot à Docker, Podman, et maintenant les modules Wasm, 40 ans d’évolution de la conteneurisation
Un peu d’histoire également avec la conteneurisation, qui a commencé il y a plus de 40 ans. Nous vous proposons quelques dates (non exhaustives) à retenir :
1970 — Naissance des containers dans les systèmes Linux, avec leurs problèmes fondamentaux : Partage de ressources limitées et séparation de la production et du développement.
2006 — Process container (cgroups) : Partage basé sur la limitation, la quantification et l’isolation. C’est la base de l’isolation moderne.
2011 — Warden : Automatisaton de la gestion des containers LXC grâce à une API.
2013 — Docker : Réutilisation des users namespaces, remplacement des LXC par des libcontainers et mise à disposition d’une API pour automatiser la création des containers.
2016 — WebAssembly (WASM) : Partage basé sur l’exécution d’un bytecode dans une sandbox isolée. Cela permet une très bonne portabilité, de la performance et de la sécurité.
2022 — Docker supporte Webassembly.
À retenir : WASM est le container runtime le plus abouti à ce jour, si bien qu’il est supporté par Docker.
Sans oublier des sujets annexes, mais tout autant intéressants, lors des kick-off notamment, dont :
Voyage au centre de la veille : Apprendre en continu avec sa veille technologique
Conférence moins technique, le sujet était focalisé sur la manière de faire de la veille, avec plusieurs conseils pour une veille efficace et organisée.
Il existe deux types de veilles :
– On parle de veille professionnelle quand c’est l’entreprise qui donne du temps dédié à celle-ci. Cela est donc souvent limité au cadre proposé.
– Là où la veille personnelle est sur le temps personnel du développeur, et donc sur les sujets et formats qu’il souhaite.
C’est surtout sur ce type de veille que les conseils suivants sont applicables :
– En premier temps il faut sourcer. Il est important d’organiser ses sources et de garder à l’esprit que chaque source équivaut à une “tâche” qu’il faut donc patiemment organiser comme telle, afin d’éviter un risque d’accumulation.
– Ensuite, il faut traiter ces sources, et donc les consommer. Mais il convient également de prendre des notes, ce qui permet d’aider la mémoire de travail, de mémorisation et d’alimenter une réflexion. Ces notes doivent être classées et retravaillées, pour éviter de garder des notes qui ne seront jamais relues.
– On peut enfin valoriser cette veille, en partageant notre savoir et en innovant à partir de celle-ci (lier les idées entre elles pour produire des choses).
La conférence se conclut avec quelques conseils pour commencer sa veille.
Il est précisé de définir ses objectifs de veille et de définir son processus à soi. Mais aussi, de vraiment trouver et prendre du temps pour la veille, tout en gardant à l’idée de trouver son propre rythme. Et si on utilise des outils, commencer léger et ensuite les adapter à ses besoins.
Top des sources Tech à suivre pour faire sa veille technologique
Réaliser une veille technologique régulière est indispensable dans votre métier IT.blog.positivethinking.tech
Le numérique c’est pour tout le monde… Ou pas !
Cette conférence très intéressante aborde le sujet du web inclusif.
L’inclusivité est la façon d’aborder les problématiques de non-accès au monde du numérique par les utilisateurs, et permet de se rendre compte de certaines aberrances que l’on rencontre lors du développement d’outils.
Le sujet regroupe tout ce qui est un frein à l’accès aux outils numériques, dont voici une liste non exhaustive :
– L’accessibilité sur le web.
– Le poids des sites, entraîné par le développement de nouveaux outils : Tout le monde n’a pas accès au dernier iPhone ou à la 5G.
– La couverture du réseau mobile dans les zones blanches.
– La numérisation d’outils qui n’ont pas d’alternative physique.
– …
Les oratrices ont conclu en encourageant les gens à se renseigner sur ces sujets encore trop peu abordés.
“40% des Français sont inquiets à l’idée de réaliser des démarches en ligne et 34% des habitants des villes moyennes disent ne pas profiter du tout des opportunités offertes par le numérique.” — Société Numérique.
Numérique inclusif : Prendre en compte les inégalités d’accès et d’usage
D’après le programme gouvernemental Société Numérique, 13 millions de Français ont encore un accès ou un usage réduit…blog.positivethinking.tech
Inclusion numérique : Bonnes pratiques pour un Web plus accessible
En France, environ 12 millions de personnes sont en situation de handicap temporaire ou permanente.blog.positivethinking.tech
Une Devoxx France 2023 à la hauteur des attentes
Les conférences ont répondu aux attentes de nos collaborateurs et leur ont permis d’approfondir de nombreux sujets sur des expertises variées.
Oscar : Je suis très satisfait de cette première participation. Chacune des conférences m’a appris des choses. Avec en plus quelques rencontres très sympas sur les stands ! Et bravo à Daoud pour sa présentation, solide jusqu’au bout !
Frédéric : Je suis très content d’avoir pu assister à ce grand événement. J’en ressors avec beaucoup d’informations que je vais pouvoir mettre en place dans mes projets personnels ou professionnels. J’ai aussi pu découvrir d’autres sujets que je n’avais pas initialement prévu, mais qui sont tout aussi intéressants.
Jeason : J’ai adoré cette journée et j’ai beaucoup appris. Pour une prochaine fois je me concentrerais peut-être toutefois sur une conférence à destination des développeurs front-end.
Thibaut : Cette première expérience à la Devoxx était vraiment enrichissante et intense ! J’ai beaucoup apprécié le fait de pouvoir piocher parmi des sujets variés et intéressants.
Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
