Concepts de l’informatique en nuage

L’informatique en nuage donne accès à des ressources informatiques par un réseau lorsque l’on en a besoin. Ces ressources comprennent la puissance de traitement, le stockage, les bases de données, les réseaux et les applications complètes. Elles proviennent d’un ensemble mutualisé et peuvent être rendues disponibles puis restituées rapidement, avec peu d’interactions avec le personnel du fournisseur.

De l’achat de matériel à la demande de capacité

Un fournisseur de services cloud fournit des services ; un client, ou consommateur, les utilise. AWS, Microsoft Azure et Google Cloud sont de grands fournisseurs de cloud public. Provisionner une ressource signifie la rendre prête à l’emploi. La déprovisionner signifie la libérer. Une charge de travail comprend l’application ou le processus, ses données et les ressources nécessaires à son exécution.

Dans le cloud public, le fournisseur possède et entretient le matériel physique. Les clients obtiennent les services dont ils ont besoin et paient selon le modèle de tarification du service. Une organisation peut aussi exploiter son propre cloud privé. Ses services puisent toujours dans un ensemble mutualisé et le système mesure leur utilisation, même si aucun fournisseur externe n’envoie de facture.

Comparer les façons d’exploiter une boutique en ligne

Avec l’informatique sur site, une entreprise achète un serveur pour ses propres locaux. Le personnel choisit le matériel, attend la livraison, installe un système d’exploitation, connecte le réseau puis installe la boutique. L’entreprise prend aussi en charge l’électricité, le refroidissement, les réparations et le remplacement ultérieur. Elle doit prévoir la capacité avant que les ventes ne révèlent les besoins réels.

Avec une machine virtuelle cloud, une personne choisit une taille et un emplacement dans une console web. Le serveur peut être prêt en quelques minutes. Si l’expérience s’arrête au bout d’un mois, elle supprime la machine virtuelle. Les frais de calcul correspondants cessent, mais le stockage conservé séparément ou d’autres ressources peuvent encore coûter de l’argent.

La colocation change l’emplacement des serveurs possédés par l’organisation ; elle ne change pas en elle-même leur mode de provisionnement. De même, un serveur loué accessible par Internet peut relever de l’hébergement traditionnel. L’accès réseau seul n’est qu’une partie du modèle cloud.

Trois questions distinctes

La définition du NIST distingue les caractéristiques essentielles, les modèles de service et les modèles de déploiement. Les caractéristiques posent la question : « Fonctionne-t-il comme un cloud ? » Le modèle de service demande : « Quelles couches le fournisseur gère-t-il ? » Le modèle de déploiement demande : « À qui l’infrastructure est-elle destinée ? » Un cloud privé peut fournir IaaS et un cloud public peut fournir SaaS.

Les données cloud ont un emplacement physique sur du matériel de stockage dans des centres de données. Les clients choisissent souvent une région, même s’ils ne sélectionnent généralement pas un disque ou un hôte particulier. « Dans le cloud » décrit le modèle de fourniture et ne signifie pas que les données n’ont pas d’emplacement.

La publication NIST SP 800-145 décrit cinq caractéristiques essentielles de l’informatique en nuage. Chacune répond à une question pratique différente sur l’obtention et l’utilisation des ressources. Un service doit réunir les cinq ; un grand ensemble de serveurs ou une page de commande en ligne ne suffit pas à lui seul.

Les cinq caractéristiques

1. Libre-service à la demande : les clients créent eux-mêmes des ressources dès qu’ils en ont besoin. Une personne chargée du développement peut provisionner un volume de 100 Go à 2 h du matin par une console ou une API, sans attendre une intervention du personnel du fournisseur. Une API est une interface qui permet à un logiciel d’adresser des requêtes à un autre système.
2. Accès réseau étendu : des mécanismes réseau standards rendent les services accessibles à différents appareils. Le personnel peut utiliser le même service depuis le navigateur d’un ordinateur portable, une application sur téléphone ou un logiciel qui appelle une API HTTPS. L’accès peut toujours nécessiter une authentification et une connexion réseau privée.
3. Mutualisation des ressources : le fournisseur attribue et réattribue la capacité de traitement, de mémoire, de stockage et de réseau entre les clients. Chaque client est un locataire. La séparation logique protège les locataires tandis que les ressources physiques sont partagées. Les clients peuvent souvent choisir une région sans connaître le serveur exact utilisé.
4. Élasticité rapide : la capacité peut augmenter et diminuer rapidement avec la demande. Une plateforme vidéo peut utiliser normalement 4 serveurs, 40 pour une finale en direct, puis 4 après celle-ci. L’automatisation effectue souvent ces changements, mais la définition admet aussi des changements rapides déclenchés par une personne.
5. Service mesuré : le système enregistre l’utilisation dans des unités adaptées, comme les secondes de calcul, les Go de stockage ou les comptes actifs. Le fournisseur et le client peuvent surveiller et contrôler la consommation, ainsi que produire des rapports à son sujet.

Appliquer les critères à deux services

Une entreprise loue un serveur dédié après avoir rempli un formulaire commercial. La livraison prend trois jours et une augmentation de capacité nécessite un nouveau contrat. Elle paie 200 € chaque mois. L’attente exclut le libre-service à la demande et le processus d’augmentation de capacité ne présente pas d’élasticité rapide. Le matériel dédié ne provient pas d’un ensemble mutualisé. Ces observations permettent de reconnaître un hébergement traditionnel.

Le forfait mensuel fixe ne tranche pas la question de la mesure. L’hébergeur pourrait tout de même enregistrer le temps processeur ou l’utilisation du réseau. La mesure et la facturation sont différentes : un compteur enregistre la consommation ; une règle tarifaire transforme une mesure en frais.

Considérons maintenant un service de messagerie. Un administrateur peut ajouter ou supprimer immédiatement des boîtes aux lettres, les utilisateurs se connectent depuis différents appareils, une infrastructure mutualisée sert de nombreuses organisations, la capacité change avec la demande de comptes et le service indique le nombre d’utilisateurs actifs. Cette combinaison satisfait aux cinq caractéristiques, même si la facture prend la forme d’un abonnement mensuel.

Reconnaître une correspondance partielle

Un service informatique peut exploiter de nombreuses machines virtuelles alors que les employés attendent des jours que chaque demande soit approuvée et que la machine soit créée manuellement. La virtualisation facilite la mutualisation, mais ce processus ne comporte pas de libre-service. L’ajout d’un portail n’est utile que s’il s’accompagne d’automatisation, d’un provisionnement rapide et d’une mesure de l’utilisation.

