196 personnes au total ce soir au Paris Java User Group, dans une salle bien remplie. Nous expérimentons l’inscription et l’accueil avec EventBrite, et cela se passe plutôt bien. Sur scène, le ParisJUG a le plaisir de recevoir ce soir pour la première fois Patrick Chanezon, Developer Advocate, Cloud et & Apps. A travers une présentation du Cloud, Patrick va nous parler des nouvelles opportunités et des impacts du Cloud dans nos métiers.
Pour la deuxième partie, il passera la parole à des speakers connus de la communauté Java. Didier Girard, directeur technique de SFEIR, nous parlera de son point de vue intégrateur. Guillaume Laforge présentera CloudFoundry. Nicolas de Loof présentera CloudBees. Erwan Arzur travaille chez RunMyProcess. Enfin Jérémi Joslin d’eXo Platform, présentera une démo de l’IDE dans le Cloud.
Patrick Chanezon est basé à San Francisco, il a travaillé successivement chez Accenture, Netscape, SUN Microsystems et enfin Google. Il s’est occupé tout d’abord des APIs. Il a été embauché pour les relations développeurs. Aujourd’hui il y a 70 produits, mais Patrick a travaillé aux premiers efforts de relation entre les développeurs et Google. Il débute sa présentation sur un concept simple : le futur est là aujourd’hui mais il n’est pas distribué de manière uniforme. Patrick nous conseille de potasser cet été sur les technologies du Cloud et de bronzer utile, pourvu qu’il n’y ait pas de nuages.
Qu’est-ce qui est devant soit et que l’on ne peut pas voir ?
Réponse : l’Avenir (source : Flamby)
Lorsque nous étions jeunes, nous avions une vision de l’an 2000 très futuriste. Or aujourd’hui nous en sommes où ? Charles Stross, dans Accelerendo parle de Singularité. Si la loi de Moore s’applique bien au silicium, il ne s’applique pas à l’humain.
Patrick explique cependant que nous vivons en ce moment une révolution dans l’informatique avec les principes du Cloud. Dans les années 60, apparition du mainframe. Dans les années 80, apparition du PC, l’apparition du mode client-serveur. Pour lui, nous vivons en ce moment une nouvelle ère. Dans les années 90 nous avons eu l’apparition du web. D’un point de vue technique, nous étions revenu au mainframe. Finalement le Netscape de l’époque ne faisait pas plus de travail qu’un terminal VT100. Or cette architecture est entrain de changer, le client reprend de la puissance. Depuis 2010, nous devons comprendre que les technologies HTML5, le Cloud et le Mobile vont changer durablement la manière d’écrire nos applications. Le navigateur devient un système d’exploitation à part entière. Le téléphone mobile s’appuie sur du matériel très puissant. Enfin le Cloud apporte une flexibilité et une capacité de croissance encore inimaginable.
Finalement, nous revenons au Client-Serveur.
Mais nous sommes en 2011… Et c’est la différence.
Patrick Chanezon va parler du Cloud. Sur une courbe Gartner, on voit que le Cloud est en 2011 en haut du pic d’adoption. Les désillusions ne sont pas encore là. Tout a commencé sur les sites grands publics comme Google, Amazom, Yahoo ou Twitter. Ce sont des sociétés qui se sont retrouvées avec une masse énorme de données et de clients. Google vers 1998 a utilisé non pas des serveurs puissants mais un grand nombre de petits PCs pour monter en charge. A l’opposé de l’idée de SUN Microsystems. Google est passé d’un mode de scalabilité vertical à un mode horizontal.
Cette idée est simple : une machine tombe en panne. Adaptons notre software pour que notre système fonctionne, même lorsque ce nœud tombe. Plutôt que de réparer, il sera plus intéressant de changer la machine, et la reprise sera effectuée par l’application.
Amazon a créé un énorme parc de machines. Le CTO a eu l’idée de louer finalement le temps inutilisé de son parc informatique. De fil en aiguille, Amazon est devenu un des leaders des plateformes Cloud. D’un point de vue logiciel, ces projets ont libéré la créativité des plus gros projets open-source. Finalement, les belles innovations de ces 3 dernières années s’appellent MongoDB, Voldermort, Cassandra ou Neo4J…
L’open-source a joué aussi un grand rôle dans la standardisation. Linux, les couches de software open-source, sont autant de catalyseurs qui ont permis l’essor du Cloud. En fait, depuis que nous ne pensons plus en terme de licence, depuis que nous avons enterré la vision du DVD d’installation et de la bonne grosse licence à 20 000 USD, nous avons vraiment commencé à être prêt pour le Cloud.
En effet, aujourd’hui je n’achète pas un logiciel. J’achète un service. Je pense que je n’achèterai plus de traitement de texte. J’achèterai la possibilité de créer un document et de le stocker sur Internet. Si Microsoft a été le roi du XXème siècle, Google et Facebook sont bien partis pour prendre une place importante au XXIè siècle.
Programmer dans le Cloud
La programmation dans le Cloud est aussi un nouvel eldorado à découvrir. Patrick parle de l’algo Map-Reduce. Plutôt que de remonter la donnée, vous allez faire descendre l’algo au plus près de la donnée. C’est par ce moyen, que Google peut calculer des statistiques comme le PageRank. Yahoo! a sorti le projet Hadoop. Les DSLs aussi sont des sujets qui font partie du Cloud.
BigTable est une Hashmap distribuée. Au dessus de BigTable, de nouveaux logiciels sont apparus. Si vous codez sur AppEngine, ce sera sur le DataStore, une abstraction au dessus de BigTable.
Google propose le High Replication DataStore. Ce système permet de s’assurer que votre donnée est répliquée géographiquement dans différents DataCenter, afin d’éviter l’effet « plantage Amazon » du printemps dernier.
Lorsque vous commencez à programmer dans l’environnement Cloud, vous devez passer à un mode de conception un peu différent. L’architecture est distribuée. La notion d’ACID (Atomic/Consistent/Isolated/Durable) est peut-être valable en local. Dans le Cloud, il est plus intéressant de dénormaliser les données. Faire des jointures coûte cher dans ce type d’infrastructure.
Patrick parle d’un article de Gregor Hoppe de 2004, « Starbucks does not use two-phase commit« .
Il conseille de lire cet été un livre d’informatique distribuée. Ce sera un investissement important.
Il cite Erlang, conseille d’apprendre Scala. Il cite aussi Go, le langage de Google. Compilé, il a des concepts qui viennent d’Erlang.
Regardez une base NoSQL comme Cassandra (vient de Facebook), Redis, MongoDB, BigTable (non open-source), Apache HBase…
On revient à la base hiérarchique d’il y a 20 ans. Patrick parle aussi du Théorème de CAP, à lire si vous découvrez le cloud.
Drivers économiques
La proportion du coût de l’électricité et l’enjeu énergétique est important pour Google. Aujourd’hui, les Datacenters consomment énormément d’énergie. Il faudra trouver des solutions ambitieuses pour réduire les coûts électriques.
La vision est passée du produit au service. Vous payez maintenant au mois, vous louez sous forme de service. L’ensemble de bits sur un CD est en perte de vitesse. Kent Beck à Usenix 2011 parlait de la manière dont le raccourcissement des cycles affecte le produit.
Economie d’échelle sur les machines
Ces tendances du monde grand public ont un impact sur l’entreprise. Les gens dans l’entreprise s’attendent à avoir la même chose que le soir chez eux. Ce qu’on appelle « Consumerization of IT ». Il y aura de plus en plus un écart important entre finalement les possibilités de nos ordinateurs, nos tablets et nos smartphones, et ce que l’Entreprise nous donne pour travailler. Il y aura aussi un écart de plus en plus important sur les outils. (ndlr: quelque part, le traitement de texte et le tableur, sur le poste de travail, sont morts en 2010).
Les applications évoluent comme la mode. Demain nous aurons peut-être même des applications jetables. On l’a vu dans les applications sociales, à peine mort-née. Et ce phénomène arrive aussi sur les téléphones portables.
L’influence du Cloud sur notre métier
Cela a une influence sur votre job.
On est passé d’un mode en cascade à un mode Agile. Dans les entreprises, lorsque l’on fait du logiciel, il faut avoir des échecs et se planter rapidement. Chez Google, « fail often, fail quickly and learn« . Etre professionnel aujourd’hui c’est aussi connaître les méthodes Agiles.
La culture de l’API est aussi quelque chose de très ancrée chez Google. Prenez Twitter, l’API a décuplé les possibilités du site. Créez le backend, puis les APIs et donc le service client. Si vous lancez un serviec, n’oubliez pas de penser à faire une API.
Le logiciel va vers le Cloud
Patrick voit 4 niveaux dans le Cloud :
– Google Apps/GMail/Google Calendar depuis 1994 => Delivery
– Infrastructure as a Service : c’est Amazon AWS, depuis 2002.
– Platform as a Service. C’est ce que fait Google, votre code est dans le Cloud. Celui-ci se charger de gérer la montée en charge, la persistence, pour vous. C’est ce que fait Google AppEngin
– Development as a Service : c’est enfin depuis début 2011 l’arrivée des outils pour le développeur. Dans quelques mois, nous allons pouvoir commencer à développer dans le Cloud. Peut-être un IDE, comme les efforts montrés par eXo Platform… Il y aura des startups et des acquisitions de ces startups par les gros éditeurs actuels, qui vont certainement devoir chercher de nouveaux relais de croissance. Nous sommes dans une phase d’industrialisation du computing.
Craftmanship
La production est entrain de s’industrialiser. Mais le plus paradoxal, c’est finalement que notre métier est entrain de se rapprocher vers l’Artisanat.
Il y a 20 ans, nous étions des ingénieurs. Nous devions suivre des processus pour créer des logiciels. Dans les années 90, nous étions encore des Ingénieurs, avec la modélisation UML, une vision du code générée et une approche industrielle. En 2011 un projet est vu comme la fabrication d’une oeuvre unique, pas chère, qui doit aller en production en quelques semaines. En fait, la vision du gros projet à 1500 jours/homme quoique bien ancrée dans l’entreprise, n’est plus la seule alternative. Il y a aussi maintenant grâce au Cloud la possibilité de monter un projet rapidement, de le mettre en production, de ne plus rendre « exceptionnelle » la mise en production, car celle-ci a lieu 3 heures après le début du projet.
Par rapport à l’enseignement, lorsque l’on observe notre métier de développeur, l’apprentissage se fait de plus en plus après les études. Il y a une certaine forme de compagnonnage. Notre métier est entrain de bouger vers l’Artisanat.
Regardez la mode : les objets de productions sont créées dans des chaines. Mais l’industrie de la mode est très artisanale. La qualité devient un critère énorme…
(note de Nicolas : La réputation des Artisans dépasse la réputation des Entreprises où ils travaillent.)
L’Agilité
Le développement logiciel donc se rapproche de la mode donc, par son côté artisanal. Kent Beck à la conférence Usenix 2011 ( voir la vidéo ) parle de « Software G Force », de l’accélération dans notre industrie.
Ce qu’il dit est simple : imaginez ce qu’il se passe lorsqu’un serveur, lorsque les outils pour travailler et lorsque les services ne couteront presque rien : les développeurs vont devoir se remettre en question.
Chaos of creativity
Les jours où un informaticien ne connaissait que Java sont comptés (ndlr: cela fait 2 ans que je vous le dis les amis). Patrick nous encourage à apprendre d’autres langages comme Groovy, Scala ou Clojure. Il faut comprendre que les services remplacent les softwares. On ne construira plus un logiciel de A à Z. Votre valeur sera plutôt de montrer votre capacité à intégrer et construire les services. Et pour cela, il faut maîtriser différents langages. En fait, il faut littéralement muscler vos neurones pour être en mesure d’apprendre très vite.
Apple a annoncé ces derniers jours, la sortie de iCloud, un nouveau système pour le grand public. Cela renforce encore le fait que nous, particulier, allons de plus en plus utiliser le Cloud à la maison. L’entreprise suivra, dans quelques mois ou dans quelques années.
Concernant la possibilité de livrer vos créations, regardez l’essor des Stores, comme Google App Store, l’Apple Store ou l’Android Market. Vous avez la possibilité de monétiser votre application. Attention aux APIs et pensez votre service en imaginant que la stratégie des outils que vous utilisez peuvent changer. Par exemple Twitter a racheté TwitDeck, ce qui peut causer du tord a Seesmic..
Le future de l’infrastructure c’est l’approche Content Delivery Network que l’on voit déjà dans le contenu.
Au niveau des plateformes, Google AppEngine a été le premier. Ensuite vous avez Joyent, au dessus de Node.JS, Heroku avec Ruby, Amazon elastic beanstalk ou Microsoft Azure. Il n’y a pas de standard.
Chaque service est différent, les langages sont différents. Une fois que vous entrez dans une plateforme, il devient difficile d’en sortir.
Patrick Chanezon parle de Cloud Foundry. Apache 2, multi-language/multi-services/multi-cloud. Vous pouvez vous créer votre Cloud private, en utilisant ce système.
Development
En 2011 le développeur est social. Il n’utilise plus sa machine en local pour garder son code. Il n’utilise plus SourceForge. Il utilise GitHub ou BitBucket d’Atlassian. Son code est vu de tout le monde. Un développeur au fin fond de l’Auvergne peut forker et contribuer à son projet. Le développement est un outil social à part entière. Et un développeur qui n’a pas de réseau social, qui n’a pas de follower… et bien est-ce que c’est encore un développeur ?
Ce que cela veut dire pour vous :
– oubliez le mono-language, oubliez le processs waterfall
– apprenez à vivre dans une petite boite, à vivre connecté avec les autres et à avoir une vision service/court terme.
– Essayez de toujours réutiliser ce que vous avez déjà expérimenté mais prenez des risques
– Apprenez des choses différentes, soyez rapide et agile. Apprenez une nouvelle API par mois ou un nouveau langage par an. Regardez le social et les markets places.
– Essayez de rester indépendant, regardez l’aspect open-source et open-standard.
On vit une très belle période pour le métier de développeur logiciel.
Conclusion
Avec cette présentation, Patrick Chanezon nous fait comprendre que le Cloud aura un impact durable sur notre métier. C’est un concept qui apporte tout un ensemble de nouveaux outils et de nouvelles possibilités. J’ai envie de vous dire : ne devenez pas un développeur du XXième siècle, ne loupez pas le train qui accélère. Il y a tellement de métiers, de projets et de possibilités grâce au Cloud, qu’il faut sortir de votre projet. N’attendez pas 40 ans pour vous réveiller… N’attendez pas la fin de la semaine… Commencez par installer une API, par tester Node.JS, par écrire quelques lignes en Scala… car les choses ne vont pas arrêter de s’accélérer.
Continuez votre lecture :
– Présentation de Didier Girard
Déjà merci pour ce résumé.
Ensuite j’aimerais revenir sur notre métier de développeur ou artisan du code ou ouvrier du code dans la réalité de nos entreprises (de la moyenne entreprise au grand compte).
Moi ce qui me chiffonne avec le fait d’apprendre continuellement le nouveau langage qui fait tout mieux qu’avant (Go ? oCaml ? :p ) c’est que déjà on arrive pas à faire du code correct avec Java.
Pourtant Java est un langage simple où tu n’as pas de redéfinition d’opérateurs pour faire des blagues à ton voisin, ni le coté dynamique afin d’avoir une compilation salvatrice, ni une flexibilité inouïe qui t’offre 4 façon de créer un objet (dont 3 « bad parts » façon javascript).
Essayons peut être de déjà de simplifier et rendre cohérent la façon dont on fait des projets en entreprise, d’en augmenter la qualité.
Note : peut être qu’un langage type Scala pourra simplifier le code mais le peu que je vois c’est au contraire l’inverse.
Ensuite apprendre Scala, NodeJS, Clojure, Ceylon, Lift, Ruby on rails, Python, Go, etc c’est intéressant, ca ouvre l’esprit ca fait plaisir mais dans la journée moi je fais mes 8h + transport de Struts 1 / JSP / Javascript / SQL à la main sans test (oui oui je fais de l’artisanat 😉 ). Donc en gros le fait de rentrer et de continuer à se former (vive le métier à 70h par semaine) a du mal à s’intégrer avec le reste d’une vie normale. Surtout pour apprendre un beau matin que la boite qui vient de se mettre à Grails préfère prendre un jeune qui sort d’études et qui a fait des projets la dessus pendant sa formation parce que vous voyez finalement ce qui compte c’est d’être directement opérationnel.
Conclusion personnelle : courir après les dernières technos ne résout en rien le problème de fond ni pour sa carrière ni pour le développement informatique en général.
Pourtant comme tout le monde, je n’attend que ça d’arrêter de faire de la couche de peinture mal faite en java 🙂
@Yannik je compatis avec ton métier d’ouvrier informatique que j’ai bien connu.
Je répondrais que l’apprentissage d’autres langages t’aide à mieux comprendre les limites, bonnes et mauvaises pratiques de celui que tu utilises au quotidien. Tu comprend le gap qui reste à franchir sur la programmation concurrente quand tu vois comment elle peut s’exprimer dans d’autres langages de type fonctionnel par exemple. Du coup ça t’aide à comprendre les API existantes en Java et à les utiliser correctement.
Honnêtement, ne pleure pas d’apprendre que la « boite qui vient de se mettre à Grails » ai pris un newbie. Si tu y avait mis le pied tu serais tombé dans la même bouillie d’informaticien/pigiste, certes en Grails, mais sans plus de compréhension de ta réelle plus-value. Crois moi, pouvoir tenir une discussion (sans se la jouer j’ai tout vu) sur des outils comme Ruby, Chef ou les difficultés d’un Git Rebase ça a de la valeur et ça paye lorsque tu as (enfin) trouvé le bon interlocuteur.
Conseil perso : sur le livrable, on ne te laissera jamais introduire une techno « innovante » sans 200 pages de justifications et de benchs. Par contre, sur l’aspect testing tout le monde s’en tamponne. Alors lâche toi là dessus pour te faire la main. Construit toi des outils sympa pour écrire des tests plus simplement en .
Pour ce qui est du temps que ça prend de faire tout ça, et bien fait le en sous-marin pendant tes heures de boulot (c’est 13 ans de pratique qui te parlent) 😛
Yannick, je comprends le probleme, je l’ai vecu personnellement au debut de ma carriere, mais je ne suis pas d’accord avec ta conclusion.
C’est une question de mentalite: soit tu acceptes ta condition d’ouvrier du logiciel, et tes perspectives d’avenir ne sont pas brillantes, parce qu’effectivement quand le management de ta boite, ou tes clients auront decide de passer a la vague suivante de technos ca se fera sans toi, soit tu embrasses la condition d’artisan du logiciel, qui est une recherche constante d’amelioration, d’apprentissage, une recherche de maitrise de ton art (mastery, en anglais), et la les offres d’emploi se feront nombreuses et ce sera a toi de choisir l’environnement ou tu peux te developper le mieux.
Je te conseille de commencer de maniere tres modeste et pratique: pas la peine d’intriduire 50 nouvelles technologies, regarde ta base de code et essaie d’identifier les regions qui sont le plus douloureuses (manque de tests, necessite de refactoring, integration continue) et suis le conseil de Nicolas, predn en main ton propre emploi du temps et reserve toi un jour par semaine pour creer des tests et faire du refactoring, et apprendre une nouvelle api ou un nouveau language qui peut t’aider sur ton projet (Scala, Groovy, Clojure).
Puis quand il y aura une nouvelle fonctionnalite a creer, peut etre la creer dans le nouveau language, ou avec un nouveau framework. Pas besoin de demander la permission, fais le et vois comment les gens reagissent (« better ask for forgiveness than permission »).
Apres quelques succes, tu seras capable de commencer le prochain projet avec de nouveaux outils, repete et amplifie.
A la base du changement il y a une mentalite d’apprentissage et de recherche de maitrise constante. Je te conseille le bouquin de Daniel Pink, « Drive », qui parle entre autres de ca.
Par contre, cette approche necessite un investissement personnel constant, qui ne se limite pas au cadre du travail 8h par jour, une curiosite constante, un effort constant pour s’ameliorer et comprendre plus de choses. C’est cette mentalite qui est le secret de la liberte.
Je vais te donner un exemple concret qui m’est arrive: quand j’etais chez Sun j’ai commnece a lire et jouer avec AspectJ, et ai trouve ca fascinant. Je voulais refactorer notre portal server avec des aspects, et j’avais essaye de convaincre les grands gourous de J2EE que les aspects etaient l’avenir. Ils etaient sceptiques, pendant ce temps la l’equipe JBoss rearchitecturaient toute leur base de code avec des aspects, l’equipe Spring popularisait l’injection de dependance, et J2EE stagnait. Le grand argument technique etait qu’on ne savait pas combien ca coutait en terme de perf. L’argument pour tuer toutes les discussions, avec la secuite.
Peu apres j’ai quitte Sun et rejoint Google, ou mon premier projet etait de gerer les librairies soap client pour AdWords API. La lib Java faisait 2000 lignes de code, pour la plupart du boilerplate autour de code genere par Axis. En une semaine j’ai reduit ca a 200 lignes de code, avec un bel aspect bien generique qui venait ajouter de la fonctionnalite transverse au dessus du code genere par Axis. Au lieu de m’en vanter, j’ai package AspectJ dans le meme jar avec le code genere, et n’ai pas fait trop de bruit sur le fait qu’AspectJ etait utilise dans ma librairie. Resultat, du code compact, maintenable (juste un nouveau build a faire a chaque fois que le wsdl changeait) et personne n’est venu se plaindre des perfs de ma librairie.
Voila un exemple tres concret du genre d’amelioration que peut faire un developpeur qui se sent libre et veut ameliorer le code.
Le gain de productivite associe a la nouvelle architecture m’a permis de creer une librairie .NET et Ruby (que j’ai appris a cette occasion) dans la foulee. Un des benefices d’utiliser et comprendre les aspects dans la version Java, est que ca m’a permis d’utiliser le meme genre de technique dans la version Ruby (en utilisant method_missing): quand tu as compris un concept dans un language, c’est assez facile de l’utiliser dans un autre language. Les languages changent, les concepts restent.
Je mettrais plusieurs petits bémols.
Introduire de nouvelle API, de nouveau langages que l’on vient d’apprendre sur un projet ou sur un produit que l’on développe dans l’entreprise et certes valorisant pour les connaissances que vous avez acquises. Cela peut permettre d’implémenter des demandes plus proprement, plus simplement ou encore de façon plus performante.
Mais à moins d’être le seul développeur (ouvrier ou artisan) dans votre entreprise, vous travaillez en équipe. Et votre travail doit être maintenable par tous. Le jour ou vous êtes absent et que votre code Ruby (langage que vous êtes le seul à connaître dans l’entreprise) plante lamentablement en production. Qui est la pour réparer?
Les membres d’une équipe de développement peuvent, et même doivent, avoir des compétences diverses. Chaque membre à son niveau, ses compétences, ses préférences. Mais le travail fournis par chacun doit pouvoir être repris par chaque membre de l’équipe assez facilement.
Je ne propose pas de niveler le travail sur la base du moins expérimenté/compétent mais de faire progresser l’ensemble de l’équipe.
Introduite une nouvelle techno c’est bien, mais il faut s’assurer que chaque membre de l’équipe pourra facilement reprendre votre travail. Que cela soit un choix concerté de l’équipe. Et d’éviter les zones critiques de l’application dans un premier temps.
Je voudrais cependant ajouter une remarque dans le sens du billet. Pour moi c’est l’équipe qui fait ses choix technologiques, car c’est elle qui réalisera l’application.
Bien sur ces choix technologiques sont guidés, non pas par le coté ‘hype’ d’une techno ou des goûts particuliers, mais par les demandes du client (fonctionnelles, de maintenances, d’exploitation…).