Devoxx est une conférence annuelle rassemblant des développeurs passionnés du monde entier et déclinée en plusieurs versions. Cette année avait lieu la 8ème édition de Devoxx France (du 17 au 19 Avril) et avait pour thème central le “Bonheur au travail et la bienveillance”. INEAT a pu une nouvelle fois couvrir l’événement, qui fut riche en découvertes.

Voici un retour sur nos 3 jours au Devoxx France 2019 et sur les talks qui nous ont marqués.

Une mécanique toujours bien huilée

Et on commence cette série d’articles avec la première journée, dédiée aux Universités. Pas de Keynote donc pour ce premier jour, mais principalement des conférences de 3 heures très complètes et illustrées par de nombreux exemples et live coding.

Comme à chaque édition et dès leur arrivée, les conférenciers sont guidés par le staff et les bagages pris en charge à l’entrée du salon (on se sent tout de suite plus à l’aise !). Café / viennoiseries nous attendent à chaque pause, et sandwichs au poisson, viande ou végétariens sont distribués le midi. On regrettera peut être un peu les sacs bleu, rouge ou vert des autres années contenant notre déjeuner, plus pratiques à récupérer durant les “heures de pointes”.

Première journée qui nous aura également permis de prendre nos marques sur les stands : nous avons pu ainsi échanger avec des membres de Pivotal, JFrog, Datadog, Eclipse Foundation et bien d’autres (et au passage emporter quelques stickers 😉).

 

Les talks et universités

FaaS and Furious : 3H pour devenir une star du serverless !

Speaker(s) : Philippe Charrière et Laurent Grangeau

Une des premières université du mercredi portant sur Openfaas, le projet d’Alex Ellis. Les speakers ont débuté le talk par une brève introduction présentant les généralités sur Openfaas et les notions de bases à avoir pour suivre le reste de la présentation (qui dit Function As A Service dit forcément…fonctions !). Le reste de cette université a été très orientée pratique et live coding, pour notre plus grand bonheur (rien de mieux que des exemples concrets pour se mettre dans le bain). La première démo fut donc l’installation, en quelques lignes de commandes, d’Openfaas sur MicroK8s et le déploiement d’une fonction basique. Openfaas fournit par défaut plusieurs templates de fonction pour Python, JavaScript, Java, Go ou encore PHP. Mais il est tout à fait possible de créer ses propres templates comme Philippe Charrière l’a démontré au cours de son second exemple en écrivant un template Express / Vue.js (l’occasion de nous prouver qu’Openfaas peut servir de l’HTML).

Pour la seconde partie la main passe à Laurent Grangeau, qui présentera comment installer Openfaas avec Helm, en respectant quelques bonnes pratiques de sécurité. Il nous parlera entre autres :

• des crons Openfaas
• des connecteurs, et notamment du connecteur Kafka qui permet de déclencher l’exécution d’une fonction lors de la réception d’un message depuis un topic
• du chaînage des fonctions (encore un peu artisanal)
• de la possibilité d’effectuer du Canary Deployment avec Istio
• de la possibilité de piloter Openfaas directement depuis Kubectl (en spécifiant le “kind” à “Function” dans le Yaml utilisé pour le déploiement)
• des exécutions synchrones ou asynchrones des fonctions (avec le mécanisme de callbacks)

Philippe Charrière reprendra la main pour la dernière partie du talk afin de nous présenter la mise en place de l’intégration continue de fonctions Openfaas avec Gitlab-CI. Il terminera en donnant quelques pistes sur le monitoring (point qui n’a malheureusement pas été détaillé faute de temps).

Nous avons donc démarré le Devoxx avec une université de très bonne qualité. Si vous souhaitez en apprendre plus sur le sujet et mettre en place un petit cluster pour tester la solution, nous vous conseillons la lecture de notre série d’articles.

Quarkus : pourquoi et comment faire une application Java Cloud Native avec GraalVM

Speaker(s) : Emmanuel Bernard et Clément Escoffier