Un cloud privé peut utiliser son compteur pour produire des rapports par service ou établir des frais internes. Le service mesuré s’applique donc même sans facture externe. L’élasticité exige aussi de rendre la capacité : conserver en permanence la capacité nécessaire au pic laisse des ressources inactives lorsque la demande baisse.

La virtualisation crée des versions logicielles de ressources informatiques physiques. Elle permet à un serveur physique de prendre en charge plusieurs ordinateurs logiciels distincts. Les exploitants cloud la combinent avec l’automatisation, le libre-service et la mesure de l’utilisation pour rendre rapidement de la capacité disponible.

Hôtes, invités et hyperviseurs

Une machine virtuelle possède des processeurs virtuels, de la mémoire, des disques et des interfaces réseau. Elle exécute son propre système d’exploitation invité et ses applications. L’ordinateur physique sous-jacent est l’hôte. Un hyperviseur crée les machines virtuelles, leur attribue de la capacité physique et maintient la séparation logique de leur mémoire et de leur stockage.

Une image de machine virtuelle est un point de départ enregistré pour créer une machine virtuelle. Un logiciel peut créer une machine virtuelle à partir de cette image sans commander de nouveau serveur physique. Le démarrage, le redimensionnement et la suppression de machines virtuelles facilitent le provisionnement rapide et l’élasticité. Le système de virtualisation peut suivre l’utilisation des ressources, ce qui permet de la mesurer. Certaines plateformes prennent aussi en charge la migration à chaud, qui déplace une machine virtuelle en cours d’exécution entre des hôtes afin que la maintenance du matériel ne provoque que peu ou pas d’interruption.

Étudier une consolidation

Supposons que 12 serveurs physiques de puissance égale utilisent chacun en moyenne 10 % de leur processeur. Leur charge moyenne totale est de :

Cela représente la capacité de traitement de 1,2 serveur. Le déplacement des charges de travail vers des machines virtuelles sur deux hôtes de même puissance donne une moyenne par hôte de :

Dix machines physiques peuvent être retirées, ce qui réduit les besoins en électricité, en refroidissement et en maintenance. Avant de le faire, l’équipe doit aussi vérifier les pics de demande de processeur et les besoins en mémoire, en disques et en réseau. Le seul calcul de la moyenne ne permet pas d’établir que deux hôtes pourront faire face à toutes les périodes de forte activité ou à la panne d’un hôte.

Partager sans partager les données

La mutualisation entre locataires signifie que plusieurs clients utilisent une infrastructure partagée. L’isolation empêche un locataire d’accéder à la mémoire ou aux disques des machines virtuelles d’un autre. Les limites physiques partagées peuvent néanmoins affecter les performances : un locataire exceptionnellement actif peut mobiliser la capacité au détriment des autres. C’est l’effet de voisin bruyant. Des contrôles de ressources limitent cet effet. Les hôtes dédiés fournissent un serveur physique entier aux clients dont les exigences le nécessitent.

La virtualisation du stockage présente des disques mutualisés sous forme de volumes virtuels. La virtualisation réseau fournit des réseaux distincts définis par logiciel sur des connexions physiques partagées.

Les conteneurs regroupent des applications, des bibliothèques et des paramètres tout en partageant un noyau de système d’exploitation. Une machine virtuelle possède un système d’exploitation invité complet ; ce n’est pas le cas d’un conteneur. Les conteneurs démarrent généralement plus vite et utilisent moins de ressources, tandis que les machines virtuelles assurent une séparation plus forte au niveau du système d’exploitation et peuvent exécuter différents systèmes invités. Les conteneurs s’exécutent souvent dans des machines virtuelles.

Un cloud peut aussi proposer des serveurs physiques en libre-service. La virtualisation est un fondement majeur, tandis que les cinq caractéristiques du service déterminent si l’offre dans son ensemble relève de l’informatique en nuage.

Un modèle de service décrit ce que le fournisseur fournit et ce que le client gère. Imagine la technologie sous forme de couches : bâtiments et matériel physiques, virtualisation, système d’exploitation, intergiciel et environnement d’exécution, application et données. Un environnement d’exécution est l’environnement logiciel qui exécute le code d’une application, comme Python ou Java.

Comparer les trois modèles standards

Avec l’informatique sur site, l’organisation gère toute la pile. D’IaaS à PaaS puis à SaaS, le fournisseur prend en charge davantage de travail. Le client gagne en simplicité et renonce à une partie de sa liberté de modifier le système sous-jacent.

Un blog, trois façons de l’exploiter

Un client IaaS lance une machine virtuelle Linux, installe le serveur web, la base de données et le logiciel de blog, puis entretient ces couches. Le fournisseur continue de réparer l’hôte physique et d’entretenir l’hyperviseur. L’application des correctifs au système d’exploitation invité incombe au client.

Un client PaaS déploie une application de blog sur une plateforme prise en charge. Le fournisseur fournit les mises à jour du système d’exploitation et de l’environnement d’exécution. Le client entretient l’application et doit suivre le processus de mise à jour de la plateforme. Sur AWS Elastic Beanstalk, les correctifs et les mises à jour mineures managés peuvent être activés ; les clients maintiennent leurs environnements sur des versions prises en charge et résolvent les échecs de mise à jour. S’ils désactivent les mises à jour managées, il leur appartient de les appliquer.

Un client SaaS s’abonne à une application de blog prête à l’emploi et commence à écrire. Le fournisseur exploite l’application, mais le client contrôle toujours qui peut publier et quels contenus sont partagés.

Reconnaître des exemples courants

Les bases de données managées, comme Amazon RDS, Azure SQL Database et Google Cloud SQL, sont généralement considérées comme du PaaS : le client utilise une base de données sans entretenir la plateforme serveur sous-jacente.

Classe le service, et non l’entreprise qui le vend. Un même fournisseur peut proposer les trois modèles, et certains produits répartissent les responsabilités d’une façon qui se situe entre les catégories classiques. Consulte les tâches associées à l’offre précise lorsque son nom seul ne suffit pas.

Des appellations plus ciblées suivent la même idée. DBaaS signifie base de données en tant que service ; FaaS signifie fonction en tant que service ; XaaS est une appellation générale pour « tout en tant que service ». Quel que soit le nom, il faut toujours un responsable des données du client et des décisions d’accès.

