BT

Discussions autour de Vert.X avec Aurélien Maury
Enregistré à :

Interview avec Aurélien Maury par Simon Baslé le 18 sept. 2013 |
  • Télécharger
  • MP3
07:25

Bio Aurélien est passionné par les frameworks web haute productivité comme Grails, JRuby on Rails ou Play! framework. Il est également intéressé par tous les aspects de performance et d'optimisation (mais aussi par la phytothérapie, la PNL, la basse électrique, la philosophie et pleins d'autres sujets).

Le breizhcamp, ce sont 2 journées de conférences organisées par le BreizhJug et les communautés techniques de Rennes.

   

2. InfoQ : Donc tu interviens sur Vert.x notamment, est-ce que tu peux nous présenter rapidement ce conteneur, si je puis dire, et son architecture ?

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.

   

3. InfoQ : Vert.x semble être un peu l'alternative du moment à Node.js, comment les deux se comparent-ils en termes de fonctionnalités, de performance ?

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.

   

5. InfoQ : Un retour à l'essentiel donc quelque part

Aurélien : Un retour aux sources oui.

   

6. InfoQ : Qu'est-ce qu'il en est des outils et des problématiques qui peuvent tourner autour de Vert.x, comme le monitoring, le debugging, le déploiement dans le cloud (ou pas) ?

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.

   

7. InfoQ : A propos de l'EventBus de Vert.x, est-ce que tu peux nous en dire un peu plus ? Est-ce qu'on peut le voir quelque part comme une sorte de bus JMS ?

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.

   

8. InfoQ : Sur la problématique des applications legacy, comment peut-on intégrer ce genre d'applications qui n'ont pas été développées en ayant un mode asynchrone en tête ? Est-ce que c'est possible de les intégrer dans Vert.x ?

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.

   

9. InfoQ : D'accord, donc on pourrait utiliser par exemple ces workers verticles pour un framework web plus classique éventuellement, basé sur des Servlets, qui sont bloquantes ?

Aurélien : On pourrait éventuellement, je ne suis pas sûr que ce soit la bonne philosophie mais ce serait possible.

   

10. InfoQ : Selon toi, est-ce qu'on peut construire toute une architecture (enfin est-ce qu'il faut construire toute une architecture) autour de Vert.x, ou l'utiliser comme un simple composant du système ? C'est à dire est ce qu'on devrait penser tout son système avec Vert.x au cœur de celui-ci en appliquant partout les principes d'asynchronicité, en utilisant l'Event Loop, l'Event Bus ?

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.

   

12. InfoQ : Est-ce que tu as d'autres exemples, scénarios dans lesquels Vert.x trouve particulièrement bien sa place dans un système informatique d'entreprise ?

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 !

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT