Une journée à DEVOXX

Vendredi 22 avril se déroulait le troisième et dernier jour de la conférence DEVOXX FR édition 2022. Et même si – il faut le dire – peu de femmes et peu de stagiaires s’y trouvaient, il n’empêche qu’il y en avait quand même bien une dans le lot, assez motivée pour écrire un petit résumé et ressenti à chaud de sa longue journée sur place. Mais avant tout, je tiens à repréciser les circonstances qui m’ont amenée à assister à cet événement de grande envergure.

Il se trouve que pas plus que tard que le 11 avril – 9 jours avant le début de DEVOXX –, Colin DAMON nous a proposé, à Alexandre GINESY et moi, de participer une journée à DEVOXX FR. Autant dire qu’il ne lui a pas fallu beaucoup d’effort ni d’arguments pour nous convaincre de venir. :p

9h30 « Vous reprendrez bien un peu de thé vert ? »

Et voici comment vendredi matin, je me suis retrouvée propulsée au Palais des Congrès, dans les allées de DEVOXX, entre les stands d’entreprises plus ou moins connues, aux côtés d’Alexandre. La liste des entreprises s’y trouvant est ici, mais celle qui a particulièrement retenu notre attention ce matin-là était Gitlab ! Après un détour au stand de viennoiseries/café/thé noir – pas de thé vert pour les devs, car c’est bien connu, un·e dev ça ne boit pas de thé vert –, nous nous dirigeons vers l’immense queue de goodies Gitlab pour tenter de récupérer des chaussettes violettes dans le style édition limitée McDo. Mais pas de chance pour nous : pour avoir des chaussettes, il faut un Golden Ticket Gitlab style Willy Wonka, et pour avoir ce Golden Ticket il faut absolument retirer un sac à dos DEVOXX. Mais la prochaine conférence va commencer, tant pis, un petit pin's aimanté fera largement l’affaire !

10h45 Microservices, DDD et bootstrapping pour faire un départ lancé – Laurent Guérin et Aurélien Brisard

Tout cela nous amène à 10h45, heure de la première conférence ! Ne connaissant que peu de speakers, je me laisse convaincre par mon compagnon de conférence d’aller faire un tour du côté de Microservices, DDD et bootstrapping pour faire un départ lancé. Pourquoi pas ? Après tout, il y a “DDD” dans le titre. Au pire, on sera perdus, au mieux on repartira avec une nouvelle compréhension. Ni une ni deux, on se lance.

S'ensuit, 45 minutes où je note sur mon calepin “AMQP ?”, “JAX-RS ?”, “DSL ?”, “mybatis ?”, “Spring Data JDBC ne permet pas d’utiliser des clés composites ?”. Je note aussi “Templates (Velocity Apache) + conf projet + Model → Telosys → clean code custom”. Mais ce que j'ai principalement retenu de cette conférence, ce n’est pas tant la notice d’utilisation de “Telosys”, que l’effort employé à essayer de rendre des templates par essence génériques, personnalisables au maximum.

Pour voir le replay.

11h45 Doctolib a besoin d'une base de données plus puissante. Ok, mais laquelle ? – Bertrand Paquet et David Gageot

À présent, direction le grand amphi bleu pour un benchmark de bases de données, présenté par Bertrand PAQUET et David GAGEOT de chez Doctolib. Dans ma tête je pense : « À quoi peut bien ressembler la réflexion de deux anciens salariés de Google ?  ».

Alors, voilà ce que j’ai compris : depuis 8 ans, Doctolib propose des rendez-vous médicaux à plusieurs millions d'utilisateurs en utilisant une base de données unique PostgreSQL (jusqu’à 250000 commits/sec en read). Sauf qu’avant le COVID, leur philosophie était “ça tient la charge si on fait fois 2 ? Ok ça va, le mur est assez loin, on s’en occupera plus tard”. Après le COVID, c’est devenu “ça tient la charge si on fait fois 10 ? Ok il faut qu’on s’en occupe maintenant”. Cependant, ils ne sont plus très loin aujourd'hui des limites physiques d'Aurora (PostgreSQL en service managé par AWS) et prévoient de grossir encore.