L’informatique sans serveur signifie que le client utilise du code ou un service sans choisir, dimensionner ni entretenir ses serveurs. Des serveurs effectuent toujours le travail. Le fournisseur gère l’infrastructure et la mise à l’échelle, et la facturation repose sur des mesures propres au service.

Suivre un événement dans une fonction

Avec la fonction en tant que service (FaaS), le client charge une petite unité de code. Un événement déclenche une exécution : une requête web, un fichier chargé, un message dans une file d’attente ou une échéance planifiée. Pour un service de photos, la séquence est la suivante :

1. Un client charge une photo dans le stockage.
2. L’événement de chargement démarre une fonction.
3. La fonction crée et enregistre une vignette.
4. L’exécution se termine.

AWS Lambda, Azure Functions et Google Cloud Run functions en sont des exemples. Les fonctions réduisent généralement leur capacité à zéro lorsqu’elles sont inactives et sont facturées selon les requêtes et la durée d’exécution. L’informatique sans serveur comprend aussi des services tels qu’Amazon S3, Amazon DynamoDB et Google BigQuery. Les données stockées peuvent continuer à générer des frais lorsqu’aucun code ne s’exécute. Les offres de fonctions avec une capacité toujours prête peuvent aussi être facturées pendant les périodes calmes.

Calculer la facture d’une fonction

Prenons des tarifs indicatifs de 0,20 € par million de requêtes et de 0,000017 € par Go-seconde. Chacune des 3 millions de requêtes utilise 0,5 Go de mémoire pendant 200 millisecondes, soit 0,2 seconde.

Calcule d’abord la durée totale d’exécution, puis l’utilisation de mémoire dans le temps :

Le calcul coûte 5,10 € et les requêtes coûtent 0,60 €, soit 5,70 €. Dans cet exemple de tarification, il n’y a ni minimum ni frais de calcul pendant l’inactivité. Une machine virtuelle à 0,05 € de l’heure pendant 730 heures coûte 36,50 €.

Dans l’exemple, chaque requête coûte 0,0000019 €. La division de 36,50 € par ce montant donne environ 19,2 millions de requêtes. Au-delà de ce volume, le prix de calcul affiché de la machine virtuelle est inférieur, à condition qu’elle puisse traiter la charge. Le stockage, l’utilisation du réseau et l’administration comptent aussi dans une comparaison complète.

Comprendre les limites de fonctionnement

Un démarrage à froid est le délai pendant lequel le service prépare un environnement d’exécution. Une fonction doit être sans état : les exécutions ultérieures ne doivent pas dépendre de la mémoire ou des fichiers locaux des exécutions précédentes. Place les données durables dans une base de données ou un service de stockage.

Chaque offre impose des limites d’exécution. Les invocations standard d’AWS Lambda ont une durée maximale de 15 minutes. Certains modes d’invocation de Lambda Managed Instances autorisent des exécutions plus longues ; le mode de service applicable détermine la limite. Les travaux longs doivent respecter les règles du service choisi.

L’informatique sans serveur convient souvent au trafic irrégulier, au traitement d’événements, aux tâches planifiées courtes et à l’automatisation. Une utilisation soutenue et constante peut favoriser d’autres solutions de calcul. Le besoin de paramètres personnalisés du système d’exploitation peut aussi exclure une plateforme de fonctions. Les déclencheurs et API propres à un fournisseur peuvent rendre une migration future plus difficile.

L’informatique sans serveur est souvent regroupée avec PaaS. Son infrastructure managée réduit le travail sur les serveurs, tandis que le client sécurise toujours le code, les permissions, la configuration et les données.

Commence le choix d’un modèle de service par les exigences de la charge de travail. Une technologie familière peut être un mauvais choix si elle crée une maintenance que l’équipe ne peut pas assurer. Un produit largement managé peut aussi être mal adapté s’il supprime un contrôle dont l’application a besoin.

Déterminer ce qui doit être contrôlé

Pose ces questions dans l’ordre :

1. Une application prête à l’emploi répond-elle au besoin de l’entreprise ? Envisage SaaS.
2. L’équipe déploie-t-elle sa propre application dans un langage pris en charge sans avoir besoin de contrôler le système d’exploitation ? Envisage PaaS.
3. Le travail est-il court, déclenché par des événements et irrégulier en volume ? Envisage des fonctions sans serveur.
4. L’équipe doit-elle contrôler le système d’exploitation invité, installer des logiciels particuliers ou déplacer un serveur sans le modifier ? Envisage IaaS.

PaaS et l’informatique sans serveur se recoupent. Le choix utile est celui du service précis dont le modèle d’exécution, les limites et les outils pris en charge conviennent à l’application.

Associer les exigences aux modèles

Pour l’ancienne application, IaaS permet de contrôler une machine virtuelle, mais pas de contrôler sans restriction le matériel physique du fournisseur. La compatibilité et la prise en charge restent à vérifier. Pour SaaS, confirme que les fonctionnalités et les paramètres disponibles répondent aux exigences avant de choisir la simplicité qu’il offre.

Inclure l’effort d’exploitation dans le coût

Supposons qu’une machine virtuelle coûte 40 € par mois et nécessite quatre heures d’administration à 50 € de l’heure. L’administration coûte 200 €, soit un total de 240 €. Dans cet exemple, une offre PaaS adaptée coûte 90 € avec presque aucune administration. Ses frais de service plus élevés s’accompagnent d’un coût total inférieur.

La comparaison du travail comprend l’application des correctifs, la surveillance, les sauvegardes, les mises à jour des applications et les compétences nécessaires pour réagir en cas de panne. Confier davantage de couches au fournisseur réduit certaines de ces tâches, mais ne supprime pas la gestion des applications ou des accès.

Combiner les modèles selon les besoins

Une entreprise peut utiliser SaaS pour la gestion de la relation client, PaaS pour son site web, des fonctions pour traiter les nouvelles commandes et une machine virtuelle pour un ancien composant. Chaque service a sa propre limite de gestion.

La portabilité entre aussi dans la décision. Les machines virtuelles et les conteneurs peuvent être relativement faciles à déplacer lorsque leurs dépendances sont portables. Les plateformes managées et les déclencheurs de fonctions peuvent lier le code à un fournisseur. La dépendance au fournisseur désigne l’effort et le coût supplémentaires que cette dépendance crée.

