Depuis un an et demi, j’ai donné plusieurs conférences dans diverses écoles et universités. L’une de mes conférences reprend les thèmes de ce blog, l’autre s’intitule «Architecture répartie en environnement Web».
Dans cette seconde conférence, j’aborde un certain nombre de concepts, dont le Cloud Computing. Et j’ai réalisé assez vite qu’il fallait démystifier la chose. En fait, je me suis retrouvé face à deux types d’étudiants : Ceux qui n’ont aucune idée préconçue sur la question (et qui s’en font parfois une image un peu romanesque), et ceux qui s’y sont déjà frotté − souvent à l’occasion de stages dans de grosses entreprises.
Le mirage du Cloud
Ce qui m’amuse et m’énerve à la fois, c’est de voir que pas mal de personnes ont gobé le discours commercial ambiant autour du cloud. Plus particulièrement, c’est l’idée qu’une application puisse être développée avec une architecture très classique (comprendre : pensée pour s’exécuter sur un serveur unique), puis déployée sur une infrastructure limitée et peu coûteuse, et qu’en fonction des besoins cette infrastructure pourra évoluer de manière totalement transparente, il suffira juste de payer plus cher.
C’est vrai que cette idée est séduisante. Pas besoin de tout redévelopper ! Si votre trafic augmente, vous payez simplement un peu plus cher et des ressources supplémentaires vous sont allouées !
Oui, mais non.
On oublie de vous parler du coût. On oublie de vous parler des limites.
À vrai dire, il y a une différence entre le cloud «commercial» et le «vrai» cloud.
Le coût du Cloud
Je vais illustrer mon propos en me référant aux serveurs virtuels proposés par Gandi et OVH, qui sont deux entreprises françaises bien établies. Leurs offres commencent respectivement à 12 € HT et 14,99 € HT par mois, avec des caractéristiques très disparates, pour aller jusqu’à 288 € HT et 159,99 € HT par mois, là encore avec de grandes différences. J’ai décidé de les comparer aux serveurs dédiés proposés par Online sous la marque Dédibox. La comparaison est difficile, car il y a peu d’information concernant les équivalences des processeurs ; on parle de «core», mais le cœur d’un Celeron à 1 GHz est moins puissant que l’un des cœurs d’un Xeon dernière génération. On va approximer.
Si on regarde du côté de la puissance de calcul, on peut voir que le prix se tient entre OVH et Dedibox. Le prix de la puissance est élevé chez Gandi, et il augmente très vite. Les machines virtuelles d’OVH ont l’avantage de pouvoir monter assez haut en capacité, proposant une puissance avoisinant le double du serveur Dedibox le plus puissant.
Si on s’intéresse à la mémoire vive, on peut voir que les serveurs virtuels sont systématiquement plus cher qu’une solution classique.
Pour ce qui est du stockage sur disque, les prix sont élevés mais surtout les capacités sont limitées.
Conclusion
Difficile de vraiment s’y retrouver. Les offres évolues continuellement ; le temps d’écrire cet article (plusieurs semaines, quand même) et les offres avaient changé.
J’avoue que lorsque j’ai commencé à faire les graphiques, je pensais qu’il y aurait des courbes similaires, avec les machines virtuelles moins chères sur les petites capacités (faible puissance et/ou faible espace disque) et les serveurs dédiés moins chers sur les grosses configurations. J’ai donc été assez étonné de voir que les serveurs dédiés sont globalement toujours moins onéreux.
D’un certain côté, cela ne prouve rien. Le prix n’est pas le seul critère de choix entre les serveurs dédiés et les serveurs virtuels. C’est un peu comme comparer des oranges et des tomates en regardant leur couleur sans s’intéresser à leur goût. La virtualisation offre une plus grande souplesse : si la machine physique tombe en panne, on a la possibilité de redémarrer le serveur virtuel sur un autre ordinateur dans un délai très court.
Mais, de manière générale, il n’en reste pas moins qu’un énorme amalgame est fait entre le «cloud computing» et la virtualisation de serveurs. Ce n’est pas parce que votre serveur est virtuel que vous faites du cloud.
À la réflexion, j’ai l’impression que le fantasme ambiant autour du cloud prend ses racine dans l’informatique de la fin des années 90. À l’époque, la direction générale concernant les gros systèmes était de continuer à voir les clusters comme une machine unique (du point de vue de l’application). Ayant fait mes études en développement kernel entre 1999 et 2001, je me souviens bien qu’à l’époque on parlait de migration de processus et autres mécanismes intégrés aux systèmes d’exploitation, qui permettraient d’exécuter des applications “standard” sur des machines de plus en plus énormes.
Ce qui a changé par la suite, c’est que Google a montré qu’il était bien plus simple, plus fiable, plus performant et moins coûteux de développer de nouvelles applications, repensées pour s’exécuter de manière éclatée sur un ensemble de serveurs classiques. Cela a abouti notamment au map-reduce, qui change complètement la manière de développer de grosses applications.
Nulle doute que la possibilité d’écrire une application simple, et la faire tourner sur un serveur qui pourra aller de 1 à 48 processeurs virtuels et jusqu’à 256 GO de RAM, c’est génial. Mais de là à croire que c’est forcément la meilleure solution… peut-être pas. Que faites-vous le jour où vous atteindrez la limite ? (question théorique plus que pratique, problème de riche, il faut quand même y penser)
Il existe deux autres solutions : continuer à utiliser des bons vieux serveurs dédiés (et vu la différence de prix entre serveurs dédiés et serveurs virtuels, il faut vraiment y réfléchir), ou passer sur du “vrai” cloud.
Car ce qu’on considère habituellement lorsqu’on parle de cloud, c’est quelque chose qui se rapproche plus de l’offre Amazon Web Services. Vous pouvez démarrer des serveurs à la demande, le prix est facturé à l’heure. Faites tourner un serveur pendant 10 heures, ou 10 serveurs pendant une heure, le coût sera le même. Là-dessus, ajoutez des services de stockage illimité, de base de données non relationnelle, de file de messages… Bref, tout ce dont vous avez besoin pour créer des applications dont la scalabilité devient réellement sans limite.
Ça, c’est du cloud computing. Pas simplement une machine virtuelle dont la puissance est redimensionnable à la volée.
Évidemment, tout n’est pas parfait. Mais c’est certainement une vision plus globale des choses.
Bonne analyse, merci. C’est vrai que le fameux « Cloud » est avant tout un emballage commercial, et que ce qu’on trouve derrière est très hétérogène. Je partage votre analyse que aujourd’hui, pour différentes raisons liées aux architectures materielles et réseaux, le moyen le plus efficace pour atteindre la fiabilité et la tenue de charge (deux promesses courantes du cloud) est la distribution applicative. Quand en plus c’est pour du web, les proto IP, DNS et HTTP facilitent déjà pas mal les choses, avec des standards éprouvés depuis longtemps.
J’avais sauvegardé l’article la pour le lire absolument. Je suis un peu déçu en fait. C’est intéressant mais le titre devrait d’avantage avoisiner quelque chose comme « Pourquoi la virtualisation n’est pas le cloud ». Au final, un seul paragraphe parle vraiment du cloud, et il en parle très rapidement.
[/raleur]
Cela dit le contenu est intéressant, je le garde quelque part 😉
Désolé de vous avoir déçu. C’est vrai que cet article avait pour but principal de dénoncer les mensonges véhiculés par les messages “commerciaux” autour du cloud computing, pas d’expliquer les fondements du cloud…
Bonne analyse !
J’ai moi aussi au début du bruit « cloud » était attiré par le concept puis j’ai vite déchanté en voyant que ce n’était qu’un repackaging de serveur virtuel avec un prix excessif.
Je préfère rester sur du dédié avec des VM que je migre au besoin 🙂