dans Programmation 101
Quarkus pour faciliter le déploiement de Java dans le cloud
Le 15 juin dernier, c’était ma fête 😀 Mais c’était aussi le premier événement du Java User Group (JUG) de Québec. C’est une grande fierté pour moi pour pouvoir participer à cette communauté et j’aimerais profiter de cette tribune qu’est notre blogue pour présenter le sujet de la conférence, en sommaire. Félix Roberge de Red Hat nous a présenté brièvement un nouveau produit dans l’écosystème de Java qui permet de faciliter grandement le déploiement dans le cloud. Je vous présente donc aujourd’hui Quarkus.
Présentation et historique
Lorsque je dis que Quarkus est un produit assez récent, on parle de mars 2019 pour la version 0.12 et novembre 2019 pour la version 1.0. Aujourd’hui, nous sommes à la version 2.0 en mode release candidate. En gros, Quarkus permet de faciliter le déploiement de code Java dans Kubernetes en améliorant grandement son empreinte mémoire et la taille des artéfacts. Le framework fonctionne de pair avec OpenJDK de HotSpot qui améliore les performances notamment grace à de l’optimisation adaptative et de la compilation just-in-time. Il vient aussi de pair avec GraalVM pour rendre le tout natif et sans dépendances.
Mais Sylvain, Spring Boot fait la job, non?
Oui. Mais le problème est au niveau de la consommation de la mémoire des applications Java, et aussi de la taille des artéfacts produits par la compilation. De plus, il faut une image docker avec une version spécifique de Java pour pouvoir exécuter le code, et si on veut changer la version de Java, on doit refaire notre image Docker… pas très Kubernetes-ready!
Comment performe Quarkus ?
J’avais des doutes aussi… mais faut l’essayer pour le voir! Rendez-vous sur le générateur de projet Quarkus, développez une API simple avec une BD H2 et lancer le tout. Voici un exemple :
Un contrôleur
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
@Path("/projects") @RequestScoped public class ProjectController { @Inject private ProjectService projectService; @GET public List<Project> findAllProjects() { return this.projectService.findAllProjects(); } @POST public Project createProject(Project project) { return this.projectService.createProject(project); } } |
Un service
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@ApplicationScoped public class ProjectServiceBase implements ProjectService { @Inject private ProjectRepository projectRepository; @Override @Transactional public List<Project> findAllProjects() { return this.projectRepository.listAll(); } @Override @Transactional public Project createProject(Project project) { this.projectRepository.persist(project); return project; } } |
Un dépôt
|
1 2 3 |
@ApplicationScoped public class ProjectPanacheRepository implements ProjectRepository { } |
Temps de démarrage pour Quarkus avec HotSpot JVM : 1,852 s
Puis, refaire le même exercice avec Spring Boot et lancer : 3,46 s
Taille du JAR pour Quarkus : 11,3 Kb
Taille du JAR pour Spring Boot : 43,1 Mb
Conclusion
Avec un temps de démarrage 2 fois plus rapide et un artéfact ridiculement plus petit, Quarkus me semble un bon framework pour limiter la consommation innutile de ressources cloud. Dans l’exemple ici, Quarkus roule en mode normal, mais il est aussi possible de construire une image Docker directement ou encore une image native pour GraalVM. On parle alors ici de temps de démarrage de l’ordre des millisecondes, soit 100 fois plus rapide que Spring Boot! De plus, sans avoir expliqué le code ci-dessus, je suis convaincu que tous les lecteurs adeptes de Spring Boot on compris le code.
Merci pour votre précieux temps 🙂 À plus!
Commentaires
Laisser un commentaire