Une décision peut évoluer avec le temps. Réhéberger une application sur une machine virtuelle peut être une première étape utile, suivie plus tard d’une migration vers une plateforme. Le choix d’IaaS doit répondre à une exigence actuelle, comme le contrôle du système d’exploitation, plutôt qu’à la seule familiarité avec ce modèle.

Un modèle de déploiement décrit les utilisateurs auxquels l’infrastructure cloud est destinée. Un modèle de service décrit les couches fournies. Ce sont deux choix distincts : une organisation peut obtenir des machines virtuelles en IaaS dans un cloud public comme dans un cloud privé.

Cloud public

L’infrastructure d’un cloud public est accessible au grand public. Un fournisseur la possède et l’exploite dans ses centres de données. AWS, Microsoft Azure et Google Cloud en sont des exemples ; d’autres fournisseurs comprennent Oracle Cloud, IBM Cloud et Alibaba Cloud.

Les clients partagent l’infrastructure et accèdent généralement aux services par Internet, même si un accès par réseau privé est aussi possible. Ils évitent d’acheter du matériel physique, peuvent obtenir rapidement de grandes capacités et choisir parmi des emplacements dans le monde entier. Ils dépendent aussi des choix de services et de la connectivité réseau du fournisseur, avec moins de contrôle sur le matériel physique.

« Public » décrit qui peut devenir client. Cela ne signifie pas que tout le monde peut voir les données de chaque client. L’isolation et les contrôles d’accès séparent les ressources. Rendre un conteneur de stockage accessible en lecture au public est un choix de configuration, pas une caractéristique inévitable du cloud public.

Cloud privé

Un cloud privé est réservé à une seule organisation, qui peut comprendre de nombreux services. L’organisation, un tiers ou les deux peuvent l’exploiter. Il peut se trouver dans les locaux de l’organisation ou être hébergé ailleurs.

Le cloud privé offre un contrôle plus étroit du matériel, de l’emplacement et de la configuration de sécurité. Ce contrôle peut aider à répondre à certaines exigences contractuelles ou réglementaires. L’exploitant doit financer la capacité et employer du personnel pour la gérer. L’expansion est limitée par le matériel disponible : il bénéficie donc de moins d’économies d’échelle qu’un grand fournisseur public.

Une salle de serveurs sur site n’est considérée comme un cloud privé que si elle offre les caractéristiques du cloud, notamment le libre-service, la mutualisation, l’élasticité rapide et l’utilisation mesurée. L’installation de machines virtuelles seule ne suffit pas à fournir certains éléments importants du service cloud. OpenStack est un exemple de logiciel utilisé pour construire des clouds privés.

Cloud communautaire

Un cloud communautaire sert un groupe précis d’organisations ayant des préoccupations communes. Elles peuvent partager une mission, une politique de sécurité ou des exigences de conformité. Les organisations membres, un tiers ou une combinaison des deux peuvent l’exploiter, sur site ou ailleurs. Plusieurs hôpitaux pourraient partager une infrastructure conçue autour de leurs exigences communes en matière de données de santé.

Une offre réservée aux organismes publics peut servir une communauté, mais les conditions réelles d’accès et les modalités d’exploitation déterminent sa classification. L’emplacement seul ne permet pas d’identifier un modèle de déploiement. Un cloud privé hébergé reste privé même s’il se trouve dans les locaux d’un fournisseur.

Les organisations conservent souvent certaines charges de travail localement et en exécutent d’autres dans des clouds publics. Les termes cloud hybride et multicloud décrivent des aspects différents de cette organisation. Une entreprise peut adopter les deux à la fois.

Connecter des environnements dans un modèle hybride

Le NIST définit le cloud hybride comme des infrastructures cloud distinctes reliées par une technologie qui permet aux données ou aux applications de passer de l’une à l’autre. Les composants restent séparés. Dans les discussions courantes sur le cloud, y compris dans les examens de base des fournisseurs, hybride désigne généralement un cloud public connecté à un cloud privé ou à des systèmes sur site.

Une liaison sécurisée peut être un VPN chiffré sur Internet ou une connexion privée dédiée. Des outils partagés de gestion des identités et d’administration peuvent aider le personnel à exploiter les environnements ensemble. Azure Arc, AWS Outposts et Google Distributed Cloud permettent différentes formes d’exploitation sur plusieurs sites ; ce sont des exemples et non des produits interchangeables.

Le modèle hybride permet de conserver localement des dossiers sensibles, d’anciens logiciels ou des systèmes de commande d’équipements, tandis que le cloud public héberge un site web ou traite la demande supplémentaire. Il facilite aussi la migration par étapes et les dispositifs de sauvegarde ou de reprise à distance. Ces avantages s’accompagnent d’un travail supplémentaire sur les réseaux, la sécurité et la gestion.

Étudier le débordement vers le cloud

Le cloud privé d’un commerçant traite 2 000 commandes par minute. Pendant une vente, la demande monte à 5 000. Le cloud public traite le surplus :

Sa part du travail au pic est de :

C’est le débordement vers le cloud : la capacité supplémentaire est utilisée pendant les pics puis libérée. L’application et les connexions de données doivent permettre de répartir ce travail. Le simple abonnement à un deuxième service ne déclenche pas le débordement.

Utiliser plusieurs fournisseurs publics

Le multicloud consiste à utiliser les services d’au moins deux fournisseurs de cloud public. Une entreprise peut choisir le service d’analyse d’un fournisseur et l’hébergement web d’un autre. Les services peuvent être utilisés séparément ; le multicloud n’exige pas de déplacer la même charge de travail entre eux.

Les raisons possibles comprennent le choix de la solution la mieux adaptée à chaque tâche, le respect d’exigences d’emplacement, la réduction de la dépendance à un fournisseur ou la combinaison de systèmes après une fusion. Les coûts comprennent plusieurs ensembles de compétences, des outils de sécurité et des factures de transfert de données.

Pour une jeune entreprise sans centre de données, le cloud public peut réduire au minimum les dépenses initiales de matériel. Une organisation tenue d’utiliser une infrastructure exclusive peut choisir un cloud privé. Une usine qui a besoin de temps de réponse locaux très courts peut conserver la commande des machines sur site tout en utilisant le cloud public pour l’analyse. Les exigences de chaque charge de travail guident son placement ; multiplier les environnements augmente le travail nécessaire pour les connecter et en assurer la gouvernance.

