Pourquoi le cloud computing existe

Une date de lancement qu'on ne peut pas deviner deux fois

Imaginez une équipe qui prépare le lancement d'un nouveau produit dans 6 mois. Avant même d'écrire une ligne de code, quelqu'un doit répondre à une question que personne ne peut vraiment estimer avec précision : combien de serveurs faudra-t-il le jour du lancement ? Si l'estimation est trop basse, le site plie dès que le trafic réel arrive. Si elle est trop haute, l'entreprise vient de dépenser des dizaines de milliers d'euros dans des machines qui passeront la majeure partie de leur vie inactives, à tourner dans une baie, à consommer de l'électricité, en attendant un pic de trafic qui n'arrivera peut-être jamais.

Cette estimation était autrefois incontournable. Acheter un serveur n'était pas une décision du jour au lendemain. Un bon de commande, une chaîne d'approbations, une expédition du fournisseur, une installation en baie et une configuration réseau pouvaient facilement représenter plusieurs semaines avant que le matériel ne serve à quoi que ce soit. Une fois arrivé, il fallait qu'un membre de l'équipe le garde en état de marche : appliquer les correctifs de sécurité, remplacer les disques défaillants, garder la salle au frais, et finalement le retirer et le remplacer tous les quelques années, que l'entreprise ait grandi jusqu'à en avoir besoin ou non.

C'est ce monde que le cloud computing a été conçu pour éviter : un gros achat initial (une dépense en capital, ou CapEx) réalisé des mois avant d'avoir réellement besoin de la capacité, sur la base d'une estimation qu'on se trompe souvent dans un sens ou dans l'autre. Vous verrez ce modèle de coût comparé à l'alternative du paiement à l'usage du cloud plus en détail plus loin dans ce domaine.

Une idée plus ancienne que l'ordinateur personnel

On a tendance à penser que le cloud est une invention toute récente des années 2000. Ce n'est pas le cas. L'idée centrale, laisser plusieurs utilisateurs se partager un grand ordinateur coûteux plutôt que d'en posséder chacun un petit, remonte aux années 1960. Les ordinateurs mainframe de cette époque coûtaient plus que ce que la plupart des entreprises pouvaient justifier de posséder en propre, alors des fournisseurs et des universités ont construit des systèmes à temps partagé : des dizaines de personnes connectées au même mainframe physique via des terminaux distants, chacune croyant avoir la machine pour elle seule. Au milieu des années 1960, des centaines d'entreprises vendaient déjà de cette façon un accès à du temps de calcul partagé.

Le temps partagé n'a pas survécu aux années 1970 et 1980. Les miniordinateurs, puis les ordinateurs personnels, sont devenus assez bon marché pour que les entreprises puissent simplement posséder leur informatique plutôt que de louer une part de celle d'un autre. Le marché du mainframe partagé s'est effondré, mais l'idée sous-jacente, que plusieurs utilisateurs pouvaient se partager un vaste réservoir de puissance de calcul, n'a jamais disparu. Elle avait seulement besoin d'une meilleure technologie pour revenir.

Les 3 pièces qui devaient s'assembler

Le cloud computing moderne a eu besoin de 3 avancées distinctes pour converger avant de fonctionner à l'échelle qu'on connaît aujourd'hui.

La première était la virtualisation : un logiciel qui permet à une seule machine physique d'exécuter en toute sécurité plusieurs systèmes indépendants et isolés en même temps. IBM avait déjà prouvé que c'était possible sur les mainframes dès les années 1970, mais cela restait une technique réservée aux mainframes pendant des décennies. Cela a changé en 1999, quand VMware a apporté une virtualisation pratique aux serveurs x86 ordinaires que la plupart des entreprises utilisaient réellement, transformant une spécialité de mainframe en quelque chose que n'importe quel centre de données pouvait exécuter. La prochaine leçon détaille précisément comment cela fonctionne.

La deuxième était un accès internet fiable et abordable. Le temps partagé des années 1960 impliquait de se connecter à une machine précise via une ligne dédiée. Un cloud doit être accessible depuis n'importe où, sur des connexions internet ordinaires, ce qui n'est devenu réaliste qu'avec la diffusion du haut débit dans les années 1990 et 2000.

La troisième était une entreprise prête à louer sa capacité excédentaire à grande échelle. Amazon avait déjà construit d'immenses centres de données pour absorber ses propres pics de trafic, comme la période des fêtes, et s'est rendu compte que cette capacité restait sous-utilisée le reste de l'année. En 2006, l'entreprise a ouvert cette infrastructure au public sous le nom d'Amazon Web Services, en lançant Amazon EC2 pour le calcul et Amazon S3 pour le stockage. Google a suivi en 2008 avec Google App Engine, et Microsoft a lancé Microsoft Azure en 2010. En 4 ans, les 3 fournisseurs qui dominent encore le marché aujourd'hui étaient tous en ligne.

Ce que le cloud supprime vraiment

En assemblant ces pièces, on voit précisément ce qui a changé. Le pari sur la capacité disparaît presque entièrement, parce qu'on peut ajouter ou retirer des serveurs en quelques minutes plutôt qu'en plusieurs semaines. L'attente de plusieurs semaines pour que le matériel soit expédié et installé disparaît, parce qu'il n'y a plus de matériel à vous expédier. Le gros achat initial disparaît, parce qu'on paie ce qu'on utilise au fur et à mesure plutôt que d'acheter du matériel avant d'en avoir besoin. Et le travail de maintenance continue, correctifs, refroidissement, remplacement des disques défaillants, se déplace vers le fournisseur, dont l'activité entière consiste à faire cela à une échelle qu'aucune entreprise seule ne pourrait atteindre.

Rien de tout cela ne rend l'idée des années 1960 nouvelle. Cela la rend, pour la première fois, réalisable : sûre à exécuter à grande échelle, accessible depuis n'importe où, et proposée comme un service auquel on peut simplement s'abonner plutôt qu'un système qu'il faut construire soi-même.

Ce que cette leçon prépare

Les problèmes vus dans cette leçon, l'estimation coûteuse, l'approvisionnement lent et la maintenance constante, forment le "pourquoi". La prochaine leçon donne le "quoi" formel : la définition que le cloud computing doit réellement respecter pour mériter son nom, afin que vous puissiez distinguer un véritable service cloud d'un centre de données que quelqu'un appelle simplement ainsi.