Je vois de plus en plus de devs et autre afficionados technolo-geek commencer à ne jurer que par le cloud, alors à défaut de présenter une vision partiale et totalitairement contre, ce que je ne suis pas, j’aimerais bien tempéré un peu ces ardeurs.
En même temps… Fais pas bon critiquez le cloud ces temps-ci, récemment c’est David Cramer (créateur de Sentry et dev chez Disqus – la plus grosse application Django du monde) qui s’était exercer avec un article que je vous conseille comme annexe « The Cloud is not for you« . C’est mal parce qu’enfin avec le cloud (et le NoSQL), on nous vend du rêve !
Pour résumé, si vous ne le saviez pas déjà, avec le cloud vous allez :
– pouvoir « scaler » jusqu’à l’infini votre application pour gérer des milliards de requêtes par secondes;
– pouvoir enfin « vous abstraire » des machines, des base de données (ORM Mon Amour), et de toutes ces choses « sales »;
– et avec des services comme Amazon vous allez atteindre la haute disponibilité à 99.99999999999999% le tout en ayant « que » à mettre la main au portefeuille;
J’en passe et des meilleurs… Je vais mettre un peu mon grain de sel (ça donne toujours du gout ! et j’espère que ça sera utile pour certains !) parce qu’en tant que dev et ops d’APPARTINFO, la startup que nous construisons depuis bientôt 2 ans, j’ai un petit parti pris dans cette histoire.
En tant que développeur, et en tant que personne cherchant à faire notre travail, je considère que nous ne sommes pas là que pour développer, nous construisons un produit, une expérience utilisateur, une utilisation des resources mises à notre dispositions, nous rendons un service et construisons un outil.
Ce que nous vend le cloud, et qu’à très bien illustrer Nicolas Martignole dans « Le Cloud pour le développeur« , c’est pour moi un rêve pourri, une contre-utopie où le développeur pourra enfin rester totalement dans sa cave, à faire couche d’abstraction sur couche d’abstraction pour enfin ne plus avoir de lien avec ni la machine, ni le métier. Youhou !
Voilà quelques vérités que je trouve importante, et sur lesquelles je rejoint David Cramer :
– Le Cloud (version Amazon, Heroku etc.) donne juste l’illusion de pouvoir scaler une application en un rien de temps. Le Cloud permet, c’est vrai, de dépenser de l’argent en rajoutant des machines, mais au fond dans l’optique de scaler une application, on a rarement besoin de pouvoir rajouter 50 machines dans une demi heure !
Clairement il faut distinguer les utilisations, amazon trouve sa place dans les besoins de puissances de calculs instantanées, mais à moins d’être le New York Times et d’avoir besoin de générer en 5 minutes 10 Milliards de PDF, ce n’est pas ce qui va gérer vos problèmes de charges en tout cas pas les miens, ni ceux de Disqus.
– C’est la chose la plus stupide au monde que de vouloir s’abstraire à un niveau supérieur des machines sur lesquelles toute application repose. Java n’est pas vraiment « Compile Once, Run Everywhere » et C/C++ est encore le langage le plus utilisé quand on cherche la performance. Sans compter que tous nos composants critiques, Base de données, Caches, Queue Managers, Reverse Proxy, Serveurs d’applications et surtout le système d’exploitation, tous s’appuient sur des particularité, des routines et des algorithmes au plus proche de la machine. Même l’utilisation des B-Tree pour les systèmes de fichiers et bases de données est privilégié en partie à cause de l’utilisation de disques dur à cylindres…
Tout ça pour dire qu’encore une fois, on vend aux développeurs et aux décideurs ce qu’ils adorent, une couche d’abstraction supplémentaire permettant de se dire qu’enfin on va pouvoir se passer d’admin sys (c vrai que c encore des gens avec qui il faut discuter 😦 … ), on va aussi pouvoir se passer de comprendre les protocoles HTTP/TCP/WSGI/… ou de comprendre que quand la RAM est pleine, une application swap et que quand la swap est pleine… ben tout crash…
Sous le pretexte de la « Separation of Concerns » on dit au développeur, « toi tu dev et le reste c’est pas tes affaires ». Seulement un développeur qui ne s’occupe pas de sa mise en production, des performances et de l’impact de ses process sur les machines, de la sécurité de celles-ci, pour moi, il fait mal son travail.
Est ce que ceux qui défendent le Cloud coûte que coûte ont aussi bien compris qu’alors, on ouvrait tout les process critiques, les bases de données, les caches etc… sur Internet ?
On va bien s’amuser quand une série de failles sera utilisées sur les bases de données « enfin accessibles ». Je vois même pas pourquoi je parle au future, je suis sûr que linked voit de quoi je parle.
Voilà c’était mon petit grain de sel,
Vale
O. Girardot 
Complètement d’accord sur le fond. NÉANMOINS, en tant que noob, je préfère d’abord me focaliser sur le perfectionnement de mes compétences de dév. avant de m’améliorer en tant que sysop.
Un paas me permet donc d’avoir des applus en prod malgré mes compétences limitées. Et ça ne m’empêche pas de monitorer ce qui se passe (aspect facilité par les paas aussi, de façon générale).
Mais on est d’accord, ça ne dispense pas de savoir ce que l’on fait.
vu sous cet angle, Java fait déjà de nombreuses abstractions par rapport à l’OS, qui fait déjà bcp d’abstractions du hardware. Et effectivement, il est plus performant de programmer en assembleur spécifique. Maintenant est-ce que c’est vraiment mieux ?
Est-ce que je préfère « perdre » bêtement de la puissance à mal utiliser les couches d’en dessous pour avoir en contre-partie un « time to market » qui me permet de rester concurrentiel
Troll à part, le Cloud offre certes de la scalabilité, mais surtout offre le moyen de disposer de ressources à moindre cout car pour des durées très courtes. Je peux déployer mon appli sur des machines dimensionnées iso-prod et faire un test de perf quotidien de mon dernier build stable pendant 1h, ça va me couter 50cts. Je peux proposer une démo de ma feature-branch à mon product owner, ça me coute 2cts. Avec du hard c’est ingérable. Le Cloud, c’est avant tout la disparition de l’IT (du moins, pour les utilisateurs)
Bon, ok, je suis biaisé sur mon point de vue, mais très sincèrement je n’aurais plus l’idée d’aller installer un tomcat sur une machine de prod
J’avoue que j’allais dire que sur ce point tu étais biaisé :p
Mais si ça peut te rassurer, je suis d’accord avec toi sur plusieurs points (pas sur les premiers, car comme d’habitude je ne suis pas « rigoriste » au point de considérer les langages haut niveau comme des aberrations 🙂 ),
le hardware « on-demand » est un mieux, que ce soit pour du selenium, du test d’intégration ou de la génération de rapports couteux (et bien d’autres utilisations que j’oublie).
Mon seul point est que ce n’est pas la solution unique à tout les problèmes et que cette disparition de l’IT, à la manière de la disparition du développeur dans un développement MDA (lol dsl ca me fait rire juste d’y penser) n’est pas une bonne chose.
Quant à ton point sur la gestion des machines physiques, pour gérer un parc (1+) je trouve l’approche « Infrastructure as code » autour de Chef ou Puppet très valable et pertinente, m’enfin mon point de vue de dev + ops (mais dev qd même) compte peut être peu.
Merci pour le feedback 🙂
Comme le dit Nicolas, le Cloud c’est avant tout des économies d’échelle et des investissements liquides (tu arrêtes de payer quand tu veux).
Ce qu’il faut pointer du doigt, ce n’est donc pas le Cloud en lui-même mais le fait de se reposer uniquement sur la magie du Cloud pour scaler ses applications.
Dans mon article je ne parle pas de scalabilité (le mot n’est pas du tout dans l’article). La scalabilité vers l’infini et l’au delà est importante pour une startup qui lance un produit sur une plate-forme mobile par exemple. Amazon offre 99.999999999 (9 fois le chiffre 9) de dispo, comme vu lors du CloudDay chez Xebia. C’est parfois très important pour des applis d’entreprises. Une DSI ne peut pas offrir ce niveau de service.
Merci pour ton retour 🙂
Nicolas
on est donc plus ou moins d’accord. Je ne dis pas que le Cloud est la solution à tout. On me demande souvent « est ce que mon appli qui a 10 ans en EJB avec accès FileSystem et librairies natives peut tourner dans le cloud ? » et la réponse est « non ». Le Cloud standardise le « socle commun » et permet donc à des développeurs d’aller très, très vite. Par contre, sur le long terme il peut évidement être nécessaire de revoir son architecture car le Cloud a aussi ses limites et ses contraintes. Mais pour des millions de « petits » projets (non péjoratif) le Cloud est une opportunité sans équivalent jusqu’ici. Voir par exemple Google App Engine, développé avant tout pour les besoins internes de Google, qui ne tolère pas de perdre du temps pour voir une appli online en un temps record.
Après, selon la nature de l’application et des besoins très spécifiques, on peut avoir besoin de descendre du niveau PaaS (type JavaEE) à un PaaS niveau OS, ou même à un IaaS pour mettre en place des solutions très spécifiques, voir même à disposer de son propre hardware, mais bon, tout le monde n’a pas les besoins d’un FaceBook …
« Amazon offre 99.999999999 (9 fois le chiffre 9) de dispo ». Reste à voir ce qu’ils entendent par « dispo ». Je travaille quotidiennement avec EC2 et je dois être le 0.000000000001 à qui il arrive des soucis très gênants voire bloquants assez régulièrement, mais effectivement l’instance est « joignable », le seul truc c’est qu’elle ne fonctionne pas.