Ce matin en prenant le RER, je suis encore tombé sur un article sur le « Cloud Computing« . Je feuillette les pages, toujours les mêmes explications, le même emballement, bref à la lecture de ces quelques pages, on sent qu’il faut y aller. L’article parle d’Amazon EC2, et de Microsoft Azure. Et tout d’un coup, je me suis demandé si cet emballement n’était pas disproportionné, si cette excitation n’allait pas nous entraîner dans le mur. Je me suis demandé si nous n’étions pas à l’aube d’une sorte de crise du Cloud Computing…
Voyons tout d’abord Amazon avant de lister les autres points d’inquiétude.
AWS ne représente que 4,28% du chiffre d’affaire 2009 d’Amazon
Amazon a annoncé dans ses résultats 2009 que le Cloud Computing via son service avait réalisé un chiffre d’affaire de 550 Millions de dollars sur l’année. Cela peut sembler beaucoup mais ce n’est que 4,28% de 12 828 millions de dollars pour l’année 2009. Et encore je parle de la section « Other » dans le rapport financier complet disponible sur Yahoo Finance pour l’Amérique du Nord.
4% du chiffre d’affaire d’Amazon pour ce qui n’est pas vente de médias ou d’appareils électroniques pour 2009. La contribution au chiffre d’affaire est vraiment minoritaire, même si nous parlons de quelques 195 millions de dollars, uniquement pour les 3 derniers mois de 2009.
Ces chiffres peuvent être vus de 2 façons. L’optimiste dira qu’Amazon est entrain de rentabiliser ses infrastructures. Le chiffre de 550 M$ a été réalisé à 40% sur les 3 derniers mois de l’année 2009. Cette croissance du chiffre d’affaire est peut-être un indicateur que l’activité AWS dégage du chiffre. Le pessimiste relativise la contribution de l’activité Cloud Computing en regard du CA total sur 2009. Il ira même jusqu’à se demander, si ce ratio faible, qui n’est pas le coeur de l’activité d’Amazon, vaut le coup et les efforts mis en oeuvre.
Pourtant à 200 millions de dollars par trimestre, il serait dommage de se priver de ce revenu.
Les systèmes sont opaques
Il y a quelque chose de flagrant, que ce soit Google App Engine ou Azure, ces systèmes sont plutôt opaques. Il y a une part de mystère, de choses que l’on ne vous dit pas techniquement. C’est un mal nécessaire pour assurer la montée en charge, mais c’est inquiétant. Je pense qu’il y a un manque de transparence sur les performances. Nous avons entendu des présentateurs nous parler de spécifications techniques. Mais nous n’avons pas entendu de comparaison de sites Internet à fort trafic, version AWS et version classiques. Et je trouve cela inquiétant. Ne pas savoir c’est accepter de prendre un risque.
La sécurité est-elle vraiment au rendez-vous ?
Imaginons un scénario catastrophe. Un jeune hacker trouve une faille dans l’API qui contrôle le Cloud Computing. Comme votre site est hébergé sur le cloud, c’est tout votre système d’information qui s’en trouve alors fragilisé. Je pense que finalement, votre réseau hébergé chez un prestataire est moins exposé que votre application sur Google App Engine. Lorsque vous décidez de basculer sur le Cloud une partie de votre infrastructure, vous allez aussi automatiquement devenir plus vulnérable aux failles de la plateforme elle-même. C’est un peu comme faire le choix de l’open-source. Vous êtes plus exposé mais en retour, les corrections de bugs sont plus rapides. Mais je ne pense pas que ce paradigme s’applique au Cloud, où vous êtes dépendant de l’infrastructure et des équipes de développement des fournisseurs du Cloud.
Tout a un prix
Lorsque l’on parle de Cloud Computing, le mot « économie » arrive rapidement dans la conversation. Or les premiers prix d’Amazon EC2 ne sont pas compétitifs. A 61$ par mois, c’est cher. Pour 20 EUR par mois, vous avez une machine dédiée chez OVH, tout à fait correcte. En janvier pour héberger 2 serveurs, nous avons pris Gandi et son offre virtualisée. J’avoue avoir été déçu par les performances par rapport au prix, pour une machine sur laquelle j’avais installé Apache, MySQL, Tomcat et une appli Grails. Avec 6 parts, j’ai trouvé l’ensemble poussif. De plus, Tomcat avait un comportement bizarre sur cette machine virtualisée. Et là, aucuns moyens de comprendre ce qui se passe vraiment.
Le Cloud Computing est plus cher qu’une solution classique d’hébergement dédié. La flexibilité n’est peut-être pas une option indispensable à votre projet.
Aucunes garanties de performance, des SLAs au rabais
Continuons notre réflexion. Vous payez plus cher un service dont les performances ne sont pas garanties. Ne pensez-vous pas que c’est inquiétant ? Pour aller plus loin, le SLA (Service Level Agreement) d’Amazon EC2 s’engage à 99,95% et ne vous rembourse que de 10% si le service est en dessous. Le pire est que les temps de maintenance de la plateforme AWS sont exclus de ce SLA, ce qui revient à dire que vous acceptez que votre site tombe le temps d’une mise à jour d’Amazon EC2. Cela me dérange, je n’ai pas de visibilité, c’est inquiétant.
Coder moins pour gagner plus
Google App Engine est un outil magnifique, qui vous demande seulement de coder avec 7 doigts au lieu de 10 en faisant une croix sur un certain nombre d’API Java. Regardez la liste des APIs que vous pouvez utiliser. Plutôt impressionnant non ? Dans la pratique, il y a pas mal de librairies qui ne marchent pas sur Google App Engine. Ce qui revient à dire que vous allez devoir adapter votre solution et votre code pour que celui-ci fonctionne. Encore un nuage de béatitude qui s’évapore, sitôt la marié allongée dans le lit. Oui tu vas avoir de grand moments de solitude lorsque tu ne comprendras pas pourquoi le framework XXX ne fonctionne pas sur Google App Engine.
Votre application démarre lentement
Le même Google App Engine souffre d’un mal sournois. Lorsque vous visitez une application comme celle-ci qui n’a pas beaucoup de visiteurs, vous noterez un chargement assez long la première fois. Il faut savoir que GAE démarre et alloue votre application que lorsqu’il y a un visiteur. Et qu’en l’absence de ces visiteurs, votre application est éteinte. Cela pose problème, et des discussions intéressantes sur la liste de diffusion de Gaelyk par exemple, montre que le problème est connu chez Google.
En attendant, moi en tant que client je trouve cela nul. Et en tant que développeur je suis frustré. Et on a beau s’exciter devant GAE, il faut aussi parler de ce qui n’est pas top.
Vous allez faire du NoSQL
Ceux qui vendent cette idée sont des consultants comme moi, des gars bien qui veulent faire leur métier. Soyons méchant 3 minutes : après avoir tartiné tout le monde avec SOA, il semble que le nouveau Mojo s’appelle Cloud Computing. Et je pense à NoSQL. La majorité de ceux qui s’y intéresse, moi le premier, sont des jeunes de moins de 40 ans qui n’ont connu que le Web et que la base relationnel.
Les anciens rigolent gentiment en nous voyant nous emballer pour une techno (le non-relationnel) qui existe déjà depuis 25 ans. Alors oui je serai là le mardi 16 février à la 2e réunion du NoSQL User Group car je suis emballé par les idées et ces nouvelles architectures, mais je suis inquiet à l’idée que certains vont en vendre à leurs clients, en n’ayant finalement aucuns expériences sur le sujet. Ce n’est pas méchant, c’est un fait. Il est plus facile de vendre quelque chose de nouveau mal connu que quelque chose de vieux très connu. SOA c’est hasbeen, passez au Cloud, camarade.
Conclusion qui scale
Avons-nous tous besoin du Cloud ? Oui pour mes emails sur Gmail. Certainement oui pour mon infrastructure Web. Peut-être pas pour mes applications d’entreprise.
J’essaye de voir si les grandes idées du Cloud Computing ne cachent pas de futurs gros soucis, que ce soit sur la montée en charge, les promesses de la performance, le réseau qui tient la charge ou la sécurité. Peut-être qu’Amazon va simplement exploser dans 4 mois et que beaucoup de sites mettront la clé sous la porte. Ou peut-être que Kevin, 14 ans, arrivera à faire casser votre clé de cryptage, et que tous vos dossiers clients seront sur Internet jusqu’à la fin des temps.
Ou peut-être que je me suis endormi dans le RER et que tout ceci n’était qu’un cauchemar.
Références
Rapport financier d’Amazon 2009
noSql User Group de Paris, prochaine soirée mardi 16 février chez OCTO Technology
Larry Ellission critique le Cloud Computing en septembre 2008
Je partage ton avis globalement sur le cloud, un emballement des développeurs un peu illusoire. Heureusement les clients sont plus terre à terre et j’en ai pas encore vu un seul qui était prêt à tout migrer sur le cloud 🙂
Par contre concernant la sécurité, est-ce vraiment moins sécurisé de faire héberger ses applis par une entreprise comme Amazon ou Google qui ont une véritable expérience de la sécurité (car très exposés justement) ou d’héberger ses applis chez le client, dont la sécurité n’est pas du tout le métier ?
ps : sympa le captcha 😉
A coté du buzz des clouds publics, j’entends de plus en plus parler des clouds « privé », sécurité accrue, plus de souplesse, c’est peut être de la que ca va partir ?
D’accord sur le fond concernant le flou artistique, surtout sur les SLA.
En revanche, niveau tarifs rackspace démarre à 10$/mois pour une instance qui persiste même en cas de crash exactement comme un serveur standard (ce qu’Amazon ne sait pas faire si je ne m’abuse).
J’ai basculé pas mal de choses à tester que j’avais sur une kimsufi OVH vers cette petite instance. Par contre, 1 crash et 2 maintenances en un mois, bof bof, si tu as quelquechose en prod. tu as interêt à demander au moins deux instances à load balancer sur des baies voire des datacenters différents.
Pour ma part, je ne suis pas tout à fait d’accord sur ton analyse du C.A d’Amazon. Vu de ma fenêtre, cette société revend des produits finis. Donc son C.A gonfle très vite. Et il n’a rien à voir avec son bénéfice. Par contre, pour la partie EC2, Amazon vend du service. Dans ce cas, son C.A est beaucoup moins éloigné de son bénéfice. 4%, c’est donc déjà énorme. Non?
Je pense que la notion de chiffre pour une boite comme Amazon c’est pas super représentative. D’une Amazon est une boite de vente, donc gros CA mais pas forcement des gros bénéfice. Il faudrait plutôt voir la rentabilité du truc pour Amazon (chiffre impossible a avoir en externe). Et j’avoue que sur des boites qui ne font que ca je serais plus interressé d’avoir des chiffres.
Coté sécurité on reste sur le débat utilisé une plateforme propriétaire ou une plateforme libre. C’est valable pour l’hebergement, c’est valable pour le developpement, …
Dans le cas du cloud il existe des systeme de cloud libre, Ubuntu a commencé a en intégrer un il me semble si je dis pas de connerie. Au final dans ce cas le débat est le meme que .NET/Java ou ce genre de choses a chaque fois qu’on réutilise quelque choses faire pas d’autre on s’expose au fait que sa distribution entraine une plus grande propension a la découverte de bug, c’est valable sur un langage, sur une librairie, sur une archi de cloud.
Pour le reste l’avenir nous diras le sort qu’il réserve au Cloud.
Joli article qui déconstruit bien les risques « cloud ». Le cloud, c’est l’hébergement vu par des consultants avant-vente, on dirait …
Quand j’ai entendu l’épisode des Castcodeurs sur le cloud, je pensais que les services proposés sont en fait équivalents voire inférieurs à ceux amenés par du LAMP classique.
Qui a besoin d’une montée en charge transparente et violente? On le souhaite tout le monde, mais dans la réalité? ça fait rêver, voilà le but.
Mais qui a besoin de la puissance de jeu de Google ou d’Amazon?
Et pourquoi aller mettre son backend chez un hébergeur dont la techno nous lie, nous oblige. C’est aussi fort que de tout développer pour mainframe ou as400.
Le prix de l’hébergement n’est pas le seul à devoir être pris en compte. Il faut aussi toujours compter le prix d’une sortie de la techno.
Mais j’avoue GAE ou les services Amazon me font rêver. Le côté « free ». Mai voilà quand tu commences à coder, ton application prend très très vite une tournure adaptée à ta techno, dès qu’il s’agit de faire un tant soit peu persister.
Et voilà que le fameux DAO que l’on voulait faire disparaître prend tout d’un coup un peu d’interêt! Puisqu’il permet de centraliser l’accès à la ressource « persistance » . Dommage…
Mis à part pour des campagnes marketing ou pour des sites « parapluie » (que l’on déploie très facilement sur une adresse cloud)ou pour des sites expérimentaux, je ne vois pas trop l’avantage d’une solution cloud par rapport à l’achat d’une paire de pauvres serveurs dell avec 64Go de RAM.
Merci d’avoir libéré la parole 🙂
Voici un petit retour d’expérience sur un développement GAE que nous avons fait : http://www.scub.net/fr/retour-dexperience-sur-le-developpement-java-avec-google-app-engine/
Ce que je trouve super obscure c’est les tarifications. Base de données, CPU, etc… payés à l’heure, oui mais si j’utilise 1 min par heure?
Au fait quand tu dis:
« J’avoue avoir été déçu par les performances par rapport au prix, pour une machine sur laquelle j’avais installé Apache, MySQL, Tomcat et une appli Grails. Avec 6 parts, j’ai trouvé l’ensemble poussif. »
Déçu par Gandi ou Amazon? Parce que j’envisage de mettre une appli en cloud.
@Badaboum : par Gandi. C’est bien, mais pas si génial dès que tu veux faire une bonne grosse application. Pour mon blog cela marche très bien depuis 3 ans.
Une très juste reflexion, que j’ai eu aussi l’autre jour en n’arrivant pas à m’endormir, ou alors on a rêver tous les deux 😉
Mais je continue à étudier le NoSQL (avec mes amis australiens et leur application de d’IA médicale) et à voir le cloud comme une solution d’hébergement à valeur ajoutée.
Bonjour,
Je ne sais pas trop si ce champs commentaire va me permettre de critiquer ton billet, mais je m’y risque point par point 😉
AWS ne représente que 4,28% du chiffre d’affaire 2009 d’Amazon
4,28 % d’un Amazon… Combien de boîtes rêvent d’un tel CA ? 🙂
40 % de ce CA sur les 3 derniers mois et sans aucun doute cela s’accélère… Plutôt bon signe donc pour un marché naissant non ??
La rentabilité est clairement plus intéressante sur EC2 qu’un livre je pense 🙂
Les systèmes sont opaques
Valide uniquement pour du PaaS (donc Azure, App Engine and co). Pas de différence pour moi entre un EC2 et un OVH-like sur ce point.
La sécurité est-elle vraiment au rendez-vous ?
A t’on déjà entendu parler de vulnérabilité des APIs proposées ? Pas vraiment encore à ma connaissance. Je suis plus inquiet des absurdités que pratiquent 80 ou 90% des clients avec login = mot de passe = nom bdd ou des machines pas sécurisées ou très peu. Et ces cas de figure s’appliquent aussi bien au Cloud qu’à l’hébergement traditionnel.
Je trouve qu’au contraire un Amazon a plus à perdre en image de marque qu’un OVH, d’autant plus qu’on les attend au tournant sur ces points (à tort d’ailleurs — leur plateforme est probablement plus sécurisée qu’un hébergement traditionnel — le risque tient plus à l’échelle de ces acteur : une potentielle intrusion toucherait des dizaines de milliers de serveurs et seuelement quelques milliers pour un hébergeur traditionnel).
Tout à un prix
Savais-tu que tu peux commencer à $11/mois chez Rackspace Cloud ? 🙂
C’est d’ailleurs super pratique pour de petites webapp sur un Tomcat. Ca suffit pour beaucoup de besoin et on dispose enfin d’une offre permettant de faire du JEE à pas cher. Ne pas oublier non plus qu’Amazon et Rackspace Cloud inclue dans ce prix des fonctionnalités payantes chez les OVH and co du style firewall.
Par contre d’accord avec toi sur le fait que si t’as pas besoin de flexibilité alors problablement qu’un hébergement tradionnel est plus adéquat. Cependant, qui peut dire sereinement dans un contexte business (je parle pas de serveur mail ou autre) que l’on est capable de prévoir l’utilisation du service que l’on vend ? Soit tu dimensionnes pour le meilleur et tu gâches de l’argent, soit pour le moins et t’est bien embêté quand ça tient plus… 🙂
Aucunes garanties de performance, des SLAs au rabais
Vous payez plus cher un service dont les performances ne sont pas garanties.
Faux, archi-faux. Tu as une partie de l’hôte physique allouée à ton serveur. Cela fonctionne comme les serveurs virtuels d’OVH d’une certaine façon puisque tous deux font de la virtualisation. Tu as une garantie sur la disponibilité dudit serveur, même si tu la juges trop faible (cependant une meilleure garantie coûte plus cher et ça se paye d’une façon ou d’une autre).
Cependant si ton serveur EC2 plante, en 5 mn t’en as un autre opérationnel (si ton application est bien codée :-)). Tu peux en dire autant d’une panne matérielle d’un serveur OVH ?
Pour la visibilité tu connais http://status.aws.amazon.com ?
Volontairement provocateur, je te demanderais pourquoi tu as besoin d’une garantie ? Une garantie n’est qu’un instrument financier pour moi… T’en as pas et tu prends à ta charge les inconvénients engendrés, t’en as une et c’est le fournisseur qui les prends, mais dans les 2 cas, c’est toi qui paye à l’arrivée 🙂
Coder moins pour gagner plus
Raisonnement valable qu’en mode PaaS. Pas de problème avec EC2 ou Rackspace Cloud ici.
Et puis c’est pas non plus si catastrophique que cela car les APIs non-supportées se réduisent dans le temps et que de plus en plus de librairie deviennent compatibles. Maintenant, je cache pas que le PaaS c’est du vendor-lockin déguisé ni plus ni moins et c’est pas beau, d’où ma préférence pour du IaaS 🙂
Votre application démarre lentement
Mouais. Enfin là tu résumes le Cloud à Google App Engine non ? 🙂
Vous allez faire du NoSQL
Tout le monde ou pas loin en utilise sans le savoir.
Tu connais beaucoup de monde qui n’utilise ni GMail, ni Facebook, ni LinkedIn, ni SalesForces, ni … … …
Ces sociétés seraient donc à la merci de jeunes prépubères dépités par le SQL ? 🙂
Je suis volontairement provocateur, mais ton message est un peu trop orienté je trouve…
Conclusion qui scale
Au secours, les milliers de clients Amazon et Rackspace semblent ne pas savoir calculer les coûts de leur utilisation du Cloud, à t’entendre 🙂
Le Cloud répond clairement à une attente, peut être pas la tienne, mais répond réellement à une attente. Aujourd’hui faire un Google like c’est presque à la portée de n’importe quelle bourse. Va dire cela 5 ans en arrière.
Quand à Kevin, il a déjà de quoi s’occuper avec la carte vitale, les permis de conduire US en RFID, les hacks des routeurs Wifi (merci Hadopi) et TOR et autre gadgets à mettre en place (merci LOPPSI) 🙂
En quoi OVH présente moins de risque qu’Amazon ferme EC2 ou Rackspace son offre Rackspace Cloud alors qu’elles sont toutes en très fortes croissance ?
On pourrait longuement continuer ce débat je pense.
Je voulais juste tempérer ce pessimiste volontairement provocateur de ta part, je n’en doute 🙂
Merci Jérôme pour ce retour très complet, et bien argumenté.
Pour compléter le point sur le prix du Cloud, un bon billet de Julien Dubois
http://www.responcia.fr/blog/2010/02/18/calculs-de-prix-dans-le-cloud-computing/
Marrant, je le commentais peu de temps avant de répondre au tien : cf échanges bas de page dans les commentaires 😉
@Jerome : oui j’ai un peu forcé le trait, afin de tempérer l’excitation autour du Cloud. Si tu veux relire un billet où j’explique avec un autre point de vue mon intérêt pour Amazon, va jeter un oeil sur ce que je racontais à Devoxx en 2009.