La capacité cloud peut être ajustée lorsque le travail évolue. La scalabilité décrit cette capacité d’ajustement. L’élasticité y ajoute une augmentation et une réduction rapides afin que la capacité suive étroitement la demande. Toutes deux peuvent réduire le besoin d’acheter du matériel pour la charge maximale possible.

Modifier une machine ou changer le nombre de machines

Faire passer une machine virtuelle de 2 à 8 vCPU est une mise à l’échelle verticale. Passer de 2 serveurs web à 6 est une mise à l’échelle horizontale. Un répartiteur de charge distribue les requêtes entrantes entre les exemplaires. Des exemplaires supplémentaires peuvent aussi assurer la redondance, à condition d’être déployés de façon à résister aux pannes concernées.

Une stratégie de mise à l’échelle automatique peut ajouter une machine virtuelle lorsque l’utilisation du processeur reste supérieure à 70 % pendant cinq minutes et en supprimer une lorsqu’elle reste inférieure à 30 %. Un minimum de deux et un maximum de dix maintiennent la stratégie dans une plage prévue. Une machine virtuelle unique ne s’ajuste pas d’elle-même simplement parce qu’elle fonctionne dans un cloud. Certains services managés prennent en charge la mise à l’échelle pour le client.

Calculer la capacité économisée grâce à l’élasticité

Un site de vente de billets a normalement besoin de 4 serveurs et de 20 pendant 10 heures sur un mois de 730 heures. Maintenir 20 serveurs en fonctionnement tout le mois utilise :

Avec une capacité élastique, on maintient d’abord les quatre serveurs habituels pendant tout le mois :

On ajoute ensuite seulement les 16 serveurs supplémentaires pour le pic :

Le total est de 3 080 heures-serveur, soit environ 21 % de 14 600. Compter 20 serveurs supplémentaires pendant le pic reviendrait à compter deux fois les quatre serveurs de base. N’en conserver que quatre en permanence éviterait la capacité inactive, mais ne permettrait pas de répondre au pic.

Provisionner rapidement et atteindre les utilisateurs dans le monde

L’agilité est la rapidité avec laquelle on obtient des ressources, teste une idée et fournit un résultat. Une équipe peut louer 50 machines virtuelles pour une analyse de deux heures, soit 100 heures de machine virtuelle, puis les libérer. Elle évite d’attendre l’achat et l’installation de 50 machines. Des expériences rapides rendent moins coûteux l’abandon d’une idée qui échoue.

La couverture mondiale consiste à utiliser les emplacements du fournisseur dans le monde sans construire de centres de données à l’étranger. Placer une application plus près des utilisateurs peut réduire la latence, c’est-à-dire le délai de communication. Il faut toujours choisir un emplacement adapté et respecter les exigences de la charge de travail concernant les données.

Le travail du fournisseur sur le matériel libère aussi du temps pour que le personnel se consacre aux produits et aux services.

La disponibilité est la part d’une période pendant laquelle un service fonctionne et peut être utilisé. La haute disponibilité utilise des composants redondants pour limiter l’indisponibilité en cas de panne. La fiabilité concerne aussi la continuité d’un fonctionnement correct et le rétablissement après une panne.

Convertir un pourcentage en durée d’indisponibilité

Utilise la part d’indisponibilité de la période :

Un mois de 30 jours compte 43 200 minutes. À 99,95 %, la part d’indisponibilité est de 0,0005, soit une durée d’indisponibilité de 21,6 minutes.

Un accord de niveau de service (SLA) fixe l’engagement formel d’un fournisseur et la compensation prévue. Celle-ci prend souvent la forme de crédits de service, avec des conditions d’éligibilité et des exclusions, plutôt que d’une indemnisation de toutes les pertes commerciales. L’accord d’un service peut dépendre de l’utilisation de plusieurs instances ou emplacements. Les offres gratuites ou en préversion peuvent ne pas en avoir.

Distinguer les dépendances des exemplaires redondants

Si une application a besoin à la fois de sa couche web et de sa base de données, chacune peut interrompre l’application. Dans un modèle simplifié avec des pannes indépendantes et des mesures comparables, multiplie leurs disponibilités sous forme décimale :

Cela donne environ 99,94 %, soit moins que pour chacun des composants. Les engagements des accords de niveau de service ne suffisent pas à établir la disponibilité réelle de l’application ; les dépendances communes et les règles de mesure comptent aussi.

Pour deux exemplaires indépendants dont un seul suffit, les deux doivent tomber en panne pour arrêter le service. Si chacun est disponible 99 % du temps, chacun présente une part d’indisponibilité de 1 % :

L’indépendance est essentielle. Deux exemplaires qui dépendent tous deux de la même alimentation électrique défaillante n’offrent pas cette protection.

Utiliser la protection et la mesure adaptées

Les fournisseurs proposent des centres de données distincts appelés zones de disponibilité, plusieurs régions et une réplication managée. Des exemplaires dans des zones distinctes peuvent protéger contre la panne d’un centre de données ; une deuxième région peut protéger contre un incident régional plus étendu. La conception et le financement d’exemplaires adaptés restent une décision du client.

La tolérance aux pannes vise à poursuivre le fonctionnement sans interruption après la panne d’un composant. La haute disponibilité peut admettre une brève interruption. La reprise après sinistre restaure le service et les données après un incident majeur. Les sauvegardes protègent les données, mais ne permettent pas à un serveur défaillant de continuer à traiter les requêtes pendant la restauration.

La prévisibilité comprend des performances régulières et des coûts compréhensibles. La mise à l’échelle et la répartition de charge aident à gérer les performances ; les rapports d’utilisation, les prévisions, les budgets et les alertes aident à gérer les dépenses. Une disponibilité plus élevée nécessite généralement des ressources supplémentaires : l’objectif doit donc tenir compte du coût de l’indisponibilité pour l’entreprise.

Les fournisseurs cloud apportent des équipes de sécurité, des contrôles physiques et une surveillance à une échelle que beaucoup d’organisations ne peuvent pas atteindre seules. Ils proposent aussi des outils qui aident les clients à appliquer des règles cohérentes. L’avantage dépend de l’utilisation de ces outils et d’une répartition claire du travail.

Utiliser les éléments de preuve du fournisseur en matière de sécurité et de conformité

