11 technologies qui rendent le cloud possible

Les technologies du cloud réunissent le matériel, les logiciels et les outils de gestion qui transforment des ressources informatiques en services accessibles par un réseau. Les serveurs fournissent la capacité. Les logiciels l'attribuent, relient les applications, contrôlent les accès, mesurent les usages et réagissent aux changements de demande ou de conditions de fonctionnement.

Aucune invention ne suffit à constituer un cloud. La virtualisation, les conteneurs, les systèmes distribués et l'automatisation répondent à des problèmes différents et peuvent être combinés de plusieurs façons. Ce guide les regroupe en 11 familles de technologies, explique leurs interactions et les distingue des modèles de service IaaS, PaaS et SaaS.

Quelles technologies rendent le cloud computing possible ?

Les principales technologies couvrent la capacité physique, l'abstraction des ressources, l'exécution des applications, le réseau, le stockage, les accès et l'exploitation. Cette liste aide à examiner un service cloud. Elle ne constitue pas une norme imposant exactement 11 composants à chaque fournisseur.

L'architecture de référence du cloud computing du NIST distingue les ressources physiques, les logiciels qui les abstraient et les contrôlent, et les services présentés aux clients. Cette distinction explique pourquoi louer une machine virtuelle, appeler une API et utiliser un éditeur de documents en ligne donnent des niveaux de contrôle très différents.

Les plateformes cloud n'ont pas toutes la même architecture interne. Un service bare metal peut attribuer des serveurs entiers ; une plateforme de conteneurs peut utiliser des machines virtuelles. Pour évaluer un service, il faut examiner son comportement documenté plutôt que déduire son fonctionnement du seul mot « cloud ».

1. Le matériel de calcul et les accélérateurs

Toute charge de travail cloud s'exécute sur du matériel physique. Les CPU traitent des instructions générales, la mémoire contient les données actives et les supports de stockage conservent l'information. Les interfaces réseau relient les machines. L'alimentation électrique, le refroidissement et la maintenance rendent cette capacité exploitable, dans un grand centre de données ou sur plusieurs sites plus petits.

Les accélérateurs, dont les GPU, peuvent améliorer les performances de traitements parallèles adaptés, par exemple certains calculs d'entraînement et d'inférence, le rendu ou les simulations scientifiques. Ils ne sont pas nécessaires au cloud computing. Une application qui attend surtout le stockage ou exécute du code séquentiel peut tirer peu de bénéfice d'un GPU plus puissant.

Le client rencontre cette couche à travers les caractéristiques d'une instance : processeur, vCPU, RAM, mémoire de l'accélérateur, stockage et limites réseau. Comparez ces caractéristiques au principal facteur limitant de l'application. Un nombre identique de vCPU ne garantit pas des performances équivalentes entre générations de processeurs ou politiques d'allocation. La capacité disponible peut aussi varier selon le lieu.

2. La virtualisation et l'abstraction des ressources

La virtualisation présente des ressources définies par logiciel, sans obliger chaque application à gérer une machine physique. Un hyperviseur peut exécuter plusieurs machines virtuelles sur un hôte, chacune avec son propre système d'exploitation invité. Le fournisseur peut ainsi répartir la capacité, tandis que le client crée un environnement sans installer lui-même le matériel.

Le matériel apparent d'une VM correspond à une abstraction régie par une politique d'allocation. Les ressources peuvent être partagées ou dédiées ; le fournisseur définit les configurations disponibles et les opérations de gestion. Un service cloud bare metal donne accès à un serveur entier par des interfaces de gestion cloud, sans nécessiter la même couche de machines virtuelles.

Pour le client, les questions portent sur l'isolation, les performances, les systèmes d'exploitation pris en charge et ce qui subsiste après un arrêt, un redémarrage ou une suppression. La virtualisation ne supprime pas les pannes physiques. Les sauvegardes, la répartition entre domaines de panne et la reprise de l'application restent des choix distincts.

