Voici la retranscription de la soirée du Paris JUG du 5 juillet, dédiée au Cloud.
A l'origine, seul Patrick Chanezon devait intervenir, mais toute la clique du cloud à la Française ayant été prévenue de la soirée, ce sont finalement 6 speakers qui se sont partagés la scène - même si les derniers ont dû parler très vite compte tenu du planning particulièrement serré !

Cloud par-ci, cloud par-là, tant et si bien qu'en sortant il pleuvait... Les aléas de la météo font parfois écho à ceux de la technique.

A propos de technique, l'absence de réseau m'a empêché de vous proposer une Wave (sisi, ça existe encore), mais Antonio m'a laissé entendre que des dispositions seraient prises à la rentrée pour bénéficier des ondes bienfaitrices du Wifi. Je croise les doigts.
J'ai néanmoins pris quantité de notes off-line, que je vous présente ci-dessous, un peu retravaillées. Armez-vous d'un grand café, car il y a beaucoup de lecture !

Patrick Chanezon, Google

Mail : chanzeon /at/ google.com
Twitter : @Chanezon

Patrick Chanezon est un ingénieur français, passé par Centrale Lyon, puis ayant travaillé aux USA chez Accenture, Sun, pour terminer chez Google où il s'occupe des APIs.
Chez Google, la culture de l'API est importante. Ils conçoivent d'abord les services complexes du coeur des applications, puis les rationalisent sous forme d'APIs, et construisent ensuite seulement les interfaces clientes (web, mobile, WS...) par-dessus ces API.

Petite météo du cloud

"The future is already here, it is just not evenly distributed".
Nick Carr compare l'arrivée du cloud à l'arrivée de l'électricité au début du siècle dernier. C'est quelque chose qui va révolutionner le métier de développeur, qui devient de l'artisanat plus que de l'ingénierie : moins de processus, moins de lourdeur, du passage de connaissance communautaire... L'outil de production s'industrialise, mais le savoir est plus que jamais artisanal, tourné vers l'expertise et la qualité.

D'après un sondage à main levée, seules quelques personnes dans la salle utilisent du cloud actuellement - et la plupart travaillent chez des éditeurs de ce type de solution (CloudBees, VMWare...). On pourrait donc penser que cette technologie est encore assez confidentielle ; mais en y réfléchissant bien, elle est déjà en train de s'imposer silencieusement auprès grand public (cf. iCloud, Steam...). Il faut donc réagir rapidement !

Mais revenons en arrière. Il y a 30 ans, la SF nous promettait des robots à tous les coins de rue, des voitures volantes et la domotique pour tous. Cette prophétie ne s'est toujours pas réalisée, mais des progrès fulgurants ont été réalisés dans un autre domaine : la communication et l'information. Aujourd'hui, les volumes de données explosent. Malheureusement, si la loi de Moore s'applique bien pour le hardware, elle ne fonctionne pas pour le software : les performances sont loin d'être aussi spectaculaires.

Mais on est en plein changement d'architecture :

