Services d'infrastructure cloud : composants et exigences

Les services d'infrastructure cloud donnent accès à des ressources de calcul, de stockage et de réseau configurables par une console ou une API. L'infrastructure sous-jacente associe du matériel et des logiciels qui attribuent les ressources, contrôlent les accès, mesurent l'utilisation et gèrent leur cycle de vie.

Le cloud computing fournit ces ressources sous forme de services accessibles par un réseau. La question pratique est de savoir ce dont votre application a besoin. Une instance CPU ou GPU fonctionnelle ne constitue qu'une partie de la réponse. Le stockage doit conserver les bonnes données, le réseau doit relier les bons systèmes, et les mises à jour, la supervision, la reprise et le nettoyage doivent avoir un responsable.

Qu'est-ce que l'infrastructure cloud ?

Le NIST décrit l'infrastructure cloud comme un ensemble de matériel et de logiciels organisé en couches physique et d'abstraction. La couche physique comprend les serveurs, les dispositifs de stockage et les équipements réseau. Les logiciels rendent ces ressources disponibles sous forme de services configurables.

Les installations, l'alimentation, le refroidissement, les processeurs, la mémoire, les disques et les connexions réseau déterminent toujours ce qu'un cloud peut fournir. La couche de gestion place les instances, rattache le stockage, applique les règles d'accès et mesure la consommation. Une interface permet au client de demander des ressources sans exploiter lui-même les équipements physiques.

Un centre de données est une installation. L'infrastructure cloud comprend les systèmes et les logiciels qui transforment la capacité d'un ou de plusieurs sites en services. Un hébergement classique peut fournir un serveur distant aux ressources fixes ; le modèle cloud ajoute notamment le libre-service, la mutualisation, l'élasticité et la mesure de l'utilisation.

Le modèle cloud du NIST définit cinq caractéristiques essentielles : libre-service à la demande, accès réseau étendu, mutualisation des ressources, élasticité rapide et service mesuré. La connexion peut être publique ou privée. Un cloud n'a pas besoin d'exposer toutes ses ressources à l'internet public.

Quelles ressources peut-on demander comme services d'infrastructure ?

Les services d'infrastructure cloud exposent des ressources configurables par l'intermédiaire d'une plateforme. Les principales catégories accessibles au client sont les suivantes :

• Calcul : instances CPU ou GPU, machines virtuelles, environnements de conteneurs et, lorsque l'offre le prévoit, serveurs physiques dédiés.
• Stockage : volumes bloc, systèmes de fichiers partagés, stockage objet et disques temporaires avec des règles de conservation définies.
• Réseau : réseaux virtuels, adresses, routage, pare-feu, équilibreurs de charge et connexions à d'autres environnements.
• Gestion : contrôles d'identité, API de ressources, supervision, relevés d'utilisation et options de sauvegarde ou de reprise.

Les fournisseurs regroupent ces capacités de différentes façons. Une VM peut inclure un disque local et un quota de trafic, tandis qu'un volume persistant, une adresse publique, un instantané ou une passerelle constitue une ressource distincte avec ses propres limites et frais. Lisez la définition du service avant d'assimiler le prix d'une instance au coût d'une application.

Infrastructure cloud et IaaS : une distinction qui compte

L'infrastructure cloud constitue le socle technique. L'infrastructure en tant que service, ou IaaS, est l'une des façons d'y donner accès. Dans ce modèle, le client contrôle généralement le système d'exploitation et les logiciels déployés, tandis que le fournisseur gère l'infrastructure sous-jacente.

Le même socle peut prendre en charge une plateforme en tant que service (PaaS), une base de données gérée, un point d'accès à un modèle ou une application prête à l'emploi. Le périmètre de gestion varie selon le service acheté. Louer une VM pour y exploiter une base laisse à votre équipe un travail différent de l'achat d'une base gérée.

La documentation Microsoft sur la responsabilité partagée distingue ces périmètres pour l'IaaS, le PaaS et le SaaS. Attribuez les responsabilités pour chaque couche de votre déploiement. Même avec un produit géré, le client conserve des décisions concernant les données, les accès, la configuration et l'utilisation de l'application.

Les principaux composants de l'infrastructure cloud

Calcul et matériel physique

Les processeurs et la mémoire exécutent le travail. Le client peut recevoir une part d'un hôte physique, une allocation dédiée ou un serveur entier. Le nom d'une taille d'instance ne prouve pas à lui seul que le matériel est dédié, que les performances seront constantes ou qu'une bande passante précise sera disponible pour l'application.

Adaptez la configuration à la tâche : architecture CPU et instructions prises en charge, mémoire vive utilisable, mémoire GPU, performances des disques et connexions entre composants. Pour un traitement multi-GPU, le modèle d'accélérateur renseigne peu sur les communications entre périphériques ou hôtes. Testez la configuration complète avec des données représentatives.

La capacité est limitée. Un produit annoncé dans une région peut nécessiter une approbation de quota ou avoir une disponibilité restreinte. Vérifiez les modalités d'allocation, ce qu'une réservation garantit et les conditions de redémarrage d'une instance arrêtée.

Stockage cloud et persistance des données

Le stockage bloc présente des volumes semblables à des disques. Le stockage fichier offre un accès hiérarchique par un système de fichiers. Le stockage objet expose des objets par une API. Le stockage éphémère dépend du cycle de vie d'une ressource temporaire ; l'événement qui efface son contenu varie selon le service.

Consignez ce qui survit à un redémarrage, un arrêt, une suppression ou une panne d'hôte. La documentation d'arrêt et de démarrage d'Amazon EC2 distingue, par exemple, les volumes EBS persistants des données instance store, effacées lors de l'arrêt d'une instance. Il s'agit d'un comportement documenté d'AWS, pas d'une règle universelle.

Pour la continuité d'activité, la durabilité du stockage et la capacité à rétablir une application sont deux exigences différentes. La réplication peut aider en cas de panne matérielle tout en reproduisant une modification indésirable. Les sauvegardes nécessitent des règles de conservation, des contrôles d'accès adaptés et une procédure de restauration testée. Confirmez si les instantanés, sauvegardes ou volumes conservés restent facturés après l'arrêt du calcul.

Choisissez le stockage selon la capacité, la latence, le débit, les IOPS, les modes d'accès et les besoins de reprise. Une API compatible peut simplifier les modifications d'application, mais les opérations prises en charge, les identités, les outils et la durée des transferts influencent toujours la migration.

Réseau et connectivité

Le réseau cloud relie les utilisateurs, le calcul, le stockage et les systèmes externes. Réseaux virtuels, routes, adresses, DNS, pare-feu, équilibreurs de charge et passerelles remplissent des fonctions différentes. Les équipements et les connexions physiques imposent toujours des limites de bande passante et de latence.

Prenons une application avec une entrée HTTPS publique et une base accessible uniquement depuis ses serveurs applicatifs. L'application a besoin d'une route autorisée vers la base ; les administrateurs peuvent utiliser une connexion privée distincte ou un hôte d'accès contrôlé. Un sous-réseau privé ne définit pas à lui seul toutes les connexions permises.

Lisez les règles du fournisseur au niveau où elles s'appliquent. Chez AWS, les groupes de sécurité contrôlent le trafic des ressources associées, comme les instances, tandis que d'autres contrôles peuvent agir au niveau du sous-réseau. Vérifiez ces différences avant de reproduire un schéma réseau chez un autre fournisseur.

Intégrez les frais de transfert et le déplacement des données à la conception. Éloigner un grand jeu de données de ses ressources de calcul peut ajouter du temps et des coûts, même lorsque chaque service semble peu cher isolément.

Virtualisation, conteneurs et isolation

Une VM fournit un environnement de système d'exploitation invité. Un conteneur classique regroupe une application et ses dépendances tout en partageant le noyau de son environnement hôte, qui peut lui-même être une VM. La présentation des conteneurs par Docker explique cette distinction.