3. Les conteneurs

Un conteneur exécute une application sous forme de processus isolés à partir d'une image. Celle-ci contient le code et ses dépendances, ce qui réduit les différences entre les environnements de construction et de déploiement. Dans le modèle classique des conteneurs de système d'exploitation, plusieurs conteneurs partagent le noyau de l'hôte plutôt que de démarrer chacun un système invité complet.

L'introduction aux conteneurs de Docker explique cette différence et l'utilisation conjointe des conteneurs et des VM. Une équipe peut créer une image d'application, puis en exécuter plusieurs instances sur un ensemble de machines virtuelles.

La portabilité reste conditionnelle. L'image doit être compatible avec l'architecture du processeur et l'environnement d'exécution. L'application a toujours besoin d'une configuration, d'un stockage, d'un réseau et d'identifiants adaptés. Les conteneurs ne préservent pas automatiquement les données et ne dispensent pas de mettre à jour les dépendances. Leur isolation dépend aussi du moteur d'exécution et des paramètres de sécurité.

4. L'ordonnancement et l'orchestration

L'ordonnancement détermine où une tâche doit s'exécuter, selon ses besoins en ressources et les règles de placement. L'orchestration coordonne le déploiement et le fonctionnement dans la durée. Ces fonctions permettent de gérer de nombreuses applications sans qu'un opérateur démarre manuellement chaque processus sur une machine choisie.

L'équipe décrit par exemple le nombre d'instances souhaité et les ressources nécessaires. L'orchestrateur tente de maintenir cet état, en remplaçant les instances défaillantes ou en conduisant un déploiement selon sa configuration. Kubernetes est un exemple pour les applications conteneurisées, mais tous les services cloud n'en ont pas besoin.

L'automatisation exige de la capacité disponible et des règles adaptées. Recréer une application ne corrige ni des données corrompues, ni une dépendance indisponible, ni une image contenant le même défaut. L'ajustement automatique de capacité demande aussi un indicateur pertinent et des limites. Ajouter des processus peut aggraver la saturation d'une base de données ou augmenter la facture sans améliorer les délais de réponse.

5. Les systèmes distribués

Un système distribué coordonne des composants exécutés sur des machines reliées par un réseau. Les services cloud utilisent cette répartition pour diviser le travail, placer les données ou tolérer certaines pannes. La réplication conserve des copies ; le partitionnement divise les données ou le travail. Ces techniques peuvent être associées, mais leurs fonctions diffèrent.

Un service de stockage peut conserver des données redondantes sur plusieurs supports, tandis qu'une application utilise plusieurs processus derrière un répartiteur de charge. Il faut néanmoins gérer les pannes partielles : un composant peut rester accessible alors qu'un autre ne l'est plus. Les délais de communication et les nouvelles tentatives influencent les performances comme l'exactitude des résultats.

Le client perçoit ces choix à travers la disponibilité, la fraîcheur des lectures, les options de placement et la reprise après incident. Davantage de copies ne garantit pas un service ininterrompu, et la répartition géographique peut augmenter la latence. Notre guide des technologies des systèmes distribués détaille les mécanismes de communication et de coordination.

6. Les réseaux définis par logiciel

Les réseaux définis par logiciel, ou SDN, rendent le comportement du réseau programmable et séparent certains aspects de son contrôle des équipements qui transmettent le trafic. Les plateformes cloud configurent ainsi la connectivité et les règles quand des applications sont créées, déplacées ou supprimées. Les commutateurs, câbles et routeurs physiques continuent de transporter les données.

Le client peut configurer des réseaux virtuels, des sous-réseaux, des routes, des règles de pare-feu, des points d'accès privés et des répartiteurs de charge. Ces paramètres déterminent quels systèmes communiquent et comment les requêtes atteignent l'application. Un répartiteur peut diriger le trafic vers des serveurs appropriés ; il ne corrige pas une application défectueuse.

