DevFest 2019 !

Le DevFest s’impose petit à petit comme la conférence technique majeure des Hauts-de-France. Organisé par le Google Developer Group (GDG) Lille, c’est une journée où se succèdent des talks sur différents thèmes : cloud, développement mobile, web, …

De notre côté, c’était une participation un peu plus active que d’habitude, car Salto Consulting était sponsor bronze de l’événement. Il s’agit d’une aide financière en échange d’une visiblité du logo de l’entreprise sur les visuels, de la com’ sur les réseaux sociaux et la possibilité de fournir un goodie dans le sac offert à chaque participant. Chose faite :

Lunettes Salto Consulting

Le Kinepolis de Lomme était le décor pour cette année. On peut y voir sans doute le signe que l’événement prend de l’ampleur et que le nombre de participants est en constante augmentation. En tout cas, il est vraiment très appréciable de suivre des sessions confortablement installé dans un fauteuil de cinéma. Et on peut imaginer la joie ressentie par le speaker lorsqu’on voit ses slides projetés sur un magnifique écran géant ! Jugez un peu :

Slides sur écran de cinéma

A 9h15 commence la keynote d’ouverture. Pierre Ziemniak nous raconte l’historique des séries françaises depuis la création de la télévision. On y découvre quelques pépites oubliées, notamment un extrait de la série « Commando Spatial », datant de 1967 et faisant référence à Star Trek. C’était une keynote sympa pour lancer la journée.

Voici le résumé de quelques conférences auxquelles nous avons pu assister.

 Des microservices aux migroservices

Beaucoup de monde dans la salle pour cette session par François Teychené. Quoi ? Un talk sur les microservices en 2019 ?
François revient dans un premier temps sur les inconvénients liés aux monolithes : livraisons lentes, scalabilité difficile, complexité d’évolution.
Les gains attendus des microservices : évoluer plus vite, faciliter la scalabilité. MAIS la complexité est toujours là notamment à cause des interactions entre les services sur le réseau… non en fait, c’est encore plus complexe qu’avant !

François nous donne alors la définition du migroservice : c’est quand on essaie de faire une architecture microservice sans avoir prévu l’outillage nécessaire. Additionné à la démarche DevOps, le nombre d’outils qui peuvent entrer en jeu est impressionnant : Traefik, Consul, Vault, Kubernetes, Kafka, RabbitMQ, AWS, GCP, Docker…

On revient sur la notion de bounded context et le fait qu’il faut définir correctement les limites des microservices ! Le découpage des services doit être métier et non technique, et surtout il doit suivre les cas d’utilisation (ventes, catalogue…) plutôt que les entités (client, produit). Tiens tiens, on a déjà évoqué ces sujets ici-même à propos de l’architecture modulaire 😉

Enfin François insiste sur l’importance d’automatiser toutes les tâches afférentes aux microservices (déploiement…). En bref une bonne conférence qui fait écho aux problématiques d’architecture distribuée que nous rencontrons tous les jours.

 Kubernetes – Pimp my laptop

Sébastien Nahelou est aux commandes pour ce talk visant à améliorer la productivité à propos de l’utilisation de Kubernetes. Ce n’était clairement pas un sujet pour débutants : nous avons parcouru beaucoup de choses en 45 minutes. Pour commencer, voici en vrac les outils évoqués :

  • kubectl-aliases : série d’alias pour la ligne de commande
  • kube-PS1 pour bash et zsh : permet d’afficher le cluster et namespace courants dans le terminal
  • kubectx et kubens pour switcher rapidement de cluster et de namespace
  • k9s : interface dans le terminal pour manager les clusters Kubernetes
  • tubekit facilite certaines tâches courantes, comme récupérer le nom d’un pod sans devoir « copier-coller »
  • kube-score analyse le yaml et donne des indications de bonnes pratiques
  • kubesec effectue des vérifications de sécurité des ressources d’un cluster kubernetes
  • kubetail aggrège et affiche les logs de plusieurs pods simultanément
  • helm-unittest : sorte de tests unitaires sur les charts Helm
  • kubectl explain (commande standard) permet de récupérer la documentation et le format du yaml dans le terminal

Au niveau des bonnes pratiques quand on écrit la configuration Kubernetes, Sébastien nous encourage à utliser les options kubectl –dry-run -o yaml : en effet cela permet de récupérer un ficher yaml propre sans devoir l’écrire à la main… beaucoup sont allergiques à ce format et c’est vraiment une astuce à suivre !

