Quarkus est un framework Java open source permettant le développement d’applications Java cloud natives et fonctionnant avec les standards Java les plus couramment utilisées (JPA, Hibernate, RESTEasy, JAX-RS, Apache Camel, …). Il fonctionne nativement avec Kubernetes, OpenJDK, HotSpot et GraalVM, un JDK hautes performances concu pour accélerer l’execution d’applications Java (entre autres).
Lorsque Quarkus et utilisé avec Open JDK, il offre un temps de démarrage et une consommation mémoire plus faible qu’avec, par exemple, Spring Boot. Cependant, Quarkus dévoile tout son potentiel d’optimisation lorsqu’il est utilisé avec GraalVM et notamment GraalVM Native Image. Cette fonctionnalité offerte par GraalVM, permet de créer une application standalone optimisée.
Au travers de cet article, vous allez découvrir l’utilisation de Quarkus avec GraalVM, les points forts, les fonctionnalités disponibles mais aussi quelques limitations de la solution.
La norme Microprofile
Quarkus se base sur la norme Microprofile 4, issue du monde JavaEE (JakartaEE). Elle définit un ensemble de standards nécessaires à la mise en place d’applications Java dans une architecture Microservice. On retrouve par exemple :
- Config : gestion de la configuration
- Fault tolérance : mise en place de coupe-circuit pour une architecture microservice résiliente
- Health : supervision d’indicateur sur l’état de santé de l’application
- JWT RBAC : prise en charge de l’authentification OAuth 2
- Metrics : indicateurs systèmes et fonctionnels de l’application
- Open API : définition et documentation d’interface REST
- Open tracing : monitoring et traçage des appels entre microservices
- Rest client : définir le webservice REST
En voyant cette liste, vous pensez très probablement à Spring Boot.
Quarkus VS Sprint Boot : Pourquoi Quarkus ?
Spring Boot est très établi dans le paysage des microservices Java, il est donc légitime de se poser la question : pourquoi choisir Quarkus ? Quarkus est conçu pour répondre à la problématique de la conception d’application cloud native optimisée. L’équipe de développement de Quarkus a fait le choix de compiler les applications en code natif via GraalVM Native Image. En effet, cette technologie permet de compiler à l’avance le code Java vers un exécutable autonome, appelé image native. Le programme qui en résulte a un temps de démarrage plus rapide et une surcharge de mémoire d’exécution plus faible par rapport à une JVM Cette approche permet d’obtenir des résultats impressionnants :
- un temps de démarrage extrêmement rapide, 17ms pour une application REST basique
- une empreinte mémoire réduite, 24Mo pour une application de base
Les performances à l’exécution restent cependant identiques à celles d’une application Java classique. Les performances de consommation de mémoire et de démarrage sont dues à :
- L’absence de classloading
- L’absence de code interprété
- L’absence de JIT et CPU Profiling
- La génération d’une image de la Heap durant le build
- L’absence de métadonnée sur les classes chargées
Voici un aperçu des résultats obtenus en local :
Un framework extensible
Quarkus a une autre grande force, il est extensible et de nombreuses extensions existent. Certains éditeurs se sont spécialisés dans la production de celles-ci, à l’instar de SmallRye.
Ces extensions permettent d’ajouter des fonctionnalités à Quarkus ou de supporter certains protocoles et outils fréquemment utilisés dans les applications Java:
- Spring Data JPA
- Spring Cloud Config
- Vert-X
- Kafka
- Flyway
- SmallRye OpenAPI
- Des dizaines d’autres…
Si vous en avez le besoin, il est également possible de créer vos propres extensions.
Doit-on migrer vers Quarkus ?
L’architecture microservice a une grande force, le langage/framework utilisé n’a que peu d’importance tant que les interactions sont normées et que les microservices sont compatibles avec cette norme. Il n’y aura donc aucun souci à faire cohabiter des microservices Spring Boot et Quarkus
Vous pouvez développer tout ou partie de vos nouveaux microservices avec Quarkus afin de bénéficier de ses qualités. Par exemple, un service qui doit être particulièrement scalable profitera du temps de démarrage très faible. Même s’il peut paraitre intéressant de migrer vos microservices existants, cette tâche peut s’avérer longue. Prenons l’exemple d’un microservice Spring Boot, il faudra :
- Trouver les composants équivalents à ceux utilisés avec Spring Boot
- Vérifier que ces mêmes composants fonctionnent correctement avec GraalVM Native Image
- Adapter le code afin d’utiliser les nouveaux plugins Quarkus
Utilisation de Quarkus
Il est temps de passer à l’expérimentation. Comme vous le verrez, l’utilisation de Quarkus ne vous dépaysera pas si vous êtes, par exemple, un habitué de Spring Boot.
Installer GraalVM pour Quarkus
Quarkus aura besoin de GraalVM pour compiler l’application en code natif. Il est donc nécessaire de l’installer avant de commencer sur Quarkus. Télécharger GraalVM depuis le site https://www.graalvm.org/ Pour MacOS:
- Il est nécessaire de déplacer graalVM dans les machines virtuelles de la JVM :
sudo mv graalvm-ce-java<version>-<version> /Library/Java/JavaVirtualMachines - GraalVM doit également être ajouté dans le Path de la machine :
export JAVA_HOME=/Library/Java/JavaVirtualMachines/<graalvm>/Contents/Home) - GraalVM a également besoin d’une image native pour le système :
gu install native-image - Pour compiler Quarkus en application native il suffit de lancer maven avec le profile native :
mvn clean package -Pnative
Pour Windows:
- Dezipper GraalVM dans un répertoire par exemple :
C:graalvm-ce-java<version>-<version> - Ajouter la variable d’environnement
GRAALVM_HOME=C:graalvm-ce-java<version>-<version> - Installer la native-image avec la commande
C:graalvm-ce-java<version>-<version>bingu install native-image - Installer le support pour la compilation native en C avec Visual Studio 2017 Visual C++ Build Tools téléchargeable via ce lien
- Suivant le type d’architecture que vous avez ( x86, x64, ARM, and ARM64), il faut lancer un .bat pour parametrer le type de compilateur. Exemple pour x64:
C:Program Files (x86)Microsoft Visual Studio2017BuildToolsVCAuxiliaryBuildvcvars64.bat. Vous trouverez plus d’informations via ce lien.
Pour compiler Quarkus en application native il suffit de lancer maven avec le profile native :
mvn clean package -Pnative
Définir une API Rest avec Quarkus
Si vous utilisez d’ores et déjà Spring Boot pour développer des microservices, vous ne serez pas dépaysé. Prenons l’exemple avec la définition d’une API REST.
Le fonctionnement est similaire que ce soit pour :
- L’injection de dépendance avec CDI (Context Dependency Injection), équivalent de Spring Core
- La définition des requêtes HTTPs par annotation
Bien que CDI et Spring soient différents, le passage d’une technologie à l’autre est relativement indolore puisque les frameworks utilisent des concepts proches. Vous définissez votre ressource avec l’annotation
@Path et le verbe HTTP par annotation (@GET, @PUT …) sur chaque méthode. Voici un exemple :
Persistance de données
Vous ne serez pas perdu avec Quarkus, la persistance se fait au travers de JPA. Cette norme est très répandue dans bon nombre d’applications. Nous sommes très habitués à l’utiliser dans le développement d’applications et d’outils Java.
Logging
Quarkus est compatible avec les principaux frameworks de logging du marché :
- java.util.logging
- Jboss Logging
- SLF4J
- Log4J
- Appache common logging
En interne, Quarkus utilise le Jboss Logging, par conséquent, vous pouvez l’utiliser sans ajouter de dépendance. Dans le cas contraire, il sera nécessaire d’ajouter une dépendance. Pour de plus amples informations à ce sujet, je vous invite à lire la documentation.
Pour le tracing, il vous sera probablement nécessaire d’encoder les logs en JSON, il existe l’extension 
quarkus-logging-json pour répondre à cette problématique :
Pour l’activer, vous devez ajouter une propriété dans le fichier
src/main/resources/application.properties :
Filtre HTTP
Les filtres HTTP via annotation sont des éléments indispensables afin d’implémenter certaines fonctions transversales d’une application web telles que la sécurité ou le monitoring.
Bien que Quarkus se base sur une stack JavaEE, les annotations @WebFilter ne sont pas incluses dans le Framework. On retrouve cette fonctionnalité dans l’implémentation Quarkus de RestEasy Reactive. Cette implémentation propose deux annotations pour effectuer cette action :
- ServerRequestFilter : pour le filtrage de requêtes entrantes
- ServerResponseFilter : afin de filtrer les réponses du serveur
Pour cela, il faut importer :
Dans l’exemple suivant, nous allons voir l’utilisation des deux annotations.
Dans notre exemple, la première annotation nous permet de filtrer les requêtes entrantes et d’extraire ou créer les informations de tracking. Le device identifier permet d’avoir un identifiant unique par client et le correlation id permet d’avoir un identifiant par session fonctionnelle. Toujours dans cet exemple, la seconde annotation permet de modifier le header de la réponse pour y ajouter le correlation id.
Concepts avancés et limitations de GraalVM Native Image
GraalVM Native Image permet une optimisation de l’application sur deux points principaux :
- Le temps de lancement
- Une empreinte mémoire faible
Contributions SPI
Les interfaces SPI sont au cœur de beaucoup de frameworks (CDI, JPA, CXF, …). Cette fonctionnalité permet de définir une interface et de déclarer les implémentations dans un fichier portant le nom de l’interface stocké dans META-INF/services. Dès lors, il est possible de charger les implémentations via le service loader. Par exemple si on définit une interface Obfuscator du type :
Il est possible de la déclarer dans le fichier /META-INF/services/com.smartwave.quarkus.spi.obfuscators.Obfuscator
Pour charger l’extension il suffit d’utiliser le service loader :
Ce code fonctionne sans problème sur une JVM classique. Pourtant ce type d’usage ne sera pas fonctionnel sur Quarkus avec GraalVM Native Image. En effet, une des limitations de GraalVM Native Image est l’absence de classloading.
Alors que le même code fonctionnera en mode Developpement (sans GraalVM Native Image):
Ce détail révèle une information importante : il ne faut pas avoir une confiance aveugle dans le mode développement lorsque vous avez pour objectif de générer votre livrable avec GraalVM Native Image. Seuls les tests avec la version native peuvent nous garantir le bon fonctionnement de l’application.
Proxification
Le proxy est un des design patterns important. On le retrouve dans tous les ORM, frameworks d’IOC et d’injection de dépendances tels que Spring ou CDI. En Java il y a deux façons de créer des proxies :
- en utilisant les proxies Java. Ces proxies sont cependant réalisables uniquement sur des interfaces. Nous ne rentrerons pas dans le détail de cette méthode.
- en utilisant une librairie tel que CGlib ou Byte buddy. La plupart des frameworks sont basés sur CGlib (Spring, Hibbernate ou Weld CDI pour ne citer qu’eux).
Proxification CGlib
CGlib permet la création de proxy sur des objets réels. L’utilisation est très simple, il suffit de définir un Enhancer en lui donnant la classe à proxifier et un handler pour traiter l’interception.
Ici GraalVM refusera de compiler l’image native. Une erreur est affichée dès la compilation:
L’utilisation de CGLib n’est pas possible avec GraalVM Native Image.
Comment contourner cela ?
L’extension Hibernate pour Quarkus utilise ByteBuddy pour effectuer sa proxification. Cette approche est donc à privilégier, bien que son utilisation soit beaucoup moins intuitive et répandue que CGLIB (référence : ProxyBuildingHelper.java)
Si vous souhaitez en savoir plus sur les limitations de Quarkus, je vous invite à consulter cet article plus complet sur le sujet.
Conclusion
Quarkus avec GraalVM Native Image permet d’optimiser grandement le temps de démarrage et la consommation mémoire. Aujourd’hui, beaucoup de solutions ont été trouvées pour faire fonctionner des frameworks très variés (CDI, JPA, Jax-RS, etc. … ) et la grande majorité des fonctionnalités natives Java sont fonctionnelles. Il existe toutefois encore certaines limitations.
La conception d’application avec Quarkus demande de porter une attention particulière sur les librairies incluses. L’ajout de certaines librairies externes peut en effet aboutir à des erreurs lors de la génération ou l’exécution de l’image.
Globalement, il est préférable d’utiliser Quarkus et GraalVM Native Image pour de nouveaux microservices qui nécessitent une optimisation des ressources. La migration d’applications existantes sera couteuse et le coût sera probablement supérieur aux bénéfices retirés dans une grande majorité des cas.