L'abstraction conserve des limites physiques. La distance entre régions, la bande passante, les pertes de paquets et la congestion influencent les performances. Un réseau privé n'est pas nécessairement chiffré, et un point d'accès exposé demande des règles d'authentification et d'autorisation adaptées. Examinez la connectivité et les frais de transfert en même temps que le prix du calcul.

7. Les systèmes de stockage cloud

Le stockage cloud présente les données par des interfaces adaptées à différents usages. Le stockage bloc expose des volumes qu'un système d'exploitation peut utiliser comme des disques. Le stockage fichier fournit des fichiers et des répertoires. Le stockage objet donne accès à des objets par une API, généralement à l'aide de clés et de métadonnées plutôt que d'opérations de disque ordinaires.

L'interface ne définit pas à elle seule la durabilité, la latence ou le fonctionnement des sauvegardes. Le fournisseur peut employer la réplication ou le codage à effacement, selon des règles de protection et de placement propres au service. Les termes persistant et éphémère décrivent le cycle de vie des données ; ils ne désignent pas des interfaces supplémentaires au même titre que bloc, fichier et objet.

Avant de choisir, précisez les accès attendus : petites modifications aléatoires, fichiers partagés, longues lectures séquentielles ou récupération d'objets. Vérifiez ensuite ce qui subsiste après la suppression d'une instance, comment restaurer les données et quels frais s'appliquent aux requêtes ou aux transferts. La réplication protège contre certaines pannes, mais peut aussi propager une suppression accidentelle. Elle ne remplace pas un plan de restauration.

8. La gestion des identités et des accès

La gestion des identités et des accès, ou IAM, établit qui émet une requête et quelles opérations cette identité peut effectuer. Les utilisateurs, les applications et les tâches automatisées ont besoin de permissions différentes. L'authentification vérifie l'identité ; l'autorisation détermine si elle peut accéder à une ressource ou effectuer une action.

Les rôles, les identifiants à portée limitée et les règles d'accès évitent de donner des droits d'administration à chaque application. Une application qui dépose des objets peut avoir besoin d'un seul compartiment de stockage, sans pouvoir supprimer les autres données ni modifier les paramètres du compte. Chaque identifiant doit avoir une durée de validité adaptée et un responsable clairement identifié.

L'IAM intervient à travers toutes les autres couches. Les restrictions réseau et le chiffrement le complètent, sans remplacer une attribution correcte des droits. Les clients restent responsables des décisions d'accès qu'ils contrôlent. Les journaux d'audit, le renouvellement des identifiants et le retrait des accès inutilisés comptent même lorsque le fournisseur exploite le service d'identité.

9. Les API, l'automatisation et l'infrastructure en tant que code

Les API permettent aux logiciels de demander et de gérer des ressources cloud. Un bouton dans une console et un déploiement automatisé peuvent déclencher des opérations similaires : créer une instance, attacher du stockage, modifier une règle ou consulter un état. Ces interfaces rendent le libre-service possible sans intervention du fournisseur à chaque demande courante.

L'infrastructure en tant que code décrit l'infrastructure souhaitée dans des fichiers de configuration versionnés. Terraform, par exemple, interagit avec les API au moyen de fournisseurs logiciels et prépare un plan avant d'appliquer les changements. Cette approche facilite la revue et la répétition des opérations, à condition que le service et les ressources concernés soient pris en charge.

L'automatisation répète aussi bien les erreurs que les bonnes instructions. Examinez les opérations qui remplacent ou suppriment des ressources, protégez les identifiants et les données d'état, et recherchez les écarts entre configuration déclarée et réelle. Une réponse positive de l'API peut indiquer qu'une demande a été acceptée avant que la ressource soit prête. Le déploiement doit gérer ces états intermédiaires.

10. L'observabilité et la mesure des usages

L'observabilité aide une équipe à comprendre le comportement d'un service. Les métriques décrivent des mesures dans le temps, les journaux enregistrent des événements et les traces suivent les opérations entre composants. OpenTelemetry fournit des mécanismes pour collecter, traiter et exporter ces signaux.