Une solution serait de découper l'énorme base de données, mais elle est écartée par l'équipe de Doctolib, trop attachée à la simplicité de n'avoir qu'une seule base. Alors la solution de repli : trouver une base de données dont la migration sera simple (peu de réécriture de code), pas trop chère non plus, et qui tienne la charge. Trois solutions sont passées au crible : Spanner, Yugabyte et Citus.

• Spanner (Google). Problème : Spanner ne supporte pas plus de 20 jointures *rires dans la salle* « Qu’est-ce que vous voulez ? Les développeurs n'ont pas trop réfléchi, ils ont fait des requêtes avec 21 join… ».
• PG + Citus + MX (MX option payante de Microsoft). Problème :  pas tous les join sont possibles (local vers distribué). Et ne tient pas la charge pour un million de petites queries.
• Yugabyte. Problème : c’est cher et pas d'autoscaling disponible (or Doctolib est seulement présente en Europe et n'a donc pas besoin d'instances la nuit). Mais l’option multi cloud (un nœud chez AWS, un autre chez GCP) n’en reste pas moins intéressante.

Conclusion : aucune des trois ne fait l'affaire. Toutefois c’est le côté legacy qui rend la migration difficile. Avec un projet from scratch, une des solutions pourrait rendre Doctolib 1000 fois plus rapide… En tous cas, fort intéressant et concret de rencontrer l’envers du décor de Doctolib.

Pour voir le replay.

12h30 « Ouf ! Il reste des sandwichs végé ! »

12h30 sonne, nous décidons d’aller casser la croûte avec le reste de la troupe ipponaise en allant sur notre superbe stand Ippon. Mais c’était sans compter l’activité Kahoot qui devait avoir réuni pas moins de cinquante personnes tout autour du stand, nous obligeant à manger debout, et observer l’agitation de loin avec nos gueuletons à la main.

De nos échanges ce midi-là, je retiens que : le DDD, c’est un sujet délicat. Un livre en particulier fait couler beaucoup d’encre, car chacun en fait son interprétation, ce qui donne naissance à beaucoup de désaccords et de partis pris, mais aussi de débats intéressants.

« Quelqu’un a dit Promyze ? »

« Mais du coup, Promyze, qu’est-ce que c’est ? »

L’idée c’est que certaines bonnes pratiques de coding au sein d’une équipe, sont parfois implicites et subtiles, et même lorsqu’elles sont explicitées lors d’une PR / MR, leur vie est de courte durée. Alors, pour que tout le monde profite de ces petits conseils qui rendent le code plus homogène et propre, et que cette connaissance soit capitalisée, Promyze propose de les répertorier directement dans l’IDE ou dans le navigateur, et d’échanger sur ces pratiques lors de craft workshops. Ensuite, des suggestions automatiques basées sur votre “banque” de conseils apparaissent sur vos PR !

À titre personnel, je pense que le produit vise dans le mille, mais qu’effectivement toute l'équipe doit être également convaincue par son utilisation. Alors je ne saurais que vous conseiller d’aller jeter un coup d'œil à leur site.

15h30 Comprendre le comportement des français, c'est possible grâce à la data chez Leboncoin – Stéphanie Baltus-Bergamo et Mathieu Coudert

Après Doctolib, compte à rebours lancé pour Leboncoin ! Et une fois n’est pas coutume, Alexandre et moi ne savons pas vraiment à quoi nous attendre pour cette troisième conférence. Néanmoins, c’est celle-ci que nous avons préféré, notamment grâce à la dynamique du duo qui présentait la conférence. Stéphanie BALTUS-BERGAMO (Data Lead) et Mathieu COUDERT (product owner) ont travaillé un an sur la plateforme Data LeBonObservatoire lancée en 2021. Celle-ci permet d'analyser les tendances de consommation des 29 millions d’utilisateurs par mois. Parmi ces tendances : l’automobile et l’immobilier. On peut par exemple y constater, l’essor des voitures électriques, la baisse des prix immobiliers dans certains secteurs à la suite de la crise du Covid, ou encore des ruptures de stocks de meubles IKEA.

Comme chez Doctolib, l’équipe s’est posée la question de quelle base choisir. Une base maîtrisée, pas trop chère (car il ne faut pas oublier que Leboncoin reste un service gratuit) et distribuée… Et c’est finalement Citus (surcouche de Postgre) qui a été retenue.

Par la suite, Stéphanie nous cite deux fonctionnalités bien sympathiques dont ils se sont servis :

• HLL (HyperLogLog) : top pour compter le nombre de distinct de manière approximative et performante avec un très faible pourcentage d'erreurs. Dans le cas présent, ce module était parfait pour compter le nombre approximatif de modèles de motos en vente sur leboncoin.
• Column storage :  permet de réduire la taille du stockage, mais aussi la taille des IO.

Une autre problématique mentionnée par les speakers : le traitement des données selon leur localisation géographique (géo data). Exemple : comment faire pour connaître le prix au m² dans une ville où l’on n'a pas d’annonces ? Mathieu nous explique que pour pallier ce manque d’informations, mais également pour “lisser” des données hétérogènes (car certaines villes regroupent plus d’appartements que de maisons ou concentrent plus d’habitations luxueuses par exemple), l’algorithme Max-p-Regions est utilisé sur les données. Le principe est que pour calculer un prix moyen dans une région, le prix moyen des régions adjacentes doit être pris en compte.

Un peu plus tard, Mathieu nous explique également comment il faut absolument se méfier des recherches des utilisateurs, lorsqu’on cherche à trouver des tendances de consommation à partir des mots-clefs : « Si dans cette salle, il y en a qui rentrent des emojis de mouton sur leboncoin, qu’ils se dénoncent svp » * rires dans la salle *.

Alors conclusion de tout ça ? Encore une fois, c’était une expérience très intéressante. Côtoyer un service célèbre, et toucher du doigt l’envers du décor est un vrai plaisir.

Pour voir le replay.

16h45 La fin des architectures en couches avec l’approche hexagonale – Benjamin LEGROS

Malheureusement, mes capacités de concentration se sont amenuisées au fil de la journée, et ce que je retiens de cette dernière conférence, c’est d’aller faire un tour du côté de Hexagonal Architecture de Alistair Cockburn, Spring Boot Java dans l'hexagone et Eviter les bugs et anticiper l’avenir de Colin DAMON.

Pour voir le replay.

Bilan personnel de cette journée

Même si cette journée au rythme frénétique de conférences et tombolas est bien fatigante il faut l’avouer, j’en garderai un très bon souvenir. Pour citer – à peu de choses près – mon compagnon de route ce jour-là : « C’est formidable de voir en chair et en os toute cette communauté de développeurs et développeuses, pas si différent·es que ça de nous finalement ». Car toute cette communauté d’entraide est absolument immense, et au même titre que nous, elle utilise au quotidien tout un tas de technologies, et ce faisant, rencontre tout un tas de problèmes semblables aux nôtres. Parfois même, elle se retrouve derrière des produits que l’on utilise au quotidien, que ce soit pour vendre ou acheter un vélo d’occasion, ou encore prendre un rendez-vous chez le médecin. Alors, même si toutes ces introspections dans tous ces projets ne me serviront probablement pas de si tôt, je n’en reste pas moins imprégnée de l’univers et je garde d’ailleurs à ce titre quelques clés en main pour plus tard (il semblerait que PG soit la référence, que l’archi hexagonale ait le vent en poupe, et que le code legacy se paie vraiment sur le long terme).

Enfin, je tiens à remercier Ippon de m’avoir permis d’assister à DEVOXX, une conférence ponctuée d'échanges enrichissants et conviviaux.