Du 6 au 10 novembre s’est tenue la 16e édition de Devoxx Belgium, toujours au Metropolis d’Anvers en Belgique. Voici un retour sur quelques sessions que j’ai suivies lors de ces deux premières journées de Devoxx Belgium.
Les deux premières journées de Devoxx Belgium
Le lundi et le mardi sont consacrés à deux types de sessions :
- deep dive : des sessions de deux fois 75 minutes qui permettent d’approfondir dans le détail un sujet
- tools in action : des sessions de 30 minutes généralement sur un outil
Au vu du nombre et de l’intérêt des sujets proposés lors des sessions, il est souvent difficile de choisir mais un choix doit être fait. Cette année les sessions sont diffusées en streaming live via YouTube, ce qui permet notamment de voir des sessions alors que la salle est pleine.
Testing Java Microservices
Alex Soto et Andy Gumbrecht nous proposent une session sur le sujet de leur livre à paraître prochainement chez Manning.
Les tests évoluent : tests manuels, tests automatisés, test first, TDD et BDD, service de virtualisation et CDC et test en production. Différents types de tests sont présentés : unitaires, de composants, d’intégration, de contrat, de déploiement et test en production.
Certaines parties de la session s’appliquent à tous projets :
- Tests unitaires avec doublures en utilisant JUnit, AssertJ et Mockito
- Tests de composants avec Arquilian
- Tests d’API REST avec REST-assured
Mais d’autres sont plus spécifiques aux micro-services :
- Service virtualization avec HoverFly : utilisation d’un proxy pour capturer les appels à un service qui est une dépendance (capture mode) pour simuler les réponses lors des prochaines requêtes (simulation mode)
- Persistence tests avec Arquillian APE
- Tests d’intégration utilisant des conteneurs pilotés par Arquillian Cube
- Contract tests avec Pact Foundation
- Tests de déploiement avec Fabric8 et Arquillian Cube
- Smart testing
- Blue/green deployment
- Canary release
Collectors in the wild!
 |
José Paumard nous détaille l’API Collectors, incluse dans l’API Stream mais généralement méconnue. C’est une API riche, assez complexe et extensible. Sa session est illustrée avec des démos en live coding et il nous distille quelques bonnes pratiques sur sa mise en œuvre :
|
Java9 and REPL. Forget debugging, welcome joy and productivity
Jakub Marchwicki nous présente JShell, un outil de type REPL (Read Evaluate Print Loop) livré avec Java 9. Après quelques slides, l’essentiel de la session est du live coding pour présenter les différentes fonctionnalités de JShell.
Prometheus Monitoring for Java Web Applications w/o Modifying Source Code
Une session par Fabian Stäber qui aurait sûrement mérité plus de temps, dans une conférence, pour aller plus en détail dans le sujet plutôt intéressant.
L’idée est d’envoyer des métriques à Prometheus pour monitorer une application web.
La première approche présentée est intrusive car elle utilise l’API client de Promotheus dans le code. Cette approche n’est pas toujours possible.
La seconde approche consiste à développer un agent qui sera pluggé sur la JVM. Elle utilise ByteBuddy pour manipuler le byte code et ajouter l’exécution de code utilisant l’API client de Prometheus.
Bien sûr si une solution de monitoring est déjà présente il ne faut pas la remplacer, notamment si elle repose sur JMX, mais le concept est intéressant. Il pourrait notamment être utilisé pour d’autres besoins.
Baking a Microservice PI(e)
Antonio Goncalves et Roberto Cortez construisent au fur et mesure une petite API utilisée par une application Angular en introduisant à chaque itération une problématique et une solution possible, parmi de nombreuses, pour au final développer une API basique qui soit scalable, résistante aux pannes et sécurisée dans un cluster de 24 Rasperberry Pi.
Ce qui leur permet d’introduire certaines fonctionnalités et solutions utilisées dans leurs démos : MicroProfile (JAX-RS, CDI, JSON-P), Swagger, CORS, JBoss Wildfy Swarm et TomEE, Docker (Registry et Swarm), Ansible, Netflix Feign/Hystrix/Ribbon, Logstash/Elastic Search/Kibana avec Gelf dans Docker, HashiCorp Consul, TribeStream.
Je partage complètement la conclusion d’Antonio et Roberto relative aux nombreuses problématiques liées à la mise en œuvre des micro services : ce type d’architecture n’est pas adapté à tous les besoins et à toutes les applications.
Bien sûr, les micro services ont des avantages :
- Livrer des fonctionnalités plus rapidement
- Fournir ces fonctionnalités sous la forme de service
- Des équipes plus petites et plus agiles
- Permettre la montée en charge de chaque service indépendamment
- …
Mais la mise en œuvre de micro services est complexe :
- Doit s’intégrer dans l’infrastructure de différents environnements
- Plus il y a de technologies et/ou de langages de développement, plus c’est complexe
- L’environnement doit être régulièrement mis à jour (OS, JVM, …)
D’autant que de l’aveu même d’Antonio et Roberto, ils n’ont pas abordé les sujets qui piquent vraiment : les bases de données (une pour chaque service), des règles métiers complexes, la complexité du réseau, la redondance du load balancer et du registre, pas d’événements asynchrones, ni de tests d’intégration, ni de limite d’utilisation des API, …
Exploring Java 9: The Key Parts
|
Venkat Subramaniam nous propose sous son format habituel qui repose sur du live coding d’explorer les principales nouvelles fonctionnalités de Java 9 réparties en trois catégories :
|  |
Comparison Method Violates Its General Contract! – Part 1 and 2
 |
Deux sessions par Stuart Marks particulièrement intéressantes sur un sujet qui peut sembler connu et bien maîtrisé : la comparaison d’objets en Java en utilisant les interfaces Comparator et Comparable. Il est très important que :
Stuart nous propose quelques démos avec des exemples qui peuvent paraître justes mais qui en fait lèvent une exception de type IllegalArgumentException avec le message « Comparaison method violates its general contract ». Notamment, un cas fréquemment rencontré pour comparer deux entiers simplement en faisant leur soustraction. Dans la seconde partie, Stuart détaille les nouvelles fonctionnalités introduites en Java 8 dans l’interface Comparator pour faciliter sa mise en œuvre. Il nous rappelle aussi que compare(a,b) == 0 n’implique pas obligatoirement a.equals(b) == true. |
The Do’s and Don’ts with Java 9
Robert Scholte, le responsable du projet Maven d’Apache, nous propose de partager sa vision des modules de Java 9 sous l’angle Maven :
- Le choix des noms des modules qui doit pouvoir contenir des chiffres
- Automatic module names : une bibliothèque ne devrait pas faire référence à un automatic module (warning par Maven 3.5.0+)
- Ne pas changer la structure d’un projet Maven en Java 9 car un projet Maven ne produit qu’un seul module : le descripteur de module peut être mis à la racine des sources du projet
- Pas de scope particulier pour les dépendances dans les projets Java 9
- Remplacer source/target 1.9 par <release>9</release>
- Tous les projets ne seront pas facilement modularisés : utiliser le classpath qui est toujours présent
- Maven ne générera pas de module-info : les fichier pom et module descripteurs ont des rôles distincts
- Nettoyer régulièrement les dépendances des pom : des dépendances peuvent être exclues, les modules requis ne le peuvent pas
Ces deux premières journées sont comme toujours à Devoxx, intenses et instructives. N’hésitez pas à aller voir les vidéos sur la chaîne Devoxx de YouTube de ces sessions ou des autres auxquelles je n’ai pas pu assister.