• Dans les années 60, tout le processing était cantonné côté serveur (Mainframe).
• Dans les années 80, c'est la mode du client/serveur, notamment grâce à l'apparition de machines personnelles puissantes (pour l'époque naturellement) ; le traitement est donc local, mais les données restent côté serveur (Oracle...).
• Dans les années 90, passage au web ! Ce qui est en quelque sorte un retour en arrière car le client redevient un simple afficheur.
• Dans les années 2000, apparition de XHR et donc d'Ajax : le client redevient un acteur, mais est encore limité.
• Enfin, cette année, c'est le côté serveur qui s'étend à nouveau, grâce au cloud.

On voit que le même cycle se répète avec une période de 10 ans environ.

Actuellement, le cloud est tout en haut de la fameuse courbe time/expectations : c'est le buzz du moment, tout le monde est enthousiaste et les projets fleurissent. Les technologies sont encore jeunes et peu de projets en tirent parti. Les premiers retours d'expérience concrets, notamment négatifs, ne devraient pas tarder ; la nécessaire stabilisation des offres et la concentration du marché ne devraient pas intervenir avant quelques années.

Quels fournisseurs ?

A l'origine, le cloud a été mis en place par des grosses sociétés pour manipuler d'importants volumes de données, obtenir une scalabilité verticale, virtualiser les environnements... L'architecture en cloud permet de transformer la plateforme en un simple produit, utilisable et facturable à la demande. L'utilisation de multitudes de machines standards à la place de quelques gros serveurs permet également de réduire les risques de rupture de la plateforme, et de remplacer les noeuds défectueux rapidement et à moindre coût.

Amazon a été le premier à louer ses infrastructures. Ses clients bénéficiaient ainsi d'une plateforme éprouvée, et limitaient leur charge d'entretien.

Chez Google, tout est parti d'un papier de Larry Page et Sergey Brin (les fondateurs) qui décrit l'infrastructure idéale d'un moteur de recherche à grande échelle. L'infrastructure de Google est composée d'éléments standards, la plupart open-source : machines simples ("commodity hardware"), Linux...
Le système est tolérant à la panne grâce à GFS (leur filesystem réparti), les données en mémoire distribuées via BigTable, et les traitements parallélisés grâe à des opérations de type Map/Reduce. Des langages personnalisés (DSL) permettent de faire fonctionner tout le système (ex: Sawzall permet de piloter le Map/Reduce facilement, et non pas en C bas niveau). Plusieurs niveaux d'abstraction existent ; par exemple, BigTable peut être vu comme une simple HashMap distribuée ; par-dessus s'empilent des couches plus haut niveau comme MegaStore, puis DataStore (utilisable sur Google App Engine).

Un cloud, pour quoi faire ?

Economiquement, le recours au cloud a du sens. Des études montrent que la proportion du coût de l'électricité dans le coût global de traitement informatique devient très significatif. De même que les opérateurs "offrent" des téléphones avec leurs forfaits, peut-on imaginer qu'EDF propose un jour des ordinateurs à ses clients ? Il devient donc intéressant de louer du temps de traitement plutôt que d'héberger ses propres serveurs : "pay as you go".
Les gros datacenters investissent beaucoup dans la recherche de l'efficacité énergétique. Facebook a publié les spécifications de leur matériel conçu ad-hoc ; Google a également publié des études sur la composition de leurs fermes de calcul. Pour autant, ce sont des économies d'échelle, et un datacenter privé sera généralement moins économique qu'un gros cloud partagé.

Culturellement, il y a également des changements importants. De plus en plus, les applications sont considérées comme jetables, en particulier les applications "sociales" (type Facebook) ou mobiles, qui ont une durée de vie courte mais qui doit être exploitée et monétisée avec un rendement maximum. Elles deviennent donc peu à peu de simples produits de consommation courante, qui suivent une mode éphémère.

Enfin, les développeurs préfèrent passer du temps à coder plutôt qu'à administrer des plateformes, qui deviennent de plus en plus complexes. Cela leur permet de livrer et tester rapidement les nouvelles fonctionnalités et d'avoir un feedback immédiat - quitte à faire des erreurs, autant les détecter rapidement et les corriger plus rapidement encore. Les méthodes agiles trouvent ici une application évidente.

Chez Google, l'échec fait partie de l'apprentissage et n'est pas sanctionné (sauf fautes graves évidemment). Patrick, à sa grande surprise, a été félicité alors qu'un contrat qu'il supervisait était tombé à l'eau, car "il fallait essayer". Tester de nouvelles idées est ainsi vivement encouragé. Qui sait si, après neuf idées infructueuses, la dixième ne sera pas révolutionnaire ?

Une migration progressive

D'une manière générale, le software se déplace progressivement vers le cloud, et on peut identifier 4 grandes ères :

• Delivery (94, Netscape) : consommation de services distants,
• Infrastructure (2002, AWS) : provisionning de machines
• Plateforme (2008, GAE) : PAAS. On pousse le code sur le cloud, et celui-ci se charge de scaler l'infrastructure.
• Développement (maintenant!) : Cloudbees, Exo IDE... Patrick explique que pour coder, aujourd'hui, on est obligés de disposer de machines puissantes. Les portables performants ne sont pas très portables et très chers. Un IDE dans le cloud permet au contraire de coder depuis n'importe quel terminal connecté.

1. Delivery / Monetization / Marketing
Beaucoup d' appstores apparaissent, autant de possibilités de monétiser nos applications. Mais le risque de fragmentation est réel ; attention à ne pas se lier à une unique plateforme ("Be your own Bitch") ! En particulier, quels sont les risques si la plateforme change ses conditions d'utilisation (ex: Twitter vs Seesmic) ? Il est difficile de déterminer la stratégie à long terme de ces plateformes : votre application leur fera-t-elle compétition dans quelques mois ?

2. Infrastructure
On constate un début de standardisation, mais la bataille des standards fait rage. Le mieux actuellement est d'être compatible multi-cloud, afin de ne pas se faire enfermer dans une technologie possiblement condamnée. Chouette, une nouvelle couche d'abstraction !

3. Plateforme
Google AppEngine a été le pionnier, mais de nouvelles offres apparaissent : Joyent, Heroku, Stax/Cloudbees, Amazon Elastic Beanstalk, Azure... Les langages supportés sont différents, les offres varient... Difficile de quitter une plateforme une fois qu'on a enfin réussi à faire tourner notre application dessus !
CloudFoundry est une offre complète qui permet d'abstraire les clouds. C'est un socle opensource, multi-langages, multi-bases... Davantage d'informations plus loin.

4. Développement
C'est le buzz du moment. Les offres actuelles permettent d'héberger, développer, tester et assembler des applications depuis un simple navigateur.

Ce qui change pour les développeurs

Le "distributed computing" commence à rentrer dans le quotidien du développeur. Les nouveaux langages comme Erlang, Scala, Goo proposent des constructs adaptés. Patrick recommande fortement d'apprendre l'un de ces nouveaux langages. De même, les bases de données de type NoSql offrent de nouvelles possibilités intéressantes, même si, ironiquement, elles reprennent les concepts des bases hiérarchiques d'il y a 20 ans.

Lorsqu'on programme pour le cloud, il faut changer de paradigme de développement, et prendre conscience que le code sera exécuté dans un environnement dynamique et extrêmement distribué. Notamment, il faut parfois savoir oublier les formes normales pour les données, car le coût de stockage des informations dupliquées est bien inférieur à celui d'exécution de jointures entre les tables, en termes de temps d'accès et de charge CPU.

Cela peut faire peur, mais en réalité on peut se contenter d'une "eventually consistence" (cohérence à terme). Patrick prend ici l'exemple de Starbucks, qui n'effectue pas de "2-phase commit" à la caisse : le café est préparé dès la commande, avant même le paiment. Le gain de temps obtenu compense très largement les éventuels désagréments (le client change d'avis ou ne paie pas...)

