Les fondamentaux du cloud computing

Qu'est-ce que le cloud computing ?

La définition officielle du NIST pour le cloud computing, décortiquée expression par expression, et le test qu'elle donne pour distinguer un véritable service cloud d'un centre de données que quelqu'un appelle simplement ainsi.

Débutant 14 minutes 4 Objectifs d'apprentissage
  1. Énoncer la définition du NIST pour le cloud computing
  2. Expliquer ce que chaque expression de la définition exige réellement d'un véritable service cloud
  3. Lister les 5 caractéristiques essentielles, les 3 modèles de service et les 4 modèles de déploiement que la définition nomme
  4. Identifier les cas où un serveur hébergé ne correspond pas au cloud computing

Une définition qui doit vraiment servir

Le mot "cloud" est employé de façon si large qu'il peut presque tout désigner : un fichier synchronisé sur un téléphone, un site web hébergé ailleurs, un compte email qu'on n'a pas eu besoin d'installer soi-même. Cette imprécision devient un problème dès qu'il faut vérifier si un service donné est réellement du cloud computing, ou juste quelque chose qui tourne sur le serveur d'un autre. Il vous faut une définition assez précise pour tester un service, pas seulement une impression.

La définition utilisée par l'ensemble du secteur vient du National Institute of Standards and Technology (NIST) des États-Unis, publiée dans la Special Publication 800-145. Elle est neutre vis-à-vis des fournisseurs : le NIST ne vend aucun service cloud, si bien que sa définition décrit le modèle lui-même plutôt que le discours marketing d'un fournisseur en particulier.

La définition du NIST, expression par expression

Voici la définition complète :

"Le cloud computing est un modèle permettant un accès réseau omniprésent, pratique et à la demande à un réservoir partagé de ressources informatiques configurables (par exemple des réseaux, des serveurs, du stockage, des applications et des services) qui peuvent être rapidement provisionnées et libérées avec un effort de gestion minimal ou une interaction minimale avec le fournisseur de service."

C'est une phrase dense, alors décortiquons-la morceau par morceau.

"Accès réseau omniprésent, pratique et à la demande" signifie que vous accédez au service via un réseau, presque toujours internet, depuis des appareils ordinaires, quand vous le souhaitez, sans organiser cet accès à l'avance.

"Un réservoir partagé de ressources informatiques configurables" signifie que plusieurs clients puisent dans le même matériel sous-jacent, serveurs, stockage, réseau, plutôt que chaque client possédant une machine dédiée. "Configurables" compte ici : vous ne recevez pas seulement une part fixe, vous pouvez ajuster ce que vous obtenez selon vos besoins.

"Rapidement provisionnées et libérées" signifie que la capacité apparaît quand vous la demandez et disparaît quand vous n'en avez plus besoin, en quelques minutes, pas les semaines vues dans la leçon précédente.

"Avec un effort de gestion minimal ou une interaction minimale avec le fournisseur de service" signifie que vous ne déposez pas une demande en attendant qu'une personne chez le fournisseur agisse. Vous configurez vous-même, via une console, une API ou une ligne de commande.

La forme du modèle complet

La définition du NIST est en réalité le titre d'un modèle plus large en 3 parties, chacune traitée à sa place dans ce cours :

  • 5 caractéristiques essentielles, les traits précis et testables que tout véritable service cloud doit présenter. La prochaine leçon les détaille toutes les 5 en profondeur.
  • 3 modèles de service, IaaS, PaaS et SaaS, qui décrivent quelle part de la pile technologique le fournisseur gère pour vous par rapport à ce que vous gérez vous-même. Vous verrez ces modèles dans le sujet Modèles de service cloud plus loin dans ce cours.
  • 4 modèles de déploiement, public, privé, communautaire et hybride, qui décrivent avec qui l'infrastructure est partagée. Vous verrez ces modèles dans le prochain sujet, Modèles de déploiement du cloud.

Pas besoin de mémoriser ces listes tout de suite. Ce qui compte ici, c'est la forme générale : un service cloud se définit par des caractéristiques qu'il doit présenter, pas par une seule technologie ou une seule entreprise.

La frontière qui piège le plus souvent

Voici la confusion à nommer directement : un serveur que vous n'avez pas acheté n'est pas automatiquement "cloud". Un hébergeur traditionnel qui installe un serveur physique en baie pour vous, vous donne un accès SSH, et exige un email au support avec un jour d'attente chaque fois que vous voulez plus de RAM, ce n'est pas du cloud computing, même si c'est distant et même si quelqu'un d'autre possède le matériel. Ce service échoue sur "à la demande" et sur "interaction minimale avec le fournisseur", parce qu'une personne doit agir avant que vous obteniez plus de capacité.

Comparez cela à un service où vous ouvrez une console, demandez plus de capacité, et l'obtenez en quelques minutes, sans email, sans ticket, sans attente. Cet écart, en libre-service contre demande-et-attente, est le test pratique que vous pouvez appliquer à presque n'importe quel service que quelqu'un appelle "cloud" pour vérifier s'il mérite vraiment cette étiquette.

Ce que vous emportez avec vous

Vous disposez maintenant du test : un véritable service cloud est à la demande, en libre-service, accessible par réseau, puisé dans un réservoir de ressources partagé et élastique, et facturé selon ce que vous consommez réellement. La prochaine leçon s'attarde sur chacun de ces 5 traits individuellement, parce que ce sont exactement eux qu'une véritable décision d'architecture, ou une question d'examen, vous demandera de reconnaître.