Cette année, j’ai eu la chance d’assister à Devoxx France, j’ai même eu la chance d’être speaker et de donner deux talks (Mes premiers pas en deeplearning avec Keras et Arthas – Alibaba Java Diagnostic Tool ), mais ça je vous en parlerais plus tard 😉

Voici un petit compte rendu sur une partie des talks auxquels j’ai assisté.

 

Quarkus: Comment faire une appli Java Cloud Native avec Graal VM (E. Bernard, C. Escoffier)

Quarkus est un tout nouveau framework Java OpenSource, développé principalement par RedHat, pensé pour le développement de microservice à déployer dans le Cloud / dans des containers. A sa sortie il a suscité pas mal de question et semblais assez prometteur, c’est pour cela que j’attendais avec impatience l’université sur le sujet. J’avais d’ailleurs écrit un article sur Quarkus en cours d’écriture (sorti quelques jour après Devoxx), à lire si vous ne connaissez pas Quarkus : Zoom sur Quarkus

Emmanuel et Clément ont débuté par expliquer le pourquoi de la création de Quarkus : à l’ère des conteneurs, le temps de démarrage et l’empreinte mémoire d’une application sont aussi (plus) important que sa performance. Ce qui a mené à GraalVM qui est en rupture avec la manière dont Java fonctionnais avant. De plus, les applications cloud native ont des problèmes spécifiques qu’un framework doit couvrir : unreliability, autoscaling, …

Aujourd’hui, les applications passent d’une architecture monolithique à une architecture microservice voir fonction (serverless) : on a donc un morcellement des artefacts de déploiement de 1 monolithe à 20 microservices ou … 200 fonctions !

On a ensuite parlé de Responsive et du problème de communication HTTP entre services :  failures, limitation du système de callback (thread pool, erreur au client, retry storm), …

La JVM n’a pas été pensée au départ pour le cloud et le développement de fonctions (même si cela évolue) :

• La JVM a été faite pour maximiser le throughput et pensée multi-thread, multi-core
• La JVM est lente à démarrer (beaucoup de classes, bytecode verification, JIT warmup) : problème de warmup avant le pic de performance.
• Memory overhead (metadata, JIT, …) :  pb de Resident Set Size (RSS)  même avec une heap de 32Mo on peut consommer jusqu’à plus de 200 Mo, ce qui peut poser des problèmes à l’OOM-killer de Docker par exemple.

Quarkus est optimisé pour un nombre de requêtes par Mo consommé !

Quarkus a été pensé pour fonctionner en mode natif via SubstratVM (un des sous-projet de GraalVM). SubstratVM est une VM permettant de faire fonctionner des applications Java compilées Ahead-Of-Time (AOT) via l’outils native-image. Il ne contient pas de JIT, et a son propre GC.

SubstratVM vient avec ses propres limites :

•  Hypothèse de monde fermé : tout ce qui est dans le package est ce qui va être exécuté : supprime du binaire final de manière agressive toutes les classes inutiles (lib, JDK, …) via tree-shaking.
• Gestion des ressources : liste exhaustive donnée à native-image
• Reflection : chaque classe/méthode appelées via réflexion doit être définie en JSON dans un fichier de configuration
• Pas mal de chose pas supporté (voir les slides) ou manuel (à configurer pour native-image)

SubtratVM est compliqué à utiliser … et devient un cauchemar quand on a un écosystème complexe (framework !). C’est là où Quarkus nous rend service en gérant SubstratVM et native-image pour nous.

Quarkus est Subatomic :

• Dépendances pour l’exécution en natif : zlib, libc, (openSSL) => distroless !
• Optimisation conso mémoire => container friendly
• Utilisation des framework java apprécié … Bon, OK, chacun a son avis sur la question mais :  Vert.X, Hibernate, MicroProfile, RxJava, …
• Live reload sans limitation (remplacement de classloader) : stable et performant (200ms, moins au second reload)

Le principe : passer le plus de choses possible du runtime au compile-time, ce qui permet d’avoir un temps de démarrage plus rapide et nécessite moins de mémoire au runtime (car tout est pré-compilé en quelques sortes).