La mesure des usages répond à une autre question : quelle quantité de ressources a été consommée ou allouée selon les règles du service ? Ces relevés peuvent alimenter les quotas, la planification de capacité et la facturation. Un graphique d'utilisation du CPU et une facture ne mesurent pas nécessairement la même chose. Une instance réservée peut être facturée alors que son application est inactive.

Une supervision utile relie les signaux techniques aux résultats pour l'utilisateur, par exemple les dépôts échoués ou les requêtes lentes. Déterminez quels événements nécessitent une action et conservez le contexte nécessaire à leur analyse. Les journaux peuvent contenir des données sensibles ; tout collecter sans limite augmente parfois les coûts et les risques d'accès. Mesurer ne suffit ni à diagnostiquer une panne ni à garantir des économies.

11. Les environnements gérés et l'exécution serverless

Un environnement d'exécution géré permet de déployer du code ou une application tout en confiant davantage de tâches d'exploitation au fournisseur. Les services serverless vont généralement plus loin : le provisionnement et l'ajustement des serveurs sont gérés derrière une interface d'application ou de fonction. Des serveurs exécutent toujours le travail ; le client en assure moins directement la gestion.

Ces services peuvent réduire les tâches courantes, mais la répartition précise des responsabilités varie. Les versions d'exécution, les bibliothèques prises en charge, la durée des tâches, la concurrence et les accès réseau peuvent être limités. Les délais de démarrage comptent pour certains traitements intermittents ; les tâches longues ou spécialisées peuvent nécessiter un autre modèle.

Le terme serverless ne garantit ni une réduction à zéro de la capacité, ni une facturation à la requête, ni des ressources illimitées. Consultez les règles du service choisi. Une base de données gérée, un environnement de fonctions et un service d'exécution de conteneurs peuvent tous masquer l'infrastructure, avec des contraintes et des coûts différents.

Comment ces technologies fonctionnent ensemble

Prenons une équipe qui déploie une application de traitement de documents. Elle déclare son environnement par une API ou un fichier de configuration. Les contrôles d'identité autorisent la demande, la gestion des ressources attribue la capacité et l'ordonnancement place l'application sur des machines adaptées. Les règles réseau déterminent comment les utilisateurs y accèdent et quels autres services elle peut joindre.

L'application s'exécute dans une VM, un conteneur ou un environnement géré, puis écrit dans le stockage choisi. La supervision enregistre les erreurs et les temps de réponse ; la mesure des usages relève les ressources concernées. Si la demande change, l'automatisation peut ajuster la capacité dans les limites de la conception de l'application, des quotas et des ressources disponibles.

Les pannes traversent ces frontières. Une erreur de permission de stockage peut sembler être un défaut de l'application ; un réseau saturé peut laisser les processeurs sous-utilisés. Suivez l'opération complète avant d'ajouter du matériel. Distinguer les couches aide à identifier le paramètre concerné et l'équipe capable de le modifier.

Le lien avec les caractéristiques du cloud

La définition du cloud computing du NIST retient cinq caractéristiques essentielles. Différentes combinaisons de technologies peuvent les rendre possibles :

• Le libre-service à la demande : les API, les contrôles d'identité et le provisionnement automatisé permettent de demander des ressources sans intervention du fournisseur à chaque opération.
• L'accès étendu par le réseau : des mécanismes standards donnent accès aux services depuis les clients appropriés, par une connexion publique ou privée.
• La mutualisation des ressources : la capacité physique et les logiciels d'allocation répondent à des besoins changeants. Les modalités de partage et d'isolation dépendent du service.
• L'élasticité rapide : l'ordonnancement, le provisionnement et la conception des applications permettent d'ajuster la capacité, sous réserve des quotas, de l'offre disponible, des délais de démarrage et des contraintes du traitement.
• Le service mesuré : des outils relèvent et rapportent les usages. Cela n'impose pas une unité de facturation ou un modèle tarifaire unique.

