1. InfoQ : Bonjour Aurélien, merci d'accepter cette interview pour InfoQ dans le cadre du BreizhCamp
Aurélien : Bonjour, avec plaisir
Aurélien : Alors c'est un conteneur d'application orienté asynchrone et qui a beaucoup travaillé sur la partie clusterisation des instances et intégration avec différents langages. Il a un côté polyglotte puisqu'il supporte 6 langages par défaut et il y a deux ou trois chantiers supplémentaires, notamment Scala et Clojure qui sont en attente.
Aurélien : Alors en termes de performances les deux communautés se battent pour savoir en fonction des types de benchmark qui est le plus performant. En terme de fonctionnalités ils se posent sur le même créneau qui est l'applicatif asynchrone orienté Web. Maintenant Vert.x fourni des mécanismes out-of-the-box pour scaler sur tout les cores de la machine et mutualiser les différentes instances à travers un réseau, notamment il y a un bus de messages distribué qui vient je crois en outillage autour de Node.js mais pas directement dans l'outil.
4. InfoQ : Qu'est-ce qui fait selon toi le succès aujourd'hui de ce genre de conteneurs d'application ?
Aurélien : Hé bien j'ai l'impression qu'on revient à du vrai Web où l'on manipule beaucoup plus directement du HTTP, du TCP, sans aller piocher dans les spécifications Servlet et autres gros frameworks Web, et ces piles Node ou Vert.x reviennent vraiment à l'essentiel où on manipule du Socket et vraiment juste ce qu'il faut pour faire fonctionner le Web.
Aurélien : Alors il y a déjà eu des tentatives de déploiement dans le cloud, notamment avec succès sur Heroku. Je sais que chez CloudBees ils sont en train de préparer un Click-Stack Vert.x pour la rentrée. Et pour tout ce qui est monitoring pour l'instant il n'y a rien si ce n'est des stratégies pour remonter des métriques métiers via le bus de message. Et toute la partie monitoring / debugging est activement en chantier pour la version 2 de Vert.x.
Aurélien : Effectivement c'est une sorte de bus JMS dans la mesure où ça supporte du publish-subscribe, du request-response, du send point-à-point, mais ce qui transite à l'intérieur de ce bus là est systématiquement sérialisé en Json, ce qui permet d'avoir un format neutre pour faire communiquer des Verticles (qui sont des unités de déploiement Vert.x) qui sont développés dans différents langages. En l'occurrence entre un module Javascript et un module Java, le langage commun sera le Json.
Aurélien : Alors dans l'architecture de Vert.x il y a un peu le même système que dans Node, à savoir des Event Loop mais il y a également ce qu'ils appellent des Workers Verticles, qui sont dédiés aux traitements plus longs, bloquants, qui eux sont gérés par un Thread Pool à part et donc on peut très bien penser porter tous les traitements connectés à des applis legacy et donc potentiellement bloquantes dans des workers verticles, et quand même profiter de tout ce qui est asynchronisme pour les plus hauts niveaux de nos verticles.
Aurélien : On pourrait éventuellement, je ne suis pas sûr que ce soit la bonne philosophie mais ce serait possible.
Aurélien : Je pense que ce serait un cas d'école assez intéressant, maintenant l'outil en lui-même est peut-être un peu light pour le moment, notamment sur tout les aspects debugging et monitoring qui sont encore "pas sec", mais ça peut être un très bon outil d'appoint, puisque ça fourni une excellente boîte à outils pour masquer des services legacy et créer des API REST très rapidement, et très performantes. C'est vraiment à essayer, c'est le bon moment pour commencer à regarder et développer des nouveaux modules...
11. InfoQ : D'accord donc en façade éventuellement à des composants existants ?
Aurélien : Voilà en façade c'est vraiment un bon cas d'utilisation.
Aurélien : Hé bien comme on vient de le dire en façade, enfin en façade si on veut, si on a une migration "web-oriented" ça peut être très très utile pour mettre une façade devant une vieille implémentation serveur, faire du REST propre et petit à petit décommissionner l'application qui se trouve derrière vers quelque chose de plus récent. Ça vient également en tant que boîte à outils, ça peut notamment pas mal servir pour isoler des applications, pour les tester en charge, parce que ça fourni quand même quelque chose de très solide, donc pour éviter d'écrouler nos instances de recette en testant en charge sur notre poste, ça permet de l'isoler quand même assez efficacement en faisant des proxy-cache custom... Y a pas mal de petits cas d'utilisation, tout ce qui tourne autour du réseau et de la bricole ça peut donner quelque chose de très puissant très vite.
13. InfoQ : Hé bien merci Aurélien d'avoir répondu à nos questions, et à bientôt !
Aurélien : Merci de me les avoir posées. Au revoir !