Comment fonctionne le cloud computing ? De la demande à l'exécution

Comment fonctionne le cloud computing ? Une plateforme cloud transforme des processeurs, de la mémoire, du stockage et des réseaux physiques en ressources que vous demandez par logiciel. Elle vérifie votre identité et la configuration souhaitée, cherche une capacité disponible, prépare l'environnement et le rend accessible. Votre application s'exécute ensuite sur du matériel réel, tandis que la plateforme gère l'état de la ressource et mesure son utilisation.

Pour un développeur, un étudiant ou une personne chargée d'un choix technique, suivre ce parcours permet de comprendre ce que gère le fournisseur et où commence son propre travail. Comprendre ce processus aide lorsqu’une application ne démarre pas, que la capacité manque ou que la facturation continue après une tâche. Ce guide suit une demande d'infrastructure de la création à l'arrêt, puis montre comment les services managés et Compute with Hivenet en modifient les détails.

Les deux couches de l’architecture du cloud computing

La description de l'infrastructure cloud par le NIST distingue le matériel physique de la couche logicielle d'abstraction. Cette distinction explique pourquoi une simple action dans une console peut mobiliser plusieurs systèmes.

L'infrastructure physique exécute le travail

Les serveurs physiques fournissent des processeurs, de la mémoire et parfois des GPU. Les supports de stockage conservent les données, et les commutateurs et routeurs relient les machines. L'alimentation, le refroidissement, les locaux et la maintenance matérielle permettent leur fonctionnement. Cette infrastructure peut occuper de grands centres de données, des sites de colocation, des locaux privés ou des sites distribués plus petits.

Une région ou un type de ressource proposé dans une console représente un choix au sein de cette infrastructure physique. Sa capacité n'est pas illimitée. La maintenance, la demande existante, la compatibilité matérielle et les règles de placement peuvent rendre une configuration indisponible.

Le logiciel rend l'infrastructure disponible sous forme de service

Les logiciels de gestion exposent des API, consoles, modèles, identités, règles et commandes de cycle de vie. D'autres composants allouent les ressources, créent les environnements d'exécution, configurent les réseaux, relient le stockage et recueillent les informations d'exploitation.

Les machines virtuelles constituent une façon de fournir des ressources de calcul. Les conteneurs, les serveurs bare metal et les environnements d'exécution managés en sont d'autres. La mise en œuvre varie selon le fournisseur, et plusieurs mécanismes peuvent coexister dans une plateforme cloud.

Comment fonctionne le cloud computing, étape par étape ?

Prenons une demande d'instance destinée à exécuter une application. Le parcours suivant est un modèle conceptuel : un fournisseur peut regrouper des opérations, les réordonner ou en effectuer certaines en parallèle. Créer une ressource diffère aussi d'une requête ordinaire envoyée à une application déjà active.

1. Vous décrivez la ressource nécessaire

Une console, un outil en ligne de commande, un client API, un pipeline de déploiement ou un outil d'infrastructure as code envoie une demande. Pour une instance, la configuration peut préciser la localisation, les ressources CPU ou GPU, la mémoire, le disque, l'image du système d'exploitation ou le modèle de conteneur, ainsi que les connexions.

La plateforme reçoit une configuration souhaitée. Elle peut accuser réception avant que l'environnement soit prêt : conservez l'identifiant de ressource et suivez la progression au lieu de supposer qu'une demande acceptée signifie que l'application fonctionne.

2. La plateforme vérifie l'identité et les autorisations

L'authentification détermine quelle personne ou quel service émet la demande. L'autorisation vérifie si cette identité peut effectuer l'action dans le compte, l'organisation ou le projet concerné.

Une connexion valide ne donne pas tous les droits. Une personne peut être autorisée à utiliser une instance existante sans pouvoir modifier la facturation ou supprimer une ressource partagée. Les identifiants de gestion de l'infrastructure peuvent aussi différer des clés utilisées pour accéder à l'application.

3. Le plan de contrôle valide la configuration