Un parc de serveurs virtualisés ne constitue donc pas automatiquement un cloud. Il peut ne proposer ni libre-service, ni provisionnement élastique, ni suivi utile des usages. À l'inverse, le client n'a pas besoin d'accéder directement à chaque mécanisme interne pour bénéficier de ces caractéristiques.

Technologies, modèles de service et modèles de déploiement

IaaS, PaaS et SaaS décrivent ce que reçoit le client et la répartition des responsabilités d'exploitation. L'infrastructure en tant que service expose des ressources informatiques. La plateforme en tant que service fournit un environnement de déploiement. Le logiciel en tant que service donne accès à une application exploitée par le fournisseur. Les mêmes technologies sous-jacentes peuvent soutenir les trois modèles.

Les termes public, privé, communautaire et hybride désignent des modes de déploiement plutôt que des composants logiciels. Un cloud privé peut utiliser la virtualisation, les API et la mesure des usages sans exposer ses applications à l'internet public. Le recours à plusieurs fournisseurs est un autre choix d'architecture, pas une technologie fondamentale supplémentaire.

Cloud native décrit une manière de concevoir et d'exploiter les applications. Serverless désigne une approche d'exécution et de gestion dont les limites dépendent du service. L'IA représente une catégorie de traitements pouvant bénéficier de certaines ressources. Aucun de ces termes n'est interchangeable avec les mécanismes matériels ou logiciels présentés ici.

La décision d'adopter des services cloud pose une question distincte de leur fonctionnement technique. Elle demande d'examiner les traitements, les coûts et les besoins d'exploitation. Une technologie utile pour un projet peut ajouter des contraintes inutiles à un autre.

Un exemple concret : les couches de service de Hivenet

La présentation de l'architecture de Hivenet distingue l'infrastructure physique, la plateforme logicielle et les produits accessibles aux clients. Elle précise aussi que les produits ont des architectures différentes. Une plateforme commune ne signifie donc pas que tous les services utilisent les mêmes mécanismes de stockage ou d'exécution.

Le guide de démarrage de Compute with Hivenet présente les contrôles accessibles au client : choisir une VM ou un conteneur, sélectionner les ressources disponibles et un lieu, configurer l'accès et lancer une instance. Ces choix documentés illustrent l'abstraction et le provisionnement sans supposer un hyperviseur, un ordonnanceur ou une architecture réseau non documentés.

Questions fréquentes

La virtualisation est-elle synonyme de cloud computing ?

Non. La virtualisation abstrait des ressources et peut contribuer à un service cloud. Le cloud implique aussi la fourniture du service, le provisionnement, les accès et la mesure. Des VM gérées par demandes manuelles ne possèdent pas toutes les caractéristiques du cloud simplement parce qu'elles sont virtuelles.

Tous les clouds utilisent-ils des conteneurs ou Kubernetes ?

Non. Un service cloud peut fournir des VM, des serveurs bare metal, des applications gérées ou d'autres environnements d'exécution. Les conteneurs et Kubernetes sont des choix possibles, pas des conditions universelles. Consultez la documentation du fournisseur pour établir ce qu'un service précis prend en charge.

Les GPU et l'IA sont-ils nécessaires au cloud computing ?

Non. Les CPU exécutent de nombreux traitements cloud sans accélérateur. Les GPU sont utiles lorsque le logiciel et le traitement peuvent exploiter leur modèle d'exécution. Les applications d'IA peuvent utiliser le cloud, mais l'IA n'est pas ce qui transforme une ressource en service cloud.

Quelles technologies une équipe doit-elle examiner en premier ?

Commencez par les besoins de calcul, d'accès aux données, de réseau et de reprise. Examinez ensuite les contrôles d'accès, le déploiement et la supervision nécessaires à l'exploitation. Les choix utiles répondent à ces besoins avec des responsabilités et des limites que l'équipe comprend.