Hier soir, le 5 Avril 2022, ont eu lieu deux présentations autour de Quarkus, au Ch'ti JUG Decathlon Campus à Villeneuve d'Ascq:
Quarkus Microservices - one stack, infinite possibilities par Clément Escoffier (@clementplop sur Twitter)
Ecrire ses Operators Kubernetes en Java par Sébastien Blanc (@sebi2706
sur Twitter)
Première partie: Quarkus Microservices - one stack, infinite possibilities
Historique
Clément Escoffier commence sa présentation en parlant un peu Histoire, celle des applications, souvent sous forme monolithique. Elles tournaient en général sur un serveur dédié, où toutes les ressources leur étaient dédiées, leurs déploiement étaient longs et douloureux, et le scaling était compliqué.
Puis, s'ensuivit leur “évolution logique” : les microservices. Plus petits, moins couplés, avec un cycle de release court. Cependant on se retrouve avec un système distribué, qui apporte d’autres complexités.
Serverless
On a vu ensuite se développer un découpage encore plus fin: le serverless. Avec comme gros avantage le Scale to 0. Mais afin qu’un utilisateur ait une expérience décente, il faut démarrer vite !
Clément Escoffier nous énonce une analogie qui aura fait sourire: “Java dans un container, c’est comme mettre un lion dans une brouette, c’est rigolo mais ça peut être dangereux”. Et il nous explique que le langage à évolué dans ce sens (celui des containers, du serverless et du cloud), mais pas forcément l’écosystème. Quarkus est une réponse à ce manque.
Quarkus
Comment Java peut-il être Cloud native ? en permettant de faire des microservices et du serverless, des systèmes distribués qui impliquent beaucoup de fonctionnalités (Kafka, DB, Rest, Graphql, authentification…)
Quarkus est fondé sur deux principes: le temps de build et le réactif.
Ici Clément Escoffier, nous explique comment Quarkus gagne au temps de démarrage en effectuant des opérations en amont, lors du build (et non du runtime).
Concernant la compilation native, Clément Escoffier explique que c’est en fait un “effet de bord” (non voulu initialement) de Quarkus et de son avènement. Il rappelle que la compilation native est un choix à prendre en connaissance de cause, en effet elle a des use case, mais aussi des défauts (dur à débugger, observabilité et monitoring réduits).
Le réactif dans Quarkus
Le cœur de Quarkus est réactif, mais on peut aussi l’utiliser en mode impératif, ou les deux.
Clément Escoffier nous explique plus en détail le fonctionnement interne, et comment le Routing layer nous permet d’écrire du code dans ces deux paradigmes.
Les microservices
Clément Escoffier nous explique qu’il trouve que les gens à qui il parle ont souvent une compréhension naïve des microservices. On pourrait penser, que juste avoir une application Java au périmètre réduit, et avec sa propre BDD, en fasse un microservice.
Live coding
Nous en venons au live-coding ! L’application finale est disponible sur github: https://github.com/cescoffier/microservice-demo
Le principe est simple, on veut faire combattre des héros contre des vilains, et avoir un résultat. Tout ça en créant un système distribué, composé de microservices Quarkus, qui s’appellent avec différents protocoles (voir par exemple Quarkus superheroes to the rescue).
Les applications sont créées à partir de https://code.quarkus.io/, l’équivalent de Spring initializr, où Quarkus nous facilite la vie, à nous, développeurs, en nous fournissant du code d’exemple fonctionnel.
Une des grandes forces de Quarkus est son expérience développeur. Ici, avec une commande, on démarre notre application en mode ‘dev’, qui redémarre automatiquement à chaque changement grâce à son hot-reload. De plus, si vous le voulez, le continous testing relance vos tests unitaires lorsque vous effectuez des changements.
Un autre outil intéressant: la dev ui, qui est accessible via navigateur en mode dev, où vous avec diverses informations sur l’application (les beans par exemple) et vous permet de tester dans le navigateur votre api via Swagger, ou Graphql.
On a plusieurs microservices utilisant différentes technologies (kafka, grpc, graphql, postgresql) où le framework nous facilite la vie (surtout en mode dev), en démarrant un container kafka ou postgresql si vous avez déclaré la dépendance par exemple. Il y a même un protocole de découverte qui permet à 2 microservices Quarkus en mode dev, d’utiliser un même container.
On peut voir ici qu’il est relativement facile de créer de telles applications utilisant diverses technologies.
Cerise sur le gâteau: avec une librairie exposant la santé de l’application, et une autre permettant de communiquer avec Openshift, les applications sont conteneurisées et déployées en une ligne de commande Maven (Clément Escoffier estime le build complet à 10min sur Openshift).
Instant promo
Si vous voulez en savoir plus sur le sujet, un E-book gratuit est proposé par Redhat: https://developers.redhat.com/e-books/quarkus-spring-developers.
Et Clément Escoffier a sorti l’année dernière, avec Ken Finnigan, le livre Reactive systems in java (Oreily)
Seconde partie: Écrire ses Operators Kubernetes en Java
Why
Sébastien Blanc commence par nous expliquer pourquoi on a besoin d’opérateurs Kubernetes.
Déployer une application simple, c’est facile dans kube, par contre, c’est plus dur quand elle se complexifie (persistent volume, job, accès à l'extérieur). Et, la maintenir dans l’état désiré, c’est encore plus dur.
Sébastien Blanc avoue bien aimer le YAML, “mais quand il y en a trop, c’est dur”
What
Un opérateur c’est un POD qui va communiquer avec Kubernetes pour nous.
Par défaut, Kube comprend les CRD (Custom Resource Definition), c’est avec ça qu’on va écrire nos opérateurs. Sébastien Blanc propose le parallèle avec Java: un CRD c’est une classe, un Custom Resource c’est une instance de cette classe.
Dans le CRD on écrit l’état désiré, le rôle du POD est de maintenir cet état.
Par exemple l’outil Strimzi (kafka dans kube) fournit des opérateurs permettant de créer et gérer des ressources kafka.
Comment en créer un
Historiquement les opérateurs sont écrit en GO, mais ça serait bien de pouvoir en faire en Java. Pour cela il y a Java Operator SDK , qui propose un CLI nous permettant d’initier un projet Maven en une commande (avec Quarkus) et d’initier notre API à l’aide d’une seconde commande. On à donc de quoi commencer à créer son opérateur en se basant sur les classes Java d’exemple. Ici la commande dev de Quarkus déploie l’opérateur dans le minikube local (configuré à côté).
On note que lorsque l’on crée un opérateur, il nous faut coder certaines choses importantes dans la boule de réconciliation, comme la gestion du statut, ou la cascade de suppression des PODs si on supprime la Custom Resource qui les a créés. Ici javaoperatorsdk nous épargne de coder la suppression grâce à son API.
Sébastien Blanc nous explique les grands principes et décide de déployer le jeu vidéo Quake3 (en se basant sur un Deployment et Service disponibles sur github) sur Openshift avec son opérateur, sans l’avoir vraiment testé au préalable, parce que c’est cool. Après quelques configurations et erreurs de mapping, le jeu était déployé et Sébastien Blanc à pu battre des spéctateurs dans la salle qui venaient de rejoindre le serveur.
Questions
A la fin de ces deux présentations les speakers ont pu répondre à des questions notamment:
“Il y a t il des grosses entreprises utilisant Quarkus en production ?”
Clément Escoffier: Ca commence à venir, sur le site de Quarkus vous pouvez déjà voir des grands noms, Décathlon qui nous invite possède des applications sous Quarkus, et, récemment, Keycloack passe de même sous Quarkus
invite
“Quel est le coût de migration d’une application Spring vers Quarkus ?”
Clément Escoffier: C’est un vrai coût. J’ai un talk sur le sujet (https://www.youtube.com/watch?v=opqQSEyRub8) ça dépend du nombre de modules Spring utilisés et de leur disponibilité sur Quarkus. A savoir qu’il existe une couche de compatibilité Spring -> Quarkus (concernant les annotations, comme les Restcontroller)
Un grand merci au Chti JUG et au speaker pour ces talks enrichissants, même en ayant personnellement déjà pratiqué Quarkus j’ai pu apprendre des choses sur ses mécanismes internes, et des fonctionnalités de développement que je n’avais pas encore utilisées.
L’écosystème de Quarkus (qui ne cesse de se développer), sa simplicité, et son expérience développeur m’avaient déjà séduit, et ces deux talks ont relancé mon intérêt.
Top comments (0)