La couche de gestion confronte la demande aux quotas, règles, configurations prises en charge, conditions du compte et limites du service. Une demande peut échouer parce que le type de ressource n'est pas disponible, qu'un quota est épuisé ou que le compte manque de crédits.

La validation et le provisionnement sont deux opérations distinctes. Certaines erreurs surviennent avant toute création ; d'autres apparaissent pendant la préparation. Après un déploiement échoué, examinez son état et les ressources déjà créées avant de réessayer. Des tentatives répétées peuvent sinon laisser des doublons ou des frais inattendus.

4. Un ordonnanceur trouve une capacité adaptée

Un ordonnanceur ou un service d'allocation choisit une capacité répondant à la demande. Le processeur, la mémoire, les accélérateurs, la localisation et les règles de placement peuvent tous compter. Une demande conforme au quota du compte peut échouer faute de capacité physique correspondante.

L'ordonnanceur Kubernetes fournit un exemple concret : il écarte les nœuds inadaptés, évalue les autres et choisit où placer un Pod. Sans nœud compatible, le Pod reste en attente de placement. Cet exemple illustre l'ordonnancement ; il ne signifie pas que tous les fournisseurs utilisent Kubernetes.

5. Un environnement d'exécution est préparé

Pour une machine virtuelle, le logiciel de virtualisation présente des ressources à un système d'exploitation invité. Une VM ne correspond pas nécessairement à un serveur physique dédié. Dans un conteneur classique, les processus partagent le noyau de l'hôte avec des mécanismes d'isolation ; certaines plateformes ajoutent d'autres couches d'isolation.

Les services bare metal donnent accès à du matériel physique dédié, avec une répartition différente des tâches de gestion. Les bases de données, fonctions et points de terminaison de modèles managés masquent davantage leur environnement d'exécution. Ces choix offrent des niveaux différents de contrôle, d'isolation et de responsabilité de maintenance.

6. Le réseau et le stockage sont raccordés

L'environnement doit pouvoir communiquer avec ses utilisateurs, ses données et ses dépendances. Selon le service, la plateforme configure des adresses, réseaux virtuels, règles de pare-feu, passerelles, équilibreurs de charge ou points de terminaison managés. L'accès par l'internet public est un choix de configuration, pas une obligation pour toute ressource cloud.

Le stockage peut prendre la forme d'un volume bloc, d'un système de fichiers partagé, d'un service objet accessible par API ou d'une base de données managée. L'application a besoin des bonnes adresses, autorisations, clés et configurations de montage ou de client. Le fonctionnement du processeur ne prouve pas que ces connexions sont établies.

7. L'environnement démarre et l'application s'initialise

Une VM démarre son système d'exploitation et applique sa configuration initiale. Un moteur de conteneurs lance l'image et le processus demandés. L'application peut ensuite charger ses paramètres, se connecter à une base de données, appliquer des migrations ou charger les poids d'un modèle en mémoire.

L'état de l'infrastructure et la disponibilité applicative sont deux signaux différents. Une instance active peut contenir un processus arrêté, un chargement de modèle échoué ou une application qui écoute sur le mauvais port. Vérifiez l'état de l'application et une requête représentative avant de lui envoyer du trafic réel.

8. La charge de travail s'exécute et son cycle de vie continue

Les processeurs physiques exécutent les instructions avec l'appui de la mémoire, du stockage et du réseau. Le travail peut consister à servir un site, traiter des données, produire un rendu ou effectuer une inférence. La plateforme continue à gérer la ressource et à mesurer l'utilisation pertinente.

Les actions suivantes, comme un redimensionnement, un redémarrage, un remplacement, un arrêt ou une suppression, repassent par la couche de gestion. Chacune possède ses autorisations, ses besoins de capacité et ses conséquences pour les données et les frais.

Qu'est-ce que le plan de contrôle du cloud ?

Le plan de contrôle gère les ressources. Le plan de données ou d'exécution porte leur travail actif. Créer une base de données est une opération de gestion ; interroger ses enregistrements est une opération de données. L'explication de Microsoft présente cette distinction.