Quarkus n’utilise quasiment pas de réflexion, ce qui facilite aussi le travail du JIT.

Comment ça marche : lors du build (via plugin Maven ou Gradle), chaque extension va générer le code nécessaire pour son démarrage via le framework Gizmo. Quarkus a son propre moteur d’injection de dépendance : arc et réalise l’injection de dépendance au build via Maven/Gradle et pas via annotation processor (compliqué à configurer et scale mal par rapport au nombre de bean).

On a ensuite parlé de développement réactif en différenciant :

• Reactive Steam : réactif au sein d’un service
• Reactive System : messaging asynchrone entre service

Quarkus utilise Reactive Messaging de MicroProfile :

• @Outpoing : génère des messages dans un stream (RxJava par exemple)
• @Incoming : consomme un topic
• Pas de dépendances sur implémentation messaging (Kafka, RabbitMQ, …)
• Possibilité d’avoir un Emitter qui permet de générer un message depuis un appel HTTP par ex.
• A l’inverse possibilité de s’enregistrer comme consommateur d’un topic (@Stream) et de recréer des événements en reactive (via Server-Side-Event par ex.)

Pas mal de démos ont été faites pour montrer le fonctionnement du framework, on peut retrouver les sources de ces démos ici : https://github.com/cescoffier/quarkus-deep-dive

Lien vers la vidéo : https://www.youtube.com/watch?v=S05WsHJZsYk

 

Observabilité : mythes, réalité et Chaos (B. Gakic)

Tout d’abord, parlons de Monitoring.

Monitoring : test répété (par une machine) => nécessaire de connaître ce qu’on veut monitorer. On sais ce qu’on regarde, pourquoi on le regarde mais pas le quand.

Problème : ne pas détecter un problème !!!
Le Monitoring technique ne suffit pas => il nous faut un monitoring métier.
Question: qu’est qu’un bon indicateur => pertinent, utilisable, utilisé 🙂

Le Monitoring ne suffit plus à cause de la complexité des systèmes actuels. Il faut passer du monitoring à l’Observabilité !

Observabilité : un système est observable si son état est déduit de ses symptômes.
C’est la capacité du système à exposer des infos que l’on peut choisir d’exploiter et permettant appréhender son fonctionnement et ses état (pour les humain).
But : être capable de gérer les choses dont on n’a pas conscience et qu’on ne maîtrisent pas.

Observabilité : comment ? Manuelle ou automatique (OpenTracing par exemple).

Chaos engineering : permet de tester l’observabilité du système :

• expérimentation sur le système pour améliorer la confiance
• détecte les choses inconnues en maîtrisant le quand/comment
• sérendipité : découverte fortuite à partir de l’observation (ie la pomme de newton)

Plusieurs test de chaos engineering ont été réalisé par oui.fr.

Tout d’abord via Chaos Monkey : test basique (kill une instance) => pas de soucis mais problème d’observabilité.

Puis via Chaos Kong : arrêt complet d’un Datacenter !!! :

• Réalisé via la coupure du lien réseau !
• Plusieurs test effectués (date/heure définie puis date définie puis date inconnue)
• Tout s’est bien passé mais détection incorrecte (incident de réplication de BDD alors que le Datacenter n’était plus joignable)
• Mauvais diagnostique, latence d’alerte, problème de procédures
• Correction : utilisation de l’outils d’observabilité de Netflix : https://github.com/Netflix/vizceral

Leçon : la vérité est dans la prod => les dév doivent donc regarder la prod !!!

Pour finir, voici quelques définitions :

• Monitoring : permet de répondre à une question connue à l’avance.
• Observabilité : permet de répondre à une question que l’on ne connait pas.
• Test : valider le fonctionnement nominal d’une application.
• Chaos Engeneering : trouver ce qu’on n’est pas capable trouver avec les tests.

Lien vers la vidéo : https://www.youtube.com/watch?v=lV7zTJJOx1Y

 

