Supersonic Subatomic Java

A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
https://quarkus.io/

Quarkus est un framework full-stack Java natif pour Kubernetes, conçu pour les machines virtuelles Java (JVM) et la compilation native, qui permet d’optimiser Java spécifiquement pour les conteneurs afin d’en faire une plateforme efficace pour les environnements sans serveur, cloud et Kubernetes.
source : Quarkus.

Contexte

L’arrivée des architectures ‘Cloud‘, ‘Cloud Native‘ ‘Serverless‘ ont fondamentalement fait évoluer notre façon d’aborder nos infrastructures, les déploiements, la gestion des ressources. Dans un ancien monde, on achetait un gros serveur surdimensionné qui hébergeait 1 voir 2 applications. On anticipait les besoins en ressources mémoire, CPU, disque. On faisait des capacity planning, on provisionnait… Désormais ces architectures nous promettent de la scalabilité à l’infini, de l’immédiateté, ‘on demand’. Là où avant on faisait un gros chèque pour acheter un gros serveur avec des coûts fixes et donc maitrisés on bascule vers coût au consommé difficilement estimable et donc approximativement maitrisé/maitrisable. Ce qui est sûr c’est qu’il est nécessaire que les applicatifs soient opérationnels le plus rapidement possible en consommant le moins de ressources possibles.

Parallèlement à cela, depuis toujours j’ai lu/entendu des critiques sur JAVA pour sa lourdeur, son temps de démarrage, sa consommation mémoire excessive. Malgré les nombreuses évolutions, améliorations de la JVM, du JIT, l’écosystème JAVA ne semble pas le plus adapté au Cloud. D’autres plateformes type Node.Js, Go ont alors été très plébiscitées.

Mais ça c’était avant : désormais il y a Quarkus !

Principes

GraalVM est une machine virtuelle universelle développée par Oracle. Elle est polyglotte, supporte ainsi plusieurs langages mais surtout elle permet de générer des images natives avec pour but de réduire considérablement le temps de démarrage des applications ainsi que leur empreinte mémoire.

Quarkus utilise GraalVM et plus particulièrement sa compilation Ahead Of Time faisant un maximum de choses au moment de la compilation (build time). Ainsi Quarkus réduit le nombre d’opérations nécessaires au runtime, limite la quantité d’informations stockées dans le metaspace (suppression de JIT) et donc optimise le temps de démarrage.

Pour produire l’executable le plus frugal possible, au moment de la compilation, GraalVM fait l’hypothèse d’être dans un monde fermé : tout le code est accessible. De là tous les chemins de code, attributs, classes non utilisés sont supprimés : c’est l’élimination de code mort.

Avantages

Les caractéristiques de Quarkus qui nous ont séduites/intéressées :

Frugalité mémoire & Rapidité: Chez Aepsilon concevoir des solutions nécessitant peu de ressource est un véritable enjeu;
Fonctionne avec les normes, frameworks et bibliothèques Java les plus utilisés, tels qu’Eclipse MicroProfile,Spring, Kafka, RESTEasy, Hibernate. La montée est en compétence sur le sujet est très accessible;
Expérience de développement : Quarkus compile et recharge à chaud l’application en quelques centièmes de seconde. Pas besoin d’arrêter et de relancer.

Premiers essais

On va tester la techno sur un cas d’utilisation archi simple : notre bon vieux « HelloWorld » sous forme d’api rest. Pour cela, on va générer 2 projets: l’un réalisé avec Quarkus et l’autre avec SpringBoot et l’on va comparer. On va utiliser les technos « out Of The Box » en intégrant le minimum d’extension. Nous sommes conscients que la configuration des projets pourrait être ‘fine tunée’ pour améliorer les résultats mais l’objet de ces premiers essais est de nous donner un « ordre d’idée ».

J’ai fini par le build natif Quarkus (après installation de Graal, j’ai lancé ./mvnw package -Pnative) et je vous laisse découvrir les résultats :

C’est juste très impressionnant : démarrage en 0,02 secondes et consommation 18 Mo

Go / No Go

GO, GO, GO ! Quarkus arrive sur les bases d’un écosystème mature, puissant qui nous a donné envie de continuer à découvrir cette techno.

C’est pourquoi, nous prévoyons de :

Intégrer une couche de persistance de données et refaire le même exercice ;
Tester la sécurisation de l’API avec Keycloack ;
Tester GraphQL
….

Références / Liens

Partager cet article

Nous contacter Nous rejoindre

Consulter d'autres publications

10 ans chez æpsilon

Afterwork Fresque du Climat æpsilon

Quarkus avec Panache

SpringBoot	Quarkus
Génération du projet
https://start.spring.io/	https://code.quarkus.io/
Creation de la classe implémentant notre service Rest
	Il est déjà créé
Lancement en local
`./mvnw spring-boot:run` Test : `curl`	`./mvnw quarkus:dev` Test : `curl http:/localhost:8080/hello-resteasy` Rem.: La modification du code est pris à chaud !
Build du JAR et lancement
`./mvnw package java -jar target/helloworldspringboot-0.0.1-SNAPSHOT.jar` Le fichier est un ‘uber’ jar qui intègre toutes les dépendances	`./mvnw package` `java -jar target/helloworldquarkus-1.0.0-SNAPSHOT-runner.jar` Le fichier helloworldquarkus-1.0.0-SNAPSHOT-runner.jar est un jar executable mais pas un uber jar. Le répertoire lib intègre les librairies nécessaires.
Récupération consommation mémoire (Resident Set Size (RSS))
`ps -eo pid,rss,comm \| grep java` `50657 277024 /usr/bin/java`	`ps -eo pid,rss,comm \| grep java` `60306 138316 /usr/bin/java`
Conclusion
L’api rest springboot prend 277 Mo de RAM et démarre en 3 secondes 15	L’api rest quarkus prend 138 Mo de RAM et démarre en 1 seconde 03.

Introduction à Quarkus