Cette séparation aide à diagnostiquer un incident. L'échec d'une création de ressource ne signifie pas nécessairement qu'une application existante a cessé de répondre. À l'inverse, une console fonctionnelle ne prouve pas que la base de données ou le chemin réseau de l'application est disponible.

Il s'agit de responsabilités logiques, sans garantie que chaque plan occupe du matériel distinct. Dans l'architecture Kubernetes, le plan de contrôle gère les nœuds et les charges de travail, tandis que les composants des nœuds exécutent les conteneurs. Le placement physique varie selon le déploiement.

Comment fonctionnent le partage et l'isolation ?

La mutualisation permet à une plateforme d'allouer son infrastructure à plusieurs utilisateurs. Les mécanismes d'isolation séparent l'exécution, les accès et les données. Partager un hôte n'autorise pas un autre client à lire vos fichiers, mais la qualité de l'isolation dépend de la technologie, de la configuration et de l'exploitation du service.

Un processeur virtuel est une ressource de calcul attribuée, sans promesse universelle de cœur physique exclusif. De même, un service GPU peut attribuer un appareil entier, une partition ou une autre forme d'accès partagé. Consultez les spécifications de la ressource au lieu de supposer que toute instance GPU donne accès à une carte complète.

Notre guide des machines virtuelles GPU explique cet environnement particulier. Choisissez le contrôle et la capacité nécessaires à votre logiciel, notamment la mémoire et la compatibilité des pilotes, plutôt que de considérer le nom de l'instance comme une description matérielle complète.

Calcul, réseau et stockage ont des cycles de vie différents

Le stockage bloc se comporte comme un disque, le stockage fichier fournit une interface de système de fichiers et le stockage objet expose des objets par des requêtes au service. Ces interfaces déterminent la façon d'accéder aux données. Leurs règles de conservation et de suppression constituent une autre question.

La documentation du stockage Amazon EC2 distingue par exemple les volumes EBS du stockage temporaire lié à l'instance. Les données de ce dernier sont perdues à l'arrêt, à l'hibernation ou à la terminaison. Un stockage persistant peut conserver ses propres paramètres de suppression et ses propres frais.

Avant une modification du cycle de vie, identifiez où se trouvent les données importantes, si elles survivent à l'action et comment les restaurer. Une réplication, un volume monté et un instantané disponible ne valent pas un processus de restauration testé. Un test de récupérabilité permet de vérifier le résultat dont vous dépendez.

Le réseau peut aussi changer. Le redémarrage ou le remplacement d'une instance peut modifier les adresses, les associations de points de terminaison ou les connexions actives. Utilisez les informations de connexion documentées et ne supposez pas qu'une ancienne adresse restera valide.

Comment le cloud adapte-t-il sa capacité ?

La mise à l'échelle verticale modifie les ressources d'une instance ou d'une charge de travail. La mise à l'échelle horizontale change le nombre d'instances ou de réplicas. Les deux peuvent être manuelles ou automatiques ; héberger dans le cloud n'active pas à lui seul l'autoscaling.

La présentation de l'autoscaling Kubernetes distingue ces approches. Une règle automatique a toujours besoin de mesures adaptées, de limites et de capacité disponible. Une allocation plus grande peut demander un redémarrage, et des réplicas supplémentaires ont besoin d'un travail répartissable entre eux.

La capacité supplémentaire n'aide que si elle traite le facteur limitant. Ajouter des réplicas applicatifs peut ne pas résoudre une base saturée, un stockage lent ou une tâche nécessairement séquentielle. Mesurez la latence, les files d'attente, les erreurs et l'utilisation des ressources avant de choisir une modification.

Que se passe-t-il lors d'une panne d'infrastructure cloud ?

Un disque, un hôte, un chemin réseau, une dépendance ou un processus peut tomber en panne. Une plateforme peut détecter le problème et redémarrer ou remplacer une ressource, rediriger le trafic ou signaler une erreur à un opérateur. Les actions automatiques dépendent du service et de sa configuration.