Ces options offrent des contrôles et des limites de sécurité différents. Vérifiez les exigences de système d'exploitation, les privilèges, les pilotes, l'accès aux périphériques et le modèle d'isolation pris en charge. Les mots « conteneur » et « VM » ne suffisent pas à déterminer la sécurité d'un déploiement.

Certains services cloud provisionnent directement des serveurs physiques : la virtualisation n'est donc pas nécessaire pour chaque ressource. Pour choisir au niveau d'une instance, consultez notre guide VM ou conteneur.

Plans de contrôle et automatisation

Le plan de contrôle reçoit les demandes de ressources et gère leur cycle de vie. Il peut vérifier les autorisations, les politiques, les quotas et la capacité avant d'organiser le placement et la configuration. Le travail s'exécute ensuite sur les ressources attribuées.

Les ordonnanceurs et les systèmes d'orchestration coordonnent le déploiement et le remplacement. Kubernetes gère, par exemple, des applications conteneurisées ; il peut constituer l'un des composants d'un environnement cloud. Son utilisation ne fournit pas automatiquement un service cloud complet.

Les API et l'infrastructure as code peuvent rendre les environnements reproductibles et les changements vérifiables. Elles peuvent aussi reproduire les erreurs. Définissez les autorisations, les quotas, la revue des changements et les règles de nettoyage avant d'automatiser de grands déploiements. Vérifiez les actions disponibles par API et celles qui nécessitent encore le support ou la console.

Sécurité cloud, supervision et mesure de l'utilisation

La gestion des identités et des accès concerne les utilisateurs, les organisations, les rôles, les comptes de service et les identifiants. Séparez les accès humains de ceux de l'automatisation, accordez uniquement les autorisations nécessaires et définissez comment retirer l'accès lorsqu'une personne ou une application n'en a plus besoin.

La supervision de l'infrastructure peut montrer l'état et l'utilisation des ressources. Les journaux, métriques, traces et alertes applicatifs répondent à d'autres questions : les requêtes réussissent-elles, une file d'attente s'allonge-t-elle, les utilisateurs rencontrent-ils des erreurs ? Désignez un responsable des incidents d'infrastructure et des incidents applicatifs.

La mesure de l'utilisation enregistre l'activité facturable selon les règles du service. Temps d'exécution, données stockées, requêtes, transferts et capacité réservée sont des unités possibles. Une instance active mais inutilisée peut rester facturée, et une notification de budget peut alerter votre équipe sans arrêter les ressources.

Les exigences d'infrastructure cloud à vérifier

Un fournisseur doit disposer de ressources suffisantes, d'une interface de gestion, de contrôles d'accès, d'une isolation adaptée et de règles d'exploitation documentées. L'acheteur doit pouvoir vérifier les points suivants :

• Provisionnement et limites : configurations prises en charge, quotas, allocation de capacité, automatisation, délais ou conditions de création des ressources.
• Persistance et reprise : cycle de vie du stockage, responsabilité des sauvegardes, procédures de restauration, objectifs de reprise et traitement des pannes.
• Accès et responsabilités : rôles, identifiants, traces d'audit disponibles, obligations du client et escalade auprès du support.
• Localisation et connectivité : placement des applications, services connectés, parcours des données, protocoles nécessaires et contraintes réseau.
• Mesure et coût : visibilité sur l'utilisation, unités de facturation, frais minimums ou engagements, services optionnels et comportement du nettoyage.
• Sortie : exportation des données, configurations portables, fermeture du compte, procédures de suppression et dépendances à remplacer.

Les preuves nécessaires dépendent de l'application. Un environnement de développement jetable et une base utilisée par des clients n'ont pas les mêmes besoins de reprise. Précisez la perte de données acceptable et le délai de rétablissement du service, puis testez si l'architecture proposée respecte ces objectifs.

Pour les données sensibles ou les contraintes de localisation, cartographiez les données principales, les réplicas, les sauvegardes, les journaux et les services connectés. Notre guide sur les lieux de stockage du cloud explique pourquoi un sélecteur de région ne répond qu'à une partie de la question.

