Salesforce a organisé une présentation d’Heroku à Paris, à l’occasion du passage d’une partie de l’équipe en Europe. Pierre-Olivier Chotard de Salesforce nous présente l’équipe. Adam Seligman (@adamse), en charge des relations avec les développeurs, a tout d’abord présenté la plateforme et la philosophie, avant de passer la main à Blake Gentry. pour une démo intéressante.
Premier point intéressant de ce type de présentation : vous écoutez le message et les valeurs de l’entreprise, de la bouche de ceux qui font ce produit. Heroku est une plateforme applicative dans le Cloud. Le premier objectif des fondateurs d’Heroku était d’offrir un outil avec une ergonomie simple et puissance. En quelques sortes, l’Apple du Cloud.
Heroku est une plateforme pensée pour la construction d’applications webs sociales. Initialement focalisé uniquement sur Ruby, les équipes ont ajouté le support de Clojure, Node.JS, Java, Scala, PHP et Python ces derniers mois seulement. Comme l’explique Adam, lorsque vous souhaitez installer une application, il n’y a pas de « petit 1, petit 2 et petit 3 ». Il suffit de pusher son code via Git vers le repository d’Heroku. La plateforme se charge alors de déployer pour vous en production votre application.
Le deuxième objectif était de permettre au développeur de déployer immédiatement son application. Pas besoin de DevOps, ici la mise en production est ultra-simple. Ensuite, et c’est l’un des points forts de cette plateforme, Heroku propose tout un ensemble d’Add-Ons. Vous pouvez ainsi ajouter à votre application des fonctions comme :
– l’envoi d’email
– le support de CouchDB
– génération de PDF/Excel
– Heroku Postgres Database as a Service avec backup, sécurité et logs
– Memcache
– MongoDB
– New Relic pour monitorer votre application dans les couches basses et faire du tuning.
– Redis
– Rabbit MQ
et d’autres…
Heroku n’a pas un discours technique. Finalement, durant la présentation, on se rend compte qu’ils sont déjà un cran plus loin que les compétiteurs. Là où certains parlent de VM et ne font finalement que du Tomcat hébergé, Heroku se concentre sur l’intégration de services Webs.
Et je crois qu’ils ont raison.
La plateforme est polyglotte, avec le support de Ruby, Node.js, Clojure, Scala, Java, PHP et Python. Selon votre projet, prenez le langage et le framework le plus adapté. Adam cite plusieurs fois Play! Framework, qui est supporté sur Heroku (voir ici mes essais)
Un point important : les outils de déploiement et d’administrations sont identiques, quelque soit le langage. Cela rend plus simple l’administration et la gestion d’une application, tout en se focalisant sur l’utilisabilité. Que votre application soit écrite en Ruby ou en Java, la commande « heroku ps » ou « heroku logs » se comportera toujours de la même façon.
La plateforme est ouverte, car elle est basée sur des langages et des frameworks open-source. Comparez simplement les projets d’Oracle, qui s’adresse plutôt au monde de l’entreprise.
Pour ce qui est du scaling, vous pouvez simplement augmenter/diminuer le nombre de web worker à partir d’une ligne de commande :
heroku scale web=20 worker=15
Vous voyez le bouton « Volume » de la télécommande TV que votre fils de 3 ans maîtrise ? Et bien là c’est pareil.
Qui utilise Heroku ?
Plus de 378 000 applications déployées, dont une bonne partie sont des applications pour Facebook. Adam insiste sur l’importance du métier de « développeur web social » dans les années qui arrivent. Il sera indispensable de connaître OAuth, l’API Facebook, comment récupérer son profil sur LinkedIn… bref le développeur web de demain sera aussi un excellent intégrateur.
Il enchaine avec une démonstration sur Facebook. Après s’être authentifié, il créé en quelques minutes une application PHP hébergée sur Heroku, le tout en étant dans l’espace dev de Facebook. Heroku est pour l’instant la seule plateforme proposée sur Facebook.
Il cite d’autres exemples comme l’application Dark Knight, développée lors de la sortie du DVD de Batman. En quelques heures, plusieurs milliers de fans sur Facebook ont visualisé le film et commenté le film, directement de leur espace Facebook. Le tout avec 43 dynos encaisse 25 millions de visiteurs… (détails ici)
Un autre exemple : Rapportive. Cet outil s’intègre dans votre compte GMail pour vous donner des informations sociales sur les personnes qui vous envoient des emails. Les développeurs avaient parlé de ce projet avec un journaliste… qui en a parlé à un autre… qui finalement a fait que plus de 100 000 personnes se sont connectées, alors que l’application était encore en bétâ. Grâce à Heroku, l’équipe a tenu la charge et l’application est maintenant un succès.
L’architecture
Oubliez les serveurs, vous ne vous connecterez pas sur le serveur, ni sur une quelconque VM. Heroku est pensé par des développeurs pour des développeurs. Je sais pas pour vous, mais moi le serveur… je m’en fiche. Tant que cela fonctionne, que je suis assuré de la sécurité et que je peux suivre ce qu’il se passe… je me fiche de savoir comment cela fonctionne.
En frontal, Heroku utilise un HTTP Reverse Proxy, les ressources statiques sont automatiquement cachées avec des caches classiques. Le routage ensuite, passe par une grille (Routing Mesh), puis ensuite sur une grille de worker dynamique, les Web Dynos. La persistence peut s’effectuer par défaut sur une base de données SQL, ou sur des bases NoSQL. Heroku a fait le choix de PostgreSQL, une base aussi performante qu’une base Oracle, avec des fonctions de réplications poussées qui n’existent pas sur MySQL. N’étant pas un spécialiste de la question, je ne peux pas vous en dire plus.
L’entreprise
Heroku a été fondé en 2007 à San Francisco, par 3 développeurs de la communauté Ruby. En décembre 2010, Salesforce rachète Heroku, en juillet 2011 la société a embauché Yukihiro « Matt » Matsumoto, le fondateur de Ruby. Imaginez que James Gosling soit embauché non pas par une boite de Robotique, mais par entreprise qui fait un PaaS…
On a encore un peu de mal à voir l’intégration et les synergies possibles entre Salesforce et Heroku. Salesforce propose Force.com, une plateforme qui permet de créer ses applications, sans passer par la phase « développement de code ». Heroku est plutôt orienté vers les réseaux sociaux, le développement d’applications massivement sociales.
Conclusion
Pour nous, développeurs Java, tout ceci est encore nouveau. Nous sortons juste de 8 années de J2EE et de 2 années de « Spring va sauver le monde« . La création d’une application web sociale, ou d’une simple application de la gestion de la relation client, est encore un peu loin du radar du développeur de base.
Cependant, un gros point fort de notre communauté : nous sommes nombreux. En venant chercher la communauté Java, qui quoique l’on dise, représente 10 millions de personnes dans le monde, 19 Java User Group rien qu’en France, Heroku a fait un bon choix. J’imagine dans les mois qui viennent qu’un certain nombre de développeurs vont se lancer, et basculer du côté Web de la chose.
Oh je sais ce que tu vas me dire : moi je fais une grosse application de gestion en Struts et ton machin avec Facebook, ça ne me parle pas.
Mais dis-donc, tu comptes faire du Struts jusqu’à la fin de ta vie mon pote ? Y’a pas un petit gars dans ta tête qui te dit « bouge toi raymond » ? Et tant qu’à faire, n’as-tu pas envie de travailler sur des architectures de 2011 ?
Revenons à nos moutons. Je pense que Java a encore un peu de travail à réaliser pour se rendre plus simple. Je trouve que l’approche présentée dans cet article est encore un poil compliquée. A croire que faire une application web en Java doit forcément passer par l’écriture d’une Servlet… Attendons JEE7 et j’espère que la création d’une application web sera enfin vu comme quelque chose de simple, comme dans les autres langages.
Mike Gualtieri de Forrester balance un pavé dans la marre :
Traditional application servers or containers such as Tomcat will fast become legacy methods for deploying Java applications. The next generation is elastic application platforms (EAP) that are containerless.
Heureusement il y a Play! Framework. Un framework sans état conversationnel du côté serveur… c’est juste indispensable pour ce type de plateforme. Si vous maintenez une session en mémoire sur le serveur systématiquement (et pas exceptionnellement comme avec d’autres approches) votre visiteur doit revisiter le même serveur physique. Autre solution : vous pouvez aussi répliquer sa session dans votre cluster, via la base de données ou via un cache.
Je n’ai rien contre les frameworks Webs avec session, qui prennent l’approche stateful portée par l’API JEE. Vous pouvez aussi écrire une application web sans état, mais ce n’est pas ce qui saute aux yeux au premier abord. Dommage.
Heroku alors ?
En conclusion, j’ai découvert une nouvelle culture et une nouvelle porte pour le développement web. Je vois de plus en plus malheureusement un fossé entre l’écriture d’applications d’entreprise en Java, et cet univers qui ne cesse de progresser et d’avancer. Est-ce mieux ? Est-ce moins bien ? Une chose est certaine en tous les cas : c’est ici que se trouve les métiers de demain. Dans quelques années, un développeur Web sera un expert OAuth2, un maître de l’API Twitter, un intégrateur hors-pair de l’API Paypal et de l’API Facebook.
Autre point qui m’a marqué : le discours éloigné de la technique. Au lieu de vous parler de serveurs, de maven ou de déploiement d’un War, les gens d’Heroku parlent « développeurs ». A croire que le métier d’administrateur système n’aura plus d’importance, ce dont je doute.
A suivre donc !
0 no like
Salut Nico
> Le deuxième objectif était de permettre au développeur de déployer
> immédiatement son application. Pas besoin de DevOps
Pour rappel, Devops (et pas DevOps) = alignement des équipes tech sur les objectifs business. Donc il y’a toujours besoin d’une mentalité devops :).
> Heroku n’a pas un discours technique
Ah dommage, c’est ce ce qui m’intéressait 🙁
> Finalement, durant la présentation, on se rend compte qu’ils sont déjà un
> cran plus loin que les compétiteurs.
Clairement ! On sent bien dans leur solution une certaine maturité, le fait d’avoir résolu quelques problèmes alors que les autres pataugent encore. Mais pour avoir testé d’autres solutions (ca pousse comme des petits pains depuis quelques mois dans le monde Ruby et Python), les autres progressent.
> Oubliez les serveurs, vous ne vous connecterez pas sur le serveur, ni sur
> une quelconque VM. Heroku est pensé par des développeurs pour des
> développeurs. Je sais pas pour vous, mais moi le serveur… je m’en fiche.
Pour moi, c’est un soucis de voir les développeurs ne pas soucier de la plateforme qui gère le code. Tu aimes répeter qu’il faut connaitre html et sql, je vais plus loin en disant que le matos à son importance. Comme éviter de voir des développeurs tout recoder dans leur langage ce qu’Unix fait très bien depuis longtemps (par ex.).
> Heroku a fait le choix de PostgreSQL, une base aussi performante qu’une
> base Oracle, avec des fonctions de réplications poussées qui n’existent
> pas sur MySQL. N’étant pas un spécialiste de la question, je ne peux pas > vous en dire plus.
Postgresql c’est juste balle ! Bien plus performant et complet que Mysql depuis bien longtemps (il avait déjà ma préférence en 99), il lui manquait la réplication (dispo depuis la 9.0). Je conseille vivement ce SGBD (qu’on utilise au taff avec bonheur). Le succès de Mysql vient essentiellement du fait qu’il était très rapide en lecture (et pendant longtemps, le web c’était de la lecture et peu d’écriture), facile à administrer et à utiliser avec PHP. Rhalala, ca me rappelle mes 1ers taff php/mysql fin 90 / début 2000 :).
> A suivre donc !
Merci pour le retour, j’étais un peu deg d’avoir raté la conf après celle sur OpenStack. Le cloud à, comme on l’a vu au Devops meeting de hier un défaut qui est la gestion des gros volumes de données perso(cela coute cher, en argent comme en temps) et la réplication. Le cloud est pour l’instant intéressant pour la CPU, et les exemples que tu donnes le montre (en gros, des données qui sont déjà sur le net).
Pour l’instant, je trouve que le cloud est de la suite «logique» de virtualisation. Une sorte de virtualisation «maitrisée», ie avec un API backend et un frontend simple et efficace. Je crois beaucoup au cloud privé qui permettra de gérer plus efficacement son infra d’un coté, et de simplifier les déploiements de l’autre. D’ou ma curiosité pour OpenStack.
Merci pour ton article. Il est vrai qu’une nouvelle idée du développement web apparait et ça va dans le bon sens.
Play ou Heroku vont vers ce sens. Le métier d’intégrateur prends tout son sens avec ces nouveaux frameworks.
De plus en plus de sociétés les utilisent d’ailleurs. C’est très bon signe.
« Heureusement il y a Play! Framework. »
En commençant la lecture de votre billet, je pariais avec moi-même de la présence de cette phrase magique ! J’ai gagné.
Je dirais à Raymond englué dans ses « WAR.EAR » de faire un plus long détour. Vers Ruby || Node.js || Python || Scala || Erlang || PHP && (une bonne WTF librairie JS), avant de revenir vers Java (7) et Play!. Et justement, j’ai une question. Quand sort donc ce foutu Play 2, sans python ? Car il est beaucoup plus difficile de vendre Play s’il faut installer Python sur les PC des développeurs. J’ai bon avoir du poids dans la hiérarchie, je sais que ça, cela est impossible. Donc une petit idée de la date ?
Ainsi, je pourrais évangéliser très vite vers Play! (même si nous savons tous ici parfaitement que Python est le meilleur langage du monde, d’ailleurs c’est Steve Jobs qu’il l’a inventé)
Ouups j’avais striké PHP ?! ABANDONNEZ PHP LES JEUNES !
@pj pour les développeurs sous windows il n’y a rien à installer, un simple dezip de l’archive Play et c’est prêt
Sous mac et linux les outils pythons sont généralement pré-installés
@pj Play! 2 est en principe prévu pour le début de l’année prochaine. On espère avoir une béta pour la fin de cette année, car 2 speakers présentent le framework à Devoxx mi-novembre : Nicolas Leroux et ma pomme.
Donc stay tuned.
Pour python+windows, la version de Play! sur Windows vient avec son python. En principe tu n’as rien à installer je crois. La justification de Python était que spawner une nouvelle Thread Java à chaque fois que l’on a besoin de faire du tooling est lent. Python est bien plus adapté et pratique. Cependant, et je te rejoins, cela peut poser des soucis sur Solaris 2.8/2.9 ou de vieilles version de Linux.
Donc attends la fin de cette année, et Play! 2 qui utilise SBT devrait te faire plaisir.
Ah ben mince alors ! Je ne savais pas que py était fourni avec la charette sous windows. En dehors du travail, je suis sous un OS moderne : linux. Cependant, de mon point de vue de vieux, l’intérêt de Play! est d’abord de travailler et de déployer avec un serveur léger (Netty of course), faire du REST/JSON, un peu de templating, utiliser les http-headers, avoir une démarche « router » plutôt que « naviger à la struts ». Par contre pour la partie UI, notamment pour des applications de gestion complexes (des trees, des forms, des grid en veux tu en voilà…) un très bon framework js, bien structuré genre dojo mais en mieux : qooxdoo. Bref des trucs qui plaisent aux jeunes qui s’ennuient dans les grosses DSI.
Si un oracle du Forrester annonce qu’il n’y aura plus de container sous peu, alors je pense qu’il faut qu’on se précipite sur les Tomcat, TomEE et autres !!!