Releasé il y a quelques semaines, le nouveau framework Java de Red Hat à fait l’objet d’une autre excellente université lors de cette édition du Devoxx France. Emmanuel Bernard et Clément Escoffier ont tout d’abord présenté les limites des modèles actuels : le fait que les temps de démarrage des applications Java est parfois long et par conséquent que cette technologie n’est pas vraiment optimale pour écrire des microservices Cloud Native ou bénéficier pleinement du Serverless (ou du moins du FaaS).
Quarkus est une réponse à ces problématiques, puisqu’il permet non seulement de réduire l’empreinte mémoire des applications générées mais permet aussi de diminuer les temps de démarrage.

Après avoir fait quelques rappels sur le cloud, les systèmes réactifs et l’optimisation mémoire, les deux speakers entrent dans le vif du sujet et illustre la puissance de Quarkus avec bon nombre de live coding. Nous avons pu voir que Quarkus pouvait générer très simplement des exécutables natifs taillés pour GraalVM, éliminer le code mort automatiquement et gérer le hot reload. La première application d’exemple ne “pesait” que 20MB et démarrait en quelques millisecondes ! Alors oui pour une application de type “Hello World” ce n’est pas forcément très révélateur, mais les autres démonstration nous ont définitivement convaincu :

• une application gérant de la persistance de données avec Hibernate / Panache prend 53MB et 123 millisecondes au démarrage.
• une application réactive en Vert.x manipulant des flux Kafka démarre quant à elle en 17 millisecondes et ne prendra que 36MB de mémoire.

Quarkus repose sur des outils connus (Vert.x, Hibernate, Kafka, …), fournissant ainsi un large panel de possibilités, mais comme nous l’avons constater il offre également des performances impressionnantes et ceci sans surcharger le code.

En effet ce dernier est allégé par l’usage d’annotations simplifiant l’écriture d’applications réactives : pour ce type d’applications Quarkus s’appuie sur Vert.x qui de base ne fourni pas d’annotation. L’usage de Vert.x est donc ici entièrement masqué et nous obtenons un code visuellement épuré. Le vrai point fort est la cohérence entre annotations : le passage d’une application statique a une application réactive est presque transparent (il n’y a qu’une propriété a changer).

Cette université s’est terminée avec la présentation des tests sur Quarkus et en particulier les tests natifs avec @SubnativeTest qui permet de s’assurer que les tests fonctionnant en mode JVM fonctionneront toujours en natif.

En conclusion nous pourrons retenir de Quarkus les avantages suivants :

• une stack complète pour le développement d’applications Cloud Native, reposant sur des briques connues
• possibilité de générer des exécutables natifs optimisés et démarrant très rapidement
• une surcouche d’annotations simplifiant la vie du développeur
• monitoring possible avec Prometheus
• bon nombre de connecteurs existant pour Kafka, RabbitMQ et bien d’autres.

Deux petits bémol cependant :

• encore des choses a ajuster, le projet est jeune et des correctifs sont régulièrement poussés
• la compilation en natif peut être un peu longue (80 % du travail d’optimisation étant effectué au build time)

Une nouvelle fois nous avons pu assister a une conférence de qualité, et qui nous aura donner envie de tester Quarkus !

La boite à outils Chaos Engineering du Javaiste

Speaker(s) : Sylvain Maucourt

Mercredi n’a pas été consacré qu’à des universités, il y avait également des tools-in-action de 30 minutes, qui nous ont permis d’en apprendre plus sur le Chaos Engineering et comment la mettre en place dans un écosystème Java.

Netflix fait office de précurseur dans ce domaine. Afin de s’assurer que leurs équipes d’infra étaient en mesure de corriger les problèmes, ils ont développé Chaos Monkey, un outil qui provoque volontairement des pannes en production, en faisant tomber des instances. En confrontant leurs équipes à des vrais problèmes de manière régulière, Netflix s’assure que les process de résolution de problème sont efficaces, connus et facilement applicable.

Cependant, ces outils sont très orienté infra. Comment pouvons nous avoir cette approche lors de nos développements pour assurer la robustesse de nos applications ?

Chaos Monkey for Spring Boot

Chaos Monkey for Spring Boot a été développé par Codecentric (qui était d’ailleurs présent pour une Université sur le DDD et CQRS le jour même) et s’inspire des travaux réalisés par Netflix, mais orienté logiciel cette fois.

Il suffit de rajouter une dépendance à son application Java, et de l’exécuter avec le profil “chaos-monkey” pour introduire du chaos dans son application. Des endpoints sont également mis à disposition pour modifier la configuration, ou bien activer/désactiver Chaos Monkey.

