Heroku est une plateforme d’hébergement multi-langages type PaaS. Ce service vous permet de déployer rapidement une application web sans vous soucier de l’installation de la machine, des langages et de la configuration du serveur. En bref c’est un système de location de ressources d’hébergement. Heroku a été racheté par SalesForce.com environ $212 million fin 2010. Le service était au départ centré sur Ruby. Plus d’un millions de développeurs ont testé cette plateforme. Il y a plus de 100 000 applications en production aujourd’hui, majoritairement en Ruby. Gardez ce chiffre en tête pour tout à l’heure… Heroku s’est ouvert à d’autres langages comme Clojure et d’autres plateformes comme Node.JS avec Javascript côté serveur. Mais il manquait ce bon vieux Java.
Java a été annoncé la semaine passée. Le langage le plus utilisé pour faire des applications d’entreprises apporte une pile technique puissante et mature. Cependant, Adam Wiggins l’un des fondateurs d’Heroku explique que l’architecture JEE n’a pas été retenue. Selon lui, « les conteneurs J2EE sont amenés à disparaître« . Il ajoute aussi « You don’t need them for scalability, for reliability, for robustness« .
Je pense que les serveurs J2EE ont encore de belles années dans le monde de l’entreprise. Heroku s’adresse plutôt aux entreprises à la recherche d’une solution clé en main, prête à l’emploi. Elle permet aux PME et aux entreprises sans DSI de mettre en oeuvre rapidement des solutions webs. Cela ne s’adresse pas à GrosseBanque ou MegaAssureur qui doivent garder un oeil sur son informatique.
Lors de la sortie de Java pour Heroku, les fondateurs parlent sans langue de bois de notre plateforme Java. Dans un billet posté sur leur blog, vous apprendrez à mettre en marche votre premier projet en quelques minutes. Heroku se base sur Git pour tout ce qui est de la mise en production. Heroku a un dépôt Git. Vous pusher vos modifications vers ce serveur, vers votre repository, et Heroku effectue la compilation et le déploiement pour vous. Oui c’est bien de code source dont je parle. Vous ne poussez pas un WAR ou une image. Vous envoyez votre code source, qui est compilé et mis en production. La version de base utilise maven et le conteneur jetty. Un autre tutorial montre l’utilisation de Spring Roo afin de construire et déployer une application rapidement, en utilisant Spring/Hibernate. Bref c’est sympa mais cela ne m’intéresse pas.
Ce que j’attendais, c’était plutôt l’équivalent de Rails. Soit Grails, soit Play! Framework. Pour le développement purement web, j’ai vraiment tourné la page des autres frameworks dit Web. Non, ce qu’il faudrait c’est un framework « full-stack » qui compile et fait tourner votre code. Il n’y en a que 2 dans le monde Java : Grails avec Groovy et Play! Framework. Ce sont les seuls frameworks capables de compiler, vous montrer d’éventuelles erreurs, et vraiment faire tourner votre code en production. Le génie de Play! c’est de le faire en Java. Pourquoi suis-je fan ? Car ce n’est pas uniquement un framework d’exécution, c’est un vrai socle de travail. Peu le comprennent, car nous sommes habitués à intégrer dans le monde Java. Tout bon développeur Java doit maitriser Maven, JPA et un moteur d’IoC pour pouvoir travailler efficacement aujourd’hui. Mais la bataille des dépendances dans maven, la mise en production héroïque et l’incapacité de développer rapidement à chaud sont vraiment des freins à la productivité et au plaisir. Oui je sais, vous utilisez JRebel. J’en ai vu qu’un seul vraiment s’en servir. J’ai plus vu des développeurs recopier des .class via FTP vers le répertoire « exploded » de Websphere, recharger la home-page de l’application puis cliquer sur 3 écrans de suite pour remettre la page en l’état, et s’apercevoir que cela ne marche pas… Moi le premier. Ca c’est du vécu mon ami.
Or aujourd’hui, Heroku a officiellement annoncé la sortie de Play! Framework pour Heroku.
Cool on va pouvoir vraiment commencer à bosser comme les autres. Je développe en local, une version me plaît bien et je dois la montrer au client. Un git push d’une petite branche, je recharge ma page dans mon navigateur et CA MARCHE ! Mince dis-donc, je ne pensais pas que l’on pouvait faire AUSSI SIMPLE. Le couple Git/Heroku/Play! Framework est vraiment impressionnant. Si vous connaissez Git, vous voyez avec moi ces nombreuses petites branches, que vous mettez en place pour travailler efficacement. Si vous connaissez Play! Framework vous savez qu’il compile, vous montre aussi dans le navigateur vos erreurs et vous permet de faire tourner vos tests. Votre nouveau copain va s’appeler Heroku. Il est votre nouveau copain car il ne coûte pas cher. Vous allez pouvoir vous en servir et tester gratuitement vos développements, car il est possible d’utiliser la plateforme librement jusqu’à un certain seuil. Comme Google AppEngine mais en mieux. Pas de restriction sur les class, allez-y servez-vous mon ami.
Le service PlayApps.net de Zenexity (sur lequel est hébergé l’express-board) a ouvert la voie. Il a donné la possibilité à la société Zenexity, fondée par Guillaume Bort, créateur de Play! Framework, d’acquérir des compétences dans le domaine du PaaS. Or Heroku n’a pas lancé ce service dans son coin. Guillaume Bort, interrogé sur la question, m’explique que Zenexity et Heroku ont travaillé ensemble pour proposer ce nouveau service. Encore un coup de génie qui ne fait que renforcer le petit framework qui monte…
Voilà, je vous disais au début que la plateforme héberge plusieurs milliers d’application en Ruby. Imaginez maintenant que la communauté des développeurs Java s’y mette… Mince nous sommes peut-être 10 millions de développeur sJava dans le monde, et je suis certain qu’un bon nombre d’entre nous ont envie de faire du web et des applications webs, tout en utilisant Java.
Bref encore un joli coup de Zenexity, qui n’a pas terminé de nous surprendre. A quand la prochaine annonce ?
0 no like
As tu prévu de passer l’express board dessus ou un autre projet histoire de comparer un peu avec playapps ?
@hsablonniere je ne manquerai pas de tester. J’ai aussi CloudBees et CloudFoundry sur mon radar
Sinon on l’avait vu venir avec ton teaser sur Twitter (c’est de bonne guerre).
Bonne nouvelle en tout cas et bon article comme d’habitude, même si en l’espèce, tu as laissé ton objectivité de côté (mais cela fait l’intérêt d’un blog) 🙂
Play rocks, vivement un support maintenu dans Cloud Foundry!
D’un coté c\’est super d’avoir un acteur PaaS de plus qui fait du Java, mais de l’autre j’ai du mal à ne pas m’étouffer en lisant des exemples J2EE d’il y a 10 ans pour justifier des choix techniques.
Pour faire du Java coté serveur, il faut une stack web, un modèle de composant métier, du transactionnel, de l’accès aux données, de l’orienté message, etc . Bref, ça ressemble furieusement à Java EE…
Heroku a l’ai très intéressant mais on a surement encore quelques problèmes.
Exemple :
– preompiling : Module secure is available (/tmp/build_2cyclo5ijcsho/.play/modules/secure)
– run : Module not found: /app/.play/modules/secure
En dehors de ce petit point surlequel je regarde l’intégration est vraiment très agréable et simple.
Je me pose la question de l’avenir de PlayApps. Vont-ils prendre la peine de continuer son développement, ou préférer se concentrer sur le framework maintenant qu’il y a une plateforme d’hébergement sérieuse?
Si cela peut servir j’ai trouvé la solution aux problèmes de module :
Il ne faut plus utiliser la déclaration dans le fichier application.conf qui est déprécié mais déclaré les dépendances dans dependencies.yml
Exemple :
…
play -> secure
Et hop le tour est joué 🙂
@sbert En effet depuis la version 1.2.3 de Play! les dépendances sont déclarées avec la syntaxe yaml, le framework récupère les JAR sur les repositories Maven avec Apache Ivy. Bien vu. Lorsque tu ajoutes une dépendance, il faut ensuite lancer « play dependencies » lorsque tu bosses en local.