Architectures publiques, privées, hybrides, distribuées et en périphérie

L'infrastructure de cloud public est proposée à un large ensemble de clients. « Public » décrit l'accès au service, pas l'autorisation de lire les données d'un autre client. Certaines offres de cloud public comprennent des options de matériel dédié.

L'infrastructure de cloud privé est réservée à une organisation et peut être exploitée sur site ou par une autre organisation. Elle doit toujours présenter les caractéristiques du cloud ; un serveur statique accessible de façon privée ne suffit pas à constituer un cloud privé.

Le cloud hybride relie des environnements cloud distincts. Les équipes emploient aussi « infrastructure hybride » dans un sens plus large pour associer cloud et systèmes classiques sur site. Précisez l'organisation retenue, puis attribuez les responsabilités pour les identités, le réseau, les transferts et l'exploitation de l'ensemble.

L'infrastructure cloud distribuée répartit des composants de service ou de la capacité entre plusieurs lieux sous une gestion cloud coordonnée. L'infrastructure en périphérie prend en charge l'edge computing en rapprochant certains traitements des utilisateurs, des appareils ou des sources de données. Ces descriptions peuvent se recouper, mais elles répondent à des questions différentes de placement et d'exploitation.

Aucune de ces étiquettes ne démontre à elle seule la sécurité, la souveraineté, la durabilité environnementale ou la résilience. Un déploiement distribué a toujours besoin d'un modèle de panne et d'une stratégie de reprise. Notre guide des modèles de systèmes distribués présente ces choix d'architecture plus en détail.

Avantages, compromis et maîtrise des coûts

L'infrastructure cloud peut donner accès à une capacité temporaire et à du matériel spécialisé sans acheter le système physique complet. Le libre-service et l'automatisation peuvent raccourcir la mise en place par rapport à un processus d'achat. Libérer les ressources après une tâche peut réduire leur durée de facturation.

Ces avantages dépendent de la capacité disponible, de la conception de l'application et du nettoyage effectif des ressources. L'élasticité nécessite une plateforme adaptée et une application capable d'utiliser une capacité variable. Une base de taille fixe ou un traitement dépendant strictement d'un périphérique ne passe pas forcément à l'échelle parce que d'autres instances sont disponibles.

Les compromis incluent la dépendance au fournisseur, les contraintes réseau, les factures variables, le travail de migration et une maîtrise moins directe du matériel. Les équipes doivent aussi savoir configurer les accès, l'automatisation, la supervision et la reprise dans leurs environnements cloud. La gestion de l'infrastructure physique par le fournisseur réduit certaines tâches tout en en laissant d'autres au client.

Comparez le coût complet de l'application à une solution détenue ou hébergée. Un système constamment occupé peut produire un résultat différent d'un traitement par lots occasionnel. Intégrez le renouvellement matériel et l'exploitation pour la solution détenue ; pour le cloud, incluez les ressources inactives, le stockage, les transferts, le support, les engagements et le travail technique.

Exemple : l'infrastructure d'un traitement par lots

Prenons le cas hypothétique d'une équipe qui traite un jeu de données et enregistre des résultats. Elle a besoin d'une instance CPU ou GPU, d'un espace de travail, d'une destination persistante pour les sorties, d'un accès réseau et d'identifiants. L'application peut aussi nécessiter une image compatible, des bibliothèques d'exécution et de la supervision.

L'équipe vérifie d'abord que les données et le calcul requis peuvent être placés correctement. Elle exécute un petit échantillon représentatif, mesure les durées utiles de traitement et de transfert, et relève le coût total des ressources. Elle répète ensuite le traitement à partir de la configuration enregistrée pour vérifier sa reproductibilité.

Avant de dépendre de cette architecture, l'équipe interrompt un essai et vérifie la reprise depuis un point de contrôle ou le redémarrage. À la fin, elle confirme que les résultats sont lisibles depuis leur destination persistante avant de libérer le calcul. Elle recherche les volumes, instantanés et autres ressources facturables conservés.

