BreizhCamp2024 : à l'ouest toute !

Ivan Béthus - Jul 11 - - Dev Community

Nous sommes de nouveau sur la route avec quelques membres des équipes onepoint pour le rendez-vous breton des développeurs en tout genre : le BreizhCamp.
Créé en 2011 à l’initiative du BreizhJUG, le BreizhCamp propose de faire se rencontrer les communautés du développement et de l’expertise, avec un contenu à la carte sur plus de 100 thèmes présentés.

En plus des nombreux sujets présentés par nos collègues, nous avons préparé avec @dlucas un petit top 3 de nos conférences préférées. À vos lunettes, il y a de la bonne lecture !

Du code source à l'exécutable : plongée dans les entrailles de la compilation en Rust par Édouard Siha

Comment le compilateur Rust fait-il pour assurer le respect de la notion d'emprunt ? Pourquoi est-il capable de générer facilement des binaires spécialisés pour une plateforme d'exécution différente de celle de la plateforme de compilation ? Quel genre d'optimisations surprenantes est-il capable de réaliser ? Quelles caractéristiques le différencie des compilateurs utilisés pour le C ? Pour le Java ?

Si ces questionnements vous intéressent, la conférence d'Édouard Siha est un incontournable. Il rentre en détail dans les étapes de la compilation en Rust, en faisant une analogie assez pédagogique avec les profondeurs marines. Un deep dive très intéressant pour renforcer sa compréhension du Rust et de manière générale des différentes étapes de création d'un binaire exécutable.

MongoDB en scale-up : comment sortir d’un enfer monolithique par Alexis Chotard et Caroline Becker

Ce talk, c'est l'histoire d'une scale-up spécialisée dans la gestion de fiches de paie : PayFit. Le 15 mars 2023, leur cluster MongoDB s'écroule, alors qu'il contient 95% des données utilisateur et il est vital au fonctionnement de l'application.

A travers cette conférence, on découvre comment de mauvais choix d'architecture ou une croissance organique et (trop) rapide ont pu mener à une situation aussi critique. Heureusement, Alexis et Caroline nous expliquent également comment ils ont réussi à réparer leur application, entre stabilisation technique, détricotage du modèle de données, ou encore élimination de single point of failure.

Si on ne doit retenir qu'une chose de ce retour d'expérience, c'est qu'un modèle de donnée doit coller au métier et que la duplication doit être maitrisée. Ici, le principal problème était lié à des données redondantes et stockées en grande quantité, qui ont fini par saturer la base NoSQL...

RetEx : Optimisation du temps de démarrage d'une application Java Spring par Daria Hervieux

Daria Hervieux nous explique comment elle et son équipe ont étudié plusieurs manières de réduire le temps de démarrage d'une application Spring pour atteindre un taux de disponibilité de l'application à 99,9%

Elle nous livre donc les résultats des trois expérimentations effectuées :

  • Class Data Sharing (CDS) : cette technique permet de réduire le temps de démarrage et l'empreinte mémoire des JVM en mettant en cache les métadonnées de classes dans un fichier d'archive afin qu'elles puissent être rapidement préchargées dans une JVM nouvellement lancée.

  • Spring Ahead-of-Time (AOT) : sans aller jusqu'à la création d'image native, Daria nous explique qu'ils ont utilisé la technique de compilation AOT qui permet de pré-compiler le bytecode en code natif avant le démarrage de l'application. Le tout, s'exécutant sur une JVM traditionnelle.

  • CRaC (Coordinated Restore at Checkpoint) : cette technique repose sur le principe d'effectuer un checkpoint de l'état de l'application à un moment donné, puis de le restaurer à partir de ce checkpoint lors du redémarrage de l'application. Cela permettant notamment d'avoir les hotspots de l'application déjà chargés en mémoire.

Daria conclut par un tableau comparatif en termes de gain, inconvénients, taille de livrable... Pas de spoil ! Nous vous laissons découvrir le résultat de son étude dans le replay (quand il sera disponible) !

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .