A la suite de ses annonces de ce printemps dernier sur le support de GlassFish 4 et Java EE 7, CloudBees annonce le support de Wildfly 8 dès le premier jour. En fait, CloudBees a même pris de l’avance car le successeur de JBoss Application Server est toujours en version “Release Candidate”, la première version “Release” est pour sa part annoncée pour début 2014. Le support de Wildfly 8 sur CloudBees est pour le moment de type communautaire, le support officiel (appelé “curated”) interviendra plus tard, après la “Release” de Wildfly 8 et des tests plus poussés côté CloudBees.
InfoQ FR a pu parler avec Cyrille Le Clerc de CloudBees pour en savoir plus.
InfoQFR : Vous proposez JBoss et Glassfish, quel est le statut de JavaEE chez CloudBees?
Cyrille Le Clerc : Chez CloudBees, nous revendiquons d’être la meilleure “Platform as a Service” pour Java. A ce titre, nous voulons être exemplaires sur Java EE et nous proposons déjà JBoss 7, 7.1 et 7.2 ainsi que Glassfish 3 et 4. Glassfish 3 & 4 sont disponibles en version "Web Profile" et "Full Platform” ; les versions “Full Platform” sont disponibles en support “communautaire” et sont davantage destinées à des usages d’expérimentation.
InfoQFR : Quelle est la proportion d’utilisation de Java EE chez les clients CloudBees? Quels sont les types d’usage ?
Cyrille Le Clerc : Tomcat est de très loin le conteneur dominant ; il représente de 83% des utilisations sur la plateforme CloudBees. Java EE représente environ 4%, c’est une part d’utilisation légèrement inférieure à celle de Play Framework 2 (6%). Parmi ces déploiements Java EE, JBoss est largement majoritaire et l’utilisation de GlassFish reste marginale. Si on limite l'analyse aux seuls comptes payants (nous avons un modèle freemium), la part relative de Java EE en termes de revenus est plus importante.
Pour les typologies d’usage de Java EE, on retrouve bien sûr beaucoup d’utilisateurs d’EJB et les équipes sont très “entreprise”. Pour Glassfish, nous avons aussi beaucoup d’utilisateurs “éducation”, des enseignants qui demandent à leurs élèves de déployer leurs projets sur CloudBees. Il est alors amusant de voir les pics de questions au support à la fin des projets.
InfoQFR : Pourquoi proposer aussi tôt Wildfly 8, comme vous aviez proposé très tôt Glassfish 4?
Cyrille Le Clerc : Les motivations sont multiples. Java EE est une “bête particulière” avec son approche Full Stack et nos clients étaient frustrés de ne pas pouvoir utiliser les fonctionnalités de Java EE 7 dans leur conteneur alors que c’est souvent possible sur Tomcat. Nous avions en particulier des demandes pour utiliser JSF 2.2 sur JBoss AS 7.x bien que ce soit impossible. Nos réponses étaient alors de passer à Glassfish 4 ou Tomcat mais ce genre de migration est compliquée ; Wildfly 8 nous permettra d’offrir Java EE 7 en écosystème JBoss.
Par ailleurs, en tant que Platform as a Service Java, nous nous devons d’être à la pointe de l’innovation sur Java EE et de permettre à nos clients d’expérimenter en “avance de phase”.
Une autre motivation est que supporter en mode “preview” les conteneurs nous permet de rôder et fiabiliser nos implémentations. Nous menons nos phases “beta” en même temps pendant la phase “beta” des conteneurs eux-mêmes pour être en service “release” sans décalage.
Enfin, nous faisons cela par jeu et par plaisir. Nous sommes impatients d’observer les choix d’implémentation des différents conteneurs et le défi de faire une industrialisation élégante nous excite.
InfoQFR : Quelles sont les fonctionnalités de Wildfly disponibles sur CloudBees ?
Cyrille Le Clerc : CloudBees se focalise sur le Web Profile de Java EE et veille à ce que des applications “pur Java EE” se déploient naturellement sur la plateforme. Pour cela, nous couvrons en particulier le moteur de servlets, les datasources JNDI, les EJB, les timers (non persistants) et l’authentification JaaS avec un backend JDBC. En revanche, nous ne nous engageons pas sur JMS et les transactions distribuées. Ces services fonctionnent sur nos stacks “Full platform” mais nous ne nous engageons pas sur la persistance des messages ou des transactions lors des redémarrages des applications. Le système de fichiers des applications est éphémère et est réinitialisé lors de chaque redéploiement. Nous transgressons toutefois nos règles et nous avons récemment ajouté le support de la persistence JDBC sur le broker JMS de Glassfish 4 Full Platform pour couvrir un besoin d’une application de la conférence Devoxx France.
InfoQFR : Oracle a récemment annoncé l’arrêt du support commercial de Glassfish, comment avez-vous accueilli la nouvelle?
Cyrille Le Clerc : Notre première réaction a été la déception. Plusieurs ingénieurs de CloudBees ont travaillé sur Glassfish lorsqu’ils étaient employés chez Sun et nous avions de nombreux clients enthousiasmés par notre support de Glassfish. Pour ce qui me concerne, c’est mon serveur Java EE préféré, je me suis beaucoup amusé à faire la ClickStack Glassfish, à faire marcher Glassfish sur la plateforme CloudBees.
Après cette émotion, nous en sommes venus aux interrogations sur la pérennité de Glassfish sans le support commercial par Oracle et nous sommes hélas pessimistes. Glassfish est un middleware sophistiqué et complexe. Sans les ingénieurs Oracle, qui va corriger les derniers bugs du monitoring ou du clustering ? Combien de contributeurs Open Source consacreront leurs nuits et leurs week-ends sur ces briques peu glamour ? Oracle partagera-t-il l’accès au référentiel de code source ? Il y a beaucoup d’incertitudes sur Glassfish et, au même moment, JBoss met une grande énergie dans Wildfly / JBoss Application Server. Nous nous attendons à voir les utilisateurs Glassfish migrer massivement sur Wildfly. Les applications sont très portables et Arun Gupta, fraîchement arrivé de Oracle chez JBoss, les accompagnera avec plaisir !