Et c’est reparti pour une deuxième journée au DevoXX !
Jeudi 13 Avril
Le matin
CRAC vs GraalVM
Animée par Lilian BENOIT, la vidéo
Quelques rappels sur comment fonctionne la JVM et pourquoi dans le monde du Cloud et du container, le problème de Java, reste le temps de démarrage pour monter rapidement des instances et répondre à des problèmes de scalabilité. Par la suite petit rappel sur la compilation native avec GraalVM qui permet de répondre à ses besoins « modernes » mais qui ne sont pas sans certaines contraintes.
Lilian nous a donc présenté le projet CRaC (Coordinated Restore at Checkpoint) qui étudie la coordination des programmes Java avec des mécanismes permettant de contrôler (créer une image, un snapshot) une instance Java pendant son exécution. Il semblerait que la restauration à partir de l’image pourrait être une solution afin de palier à certains des problèmes liés aux temps de démarrage et de warm up. Ainsi Crac propose une nouvelle API pour informer les programmes Java des événements de point de contrôle et de restauration.
#RetourAuxSources : Le cache HTTP
Animée par Hubert SABLONNIÈRE, la vidéo
Quel plaisir d’assister aux conférences d’Hubert, c’est un orateur né et qui sait parfaitement garder l’attention de son public. En plus d’être pointu, il est très pédagogue et captivant.
Donc cette fois-ci Hubert nous a parlé du Cache HTTP. En plus, bien évidemment, de revenir sur les avantages que présente le cache sur les performances de nos applications web, il a mis en avant certaines incohérences du protocole HTTP avec les directives de l’entête Cache-Control, en particulier la directive « no-cache » qui ne veut pas dire pas de cache :).
Hubert nous exposa toutes les subtilités que nous met à disposition le protocole HTTP pour gérer des caches à différents niveaux, permettant d’éviter certains pièges et de pouvoir bien optimiser la performance du rendu de nos sites web.
L’après-midi
5 ans de bien et de moins bien avec Kafka
Animée par Nelson Dionisi et Matthieu Mouminoux, la vidéo
Cette conférence est un REX sur l’utilisation de Kafka, ils nous ont présenté comment ils ont mis en place une première version fonctionnelle, quelles ont été les difficultés qu’ils ont rencontrées en terme de gestion des topics Kafka, des impacts que cela a pu avoir sur la gestion des micro services et des problèmes de gestion des messages pour analyser les bugs/problèmes et enfin comment optimiser et découpler.
Le besoin peut sembler plutôt simple fonctionnellement, une gestion de commande d’articles et une gestion du catalogue (donc des stocks).
Au démarrage, leurs client s’inscrivent et un topic leur est dédié. Ce topic permettra d’envoyer des messages à un micro service de gestion des stocks selon, entre autre, le besoin de passer une commande ou de l’annuler. Cette approche fonctionne, seulement plusieurs soucis remontent lors de l’utilisation au quotidien :
- Chaque fois qu’un nouveau client s’inscrit, ils doivent créer un topic dédié au client, il faut donc modifier la configuration de Kafka et le nombre de topics augmente.
- De plus les consommateurs de messages ne sont pas dédiés sur une seule fonctionnalité (mise à jour de l’inventaire ou une annulation de commande) et cela devient donc des programmes gérant plusieurs tâches fonctionnelles.
En synthèse les étapes qu’il ont eu sont:
- Gestion de Topic mono-tenant « fourre tout », un Topic par client et donc gestion de différent types de messages. (au sens fonctionnel) sur un même Topic. Le nombre de Topic est grandissant en plus d’avoir un Topic a créé pour les nouveaux clients et le code des micro services qui produisent et consomment ses messages sont multifonctionnels car ils gèrent différents type de message.
- Gestion de Topic fonctionnel multi-tenant, un topic par tâche fonctionnelle et chaque client est abonné à ses Topics, plus de création de nouveau Topic lorsque un client s’inscrit et les micro services qui produisent et consomment ces messages sont dédiés et spécialisés fonctionnellement (cela évite le code spaghetti).
- Puis une troisième itération aura lieu afin de gérer la perte de message et la reprise de message car la reprise peut vite devenir un sacerdoce avec l’augmentation de message qui posent problèmes et sont repris systématiquement.
En synthèse, ils nous montrent qu’il faut toujours pouvoir démarrer et mettre les services en place, on ne peut pas avoir forcément la bonne solution du premier coup. Il faut donc se servir de l’expérience en production pour analyser, comprendre et améliorer le système au fur et à mesure, que ce soit en terme d’architecture, de développement et d’exploitation.
Gestion de la dette d’architecture dans un contexte d’hypercroissance
Animée par Cyril Beslay, la vidéo
Cyril a fait un REX sur l’évolution des besoins d’architecture chez ManoMano et donc de la gestion de la dette technique au quotidien. Comment développer et architecturer le SI de son entreprise sans tomber dans le dogmatisme et relever les défis du quotidien.
Car bien évidemment la gestion de l’architecture au jour le jour ne dépend pas que des contraintes technique et des patterns théoriques à mettre en place, d’autres facteurs entre en compte comme:
- Le budget, la solution idéale peut couter trop cher donc on choisi une alternative moins couteuse mais créatrice de dette.
- Le métier et ses deadline, on peut, pour des raisons de business, avoir besoin d’aller très vite mais cela entraîne aussi des choix architecturaux dégradés qui vont vite créer de la dette.
- Cela peut être aussi un manque de recul sur les technologies mises en place par les architectes et les développeurs et donc une implémentation qui demande à être revu.
- Cela peut être aussi lié à l’évolution des outils/Framework qui introduisent des problèmes de performances et/ou de sécurité et donc qui demande à être revu régulièrement
Cyril nous expliqua donc comment il gère cette dette technique au quotidien, comment il met des outils en place pour avoir une vue de la dette à l’instant T, ce que coûte chaque action à mettre en place pour résorber cette dette et donc de prioriser au quotidien les travaux d’améliorations.
Il n’y pas forcément de vérité vraie, mais il ne faut pas se voiler la face devant l’accumulation de dette (ce qui est en un sens normal d’en avoir et d’en accumuler) mais surtout comment faire au quotidien pour gérer cela de façon pragmatique en tenant compte de tous les acteurs (le management, le métier, les architecte, les développeurs, les OPS…)