Les fournisseurs protègent les bâtiments, le matériel et les réseaux physiques. Ils entretiennent leur infrastructure et fournissent des mises à jour de plateforme pour les services managés. Les clients peuvent utiliser des contrôles d’identité, le chiffrement, des pare-feu, la surveillance de sécurité et la protection contre les attaques par déni de service distribué, lors desquelles de nombreux systèmes submergent un service de trafic.

Les fournisseurs font aussi l’objet d’audits selon des normes et des cadres tels qu’ISO/IEC 27001 et SOC 2. Ces rapports fournissent des éléments de preuve sur les contrôles du fournisseur. Les règles d’accès du client, son traitement des données et la configuration des services doivent toujours répondre aux exigences de l’organisation. L’audit du fournisseur constitue une partie de ces éléments et ne vaut pas approbation de chaque application qui y fonctionne.

Maintenir l’utilisation du cloud dans le cadre des règles de l’organisation

La gouvernance est l’ensemble des politiques, processus et contrôles qui alignent l’utilisation du cloud sur les règles de l’entreprise, ses obligations légales et ses budgets. Elle va bien au-delà de la réduction des factures.

Par exemple, une organisation peut limiter la création de machines virtuelles à un ensemble de régions approuvées. Une stratégie rejette toute demande hors de cet ensemble avant que la ressource n’existe. Les balises peuvent identifier l’équipe responsable d’une machine virtuelle, tandis que les journaux indiquent qui l’a modifiée. Chaque outil répond à une question de gestion différente.

Gérer les ressources de manière cohérente

Microsoft distingue la gestion du cloud, c’est-à-dire les capacités utilisées pour exploiter les ressources, de la gestion dans le cloud, c’est-à-dire les moyens employés pour les contrôler. La première comprend la mise à l’échelle automatique, les contrôles d’état, le remplacement des ressources défaillantes et les alertes. La seconde comprend un portail, une interface en ligne de commande (CLI), des API, des kits de développement logiciel (SDK) et l’infrastructure en tant que code.

L’infrastructure en tant que code (IaC) décrit les ressources dans des fichiers que les outils de déploiement peuvent lire. Un modèle prévoyant deux machines virtuelles web, un répartiteur de charge et une base de données peut créer un environnement de test correspondant en quelques minutes. La même description des ressources peut être réutilisée sans avoir à se souvenir d’une suite de clics manuels. Les paramètres propres à la région et les autres valeurs requises doivent toujours être corrects.

L’automatisation peut aussi planifier des arrêts, appliquer des mises à jour ou effectuer des sauvegardes. La réduction des actions manuelles répétées limite les risques de paramètres incohérents et peut diminuer les coûts d’exploitation. Après un test, la suppression de ses ressources met fin aux frais propres à celles-ci ; les sauvegardes, disques ou autres services conservés restent facturables. Le suivi de ces ressources restantes fait partie de la gestion de l’environnement.

L’informatique en nuage fait passer une grande partie des dépenses de l’achat d’actifs au paiement des services au fur et à mesure de leur utilisation. Comprendre les unités de mesure est la première étape pour lire une facture et comparer le cloud au matériel possédé.

Comparer les types de dépenses

Les dépenses d’investissement (CapEx) servent à acheter des actifs utilisés pendant plusieurs années, comme des serveurs et du matériel de stockage. La comptabilité répartit leur coût par l’amortissement. Les dépenses d’exploitation (OpEx) couvrent les coûts continus, comme l’électricité, les abonnements et les services cloud, au fur et à mesure qu’ils sont engagés.

Les coûts de capacité sur site sont en grande partie fixes : le matériel acheté, l’espace et le personnel coûtent toujours de l’argent lorsque les machines sont peu sollicitées. Les frais cloud fondés sur la consommation varient avec l’utilisation. Un engagement ou un abonnement par utilisateur peut néanmoins créer une part fixe dans une facture cloud.

Le paiement à l’usage permet aux clients d’obtenir des ressources sans engagement d’utilisation à long terme. Libérer une ressource met fin aux frais liés à son utilisation. Cesser simplement d’utiliser une machine virtuelle allouée ne la libère pas, et supprimer une machine virtuelle peut laisser des disques ou des sauvegardes facturés séparément.

Lire une facture ligne par ligne

Prenons un mois de 730 heures et des tarifs indicatifs. Deux machines virtuelles fonctionnent tout le mois à 0,10 € de l’heure. Une troisième fonctionne pendant 120 heures. Le stockage représente en moyenne 500 Go à 0,02 € par Go-mois et 200 Go sortent vers Internet à 0,09 € par Go.

• Calcul de base : deux fois 730 heures donnent 1 460 heures de machine virtuelle, pour un coût de 146 €.
• Calcul supplémentaire : 120 heures coûtent 12 €.
• Stockage : 500 Go-mois coûtent 10 €.
• Transfert sortant : 200 Go coûtent 18 €.

Additionne les frais distincts :

Le total mensuel est de 186 €. Le transfert sortant correspond aux données qui quittent le cloud ; le transfert entrant correspond aux données qui y entrent. De nombreuses offres rendent le transfert entrant gratuit et facturent le transfert sortant vers Internet ou les transferts entre régions. Un service multimédia qui envoie de gros fichiers aux utilisateurs doit inclure ces volumes sortants dans son estimation.

Comparer le coût total de possession

Le coût total de possession compare tous les coûts pertinents sur une même période. Pour l’informatique possédée par l’organisation, inclus le matériel et son remplacement, les licences logicielles, l’espace, l’électricité, le refroidissement, la sécurité physique, les réseaux et le temps du personnel. Pour le cloud, inclus le calcul, le stockage, les transferts, les licences, l’administration et les éventuels coûts de migration pertinents pour la comparaison.

Les grands fournisseurs réalisent des économies d’échelle en achetant et en exploitant du matériel en grands volumes et en partageant ces coûts entre les clients. Leurs coûts unitaires plus faibles peuvent permettre des prix attractifs. L’économie réalisée pour une charge de travail donnée dépend toujours de l’utilisation, d’un dimensionnement adapté et de l’offre choisie. Des ressources surdimensionnées fonctionnant en permanence peuvent coûter plus cher qu’un serveur possédé et bien utilisé.

Les dépenses à l’usage nécessitent aussi une surveillance. Des ressources oubliées et une mise à l’échelle inattendue peuvent augmenter une facture variable. La surveillance, les prévisions, les budgets et les alertes aident l’équipe à réagir pendant que les ressources fonctionnent encore.

