Xebia passe la seconde, en organisant presque chaque mois des ateliers ou des soirées autour du Cloud. Rendez-vous pris donc mercredi dernier non pas pour aller dans le Cloud mais au 7ème étage chez Xebia France. Sacha Labourey, CEO de CloudBees et François, présentent le Cloud et les solutions de Cloud Bees. Cyrille Le Clerc, l’un des deux responsables techniques de Xebia France, avait bien préparé la soirée. Tout d’abord une présentation assez générale par Sacha, puis une bonne heure de discussions et de débats, animés avec des questions, que j’ai aussi embarqué pour pouvoir écrire ce billet (bon en fait Cyrille me les a donné).
Sacha Labourey ouvre la soirée. Ancien CTO de JBoss, futur speaker à Devoxx France 2012 et accessoirement Suisse de son état, il est venu accompagné de François Déchery, VP of International Business Development. Ils sont co-fondateurs de la société Cloud Bees.
Le Cloud en ce moment, c’est tout d’abord beaucoup de commentaires et aussi beaucoup d’émotions dans le sujet. Les changements et la rupture d’architecture et organisationelle sont importants. Ce sont des changements fondamentaux. Ce soir, Sacha va simplement démontrer les changements qui nous attendent. Le futur est quelque chose que l’on ne voit pas, mais que l’on créé.
Sacha s’arrête sur quelques idées pour ancrer son discours. Par exemple, votre enfant ne vous a-t-il jamais demandé pourquoi les vieux téléphones ont des fils ? Ma fille de 4 ans par exemple a découvert la cassette VHS chez les grand-parents, mais elle appelle cela un « gros DVD ».
Imaginez dans quelques années une discussion avec un informaticien. Peut-être qu’il sera étonné d’apprendre que vous développiez en local sur votre poste de travail. En tous les cas, je suis sûr qu’il sera étonné d’apprendre que vous travaillez avec Eclipse (et toc, ça c’est fait…).
Cette évolution et cet impact est comparable dans une certaine mesure à l’arrivée de l’électricité. A la fin du XIXème siècle, le luxe est de générer de l’électricité et de le partager avec d’autres. Les premiers générateurs d’électricité permettent de mutualiser le coût de production d’une ressource. De nombreuses entreprises se créent et l’électricité connait un essor important.
En 1881 Edison présente une génératrice à l’exposition universelle de Paris.
L’électricité connait un essor rapide de 1870 à 1907 à Paris. Le choix entre le continu et l’alternatif et les différents standards rendent assez compliqué s la distribution de l’électricité. Mais à cette époque, peu de bâtiments et de sociétés utilisent l’électricité. Celle-ci n’est pas encore une commodité.
En 1902 on se retrouve par exemple avec un découpage de Paris, où chaque secteur a son standard.
Ce que Sacha explique, c’est que l’informatique aujourd’hui est un peu prêt dans le même état que le réseau électrique en 1900 à Paris. Il existe différents producteurs, il n’y a pas de standards, le consommateur est encore un conso-acteur qui doit s’inquiéter du format, de l’ampérage et du type de courant…
Alors qu’en 2011, une prise standard vous donne de l’électricité. Aujourd’hui, nous avons de la résilience, et il est même possible de changer de fournisseur. Chaque mois, votre entreprise paye une facture d’électricité, comme une simple commodité. Pourquoi ne pas voir dans quelques années la même approche pour l’informatique d’entreprises ?
Sacha Labourey passe ensuite sur les centres de données. Quoique l’on en dise, les data-centers ne sont pas aussi beaux que sur les publicités IBM. Dans les faits, ils coutent chers, ils dégagent de la chaleur et ils demandent de l’électricité. Dans le futur, les lois et la protection des données seront peut-être plus stricte, à un tel point que les entreprises ne seront plus en mesure d’avoir un data-center rentable.
Aujourd’hui, l’informatique c’est de la haute couture : peu de réutilisabilité, peu de services, une intégration assez compliquée, un sentiment de parfois être un Artiste Héroïque plutôt qu’un vague Ingénieur…
Le Cloud c’est avant tout de l’infrastructure, avec au départ non pas des hébergeurs, mais des utilisateurs. Quelle est la société qui gagne le plus d’argent avec le Cloud ? Ce n’est pas un hébergeur, c’est Amazon. Un site qui vend des livres… Et qui aujourd’hui a créé un nouveau business model.
Sacha fait ensuite le parrallèle entre le coût d’un centre de données pour une entreprise, et l’intérêt à moyen-long termes pour une grande entreprise. Cette immobilisation financière n’est pas forcément stratégique pour des entreprises de taille moyenne. Par contre, il l’est pour un Google et un Amazon. La question du Cloud se pose donc avant tout pour les utilisateurs finaux et les entreprises classiques.
Sacha espère que le Cloud Computing sera une commodité, comme l’électricité aujourd’hui. Vouloir faire de la haute-couture pour tout, ce n’est pas rentable. La crise financière actuelle aura même peut-être un effet sur les DSI. Nous pouvons même supposer que les équipes du métier, qui continuent à avoir besoin de l’informatique, n’attendrons pas que la DSI s’en remettent.
Je rêve aussi personnellement que certaines DSI qui ne vivent que grâce à deux ou trois grosses SSII iront se planter rapidement, histoire de laisser la place à une nouvelle relation entre le client, et les gens qui codent, nous.
Sacha termine par une citation à méditer :
If you don’t like change, you’re going to like irrelevance even less.
General. Erik Shineski
J’en ajoute une aussi pour la route et qui colle bien à CloudBees :
“Never doubt that a small group of committed people can change the world. Indeed it is the only thing that ever has.”
Citation de Margaret Mead
Définition du cloud
Sacha Labourey présente ensuite les différents types d’architectures dans le Cloud. SaaS, PaaS ou IaaS, tout ceci c’est pas mal de jargon. Mais il est important de comprendre qu’il y a différentes architectures, pour différents usages.
- SaaS (SalesForce, NetSuite, ZenDesk,HubSpot)
- Paas( CloudBees, heroku, app engine vmForce database.com)
- Iaas (Amazon Web Services, RackspaceCloud, terremark, Eucalyptus System)
- Cloud computing->informatique à la demande, accès à des ressources virtualisées.
Le SaaS : solution assez rigide, c’est l’utilisation du service qui prime sur les principes d’architecture. Le SaaS est particulièrement adapté à l’approche orientée solutions comme SalesForce. Quelque part, votre GMail c’est du SaaS si vous voulez.
PaaS : le Platform as a Service est l’étage où vous pouvez placer CloudBees. Cette couche intermédiaire redonne l’environnement de développement et surtout de production habituel. Les serveurs, les logiciels, la montée en charge sont cependant gérées par la plate-forme. Il y a différentes philosophies selon les vendeurs sur PaaS. Personnellement j’aime beaucoup Heroku pour l’approche orientée production.
IaaS : c’est de l’Infrastructure as a Service. A cette étage de la fusée, vous avez plus ou moins un méga réseau élastique, mais il faut travailler pas mal pour réellement tirer partie de l’IaaS. Amazon Web Services est la solution la plus populaire mais il en existe d’autres.
CloudBees
Alors que fait CloudBees ?
Solution de PaaS, CloudBees gère le cycle complet du logiciel. De la compilation à la mise en production, puis à l’exploitation. Cloud Bees veut devenir le leader de la solution Java pour Cloud. Fort de l’expérience de JBoss, Sacha vise rapidement une place sur le podium, afin d’apporter tout le savoir faire du monde Java Enterprise vers le Cloud.
Cloud Bees c’est aussi déjà un bon nombre d’outils et de services d’entreprises, prêt à l’emploi. Côté développement, vous pouvez démarrer un projet avec une forge logiciel, avec JFrog, Sonar ou XWiki. Côté production, on retrouve des outils populaires comme New Relic ou Mongo HQ. Il y a encore un peu de travail avant de rattraper la liste des AddOns d’Heroku, mais franchement c’est bien.
CloudBees c’est donc 2 ruches distinctes : Dev@Cloud et Run@Cloud. J’en ai déjà parlé sur le Touilleur Express à l’occasion de la présentation de N.De Loof au RivieraDev.
DEV@Cloud est un environnement de développement avec intégration continue basée sur Jenkins, repository Maven privé, et j’imagine rapidement des outils comme bug tracking ou autre.
RUN@Cloud est l’environnement d’exécution de votre application. C’est donc avant tout le moyen le plus simple de déployer une application Java dans le Cloud.
Conclusion
Sacha Labourey a quelque chose d’indispensable : une vision. Loin de la soupe technique, il sait ce que CloudBees doit faire pour réussir. Alors que pas mal de monde s’intéresse aux caractéristiques du Cloud, lui s’intéresse à la finalité et aux futurs services. Cette approche est importante, car certains éditeurs de logiciels empilent les version de leurs logiciels les unes après les autres, mais n’ont pas de mission. Ils ne savent pas expliquer « POURQUOI » leur solution est intéressante. Ils empilent les présentations sur ce que FONT TECHNIQUEMENT leurs solutions, alors que le plus important est de savoir pourquoi elles existent.
Ensuite, CloudBees si j’ai correctement compris, fait le choix de ne travailler qu’avec Java pour l’instant. Pas de Groovy ou de Scala. A voir à moyen-long terme si cela ne change pas.
CloudBees est clairement une solution pour les développeurs Java modernes. Si vous êtes habitué à utiliser Maven, à faire de l’intégration continue avec Jenkins, à faire de la mise en production vers un Apache Tomcat, c’est une solution qui vous fera gagner du temps. Un autre intérêt, c’est que finalement CloudBees abstrait l’IaaS et offre de la fléxibilité sans vous locker sur une infrastructure.
Les concurrents de CloudBees ? Le premier qui me vient en tête c’est Heroku. J’aime beaucoup l’approche différente d’Heroku. Les Add-Ons sont plus nombreux que ceux de CloudBees pour l’instant. Vous pouvez faire du Ruby, du Scala, du Java, du PHP ou du Python… et avec 510 000 applications en production, Heroku n’est pas un petit joueur.
CloudFoundry est assez similaire, et permet déjà de faire tourner autre chose que du Java. C’est surtout une solution open-source. N’ayant pas testé CloudFoundry, je n’ai pas d’avis sur la plateforme.
Il existe beaucoup de PaaS, mais je retiendrai que CloudBees est avant tout pensé et adapté aux développeurs Java.
Et mine de rien, on est 10 millions de développeurs dans le monde.
A suivre donc…
Ressources
Vous pouvez tester et découvrir les solutions CloudBees en version d’évaluation sur leu
Salut,
pour info: CloudBees héberge sans problème tout ce qui tourne sur la JVM (Grails, Play!, Lift, Clojure, etc). Nous proposons les outils/plugins adaptés sur DEV, et le déploiement sur RUN sous forme de war (pas de natif Play!, en tout cas pas à ce jour).
Nicolas,
Merci pour l’article!
Petit correctif: bien que nous ne souhaitions pour l’heure pas ouvrir la plateforme CloudBees RUN à d’autres environments que la JVM, nous pouvons par contre tout à fait faire fonctionner les langages basés sur la JVM, par exemple: Grails, Scala, Clojure, CFML, JRuby, etc. http://blog.cloudbees.com/2011/10/let-war-file-be-unit-of-deployment.html
En ce qui concerne DEV et l’intégration continue, tu peux compiler/tester d’autres environments que Java: C, C++, Ruby, PERL, etc.
A bientôt
Grails possede un plugin Cloudbees, http://grails.org/plugin/cloud-bees
L’auteur le maintient activement et le mets a jours régulièrement.
ne pas oublier openshift https://openshift.redhat.com/app/ dans les concurrents de Cloudbees
La comparaison cloud/électricité est un classique mais je ne suis pas certain qu’elle soit la plus vendeuse quand on regarde l’évolution du marché de l’énergie…
Elle illustre notamment une dérive possible mise en avant par les détracteurs du cloud : la domination du marché par quelques très gros acteurs avec un manque de concurrence pouvant avoir un impact sur les prix, sur la qualité du service (cf la Californie encore récemment), sur l’adoption de nouveautés technologiques (cf les compteurs intelligents en France).
La comparaison risque aussi de prendre l’eau si on considère les avancées en matière de production autonome d’électricité, pour l’instant sont surtout concernés les particuliers et quelques très grosses entreprises (notamment Google) mais on voit bien se dessiner une tendance qui est d’essayer de reprendre en main sa production électrique.
Je suis aussi étonné par cette phrase: « Quelle est la société qui gagne le plus d’argent avec le Cloud ? Ce n’est pas un hébergeur, c’est Amazon ». Il me semblait qu’Amazon n’avait jamais communiqué sur la contribution d’AWS à ses résultats ? Ca serait très intéressant d’avoir un lien avec ces chiffres.
Bonjour,
J’ai encore du mal à percevoir le PAAS et l’abstraction que cela impose comme un avantage. Je me souviens de développeurs qui s’arrachaient les cheveux pour faire tourner hibernate+gwt sur GAE, est-ce un progrès de devoir développer en fonction des particularités de la plate-forme de développement ? Depuis 20 ans les couches s’empilent pour que les applis soit agnostiques par rapport au hardware et à l’os et là on en arrive à composer en fonction de l’hébergeur. J’ai lu que sur windows azure par exemple, tous les types de données n’étaient pas supportés sur le RDBMS (!!)
Par ailleurs comment mettre en oeuvre des cas aussi simple que :
* mon application sur le cloud est sécurisée, l’authentification et la gestion des autorisations se fait sur une base utilisateur LDAP (et évidemment le serveur active directory est en local chez l’entreprise)
* un serveur cognos ou BO se connecte à ma base de données pour construire des cubes
* des excels sur un serveur de partage (local à l’entreprise) se connectent à des vues de la base de données pour présenter des tableaux croisés dynamiques.
Par contre là je travaille avec une boite qui choisit de migrer leur serveurs (AD, SQL, App, Exchange, web) sur un environnement virtualisé VMWare avec location au mois de l’ensemble (les vm, les licences des windows, exchange, sql server). On arrive à une architecture scalable (resources CPU, RAM et disque ajustées à la demande) en restant maitre de son environnement mais sans s’occuper de la manière dont les VM sont hostées par les machines physiques (cluster ou je ne sais quoi, etc…). Ca me semble etre le bon compromis, pouvoir se connecter en remote desktop a un serveur est parfois pratique et rassurant.
En tout cas je serai curieux d’avoir des exemples d’application d’entreprises (= non anecdotiques) hebergées sur un cloud.
Bonjour,
Voici la vidéo de la soirée !
Nous commençons par la présentation de Sacha (20 minutes) : http://blog.xebia.fr/2011/12/08/video-de-la-presentation-de-sacha-labourey-sur-le-cloud/ .
Nous sommes en train de monter la vidéo de la séance de questions/réponses de deux heures (elle sera décomposée en 4 épisodes).
Merci encore à tous ceux qui ont enrichi la soirée de leurs questions et témoignages,
Cyrille
PS : la vidéo est aussi accessible en podcast : itpc://blog.xebia.fr/feed/podcast/ et http://blog.xebia.fr/feed/podcast/
« En 1902 on se retrouve par exemple avec un découpage de Paris, où chaque secteur a son standard.[…] l’informatique aujourd’hui est un peu prêt dans le même état que le réseau électrique en 1900 à Paris. Il existe différents producteurs, il n’y a pas de standards, le consommateur est encore un conso-acteur qui doit s’inquiéter du format, de l’ampérage et du type de courant… »
Elle est bien gentille, cette comparaison entre l’électricité d’arrière-grand-papa et l’informatique d’aujourd’hui. Mais vous êtes vous posé la question du « comment est-ce arrivé ? » Qu’est-ce qui a fait que le courant électrique a été standardisé entre 1902 et aujourd’hui ?
A l’échelle de Paris, je n’ai pas la réponse, mais à l’échelle de la France, la réponse est très claire : avant 1946, il existait en France 1000 à 1500 entreprises de production, de transport et de distribution d’électricité, qui ne produisaient/fournissaient pas toutes la même tension électrique et/ou le même type de courant. Il a fallu la nationalisation et la fusion de l’ensemble de ces entreprises en une seule (EDF), pour qu’un plan de standardisation du courant (tension, type) soit mené à l’échelle du pays entier, aussi bien en termes de production que de distribution à l’ensemble des acteurs économiques (qui s’est étalé de 1956 à 1991, quand même…).
Sans cette nationalisation, il aurait malgré tout fallu une intervention étatique très forte et dirigiste pour imposer à toutes les entreprises du secteur un seul et même standard de courant, via une législation appropriée (quitte à provoquer la disparition de certaines de ces entreprises, si les changements à effectuer dans leur appareil industriel sont d’une trop grande ampleur et donc trop coûteux).
Et ne croyez pas que la standardisation du courant électrique aille de soi. Dans d’autres pays, comme par exemple au Japon (que l’on peut raisonnablement considérer comme un pays développé…), le courant n’est pas du tout unifié à l’échelle du pays : dans les prises, vous trouvez du 220 V/50 Hz au sud, et du 110 V/60 Hz au nord, typiquement.Et on retrouve cette variété du côté de la production. (C’est d’ailleurs à cause de cette non-unification du courant que l’arrêt des nombreuses centrales électriques touchées par le séisme et le tsunami de mars dernier, au nord du pays, n’a pas pu être compensé par une utilisation plus intensive de centrales qui n’avaient pas été touchées par ces deux catastrophes parce que situées au sud du pays : il n’y a pas de réseau unique et intégré à l’échelle du pays, parce qu’il n’y a pas de standard de courant, ni en haute, ni en basse tension.)
Nationalisation du secteur ?!? Ou, pour le moins, intervention étatique forte et dirigiste ? Est-ce vraiment là des options que vous envisagez pour le secteur de l’informatique ?!? J’ai comme un doute…