Byron Sebastian, Heroku : "La priorité de notre plate-forme cloud est de simplifier la vie"

Byron Sebastian,
CEO d'Heroku

Rencontré à l'occasion de Dreamforce 2011, Byron Sebastian, le CEO d'Heroku, la plate-forme Paas Ruby et Java rachetée par Salesforce en décembre fait le point sur l'évolution de la solution de l'éditeur. Il revient aussi sur les choix techniques effectués pour la mise en oeuvre du support de Java sur Heroku (un support annoncé à la veille de Dreamforce) et s'exprime plus généralement sur la stratégie de SalesForce dans le cloud et sur les points forts de son offre.

LeMagIT : Pouvez-vous nous dire ce qu’il s’est passé au cours des presque neuf derniers mois depuis l’acquisition d’Heroku par Salesforce?

La croissance a continué et on a ajouté de nombreuses améliorations pour les grandes entreprises comme le support 24/24, le monitoring applicatif, de nouvelles options de reprise après désastre pour notre service de bases de données. On répond aux besoins d’applications de plus en plus riches et de plus en plus complexes en proposant le support de multiples langages, de multiples add-ons.  On veille toutefois à préserver la cohérence de la plate-forme, de façon à ce que les utilisateurs ne nous voient pas comme une plate-forme Ruby, une plate-forme Java ou une plate-forme Node.js (javascript serveur, NDLR), mais comme une plate-forme unique à même d’offrir le meilleur en fonction du travail à réaliser. (L’une des raisons pour lesquelles SalesForce a racheté Heroku était d’ailleurs l’intention affichée par la start-up de développer les capacités multi-langage de sa plate-forme, NDLR)

LeMagIT : En annonçant le support de Java sur Heroku, vous avez aussi annoncé au passage l’abandon du modèle traditionnel de container J2EE. Pourquoi une telle décision?

Cette décision a été prise pour répondre aux besoins des développeurs. Chaque fois que c’est possible nous tentons de nous adapter à ce que demandent les développeurs et à la façon dont ils travaillent. Le déploiement avec GIT par exemple sur Heroku a été une réponse à la demande des développeurs Ruby.  Ce que l’on a trouvé avec Java est que l’on pouvait simplifier la vie des développeurs en éliminant le conteneur applicatif. En quelque sorte, on encapsule le serveur applicatif, on l’utilise comme une librairie.

Bien sûr, nous disons aux développeurs : « vous pouvez bâtir des applications qui utilisent Jetty ou Tomcat, mais pour ce qui est de ces services de déploiement J2EE qui se mettent en travers de votre route, vous pouvez les éliminer en reposant sur les services de déploiements fournis par Heroku ». Je pense que nous devons notre succès aux développeurs et nous devons les respecter. Il ne s’agit pas de leur demander de tout changer quand cela ne fait pas de sens, mais d’être suffisamment courageux pour leur dire qu’on peut leur changer la vie s’ils acceptent de changer leurs habitudes.

Par exemple, il y a deux ans, nous avons fait grincer quelques dents en interdisant l’accès au file system depuis les applications ruby sur Heroku. Nous pensions qu’une architecture de type « shared nothing » était plus adaptée au cloud et ça a effectivement permis de faire monter les applications bien plus simplement en puissance.

LeMagIT : Vous avez maintenant deux cloud Java avec Heroku et VMForce …

En fait VMForce est une expérience qui a touché à sa fin, nous l’avons annoncé peu de temps avant Dreamforce.

LeMagIT : … Dans ce cas quel app server utilisez-vous pour Heroku?

Pour Heroku, nous avons conçu notre propre technologie. Mais pour les servlets nous laissons le choix entre Jetty et Tomcat. Tous deux marchent plutôt bien dans un cadre embarqué.

Utilisez-vous une implémentation standard de Tomcat ou Tc Server de VMware.

Nous utilisons Tomcat. Mais spring est totalement supporté. J’avoue que les multiples rebranding de Tomcat par des tiers créent une confusion sans que l’on voit réellement les différences.

LeMagIT : Reste-t-il quelque chose du partenariat entre VMware et Salesforce sur Java.

On va continuer à travailler ensemble, on partage le même souhait d’ouverture et de choix. Par exemple, on a annoncé le support de Rabbit MQ dans Heroku. VMware est une grande société ("a great company", NDLR).

LeMagIT : Côté infrastructure, vous vous appuyez historiquement sur Amazon AWS. Mais l’an passé lors du rachat, Salesforce avait laissé entendre que cette infrastructure pourrait migrer sur ses propres serveurs. Cela fait-il toujours partie du plan ou êtes vous satisfait d’Amazon ?

On est très satisfait d’Amazon, mais on a des clients qui voudraient faire tourner des applications Heroku dans les datacenters de Salesforce. Il n’y a pas de date ferme, mais nous donnerons le choix entre les deux. Dans certains cas cela apportera une meilleure latence entre Database.com et Heroku. La sécurité et la disponibilité font aussi parti des arguments pris en compte par les clients.

LeMagIT : Existe-t-il un plan de rapprochement entre Force.com et Heroku.

Non. Force.com est une plate-forme très déclarative adaptée aux applications de gestion de données qui doivent aussi traiter des formulaires…  Heroku se concentre sur les applications procédurales. On doit veiller à ce que les deux plates-formes interagissent bien, ce qui se fait via des interfaces Rest par exemple, sur lesquelles on a beaucoup investi. Mais cela ne fait pas sens de fusionner les deux plates-formes.  Pourquoi le ferions nous d'ailleurs ? Cela fait longtemps qu’il n’y a pas eu de plate-forme déclarative comme Force.com. Vous, qui avez comme moi des cheveux blancs, vous rappelez sans doute de plates-formes du passé comme Powerbuilder, Visual Basic. En quinze ans, il n’y a pas vraiment eu d’équivalent pour l’internet. Et Force.com remplit à merveille ce rôle.

LeMagIT : Les plates-formes PaaS résolvent un problème mais dans certains cas il faut encore des VM pour faire tourner des composants Linux ou Windows. Joyent vient d’intégrer le support de KVM a son Os dérivé d’OpenSolaris pour faire cela. Microsoft fournit un mode VM dans Azure. Entendez-vous proposer quelque chose d’équivalent dans Heroku ?

Non. Nous ne voyons pas le besoin de fournir des VM. Nos clients peuvent très bien intégrer leurs applications dans le cloud avec leurs applications internes. Au pire, ils peuvent aussi utiliser des VM sur le nuage Amazon. Mais nous ne voulons surtout pas devenir un fournisseur IaaS (Infrastructure as a Service, NDLR).

LeMagIT : Les développeurs ne sont souvent pas formés à développer des applications qui montent en charge.  Avec le Paas on peut dans une certaine mesure résoudre ce problème en multipliant les nœuds servant l’applications, mais dans certains cas on se retrouve avec un code mal optimisé et donc avec une application qui peut devenir coûteuse.  Cela peut être résolu par une instrumentation de la plate-forme qui pourrait guider les développeurs dans l’amélioration de leurs applications, un peu comme le fait Joyent avec DTrace ?

Je suis d’accord avec vous. Je crois que cette instrumentation est clé pour les plates-formes PaaS. Elle permet de fournir une expertise à nos utilisateurs et permet aussi de tirer parti de l’expérience accumulée en analysant les centaines d’applications de nos clients pour améliorer leurs performances respectives. L’instrumentation est un terrain fertile de développement pour toutes les plates-formes PaaS. DTrace dans Joyent est d’ailleurs plutôt « cool ».