Pour Patrick, le développeur de cloud devra nécessairement :

• oublier les vieilles habitudes (forme normale...)
• apprendre de nouveaux langages : Scala, Go
• utiliser les nouvelles technologies du web (html5, etc.)
• repenser les applications en fonction des limitations des clouds (ex: request timeout 30s sur Google AppEngine)
• apprendre à décrypter les conditions d'utilisation et les business plans des plateformes (clouds, appstores...)

Conclusion

Notre travail va changer. Et celui des administrateurs systèmes risque de disparaître bientôt de chez les clients, pour se concentrer chez les fournisseurs de clouds.
Ou pas. A suivre...

Didier Girard, Sfeir

Didier Girard est directeur technique chez Sfeir.

Contrairement aux idées reçues, le principal bénéfice du cloud n'est pas forcément son coût réduit. C'est aussi un gros accélérateur de projet, notamment si le budget initial est faible ou non sécurisé.

Sur un projet récent, une équipe de Sfeir a utilisé Assembla pour la gestion des sources et les tickets, CloudBees pour le build, et AppEngine pour le déploiement. La compilation, l'assemblage et le déploiement sont totalement automatisés. Effet secondaire de la dématérialisation du projet : il suffit que les développeurs aient accès à Internet pour bénéficier de toute la plateforme instantanément. Il est également très facile de présenter l'avancement de l'application au client.

