Fondamentaux du cloud : modèles de service, de déploiement et responsabilité partagée

Le mot « cloud » s'applique à tout, du service de sauvegarde pour ordinateur portable au réseau mondial de diffusion de contenu ; mieux vaut donc partir d'une définition que les ingénieurs peuvent vérifier. Celle à laquelle presque tout le monde se réfère vient du National Institute of Standards and Technology (NIST) américain, dans la Special Publication 800-145, parue en 2011 et qui fait toujours référence. Ce guide détaille cette définition, explique ensuite les modèles de service, les modèles de déploiement et l'infrastructure mondiale communs à tous les fournisseurs, et se termine par le modèle de responsabilité partagée — celui qui détermine ce qui sera de votre faute le jour où quelque chose casse.

Les cinq caractéristiques qui font le « cloud »

Le NIST définit le cloud computing comme un modèle permettant un accès réseau à la demande à un pool partagé de ressources informatiques configurables, qu'on peut provisionner et libérer rapidement avec un effort de gestion minimal. Cinq caractéristiques essentielles détaillent cette phrase :

1. Libre-service à la demande. Vous créez vous-même une machine virtuelle, une file de messages ou une base de données, via une console, un outil en ligne de commande ou une API, sans passer de ticket à un opérateur humain.
2. Large accès réseau. Les ressources sont accessibles via des protocoles réseau standard, depuis n'importe quel type de client.
3. Mutualisation des ressources. Le fournisseur sert de nombreux clients à partir du même pool physique — c'est le multi-tenant — et, en général, vous ne savez pas sur quelle machine physique vous atterrissez et ne le contrôlez pas, au-delà d'une localisation approximative comme la région.
4. Élasticité rapide. La capacité peut augmenter et diminuer rapidement, parfois automatiquement, et elle vous paraît illimitée.
5. Service mesuré. La consommation est mesurée (secondes CPU, gigaoctets-mois, requêtes, octets transférés) et c'est ce compteur qui fait la facture.

Le test est aussi utile dans l'autre sens. Une plateforme de virtualisation exploitée par votre propre équipe ops derrière un processus de demande de changement mutualise bien les ressources, mais n'offre ni libre-service ni élasticité ; le NIST y verrait une infrastructure virtualisée, pas un cloud privé. La nuance compte, car l'essentiel des bénéfices qu'on attend d'une « migration vers le cloud » — rapidité, paiement à l'usage, montée en charge automatique — vient du modèle d'exploitation, pas du fait que le matériel se trouve ailleurs.

L'élasticité n'est pas la scalabilité

La scalabilité est la capacité d'un système à absorber plus de charge quand on lui donne plus de ressources. L'élasticité est la capacité à acquérir et libérer ces ressources automatiquement quand la charge varie. Un monolithe qui ne tourne que sur une grosse machine peut être scalable (on achète une machine plus grosse) sans être élastique. Les plateformes cloud rendent l'élasticité peu coûteuse à mettre en place, mais seulement pour des systèmes conçus pour qu'une troisième instance identique serve réellement à quelque chose — traitement des requêtes sans état, stockage de session partagé, files d'attente pour absorber les pics. Ce travail de conception vous revient ; la plateforme ne fournit que les manettes.

Modèles de service : ce que vous n'avez plus à gérer

La taxonomie classique compte trois couches, et deux autres sont devenues courantes depuis la rédaction du document du NIST. Le plus simple pour les comparer est de se demander, à chaque niveau, ce qu'il vous reste à gérer.

Deux règles empiriques en découlent. D'abord, plus vous allez vers la droite, moins vous assumez de travail d'exploitation et moins vous avez de liberté : en PaaS, impossible d'installer un module noyau, et en FaaS votre code a une durée d'exécution maximale et aucun disque local persistant. Ensuite, les services de données managés (un PostgreSQL hébergé, un broker de messages managé) se comportent comme du PaaS pour ce composant, même quand le reste du système est en IaaS. Les architectures réelles mélangent librement les couches ; l'étiquette s'applique composant par composant, pas à l'échelle de l'entreprise.

Modèles de déploiement : qui partage le pool

Les quatre modèles de déploiement du NIST décrivent pour qui l'infrastructure est exploitée, et le multi-cloud s'est imposé en pratique comme un cinquième.

Cloud public. Le fournisseur possède l'infrastructure et la met à disposition du grand public. Les clients partagent le matériel, isolés les uns des autres par la virtualisation et les contrôles réseau. C'est ce que « le cloud » désigne dans la plupart des conversations, et c'est le modèle que suppose le reste de ce sujet.

Cloud privé. L'infrastructure est exploitée exclusivement pour une seule organisation, sur site ou hébergée par un tiers. Ce peut être un vrai cloud (libre-service, élastique, mesuré) lorsqu'il repose sur une plateforme comme OpenStack ou VMware avec une automatisation digne de ce nom, mais c'est souvent juste de la virtualisation avec un portail. Les secteurs réglementés le choisissent pour des raisons de localisation des données ou de latence ; la contrepartie est que l'organisation paie d'avance pour sa capacité de pointe et doit constituer elle-même son équipe plateforme.

