GraalVM, ou l’espoir de faire passer Java à l’ère du serverless
Un an après son passage en production, GraalVM continue de faire des émules dans la communauté Java. En raison de ses capacités de compilation et d’interopérabilité, le projet est perçu comme le candidat idéal pour la modernisation de l’écosystème Java, à l’ère des microservices et du FaaS.
GraalVM, projet-cadre porté par Oracle Labs (anciennement Sun Labs) depuis 2012, est entré en production il y a un peu plus d’un an. La promesse de départ est belle : concevoir une machine virtuelle dite « universelle » capable d’exécuter du code dans plusieurs langages de programmation. Plus précisément, elle permet de lancer des applications écrites en Java, JavaScript, Node.js, C et C++ mais aussi en Kotlin, Ruby, R, Scala ou encore en Python.
Oracle a très rapidement présenté GraalVM comme une alternative au golang, imaginé par Google. L’objectif est de faciliter le travail des développeurs qui n’ont pas besoin d’apprendre un autre langage de programmation pour s’adapter aux architectures cloud natives. Pour cela, GraalVM rassemble plusieurs outils et librairies afin d’optimiser la compilation des binaires, augmenter l’interopérabilité des environnements Java avec d’autres langages et réduire la consommation en mémoire vive.
À ce titre, GraalVM s’est surtout fait remarquer pour GraalVM Native Image. Cette fonctionnalité repose sur plusieurs composants qui facilitent une compilation Ahead of Time (AoT). Il s’agit d’optimiser et possiblement supprimer les classes et dépendances JDK qui ne sont pas nécessaires à l’exécution via une analyse statique.
Cet utilitaire permet d’obtenir une image qui contient l’ensemble du code exécutable immédiatement pour les langages compatibles JVM. Les autres langages sont pris en charge via le Truffle Language Implementation Framework. Pour ces derniers, les développeurs ont implémenté une méthode de compilation Just In Time (JIT), plus classique.
GraalVM Native Image suscite l’engouement de la communauté Java. En effet, cette méthodologie doit permettre de réduire considérablement l’empreinte mémoire des exécutables, donc leur taille, et permet de lancer davantage de petites machines virtuelles. Dans cette optique, la JVM et ses composants sont remplacés par Substrate VM. Les exécutables natifs peuvent être utilisés avec OpenJDK, Node.Js, Oracle Database, mais aussi dans des environnements containerisés.
En ce sens, GraalVM devient petit à petit une pièce maîtresse des frameworks de microservices cloud natifs. Sur le site web du projet, les développeurs d’Oracle listent Helidon (mené par Oracle), Micronaut et Quarkus.
GraalVM, le terreau d’un écosystème vivace
Les communautés derrière ces projets veulent profiter des fonctionnalités de GraalVM et optimisent les runtimes applicatifs pour différents environnements et tâches. Ces frameworks doivent fonctionner sur site et dans le cloud et idéalement permettre une approche cloud hybride des développements applicatifs.
Emmanuel Bernard, ingénieur chez Red Hat et co-fondateur de Quarkus expliquait au MagIT le changement de paradigme entraîné par la compilation ahead of time, qui est selon lui un « virage technologique » pour Java. Le projet Quarkus de Red Hat est pensé comme un framework pour bâtir des applications web en exploitant GraalVM et Hotspot, pour les exécuter sur Kubernetes.
Interrogé par SearchAppArchitecture [propriété de TechTarget, également propriétaire du MagIT], Rich Sharples – directeur de la gestion des produits chez Red Hat – voit Quarkus comme un complément naturel pour les développeurs qui utilisent OpenShift et Kubernetes.
« Cette convergence est considérable et croissante et représente un marché clé pour Red Hat et IBM », déclare-t-il. « Cela concerne les organisations de tous les secteurs qui développent leur prochaine génération d’applications critiques ».
De leur côté, les développeurs du framework Spring Boot préparent Spring GraalVM native, un projet pour construire des applications Spring Boot sous forme d’exécutables natifs dans des environnements comme Docker. Le framework Micronaut Graal reprend peu ou prou le même concept.
« Avec les exécutables natives, le code est compilé en fonction de la plateforme sur laquelle il va fonctionner, par exemple un Linux containerisé. »
Alexandre VasseurHead of Solution Engineering SEMEA Tanzu, VMware
« C’est complètement surprenant si vous étiez là quand Sun Microsystems a lancé Java », confirme Alexandre Vasseur, Head of Solution Engineering SEMEA, Tanzu (Pivotal) chez VMware. Pour rappel, VMware est le propriétaire de la marque Spring et premier soutien de ce projet open source, après le rachat de SpringSource en 2009.
« Avec les exécutables natives, le code est compilé en fonction de la plateforme sur laquelle il va fonctionner, par exemple un Linux containerisé », détaille-t-il. « Nous pouvons ainsi optimiser davantage la couche d’exécution d’un microservice. Nous pouvons retirer certaines classes parce que l’environnement d’exécution est encore plus cloisonné qu’avant. […] C’est la bonne innovation pour tout ce qui est “functions as a service” [FaaS] », considère Alexandre Vasseur.
Selon le responsable chez VMware, GraalVM est un projet « en cours de standardisation » au sein de l’OpenJDK. Notons que l’édition communautaire de GraalVM repose sur OpenJDK version 11.08, tandis que la version entreprise s’appuie sur Oracle JDK 11.08.2. Pour rappel, OpenJDK est passé en version 15.0.
Certains projets de l’écosystème GraalVM sont plus avancés que d’autres, mais ils sont tous relativement jeunes. Quarkus a atteint sa version 1.7.2 en ce début du mois de septembre, tandis que Spring GraalVM native en est à la 0.08. Helidon est disponible en version 2.0 depuis la fin du mois de juin. La communauté de Micronaut propose, elle, le support des environnements de type AWS Lambda. GraalVM 20.2.0, sortie en août 2020 vient renforcer les langages en dehors de l’écosystème Java, dont Ruby et Python.
Réduire le coût d’exécution des microservices
« Tous les frameworks cités ont la même quête : celle d’optimiser l’empreinte sous-jacente des microservices. »
Alexandre VasseurVMware
« Tous les frameworks cités ont la même quête : celle d’optimiser l’empreinte sous-jacente des microservices. Nous avons un rôle à jouer dans l’optimisation de ces microservices qui sont de plus en plus nombreux. Si je dois en exécuter une centaine dans le cloud public et que je consomme 10 % de mémoire en moins, in fine cela a un impact bénéfique. Il y a une corrélation financière importante », assure Alexandre Vasseur.
« On s’attend à ce que le support des exécutables natifs soit un des grands chapitres de 2020-2021 afin d’optimiser Spring Boot pour les “functions as a service” ». VMware entend supporter cette fonctionnalité dans son portfolio applicatif Tanzu.
De son côté, Oracle a une approche différente : il propose une version commerciale de GraalVM, principalement doté d’un support sur site et dans le cloud pour ses clients. Cette Enterprise Edition est compatible avec les différents frameworks de microservices open source cités ci-dessus.
L’écosystème autour de GraalVM grandit rapidement, mais quand en est-il des cas d’usage ? S’il est encore difficile d’affirmer que son utilisation se généralise, de gros projets voient le jour. Oracle exploite lui-même le projet-cadre en production pour son service de monitoring dédié à OCI (Oracle Cloud Infrastructure). Twitter, utilise une seule brique : le « compiler ». Il lui permet d’optimiser des microservices écrits en Scala. « Cela nous permet d’économiser beaucoup d’argent et de ressources informatiques », a déclaré à plusieurs reprises Chris Talinger, Ingénieur logiciel chez Twitter.
Plus récemment, Lufthansa s’est exprimé sur son utilisation de Quarkus pour sa plateforme de SaaS (en mode cloud hybride) de planification de maintenance des avions : AVIATAR. Le framework lui aurait permis de réduire « significativement » les coûts entraînés par une centaine de microservices au moment de les migrer vers OpenShift sur Microsoft Azure.