Pour Didier, le cloud, c'est aussi un accélérateur d'innovation. Entre la naissance d'une idée et sa réalisation, il s'autorise 5 jours maximum : c'est un investissement faible qui permet de tester rapidement des concepts, et le délai court permet de conserver la motivation intacte. La créativité est maximale et le risque minimal.
Par exemple, Didier a récemment découvert la librairie ForPlay qui permet de réaliser des jeux portables (flash, html5...). Il a accordé deux jours à ses développeurs pour reproduire l'une des applications de démonstration du framework, qui simule la vie d'un aquarium. Il a également développé un lecteur mp3 pour Chrome, disponible sur le Chrome Store.

Le cloud, c'est aussi une histoire d'agressivité. Un petit David bien outillé peut aller chasser sur les terres de certains Goliaths.
Ainsi, Didier a développé l'application "A bon entendeur", un détecteur de radar concurrent de produits commerciaux. Avec plus de 4000+ utilisateurs simultanés en pic, c'est un franc succès. Le fait qu'elle soit hébergée à moindre frais sur Google AppEngine permet de la proposer gratuitement sur les différents appstores.

Le cloud c'est encore une histoire de mérite. La taille d'une SSII et ses moyens financiers n'est plus un critère. Il est possible de gagner un très gros projet, nécessitant une infrastructure importante, puisque la plateforme et la scalabilité ne sont plus un problème.

