Voxxed Days Microservices est un événement centré exclusivement sur les Microservices. Durant cette seconde édition, deux jours de conférences et un jour d’atelier (en option) auront lieu à Paris du 21 au 23 octobre 2019.
Les lecteurs d'InfoQ peuvent profiter d'une promo de 20% avec le code VXDMS19_COM_INFOQFR lors de l'inscription.
InfoQ s'est entretenu avec Emmanuel Bernard au sujet de sa session intitulée "Quarkus pourquoi, comment et quoi".
Bonjour Emmanuel, dis-nous qui tu es et qu'est-ce qui t'a amené vers les microservices?
Bonjour, je suis Java Champion, ingénieur distingué et architecte en chef des données chez Red Hat. La plupart de mes travaux sont Open Source (middleware). Je suis surtout connu pour mes contributions et mon leadership dans les projets Hibernate. Mon entreprise la plus récente est Quarkus.
Je suis venu aux microservices par la plate-forme. Les microservices ne sont possibles que parce que les développeurs ont maintenant accès au bon niveau d'abstraction à partir des plateformes sur lesquelles leur application est hébergée. Nous disposons de plates-formes très agiles, telles que Kubernetes ou le «Cloud», qui nous permettent d’augmenter ou de réduire immédiatement la scalabilité, nous permettant d’exprimer de manière déclarative la structure que nous souhaitons avoir pour notre topologie d’application.
Mon point de vue historique sur les Microservices est celui des données qui restent l’un des problèmes les plus difficiles à résoudre dans une architecture de type microservices. Alors que chaque microservice est isolé et doit posséder son datastore, une communication entre eux est nécessaire pour que les données de l'organisation puissent circuler.
De quoi parles-tu à Voxxed Days Microservices ?
Je parlerai de Quarkus, une nouvelle stack applicative Java moderne spécialement conçue pour les microservices ou ce que l’on appelle souvent Cloud Native. Quarkus est le fruit des efforts plus vastes déployés par Red Hat autour de Kubernetes et des conteneurs, de l'activation des architectures de microservices et de la place de Java dans ce tableau.
Nous avons vraiment travaillé sur les problèmes d'espace et traité les problèmes principaux. Le lancement de Quarkus a largement dépassé nos espoirs les plus fous et il semble qu’il réponde aux attentes que la communauté Java a connues depuis longtemps.
Comment Quarkus se compare-t-il aux bons vieux serveurs d'applications Java EE ? Il semble que GraalVM soit le différentiateur ici. Y a-t-il d'autres différences ?
Quarkus a 4 axes principaux que j'appellerais des différenciateurs
Mémoire et temps de démarrage
Il veut résoudre le problème de temps de démarrage et de consommation de mémoire de Java. Java en tant qu'écosystème (JVM + frameworks) est une excellente plate-forme, mais son temps de démarrage est relativement lent (prohibitif pour les fonctions de service FaaS) et son coût en mémoire «fixe» est élevé. Lorsque vous écrivez et déployez 20 microservices au lieu d'un monolithe, ces problèmes sont exacerbés.
Quarkus résout ces problèmes en démarrant les infrastructures au moment de la création plutôt que lors du démarrage. C'est une énorme amélioration du temps de démarrage mais également une amélioration de l'utilisation de la mémoire.
Le second aspect est que les applications Quarkus peuvent être compilées dans un exécutable natif grâce à Substrate VM (composant de GraalVM). Cela va encore plus loin dans les améliorations au moment du démarrage et l’utilisation de la mémoire.
Quarkus consomme alors 2 à 10 fois moins de mémoire qu'une pile alternative classique. L'une des grandes innovations de Quarkus consiste à limiter autant que possible le travail d'amorçage effectué par l'écosystème de frameworks Java au moment du démarrage. En tant que communauté, Java a utilisé (abusé de) la nature dynamique de la plate-forme (scanning de classe, réflexion, proxys dynamiques, etc…) et Quarkus offre 99% de cette flexibilité sans compromis en termes de mémoire et de temps de démarrage.
Plaisir du développeur
Dès le départ, nous voulions aider les développeurs à faire le job très rapidement. Nous apportons une offre de recharge en direct tel que node.js, comme l'expérience du code et l'actualisation instantanée. Nous simplifions la redondance de la configuration et ajoutons des fonctionnalités au-dessus des frameworkss ou des normes connus pour aider à traiter beaucoup plus facilement 80% des cas d'utilisation. Je vais donner deux exemples iconiques:
- vous n'avez besoin que d'un seul fichier de configuration dans Quarkus (pas de persistence.xml, log.properties, beans.xml, etc.)
- Nous proposons Hibernate avec Panache, une couche au-dessus de JPA et Hibernate ORM, qui simplifie la rédaction d'entités, de référentiels et de requêtes pour les cas d'utilisation courants.
Le Live Reload est un grand départ par rapport à Java EE et son modèle de packaging et de déploiement sous la forme de war, mais également de toute application Java compilée, empaquetée et démarrée entre chaque modifications.
Meilleures bibliothèques et normes
Vous avez déjà 5 ans d’expérience avec Quarkus. Les API que vous utilisez pour écrire une application Quarkus sont les API des frameworks et normes que vous aimez et que vous utilisez : Camel, Hibernate et JPA, RESTEasy et JAX-RS, etc… Elle repose alors sur le vaste écosystème que Java EE a laissé s'épanouir.
Bon, à bientôt alors
Je suis vraiment enthousiasmé par Quarkus et le virage massif que prend l'écosystème Java avec le bootstrap au moment de la compilation et la compilation anticipée. Pour moi, il s'agira d'une vague d'innovation encore plus importante que celle que les @annotation ont apportées à Java 5. Et, plus important encore, cela ramène Java dans une excellente position dans le Cloud Native, où il était à la traîne par rapport à des plates-formes comme nodejs et Go.
Twitter : https://twitter.com/emmanuelbernard
Blog : https://emmanuelbernard.com/blog/
GitHub : https://github.com/emmanuelbernard/