Sébastien nous fait ensuite une démo en mettant en application les astuces données.
On découvre alors l’outil Telepresence. Celui-ci permet de substituer un service déployé sur un cluster distant par un service local… en d’autres termes, le poste de développeur peut prendre la place d’un élément du cluster déployé afin de faciliter le développement et le débug. ça a l’air hyper utile et aurait mérité davantage de temps.

Enfin (!) Squash permet de débugger dans son IDE une application déployée sur Kubernetes. Ici aussi l’outil fait forte impression.

Vous l’aurez compris avec ce résumé, c’était un talk très rapide avec énormément de tips & tricks concrets autour de Kubernetes. Il fallait suivre mais c’était très enrichissant.

Cela montre également que l’écosystème autour de Kubernetes n’est pas très mature. On a besoin de beaucoup d’outils pour pouvoir travailler efficacement.

 Doom, gloom or loom

Rémi Forax était là pour nous parler du projet Loom ! Intéressant d’écouter un contributeur à différents projets autour du JDK (et accessoirement Java champion). On commence par les différences entre du code impératif et réactif avec des exemples en Spring. Le souci du code réactif étant la difficulté à débugger le code, les traces étant illisibles.

Le projet Loom introduit l’objet Continuation qui permet des arrêts / redémarrages dans du code impératif. Plusieurs Continuation peuvent tourner au sein d’un même thread mais pas en parallèle.

Rémi nous montre l’utilisation du mot clé async en Kotlin et ses limites, notamment par le fait qu’on doit déclarer explicitement les fonctions qui peuvent être bloquées avec le mot clé suspend. Et cela a tendance à créer deux mondes distincts. Rémi fait le parallèle avec les exceptions en Java, où les exceptions de type checked sont délaissées car contraignantes.

Autre objet introduit par loom : Fiber. C’est un objet similaire au Thread. La différence majeure est que quand il est suspendu, l’état du fiber est enregistré dans la JVM, et peut être repris plus tard. Par rapport aux threads traditionnels, on réserve beaucoup moins de mémoire car seules les choses utilisées sont stockées dans le heap quand l’exécution est suspendue.

Le projet Loom n est pas encore finalisé et il sera officiellement dans Java en… on ne sait pas !

Un talk très sympa, bien touffu pour ne pas s’endormir après la pause déjeuner 🙂

Il faut sauver le soldat Jenkins

Nicolas De Loof nous parle de Jenkins X. Ce n’est pas « juste » un jenkins sur kubernetes. Ce n’est pas non plus un jenkins amélioré ou visant à remplacer l’original.

Jenkins X is not...

Jenkins X est un outil opinionated ce qui signifie qu’il fait des choses automatiquement quand on fait les choses « comme tout le monde ».

Explication du Terme GitOps : Git est la seule source de vérité, que ce soit pour le code, l’infrastructure ou le déploiement. On va par exemple avoir un repository pour versionner les templates de déploiements Helm pour Kubernetes, les push sur ce repository sont analysés par un pipeline jenkins X et sont exécutés.

Nicolas nous fait ensuite une petite démo. Jenkins X s’installe sur un cluster Kubernetes. Pour sa démo il utilise l’outil en ligne de commande jx.

jx create quickstart : initialise un projet « hello-world » dans le langage/framework de notre choix. Jenkins X utilise ensuite le mécanisme de buildpack : par rapport à notre stack technique, l’ensemble des fichiers nécessaires à un déploiement par Docker sur Kubernetes sont initialisés (Dockerfile, templates helm…)
Quand on soumet une Pull Request sur GitHub, l’outil déploie automatiquement la version correspondante de l’application.

Contrairement à un Jenkins traditionnel, Jenkins X est plutôt fait pour être administré par la ligne de commande. On comprend avec la démo que Jenkins X est en effet très orienté : il permet d’aller très vite dans un cadre précis, mais on se pose la question de son utilisation si on veut déployer d’une façon spécifique.

A voir, je pense qu’il faut vraiment l’essayer pour se faire une idée. Il peut sans doute faire gagner beaucoup de temps à condition de ne pas faire des choses exotiques.

 Micronaut, le framework JVM ultra-light du futur

Olivier Revial nous présente ce framework que l’on a déjà évoqué sur notre blog.
Micronaut a pour but de prendre le « bon » des frameworks existants, tels que Spring, tout en s’afranchissant des contraintes de lourdeur.

Olivier nous affiche une démo de la création d’une application Micronaut avec la ligne de commande. Avec une configuration très légère on peut facilement interagir avec une base MongoDb en mode réactif, exposer un endpoint HTTP. Les métriques sont exposées simplement via la configuration.

Enfin on évoque GraalVM pour compiler des images en mode natif. La compilation est beaucoup plus longue, plusieurs minutes, mais l’application démarre en 30ms!

Olivier conclut sur le faut que Micronaut est un framework jeune, mais dont l’adoption est croissante. La faible consommation mémoire peut aider à aller vers le serverless.

De notre côté, on aime beaucoup ce framework. Mais entre les améliorations constantes apportées à Spring notamment sur les performances, et Quarkus qui est supporté par RedHat et va plus loin dans sur le concept « Java natif », il a du travail pour conserver une place de choix dans cet écosystème.

 De Java à un exécutable natif : GraalVM et Quarkus changent la donne

Emmanuel Bernard et Guillaume Smet sont sur scène pour nous parler du gros buzz du moment dans le monde Java : Quarkus. La philosophie de Quarkus est de cibler les applications cloud native, déployées sur le cloud.

On rentre tout de suite dans le vif du sujet avec une application web. Emmanuel lance l’application en mode dev qui permet de rafraîchir le code à chaud, sans devoir redémarrer. Ce mode apporte une vraie plus-value car c’est super rapide, on ne se rend pas compte du rechargement en arrière-plan.

On voit ensuite le système d’extensions qui permet d’ajouter des composants à notre application (connexion à la base, parser JSON…) via la ligne de commande.

Sur les développements d’API HTTP, l’interface swagger-ui est activée par défaut en mode développement avec l’extension OpenAPI, très pratique pour tester rapidement son API HTTP.

Au niveau de la Developer Experience, on est assez proche d’un Spring Boot mais plus conforme aux standards JEE (par exemple, notons l’utilisation de Jax-RS pour définir les routes HTTP plutôt que des annotations spécifiques).

Emmanuel fait un apparté sur Java et les containers : Java date des années 1990 où les programmes étaient généralement lancés sur un seul serveur, dans un seul process. Avec l’explosion du cloud, les ressources consommées par les applications deviennent critiques.
Attention à la confusion souvent faite : en Java, la RAM consommée n’est pas du tout équivalente à la taille max du heap (la fameuse option -Xmx). En réalité le resident set size (RSS) est très élevé sur les applications JEE/Spring y compris quand le heap est petit.

RSS size in Java

Du coup, l’accent est mis sur la consommation mémoire et le temps de démarrage de Quarkus en mode « natif », avec GraalVM. Les chiffres donnés sont plutôt impressionnants !

Guillaume évoque alors plus en détail GraalVM et son fonctionnement. La compilation en mode « natif » élimine les classes non utilisées. Comme on utilise très peu du code embarqué par les librairies, cela permet d’économiser énormément de mémoire.

La démo est assez impressionnante. Nous sommes de notre côté déjà convaincus que Quarkus est un outil incroyable et tout développeur Java devrait s’y intéresser.

Comment la GCP m’a permis de sauver ma prod chez Mamie

Sylvain Nieuwlandt commence par nous démontrer comment basculer son infrastructure vers GCP pour… gagner de l’argent.

Ensuite on voit comment débugger en live une application déployée sur GCP grâce à Stackdriver. Avec quelques modifications dans les fichiers de propriétés, et avec les fichiers de code déployés sur GCP, il est possible par exemple d’injecter du log à chaud en production.

Suit ensuite une démo de l’application modbile « Cloud console ». C’est une application Android/iOS qui permet de se connecter à la plateforme GCP. Bien sûr on n’a pas accès à tous les services comme sur l’interface web, mais un shell est disponible. Ici Sylvain nous montre comment redéployer des machines virtuelles en production depuis son téléphone.

Cette conférence était assez fun et enrichissante sur certaines possibilités de Stackdriver notamment.

 En conclusion

Le DevFest devient un événement incontournable et ce n’est pas par hasard. L’organisation est très bien huilée, et malgré le nombre grandissant de participants cela reste d’une grande fluidité. Voici une photo de l’espace principal au cours de la journée pour rendre compte de la foule (photo de Damien Cavaillès) :

du monde au devfest...

Du côté des conférences, c’est très varié et de qualité. Le fun est également présent avec la keynote de clôture à la sauce Burger Quizz.
Un grand bravo aux organisateurs pour leur travail !

On reviendra avec plaisir en 2020 !