Enfin, le cloud c'est une histoire de sérénité. La scalabilité n'est plus un problème, même avec des pics importants (par exemple, l'application qui gère la conférence des évèques de France est très sollicitée à Noël et Pâques). Et puis, il n'y a plus besoin de se soucier de la maintenance de la plateforme, ni d'entretenir une armée d'administrateurs systèmes.

En conclusion, le cloud permet la démocratisation des plateformes IT pour les développeurs - y compris les développeurs individuels ou les étudiants.

Aujourd'hui, Sfeir utilise Assembla, GitHub, CloudBees, AWS... 10% de leur activité tourne déjà autour du cloud. Didier pense que l'émergence du cloud est inévitable, même si on est encore dans des temps chaotiques. La standardisation arrivera plus tard - Java EE 7 se penche déjà sur le sujet.

Guillaume Laforge, VMWare/SpringSource

Guillaume Laforge est à l'origine des projets Groovy, Grails et Gaelyk. Il travaille chez SpringSource, division de VMWare.

Guillaume vient nous parler de CloudFoundry, qui tourne autour de 4 concepts : PAAS, multi-langage, multi-framework, opensource.

Le terme PAAS (Platform As A Service) désigne un ensemble de services intégrés, constituant une plateforme matérielle et logicielle prête à l'emploi. Celle de CloudFoundry propose les derniers frameworks disponibles, un moteur de rendu au choix (servlets, rails, node.js...), ainsi qu'un provisioning d'infrastructure automatique. La plateforme est gérée comme un simple service et est simple à administrer. Il suffit donc de créer une application puis de la déployer sur le cloud.

L'avantage de CloudFoundry est de limiter les adhérences à un hébergeur de cloud spécifique. Il n'y a pas de limitation arbitraire. Plusieurs langages (java, .net, ruby...) sont supportés, ainsi que plusieurs fournisseurs de cloud (GAE, Azure, Heroku...).
CloudFoundry lui-même étant open-source, il est possible d'analyser son code, de le modifier et de l'étendre. Cette particularité autorise les entreprises à l'utiliser sur leurs plateformes internes, et les développeurs à déployer des micro-clouds sur leurs machines de développement.

Guillaume fait maintenant une démonstration du produit.
Après avoir créé la structure minimale d'une application web d'entreprise et importé la librairie Groovy, il code un .gtpl (Groovy Template, l'équivalent d'une JSP) et un contrôleur affichant la date courante. Le déploiement sur les serveurs publics de CloudFoundry s'effectue ensuite à l'aide de la commande vmc push parisjugdemo, qui en profite pour demander des précisions sur les services à provisionner (type de serveur, base de données, etc.). Mais, horreur ! L'application a un bug. Après correction, un simple vmc update parisjugdemo permet de la redéployer instantanément.

Conclusion: l'infrastructure est vraiment devenue un simple service dont le développeur ne devrait plus se préoccuper.

Nicolas DeLoof, CloudBees

Nicolas est le président du Rennes JUG et travaille chez CloudBees

CloudBees propose deux offres : dev@cloud et run@cloud.

• le premier adresse toutes les problématiques d'industrialisation du développement, et fournit des services de gestion des sources (git, svn), de build (Maven) et de test (Jenkins, Sonar) ;
• le second consiste en une plateforme de production moderne équipée des services les plus courants (base MySql, haute disponibilité, monitoring...).

La facturation se fait à la minute (Nicolas explique finement qu' "On paye à la PAAS"), ce qui permet de s'adapter à tous les budgets et au cycle de vie des projets.
Il est également possible de privatiser la plateforme, et de l'héberger sur un cloud (interne ou externe) spécifié par le client.

L'écosystème CloudBees est extensible, et de nouvelles fonctionnalités sont ajoutées régulièrement (compilation avec Ant, etc.)

Erwan Arzur, RunMyProcess

RunMyProcess propose un environnement graphique permettant de déployer des process sur le cloud. C'est de l'orchestration de service.

Lors du blackout récent d'une partie du cloud d'Amazon, beaucoup de sites à fort trafic ont été très perturbés (Digg...). Ils ont alors pris conscience de la fragilité possible des infrastructures de type cloud, et de nombreux articles ont fleuri sur Internet pour expliquer comment se prémunir des SPOF (single point of failure).

Cas extrême, Netflix possède un processus, nommé ChaosMonkey, qui teste en permanence la résilience de sa plateforme en désactivant des services ou des composants de manière aléatoire. C'est osé !
Quant à RunMyProcess, ils ont provisionné des serveurs dans plusieurs partitions Amazon isolées, pour être moins vulnérables.

Mais si un incident survient tout de même, des solutions comme Chef et Puppet peuvent aider à reconstituer rapidement une plateforme stable. Ces outils sont capables de préparer des fermes entières de machines, en déployant automatiquement des packages logiciels configurés de manière centralisée. En cas de perte d'une machine sur le cluster, une autre peut rapidement être préparée avec la même configuration..

Conclusion

Cloud, cloud, cloud... C'est le buzzword de l'année, et probablement de l'année prochaine également. Autant s'y préparer, même si leur adoption en entreprise risque de prendre du temps...

N'ayant pas eu le temps de m'intéresser au sujet avant ce soir, j'ai découvert avec intérêt certaines des technologies présentées (CloudBees et CloudFoundry), et avec scepticisme certaines autres (en particulier les IDE web).
Quant à savoir si j'aurai l'occasion de les utiliser... Il faudrait tomber sur un client particulièrement avant-gardiste ! Et pour une utilisation personnelle, ne serait-ce que pour tester, le manque de visibilité sur le coût réel de ces services me freine un peu, j'avoue.

En tout cas, je vais continuer à suivre tout ça du coin de l'oeil, pour voir où tournera le vent ces prochaines années.
Je me demande si le cloud subira le sort d'OSGi, également présenté comme une révolution à sa sortie... On verra bien !

Références

• Google AppEngine
• CloudBees
• CloudFoundry
• Run My Process
• A bon entendeur