Le Web, ses frameworks et ses standards : déconstruire pour mieux (re?)construire (H. SABLONNIÈRE

La Hype des frameworks web :  utiliser un framework web c’est mettre la solution avant le problème ? Parce que c’est cool ;), … parce que GAFA ?

• Réinventer la roue à chaque fois avec des frameworks différents
• Coupler son code au framework => dette technique
• Très problématique dans le monde web car l’écosystème évolue très vite

Ce que nous apportent les frameworks :

• Système de composants
• Templating
• Gestion du CSS
• Manipulation du DOM
• Server Side Rendering
• Router
• State Management

Avons-nous besoin de tous ça pour notre application ?

Ce que nous apportent les standards :

• Certain frameworks (jQuery) sont les prémices des standards du web
• WebComponents :
  • custom elements ~> système de composant
  • Shadow dom ~> système de composant (slot), gestion CSS (custom prop) ~> templating

Cas de la console de CleverCloud :

• Utilisation de storybook pour définir le front => permet de développer en isolation de l’application
• Utilisation de LitElement et LitHtml comme sucre syntaxique sur les WebComponent
• Réduire l’adhérence avec le global => gérer des événements
• Bon choix ? => on s’en fou car le coût est faible et l’adhérence aussi

Questionnement sur la Solution à un problème :

• Avant de prendre une solution : est-ce qu’elle répond au problème ?
• Approche pragmatique
• Utiliser les standard
• Ne pas coupler

Lien vers la vidéo : https://www.youtube.com/watch?v=uFxVH5mFAKg

 

The Boring Architecture, ou comment construire une licorne sur un monolith (M. Domenjoud et N. De Nayer)

Retour expérience de Doctissimo sur une architecture à contre sens de la hype !

Chiffre : 40k user/jour, 3000 req/s http, 17k req/s sur BDD (4To), 95th perc < 250ms. En augmentation de 20% tout les 2 mois avec un pic de charge au retour de vacances et chaque Lundi.

Architecture : un repo unique, une application en Ruby (Ruby on Rails), une BDD Postgres sur une machine très capacitive (scale in), 19 instances de l’application.

Quelques autres techno : elasticsearch et redis.

Organisation en feature team autonome, développeur full stack qui développe l’intégralité de sa feature.

Mantra : combattre la complexité => optimiser l’existant plutôt qu’apporter de la nouveauté !

Challenge : quand faut-il introduire un nouvel outil pour ne pas faire rentrer un rond dans un carré ?

Au vu de la croissance : impossible de faire des capacity planning à plus de 6 mois : les décisions sont prise quand un “mur” est détecté à moins de 6 mois. Chaque jour un développeur va observer les dégradations et décider si il faut ou pas prendre des actions correctives sur ces dégradations.

Toujours privilégier une solution simple à un problème : ex recherche full text qui ne marche plus trop sur Postgres : passage à Elasticsearch ? Non optimisation des indexes Postgres ! Un ans plus tard, même soucis , on arrive aux limite (nécessité de forker l’outils pour optimiser) => la solution la plus simple devient de passer à Elasticsearch !

Pas de cache applicatif : implémenté en 2 jours en test : faisable, donc décision de ne pas le mettre en production car apporte de la complexité et si nécessaire, … implémentable en 2 jours 😉

Pour le front : création d’une application complexe avec React et RxJs (hype du moment) => après l’implémentation, sur une équipe de 20 développeurs, seulement 2 maîtrisent le truc ! Ce qui pose un problème d’autonomie des équipes! => Back to basics ?

Points d’attention :

• Stack simple mais comme très optimisé seul quelques dev comprennent ces optims
• Nécessité d’être toujours sur le pont car peu de marge d’erreur
• Stack simple mais produit complexe découpé en 9 feature teams
• Monolithe et repo unique : tout le monde travail ensemble
• Nécessite point de contact entre toute les équipes régulier

Pour résumer :

• Extrême design émergent
• Fine tuning : architecture simple mais ultra optimisé
• Règles d’or : qualité non négociable mais pas de future-tuning, on s’interdit “et si jamais on doit”, “peut-être qu’un jour”, “c’est plus propre”
• Respecter nos principes

La vidéo n’est pas disponible sur la chaîne Youtube de Devoxx FR.

 

Real Quantum Computing (J. Birnie)

Très difficile de faire un résumé de ce talk, le sujet, est assez complexe …

Tout d’abord, qu’est-ce qu’un ordinateur quantique? Un ordinateur est un système qui représente l’information sous forme de 0 ou de 1 (les fameux bit) et va exécuter sur ces bit des opérations logique qu’on appelle « logic gate ». Un ordinateur classique va stocker ces bit sous forme de voltage différents tandis qu’un ordinateur quantique sous la forme d’un Qubit (Quantum bit) qui peut être implémenté par n’importe quelle particule atomique (electron, io, photon, …).

Les Qubit ont quelques propriétés particulières :

• Observer leur valeur effondre le qubit : on ne peut pas le sauvegarder
• La valeur réel d’un Qubit est un point dans une sphère qui va s’effondrer en un 0 ou un 1 à la lecture
• L’incertitude quantique induit des erreurs
• On a besoin d’un ordinateur classique pour programmer des Qubit

Il n’y a que peu d’ordinateur quantique existant, certains sont utilisable depuis le Cloud, certain même sont utilisable avec un quotas gratuit (IBM en a deux qui ont chacun 5 Qbit).

On peut utiliser un simulateur, mais celui-ci donne des résultats exacte alors que l’exécution d’un programme quantique ne donne pas toujours de résultats exacte à cause de la fameuse incertitude quantique : quand on flip un bit il n’est pas toujours flipped !!!

La programmation quantique est difficile car il n’y a pas  d’abstraction facile, les quelques frameworks qui existent sont encore très bas niveau, mais les possibilités sont grandes.

Lien vers la vidéo : https://www.youtube.com/watch?v=7J4tuIsbBfk

 

Performance tuning Twitter services with Graal and Machine Learning (C. Thalinger)

Suite du talk de l’année précédente : Twitter’s Quest for a Wholly Graal Runtime.

Dans ce talk, Graal est pour le Just In Time Compiler (JIT) uniquement.

Ce talk raconte comment Twitter, après avoir gagné du CPU et des cycles GC en passant de C2 (le JIT par défaut de Java) à Graal ,a encore plus optimisé ses JVM en tunant Graal via autotune, un programme qui permet d’automatiquement tester des paramètres JVM et sélectionner les meilleurs.

Les optimisations de performance  se font traditionnellement à la main : on modifie un paramètre, on test (idéalement en production), on décide si l’optimisation vaut le coup puis on re-modifie la valeur ou on passe à un autre paramètre. C’est un processus long qui ne scale pas à la taille de Twitter (milliers de services sur des centaines de milliers de machines).

Conséquence : beaucoup de système tournent de manière sub-optimale : argent jeté par la fenêtre, sans parler de l’empreinte écologique car chaque cycle CPU consomme de l’électricité !

Un algorithme de machine learning existe qui est capable de décider si une optimisation vaut le coût : le Bayesian Optimization qui est capable en quelques itérations de trouver un quasi-optimum.

Autotune : Bayezian Optimization as a service, basé sur Spearmint. On le configure avec les paramètres à faire varier, leurs bornes min et max et le métrique à évaluer (ici l’utilisation CPU).

L’équipe VM de Twitter a utilisé autotune pour trouver les paramètres idéals de configuration de Graal, ils ont tuner plus précisément les paramètres d’inlining. Il a été lancé sur une machine dédiée, avec des requêtes identique à la production, sur une période de 24h avec des slices de 30mn : a chaque slice l’algorithme de Bayesian Optimization était appelé pour décider quel changement à effectuer dans le slice suivant.

Résultat obtenu : 8% moins de CPU !

Pour comparaison, via hand tuning de ces paramètres, ils ont obtenu 2% moins de CPU que Graal non-tuné.

Avec C2 ils ont réussit à obtenir 4% moins de CPU en utilisant autotune.

Lien vers la vidéo : https://www.youtube.com/watch?v=2ucx0gs1dH0