Cloud hybride. Deux clouds distincts ou plus — typiquement un datacenter privé et un fournisseur public — reliés par une technologie qui permet aux charges de travail et aux données de passer de l'un à l'autre : une liaison réseau privée, un fournisseur d'identité commun, une couche d'orchestration partagée. Les motivations habituelles sont une migration progressive, la volonté de garder sur site un mainframe ou un système sensible à la latence, ou le « bursting » de traitements batch vers le cloud public quand la capacité locale est épuisée. C'est dans l'hybride que vivent réellement la plupart des grandes entreprises, et c'est la tuyauterie réseau et identité entre les deux côtés qui concentre l'essentiel des difficultés.

Cloud communautaire. Partagé par plusieurs organisations ayant des préoccupations communes — un consortium d'hôpitaux, un regroupement d'administrations. Rare en pratique, mais le modèle existe.

Multi-cloud. Le recours à plusieurs fournisseurs publics. Parfois délibéré (éviter le lock-in, répondre à un régulateur qui exige des plans de sortie, profiter du point fort d'un fournisseur en analytique et d'un autre en gestion d'identité), souvent accidentel (une équipe a choisi AWS, une société rachetée tourne sur Azure). Une vraie portabilité entre fournisseurs coûte cher, car les services managés diffèrent par leur comportement et pas seulement par leur API ; la plupart des stratégies multi-cloud se contentent d'une couche d'identité commune, d'une observabilité commune et d'un placement au cas par cas, plutôt que de faire tourner la même charge de travail partout.

Régions, zones et edge

Tous les grands fournisseurs organisent leur présence selon les trois mêmes niveaux, même si les noms varient.

Une région est une zone géographique — une agglomération ou un pays — qui regroupe un ensemble de datacenters. Les régions sont isolées les unes des autres : une panne du control plane dans l'une ne se propage pas aux autres, et les données ne quittent pas une région à moins que vous ne les déplaciez. On choisit une région pour trois raisons : la proximité avec les utilisateurs (latence), les contraintes légales sur la localisation des données (souveraineté) et la disponibilité des services, car les nouveaux services et types d'instances arrivent d'abord dans les plus grandes régions.

Une zone de disponibilité (AZ) est constituée d'un ou plusieurs datacenters physiquement séparés au sein d'une région, chacun avec sa propre alimentation, son refroidissement et son réseau, reliés aux autres zones par des liaisons privées à haut débit et faible latence. Les régions AWS comptent en général trois zones ou plus ; Azure a progressivement ajouté des zones à ses régions et en propose désormais dans la plupart des principales. Le contrat de conception est qu'une panne touchant une zone doit laisser les autres en service. Toute la discipline de la haute disponibilité repose sur ce contrat : placez une instance dans chacune de deux ou trois zones derrière un load balancer, et la perte d'un datacenter devient un événement dont vous prenez connaissance dans un rapport plutôt qu'une panne.

Les edge locations sont de petits points de présence, bien plus nombreux que les régions, qui hébergent des caches de CDN, des résolveurs DNS et, de plus en plus, de petits runtimes de calcul. Elles servent à raccourcir l'aller-retour jusqu'à l'utilisateur ; elles n'hébergent pas vos bases de données.

Region eu-west-1 (Ireland)
├── Availability Zone a  ── data centre(s), own power/cooling/network
├── Availability Zone b  ── data centre(s), own power/cooling/network
└── Availability Zone c  ── data centre(s), own power/cooling/network
        ▲ private low-latency links between zones (synchronous replication feasible)

Region eu-central-1 (Frankfurt)   ── a second region for disaster recovery;
                                     replication is asynchronous over the backbone

Edge locations (hundreds)          ── CDN caches and DNS close to users

Une conséquence surprend les débutants : les noms de zones sont propres à chaque compte. La zone que votre compte appelle a peut se trouver dans un bâtiment physique différent de celle qu'un autre compte appelle a ; les fournisseurs permutent la correspondance pour répartir la charge. Utilisez l'identifiant de zone exposé par le fournisseur lorsque vous devez vous coordonner entre plusieurs comptes.

Le modèle de responsabilité partagée

Le schéma le plus important de la sécurité cloud tient en deux lignes. Le fournisseur est responsable de la sécurité du cloud — les bâtiments, le matériel, l'hyperviseur, le logiciel des services managés. Vous êtes responsable de la sécurité dans le cloud — tout ce que vous configurez ou déployez. La frontière entre les deux se déplace selon le modèle de service.

Trois lignes ne passent jamais du côté du fournisseur : l'identité, les données et les terminaux depuis lesquels vos utilisateurs se connectent. C'est pourquoi les grandes fuites de données dans le cloud public de la dernière décennie ont presque toutes été des erreurs de configuration — un bucket de stockage lisible par le monde entier, une clé d'accès commitée dans un dépôt public, une base de données sans authentification accessible depuis Internet — et non des défaillances de la plateforme sous-jacente. Le fournisseur vous donne des disques chiffrés et des politiques d'accès fines ; à vous de vous en servir.

Deux bonnes habitudes découlent de ce modèle. Lisez la matrice de responsabilité de chaque service managé que vous adoptez, car « managé » ne veut pas toujours dire la même chose : un control plane Kubernetes managé ne patche pas vos nœuds workers si vous n'activez pas la mise à jour automatique des nœuds, et une base de données managée n'applique les correctifs du moteur que pendant la fenêtre de maintenance que vous avez définie. Et considérez que les certifications de conformité du fournisseur ne couvrent que sa moitié : un certificat ISO 27001 pour la plateforme ne dit rien de la licéité du traitement des données personnelles par votre application.

Payer à l'usage : CapEx, OpEx et la réalité économique

L'infrastructure sur site est une dépense d'investissement (CapEx) : vous achetez des serveurs dimensionnés pour le pic attendu dans trois ans, vous les amortissez et vous les faites tourner avec un faible taux d'utilisation moyen. Le cloud est une dépense d'exploitation (OpEx) : vous payez chaque mois ce que vous avez consommé. Ce basculement n'est pas automatiquement moins cher. Il l'est quand la charge varie, quand vous auriez sinon fortement surdimensionné, quand vous pouvez éteindre les ressources en dehors des heures ouvrées, ou quand l'alternative était une équipe chargée de racker du matériel. Il coûte plus cher quand la charge est stable et prévisible et que l'organisation dispose déjà du datacenter et du personnel, et il peut coûter beaucoup plus cher quand personne n'éteint les ressources inutilisées.

La mesure qui rend le cloud flexible fait aussi du coût une question d'ingénierie plutôt que d'achats. Chaque décision d'architecture — le volume de données qui franchit les frontières entre régions, la conservation illimitée ou non des logs, l'exécution d'un batch sur la capacité interruptible la moins chère — apparaît désormais sur une facture en quelques jours. Le guide sur la maîtrise des coûts traite la discipline en détail ; le point fondamental ici, c'est que dans le cloud, les ingénieurs dépensent de l'argent en écrivant du code.

Erreurs fréquentes

Confondre lift-and-shift et « être dans le cloud ». Copier une machine virtuelle chez un fournisseur et la faire tourner exactement comme avant vous rapporte une nouvelle facture et aucune élasticité. Tant que la charge de travail ne peut pas passer à l'échelle horizontalement ni être recréée par automatisation, elle a déménagé, elle ne s'est pas transformée.

Croire que le fournisseur patche vos VM. En IaaS, le système d'exploitation est à vous. Les images non patchées et les machines de test oubliées font partie des constats classiques des audits de sécurité cloud. Automatisez les correctifs ou, mieux, reconstruisez régulièrement vos instances à partir d'images fraîches.

Confondre haute disponibilité et reprise après sinistre. Répartir ses instances sur plusieurs zones protège contre la panne d'un datacenter ; cela ne sert à rien face à un mauvais déploiement qui corrompt la base de données, ni face à une panne régionale. Les sauvegardes et, quand c'est justifié, une seconde région sont des décisions distinctes — traitées dans haute disponibilité et reprise après sinistre.

Utiliser le compte root ou propriétaire au quotidien. Chaque fournisseur propose une identité de compte unique toute-puissante. Protégez-la par une authentification multifacteur matérielle, conservez ses identifiants hors ligne et créez des identités aux droits restreints pour les personnes et les charges de travail.

Ignorer les frontières de transfert de données. Le trafic au sein d'une zone est généralement gratuit, entre zones il coûte un peu, entre régions ou vers Internet il coûte nettement plus. Les architectures qui font transiter de gros jeux de données d'une région à l'autre « parce que l'équipe analytique est là-bas » réservent une mauvaise surprise à leurs propriétaires en fin de mois.

Points clés à retenir

• Le cloud computing se définit par un modèle d'exploitation — libre-service, élasticité, mutualisation, mesure, accès réseau — et non par le bâtiment dans lequel se trouvent les serveurs.
• Les modèles de service forment un spectre de l'IaaS au SaaS ; chaque pas vers la droite retire autant de tâches d'exploitation que de contrôle, et l'étiquette s'applique composant par composant.
• Public, privé, hybride et multi-cloud décrivent qui partage le pool ; la plupart des grandes organisations sont en hybride, et ses difficultés portent sur l'identité et le réseau.
• Les régions isolent les pannes et répondent aux règles de localisation des données ; au sein d'une région, les zones de disponibilité sont l'unité de base de la haute disponibilité ; l'edge rapproche les caches des utilisateurs.
• Avec la responsabilité partagée, le fournisseur sécurise la plateforme, tandis que l'identité, les données, le code applicatif et la configuration restent toujours à votre charge.
• Le paiement à l'usage transforme les choix d'architecture en choix de coûts : la conscience des coûts fait partie de l'ingénierie, ce n'est pas une préoccupation financière à traiter après coup.