Une capacité de remplacement ne recrée pas le travail non enregistré. L'application peut avoir besoin de points de reprise, de nouvelles tentatives, d'une gestion des requêtes dupliquées et d'une restauration. Une nouvelle tentative demande de la prudence : répéter un paiement ou la soumission d'une tâche peut créer une seconde action si la première a réussi mais que sa réponse a été perdue.

La fiabilité et la reprise après sinistre exigent donc davantage que l'existence d'une instance. Déterminez les pannes à tolérer, conservez les données récupérables hors d'un point de défaillance unique lorsque c'est pertinent et testez la restauration. Ne supposez pas que la surveillance d'infrastructure du fournisseur vérifie les résultats de votre application.

Qui gère quoi selon le service cloud ?

Les modèles de service décrivent la part de la pile logicielle exploitée pour vous. Le guide de responsabilité partagée de Microsoft montre comment la répartition évolue entre infrastructure, plateforme et application prête à l'emploi.

• Infrastructure en tant que service (IaaS) : le fournisseur gère l'infrastructure physique ; vous gérez généralement le système invité, les applications et leur configuration.
• Plateforme en tant que service (PaaS) : le fournisseur exploite davantage l'environnement d'exécution ; vous déployez et configurez votre application.
• Logiciel en tant que service (SaaS) : le fournisseur exploite l'application ; vous gérez toujours les comptes, accès, données et paramètres qui vous concernent.

Les fonctions serverless et les points de terminaison managés ajoutent des limites propres au service. Vous pouvez fournir du code ou envoyer des requêtes API sans choisir de serveur, mais les dépendances, les entrées, les autorisations et le comportement applicatif doivent toujours avoir un responsable.

Les clouds public, privé et hybride décrivent des modes de déploiement plutôt que cette répartition du travail logiciel. Le multicloud utilise plusieurs fournisseurs. Aucun de ces termes ne précise si une base donnée est managée ou qui doit appliquer les correctifs du système d'exploitation.

Comment l'utilisation mesurée devient une facture

Les plateformes mesurent les unités définies par chaque service : durée d'exécution, stockage provisionné, requêtes ou transfert de données. Un barème transforme ces unités en frais, parfois associés à des abonnements, engagements ou coûts de support. La mesure de l'usage ne garantit pas un coût total inférieur.

Une ressource active peut coûter de l'argent sans effectuer de travail utile. Arrêter un composant peut laisser d'autres ressources facturables. La documentation du cycle de vie EC2 distingue explicitement l'utilisation de l'instance de celle des volumes et adresses conservés.

Examinez ensemble les ressources créées par un déploiement : calcul, disques, instantanés, réseau, journaux et services managés. Confirmez les états facturés, les unités minimales de facturation, les règles de conservation et le comportement de suppression. Une notification budgétaire est utile, sans constituer nécessairement un plafond de dépenses.

Une charge GPU, de la demande à l'arrêt

Supposons qu'un développeur souhaite servir un modèle sur un GPU loué. Il vérifie d'abord la licence du modèle, la mémoire GPU nécessaire, les exigences logicielles, le trafic attendu et les conditions de traitement des données d'entrée.

1. Demander : choisir une ressource, une localisation, une image, une organisation du stockage et des connexions restreintes adaptées.
2. Préparer : attendre l'instance, se connecter, charger le modèle et configurer le processus de service.
3. Vérifier : tester une requête, contrôler les autorisations, examiner les erreurs et mesurer le délai de réponse et l'utilisation mémoire.
4. Exploiter : surveiller le comportement et le coût, conserver les résultats importants et modifier la capacité de façon réfléchie.
5. Terminer : exporter les données, vérifier que la copie est utilisable et appliquer la procédure d'arrêt ou de terminaison documentée.

Le fournisseur apporte l'infrastructure ; le développeur doit encore mettre en place un service fonctionnel et protégé. Ouvrir un port ne configure pas l'authentification, et l'allocation d'un GPU ne prouve pas que le modèle tient en mémoire ou respecte la latence attendue.

Comment Compute with Hivenet applique ce cycle de vie