Ce test évalue l'infrastructure comme un système opérationnel. Une spécification de processeur ou un tarif horaire ne montre pas, à lui seul, si la tâche aboutit de façon fiable, si les résultats survivent ou combien coûte l'exécution complète.

Comment évaluer un service d'infrastructure cloud

1. Définissez le résultat attendu. Consignez l'application, la variation de la demande, les performances nécessaires, le délai de reprise acceptable et les contraintes de données.
2. Choisissez le périmètre de gestion. Déterminez si vous avez besoin d'une VM, de conteneurs, d'un serveur physique ou d'un service géré, et nommez les tâches assumées par votre équipe.
3. Validez la configuration complète. Vérifiez ensemble le calcul, la mémoire, le stockage, les parcours réseau, la localisation, les accès, les quotas et la capacité réelle.
4. Menez un essai représentatif. Mesurez le débit utile, la latence, les pannes, l'effort de préparation, la reprise et le coût par tâche terminée.
5. Examinez les conditions d'exploitation. Lisez les engagements de service, exclusions, accords de support, règles de persistance, modalités de facturation et responsabilités associées.
6. Testez le nettoyage et la sortie. Exportez les données et la configuration nécessaires, vérifiez la destination, supprimez les ressources de test jetables et confirmez les frais restants.

Gardez une comparaison assez restreinte pour tester correctement chaque candidat. Utilisez les mêmes données d'entrée et hypothèses d'exploitation, puis consignez les différences qui empêchent une comparaison équitable. Notre liste de cinq questions à poser au fournisseur fournit un point de départ utile.

Les services d'infrastructure cloud de Hivenet

La présentation de l'architecture de Hivenet distingue l'infrastructure physique, les logiciels de plateforme et les services propres à chaque produit. Le périmètre de gestion adapté dépend du produit.

Compute with Hivenet propose des instances GPU et CPU sous forme de VM ou de conteneurs, avec modèles, API, rôles d'équipe et facturation partagée. Compute utilise des crédits prépayés et une facturation à la seconde pendant l'exécution des instances. Les clients exploitent leur pile applicative et gèrent les données et le cycle de vie de leurs traitements.

L'Inference API fournit un parcours distinct de point d'accès géré, tandis que le stockage objet compatible S3 prend en charge les usages de données par API. Une instance, un point d'accès et un bucket exposent des contrôles et des unités de facturation différents. Évaluez le service précis, sa capacité actuelle et son cycle de vie documenté plutôt que de supposer un comportement commun à tous les produits Hivenet.

Questions fréquentes

L'infrastructure cloud se limite-t-elle au matériel ?

Elle comprend les équipements physiques et les logiciels qui les transforment en services configurables. Identités, ordonnancement, provisionnement, réseau, gestion du stockage et mesure de l'utilisation contribuent tous à la façon dont le client utilise ces équipements.

Chaque ressource cloud utilise-t-elle une machine virtuelle ?

Non. Les services peuvent exposer des conteneurs, des serveurs physiques ou des environnements d'exécution gérés. Vérifiez l'environnement et les contrôles disponibles dans le service acheté.

L'arrêt d'une instance supprime-t-il tous les frais ?

Vérifiez les règles de cycle de vie et de facturation du fournisseur. Le stockage, les instantanés, les adresses, les passerelles ou les engagements peuvent rester facturés indépendamment du calcul. Arrêter, supprimer et fermer un compte sont des actions différentes.

Les sauvegardes sont-elles incluses ?

Uniquement lorsque le service et la configuration retenus les prévoient. Confirmez ce qui est sauvegardé, à quelle fréquence, pour combien de temps, qui peut le supprimer et comment fonctionne la restauration. Testez la reprise avant de compter sur elle.

Quel est le critère d'achat le plus utile ?

La capacité de la configuration complète à satisfaire les exigences de votre application à un coût d'exploitation acceptable. Commencez par les besoins obligatoires, puis évaluez les performances, la reprise et le travail de votre équipe au cours d'un essai.