La tarification cloud implique un compromis entre flexibilité et engagement ou risque d’interruption. Commence par l’utilisation prévue de la charge de travail, puis choisis des conditions adaptées.

Comparer les principales options tarifaires

AWS propose des Reserved Instances et des Savings Plans ; Azure propose des Reservations et des plans d’économies ; Google Cloud propose des remises sur engagement d’utilisation. Les conditions exactes diffèrent, mais la question centrale est de savoir si l’utilisation prévisible couvrira l’engagement.

Parmi les offres Spot figurent AWS Spot Instances, Azure Spot Virtual Machines et Google Cloud Spot VMs. Elles conviennent aux tâches qui peuvent être arrêtées et reprises, comme l’analyse par lots ou le rendu. Le préavis peut être très court : AWS s’efforce de prévenir deux minutes avant une interruption entraînant l’arrêt ou la résiliation ; l’hibernation peut commencer immédiatement. Les notifications Azure Spot peuvent arriver jusqu’à 30 secondes avant l’éviction. Un service de paiement ou une base de données nécessaires en permanence ont besoin d’une protection allant au-delà d’une instance interruptible.

Calculer le seuil d’indifférence

Une machine virtuelle prise comme exemple coûte 0,10 € de l’heure à la demande. Un engagement d’un an coûte 0,06 € pour chacune des 8 760 heures :

Divise ce coût annuel par le tarif horaire à la demande :

Cela représente 60 % de l’année. Au-delà de 5 256 heures, l’engagement est moins cher à ces tarifs. Pour une utilisation continue, la tarification à la demande coûte 876 €, soit une économie de 350,40 € avec l’engagement. Pour 2 080 heures de bureau, la tarification à la demande coûte 208 €, moins que l’engagement complet. Appliquer le tarif réduit aux seules heures utilisées ferait oublier le paiement prévu au contrat.

Réduire le besoin avant d’obtenir une remise

Le redimensionnement optimal adapte les ressources à la demande mesurée. Une machine virtuelle de 8 vCPU dont l’utilisation moyenne du processeur est de 10 % mérite d’être examinée. Avant de la réduire à 2 vCPU, vérifie les pics représentatifs et les besoins en mémoire, en stockage et en réseau. Si la taille inférieure répond à ces besoins et que le prix est proportionnel, le coût de calcul tombe à environ un quart. Souscrire d’abord un engagement pourrait figer une ressource surdimensionnée.

La planification compte aussi. Un environnement de test qui fonctionne 10 heures pendant chacun des cinq jours ouvrés utilise 50 des 168 heures d’une semaine. Le libérer en dehors de ces heures réduit le temps de calcul d’environ 70 %.

Tenir compte des logiciels et des autres conditions tarifaires

Les prix avec licence incluse comprennent la licence logicielle. L’apport de licences existantes (BYOL) consiste à réutiliser des licences lorsque leurs conditions autorisent leur usage dans le cloud ; Azure Hybrid Benefit en est un exemple. Les conditions d’éligibilité, le suivi et toute exigence de matériel dédié continuent de s’appliquer.

D’autres offres utilisent des abonnements par utilisateur, des tranches de volume, des crédits d’essai ou une tarification pour hôte dédié. Une combinaison pratique peut utiliser des engagements pour la base régulière, le paiement à l’usage pour la demande incertaine et la capacité Spot pour les traitements par lots qui peuvent être repris.

Le modèle de responsabilité partagée répartit le travail de sécurité, de conformité et d’exploitation entre le fournisseur et le client. AWS appelle la part du fournisseur la sécurité « du » cloud et celle du client la sécurité « dans » le cloud. La limite change selon le service, mais il y a toujours un responsable des données du client et des décisions d’accès.

Commencer par les couches physiques

Le fournisseur protège et exploite les bâtiments des centres de données, les accès physiques, l’électricité, le refroidissement, les réseaux physiques, les hôtes et la virtualisation. Les clients s’appuient sur ces contrôles et sur les éléments de preuve issus des audits. Dans l’utilisation habituelle d’IaaS, ils n’appliquent pas de correctifs à l’hyperviseur du fournisseur.

Les clients décident comment leurs données sont classées, protégées, conservées et partagées. Ils gèrent les comptes, les identités, les droits d’accès et les paramètres de service sous leur contrôle. Ils protègent aussi les appareils utilisés pour accéder aux services. Un fournisseur SaaS peut proposer des fonctions de gestion des appareils, tandis que l’organisation reste responsable de la gestion des appareils de ses utilisateurs.

Situer la limite qui évolue

La maintenance de la plateforme suit des procédures propres à chaque service. Certaines offres PaaS exigent d’activer les mises à jour managées, de passer à une version prise en charge ou de résoudre les échecs de mise à jour. Le client doit suivre ces procédures même s’il n’exploite pas lui-même un serveur à usage général.

Attribuer la responsabilité de trois incidents

Une entreprise utilise un site web en IaaS, une base de données PaaS managée et une messagerie SaaS. Une vulnérabilité du système d’exploitation invité apparaît. L’entreprise applique le correctif à la machine virtuelle de son site ; le fournisseur entretient les systèmes d’exploitation sous-jacents à la base de données managée et à l’application de messagerie, selon les modalités de mise à jour applicables.

Ensuite, le mot de passe d’une personne employée est volé. L’entreprise doit rétablir l’accès, examiner les permissions et renforcer la protection du compte dans tous les services touchés. Le passage à SaaS n’a pas transféré ses décisions relatives aux identités au fournisseur.

Enfin, des fichiers clients deviennent lisibles par le public parce que l’entreprise a activé le partage ouvert. Elle doit corriger ce paramètre et traiter l’exposition des données. La sécurité physique du centre de données ne peut pas empêcher un administrateur autorisé de choisir une règle de partage non sûre.

Répartir les contrôles, pas seulement les désignations

Certains contrôles comportent une part pour chaque partie. Les fournisseurs appliquent les correctifs à l’infrastructure ; les clients les appliquent aux logiciels qu’ils contrôlent. Chaque partie configure ses propres couches et forme son propre personnel. Les contrôles physiques sont hérités du fournisseur, tandis que les paramètres des applications restent à la charge du client.

La conformité suit la même répartition. La certification d’un fournisseur couvre les contrôles qui ont été évalués chez lui. Le client doit prouver que sa configuration, son traitement des données et ses processus satisfont aux exigences de sa charge de travail. La documentation sur les responsabilités du service concerné et le contrat expliquent la limite en détail.