Compute with Hivenet propose des instances GPU et vCPU sous forme de conteneurs ou de machines virtuelles. Le guide de démarrage Compute commence par le choix d'une organisation, la vérification de son solde, puis la configuration d'une instance disponible, de son environnement logiciel et de ses connexions.

Consultez les ressources et le prix actuels dans la console. Après sa création, l'instance atteint l'état Running lorsqu'elle répond en SSH ; l'application peut encore être en cours d'initialisation. Connectez-vous avec les informations affichées et vérifiez séparément le travail applicatif.

La comparaison entre VM et conteneur est importante : les conteneurs Compute ne donnent pas d'accès root ou sudo. Choisissez une VM si le logiciel demande un contrôle du système d'exploitation. Toutes les instances n'autorisent pas les mêmes modifications système.

La facturation Compute utilise des crédits prépayés de l'organisation et facture à la seconde pendant l'état Running. Seul l'Owner peut ajouter des crédits. Un solde faible peut interrompre le travail : surveillez-le et gardez des copies indépendantes des données importantes.

Une instance et un point de terminaison d'inférence managé sont différents

Avec une instance, vous exploitez l'application ou le logiciel de service du modèle dans cet environnement. Hivenet Inference API fournit des points de terminaison de modèles managés ; vous intégrez l'API, contrôlez les accès, traitez les entrées et évaluez les sorties.

Sa documentation de facturation actuelle décrit des réplicas fixes actifs, facturés à la seconde plutôt qu'au token. L'autoscaling n'est pas disponible actuellement. Moins de requêtes ne réduit donc pas automatiquement la capacité provisionnée ni son coût.

L'arrêt ne conserve pas une instance indéfiniment

La documentation de démarrage et d'arrêt précise que les frais de calcul cessent lorsque l'instance quitte Running. L'arrêt libère la capacité et conserve temporairement configuration et données. Le redémarrage dépend de la capacité correspondante, et une instance arrêtée pendant plus de 10 jours est automatiquement terminée.

La terminaison supprime définitivement l'instance et ses données locales. Exportez et vérifiez les fichiers importants auparavant. L'attente d'une capacité disponible ne prolonge pas la durée de conservation. Ces règles sont propres à Hivenet et ne constituent pas une politique universelle du cloud.

L'infrastructure distribuée change-t-elle le processus ?

Une infrastructure peut être répartie entre plusieurs sites tout en proposant les commandes habituelles pour les instances, réseaux, stockages et API. Cette disposition physique peut influencer le placement et la préparation aux pannes, mais les utilisateurs demandent toujours des ressources, exécutent leur travail, surveillent les résultats et gèrent le cycle de vie.

La distribution seule ne prouve aucun résultat en matière de sécurité, de disponibilité, de latence ou d'environnement. Évaluez les limites réelles du service, les localisations, les dépendances et les engagements d'exploitation. Cela vaut aussi pour comparer les fournisseurs utilisant de grandes installations centralisées et ceux s'appuyant sur des sites distribués plus petits.

Questions sur le fonctionnement du cloud computing

Chaque requête applicative crée-t-elle un serveur ?

Non. Une requête atteint souvent un processus déjà actif ou un service managé. Certaines plateformes démarrent ou ajustent la capacité d'exécution selon la demande, mais ce comportement dépend du service, de sa configuration et de la capacité disponible.

Une connexion internet fonctionnelle garantit-elle l'accès ?

Non. Il faut aussi un chemin réseau accessible, des identifiants autorisés, une configuration correcte et une application fonctionnelle. Certains services cloud ne sont accessibles que par un réseau privé.

Une instance cloud active peut-elle être inutilisable ?

Oui. L'infrastructure peut fonctionner alors que l'application démarre, a échoué, ne peut pas accéder aux données ou ne reçoit pas de trafic. Vérifiez l'état de la ressource et le comportement de l'application.

Supprimer le calcul élimine-t-il tous les coûts et toutes les copies ?

Aucune règle universelle ne s'applique. Les données locales peuvent être détruites alors que des disques séparés, sauvegardes, journaux, points de terminaison ou engagements subsistent. Examinez les relations entre ressources et les paramètres de suppression avant le nettoyage.