Ainsi, en fonction de sa configuration, on pourra, de manière aléatoire :

• introduire du délai dans les réponses fournies par l’applicatif
• déclencher des exceptions
• tuer l’applicatif

Ces assaults, peuvent s’appliquer à plusieurs niveaux :

• controller
• service
• repository
• component

Sylvain a mis en pratique ce type d’erreur, pour montrer l’intérêt des circuits breaker (qui sont forcément beaucoup plus simple à tester avec cet outil) et a implémenté Hystrix (lui aussi développé par Netflix).

Petite parenthèse “outil” : lors de ses démos, Sylvain a utilisé HTTPie, un outil remplaçant cURL bien plus facile et agréable à utiliser.

Toxiproxy

Toxiproxy est un autre outil qui peut être utilisé pour tester son application et la rendre plus robuste. Il sert de proxy et permet de dégrader volontairement les communications avec les API tierces qui sont utilisées par nos applications.

On peut ainsi :

• introduire du délai
• réduire le débit
• rendre un endpoint down
• simuler un timeout

Tests fonctionnels avec Docker et TestContainers

Speaker(s) : Vincent Massol

Vincent est le CTO de la société XWiki SAS qui développe la solution XWiki et contributeur de cette application permettant de gérer l’information au sein d’une entreprise. Il expose un problème lié à des tests fonctionnels qui doivent être réalisés avec la création de containers et montre comment après avoir essayer diverses implémentations, il a pu effectuer ces tests périodiquement (journaliers, mensuels, trimestriels en fonction des configurations) en utilisant la librairie “TestContainers”.

La contrainte est de valider le fonctionnement correct de la solution XWiki avec des configurations différentes, ce qui est amené à varier sont les types et versions des éléments suivant :

• base de données
• driver jdbc
• servlet
• navigateur

3 containers sont nécessaires, le premier pour le navigateur qui interagit avec le second contenant le moteur de servlet et XWiki et le dernier pour la base de données dans laquelle des informations sont inscrites par l’application.

En utilisant :

• les annotation JUnit5 (Custom Extension) pour paramétrer les différentes configurations
• un job Jenkins pipeline pour pouvoir itérer sur chaque version et permettre l’intégration des tests à la chaîne de CI
• TestContainer qui permet de piloter Docker pour la création des containers

Il est possible de vérifier le fonctionnement de l’application dans tous les cas d’usage et de disposer d’environnements à l’image de la production facilitant la résolution ou la reproduction de bugs.
TestContainer dispose de nombreux containers pour nginx, MySQL, PostgreSQL, ElasticSearch…
La librairie gère la création à la volée des containers et leur destruction, c’est entièrement compatible avec l’API Docker (docker-java), possibilité d’enregistrer une vidéo des tests pour vérification.

TestContainer semble très intéressant à utiliser dans les tests avec le nombre grandissant d’applications déployées avec Docker.

Micronaut, le framework JVM ultra-light du futur

Speaker(s) : Olivier Revial

Olivier nous présente le framework Micronaut initié par Grahem Rocher (créateur de Grails) et contributeur sur ce projet qui est très récent (version 1.0.0 en août 2018) actuellement en version 1.1. Le concept est de prendre le meilleur de Spring, SpringBoot, Grails en évitant les inconvénients.

Le positif :

• l’injection de dépendances
• l’auto-configuration
• service discovery dans un concept de micro-service
• embarquer client et serveur http

Le négatif :

• la reflection utilisée dans d’autres frameworks qui engendre des temps de démarrage long et empreinte mémoire qui est croissante en fonction du développement.
• problématique de la durée des tests (unitaires et intégration) avec le lancement de l’application qui peut être chronophage mais qui ne semble pas être le cas avec Micronaut (facilité d’intégration dans la CI).

 

Oliver annonce des temps de démarrage de l’ordre de la seconde pour une application de type “Hello world” et de quelques seconde pour une API.

Les développements peuvent se faire avec Java, Kotlin en se basant les annotations processeur pour le contexte et Groovy en utilisant les transformations AST et d’utiliser la compilation ahead-of-time pour se passer de la reflection ce qui permet :

• lancer le jar sur la JVM (type Oracle) qui permet une optimisation du temps de démarrage et l’empreinte mémoire.
• déploiement sur d’autre environnement, exemple donné avec GraalVM (Substrate VM avec du code natif) qui permettra d’améliorer les performances et permettant d’envisager du micro service en serverless.

Une démo est réalisée avec une petite application de type “Crawler” développée en Kotlin qui consomme l’API Twitter pour récupérer des tweets et expose des données au travers d’une API Rest en relation avec une base de données en MongoBD et qui est compilée avec Gradle.

Ce qui a permis à Olivier de nous donner d’autres informations comme :

• support natif du mode réactif (RxJava ou Reactor)
• la sécurité supportée nativement par Micronaut
• l’existence d’une liste de module (feature) Micronaut permettant de créer une application rapidement en mode CLI pour pouvoir intégrer par exemple un serveur http, un connecteur de base de données, etc.
• la taille du JARs qui reste modeste avec les différents modules et une allocation mémoire réduite (Xmx)
• le build d’une application type “Hello world” en natif mais qui prend du temps avec une image en binaire d’une taille plus importante mais au démarrage extrêmement plus rapide.

La conclusion donnée lors de ce talk, malgré la jeunesse du projet, Micronaut est prometteur en mode serverless et déjà utilisable avec des containers, en contrepartie des composants sont manquants par rapport à Spring Boot et le framework supporte partiellement Gradle donc pas d’utilisation en production pour l’instant mais c’est projet inspirant à l’instar de Quarkus.

Adoptez le “Swagger Driven Testing” pour tester vos API simplement

Speaker(s) : Jean-Baptiste WATENBERG

Les tests en tout genre que l’on doit mettre en place lors du développement d’applications sont un vaste sujet, ce talk présenté par un développeur travaillant à la Société Générale permet de découvrir une solution interne (swat) qui permet de répondre à des besoins pour assurer la qualité des APIs. Pour ce tool-in-action, Jean-Baptiste présente en premier lieu la plateforme de service et ces quelques 3500 APIs que le groupe bancaire utilise et comment les APIs ont été définies, générées grâce à l’écosystème de composants permettant ces opérations (swagger-codegen, swagger_ui, editor-swagger.io, etc).

On découvre ensuite comment les équipes de développement ont pu tester les APIs avec du code en utilisant par exemple le framework Frisby, en faisant appel à des applications comme Postman ou Insomnia ou avec Swagger UI tout dépend du profil qui doit réaliser les contrôles soit développeur, QA/BA ou utilisateur.
Pour simplifier et unifier les tests, a été développée une solution du nom de “swat” qui permet de réaliser des opérations en faisant des appels au travers de l’interface Swagger UI, il est ainsi possible de définir un parcours utilisateur en utilisant les différents endpoints de l’API, lors de l’enchaînement, des variables peuvent être utilisées pour contrôler la cohérence des données ou pour être transmises aux appels suivants. Une démonstration a permis montrer le fonctionnement en réalisant une succession d’opération de type CRUD.

Le projet devrait être open source et bientôt disponible, c’est une alternative possible pour tester son API, des évolutions sont prévues pour une intégration dans la chaîne de CI/CD.

Bilan de la première journée

Une première journée riche en découvertes qui fut la préquelle des deux suivantes, également de très bonne facture. La suite de notre debrief du Devoxx France 2019 sera disponible très bientôt. En attendant, quelques liens utiles pour patienter.

Liens utiles

• Debrief de notre première journée au Devoxx France 2019 (vous le consultez actuellement)
• Debrief de notre seconde journée au Devoxx France 2019 – https://blog.ineat-group.com/2019/05/devoxx-france-2019-jour-2/
• Debrief de notre troisième journée au Devoxx France 2019 – https://blog.ineat-group.com/2019/05/devoxx-france-2019-jour-3/
• Site officiel d’Openfaas – https://www.openfaas.com
• Premier article de notre série consacrée à Openfaas (installation)
• Second article de la série Openfaas (mise en pratique)
• Site officiel de Quarkus – https://quarkus.io
• Episode des CastCodeurs consacré à Quarkus – https://lescastcodeurs.com/2019/03/26/lcc-207-interview-sur-quarkus-avec-emmanuel-bernard/
• Site officiel de TestContainers – https://micronaut.io/
• Site officiel de Micronaut – https://www.testcontainers.org/