L’adoption du cloud se décide charge de travail par charge de travail. L’élasticité, le déploiement rapide et les services managés peuvent être utiles, mais chaque avantage doit répondre aux exigences de l’organisation. Identifie chaque risque assez précisément pour choisir une réponse.

Identifier les dépendances et les limites du contrôle

La dépendance au fournisseur apparaît lorsque des API, des services ou des formats de données propriétaires rendent le changement de fournisseur lent ou coûteux. L’exportation de grandes quantités de données peut aussi entraîner des frais de transfert sortant. Les formats ouverts, les outils portables, les conteneurs et les exportations de données testées peuvent réduire l’effort nécessaire pour changer de fournisseur. Chacun ajoute un coût ou limite les fonctionnalités disponibles : la portabilité est donc un choix à évaluer.

Le fournisseur contrôle son matériel, la conception de ses installations et le cycle de vie de ses services. Les clients s’appuient sur les contrats, la documentation et les audits indépendants pour obtenir des éléments de preuve sur l’infrastructure. Ils doivent aussi prévoir une réponse lorsqu’un service change ou est mis hors service.

Vérifier les connexions, l’emplacement et le temps de réponse

L’accès au cloud dépend du réseau. Une panne de connexion dans un bureau peut empêcher le personnel d’utiliser une application cloud pourtant opérationnelle. Une région éloignée ajoute un délai de communication. La commande d’une usine qui nécessite des réponses en quelques millisecondes peut rester locale, tandis que les services cloud analysent les données produites.

La résidence des données désigne l’endroit où les données sont stockées et traitées. La souveraineté des données concerne les lois et la juridiction qui leur sont applicables. Le choix d’une région répond à la question de l’emplacement, mais les contrats, les modalités d’accès et les exigences légales comptent aussi. Une organisation peut avoir besoin d’une région approuvée, d’une offre souveraine adaptée ou d’un traitement local. Aucune règle juridique particulière n’est supposée s’appliquer à tous les pays.

Associer chaque risque à une réponse pratique

Une alerte budgétaire signale un seuil ; elle n’éteint pas elle-même les ressources. Les limites de mise à l’échelle aident à contenir la capacité, tandis qu’un plan de reprise répond aux interruptions. Ces contrôles résolvent des problèmes différents.

Prendre une décision d’adoption raisonnée

Un cabinet d’avocats de 40 personnes envisage une gestion documentaire en SaaS. Les avantages attendus sont l’accès à distance, la réduction du travail sur les serveurs et l’expertise de sécurité du fournisseur. Le cabinet vérifie que l’emplacement de stockage répond à ses exigences, que les documents peuvent être exportés dans des formats standards et que tous les utilisateurs peuvent utiliser l’authentification multifacteur.

Ces vérifications relient chaque préoccupation à des éléments de preuve : la région et le contrat pour la résidence des données, un test d’exportation pour la portabilité et les contrôles de compte pour les accès. Le cabinet peut décider de migrer lorsque le service répond à ces exigences. Une autre charge de travail, comme un système local de commande de machines, peut raisonnablement rester sur site.

L’exploitation du cloud nécessite aussi des personnes qui comprennent la sécurité, les coûts et l’automatisation. Le libre-service rapide facilite la création de nouvelles ressources : la gouvernance doit donc préciser clairement leur responsable, leur usage et leurs paramètres autorisés.

Une migration vers le cloud déplace des applications, des données ou de l’infrastructure depuis des systèmes existants vers un cloud. Commence par un inventaire des applications, de leurs dépendances, de leur utilisation, de leurs coûts et de leur valeur pour l’entreprise. Choisis ensuite une stratégie pour chaque charge de travail. Cette approche par portefeuille évite d’imposer la même migration à tous les systèmes.

Comparer les sept stratégies

Les 7 R d’AWS constituent un vocabulaire utile :

Google utilise aussi des termes comme « déplacer et améliorer » pour le changement de plateforme et « repenser » pour une transformation plus large. L’action entreprise est plus utile à comprendre que la seule mémorisation des termes d’un fournisseur.

Distinguer les migrations faciles à confondre

Le réhébergement laisse le code et la conception fondamentale de l’application inchangés. Il peut réduire l’effort immédiat de migration, mais conserve de nombreuses tâches de maintenance. La relocalisation déplace tout un environnement de virtualisation compatible et son mode d’exploitation, au lieu de déplacer seulement une application vers une plateforme de machines virtuelles nouvellement choisie.

Le changement de plateforme modifie une partie limitée de l’environnement. Une version managée du même moteur de base de données peut supprimer l’administration du serveur tout en préservant la conception fondamentale de l’application. Le rachat remplace le produit lui-même. Remplacer un logiciel personnalisé de gestion des clients par un outil SaaS de gestion de la relation client est un rachat, même si les deux produits servent le même objectif commercial.

La refactorisation modifie l’architecture pour obtenir des avantages tels que des composants pouvant être mis à l’échelle indépendamment. Elle peut apporter une valeur importante à long terme, mais le travail initial peut ne pas être rentabilisé pour un système stable de faible valeur. Conserver une application peut être une décision délibérée en attendant la fin d’un contrat, des travaux de compatibilité ou un examen ultérieur.

Déplacer les données et planifier le changement

Une migration de base de données avec peu d’indisponibilité peut commencer par la copie des données dans une nouvelle base, puis par la réplication des modifications ultérieures pendant que l’originale reste utilisée. L’équipe vérifie que la destination a rattrapé les modifications avant la bascule, c’est-à-dire le transfert convenu des utilisateurs ou du trafic vers le nouveau système.

La réplication réduit la quantité de modifications restant à transférer lors de la bascule. Elle ne supprime pas le besoin de vérifier l’exactitude des données, de coordonner le transfert final et de prévoir les problèmes. Pour les très grands ensembles de données, des appareils de transfert physiques peuvent déplacer le volume initial lorsque le transfert réseau n’est pas pratique.

Examine les dépendances avant de déterminer l’ordre des migrations. Une application qui a toujours besoin d’une base de données locale peut nécessiter une connexion ou une migration coordonnée. Le réhébergement peut être une première étape suivie d’une optimisation ; un portefeuille adapté peut combiner mise hors service, conservation, remplacement et reconception.