Les types de cloud computing : modèles de services et de déploiement

Les types de cloud computing relèvent de deux grandes classifications. Les modèles de services, comme l'IaaS, le PaaS et le SaaS, décrivent ce que fournit un prestataire et les couches techniques qu'il gère. Les modèles de déploiement, comme les clouds public, privé, communautaire et hybride, décrivent qui peut utiliser l'infrastructure et comment elle est organisée.

Ces classifications se combinent. Une machine virtuelle peut être un service IaaS dans un cloud public ; une plateforme de développement peut fournir du PaaS dans un cloud privé. Le multicloud, le serverless et l'edge computing apportent d'autres distinctions, mais répondent à d'autres questions. Les comprendre permet de comparer le contrôle, le travail d'exploitation et la dépendance au fournisseur sans traiter tous ces termes comme des options concurrentes.

Pourquoi les listes de types de cloud diffèrent

La définition du cloud computing du NIST, publiée en 2011, distingue trois modèles de services et quatre modèles de déploiement. Elle reste une base utile. Elle définit aussi cinq caractéristiques essentielles du cloud : le libre-service à la demande, l'accès réseau étendu, la mutualisation des ressources, l'élasticité rapide et la mesure de l'utilisation.

Le vocabulaire commercial s'est enrichi depuis. Par exemple, la présentation des types de cloud par Google Cloud aborde le serverless aux côtés de l'IaaS, du PaaS et du SaaS. D'autres listes mettent en avant le multicloud ou omettent le cloud communautaire. Une liste peut être utile sans reprendre exactement le NIST, à condition d'expliquer ce qu'elle classe.

Commencez par deux questions : quelle capacité recevez-vous, et comment l'environnement cloud est-il organisé ? Déterminez ensuite si les autres termes décrivent le choix des fournisseurs, l'exécution du code ou l'emplacement du traitement. Cela évite des comparaisons comme « SaaS ou cloud hybride », qui mélangent les catégories.

Les modèles de services cloud : ce que gère le fournisseur

Une application cloud repose sur du matériel, un réseau, un système d'exploitation, un environnement d'exécution, du code applicatif et des données. Les modèles de services placent la frontière entre fournisseur et client à différents niveaux de cet ensemble. La répartition exacte dépend du produit et du contrat.

Infrastructure as a Service : IaaS

L'IaaS fournit des ressources que les clients configurent pour leurs traitements : machines virtuelles, stockage et réseau, notamment. Le fournisseur exploite les installations, le matériel et la virtualisation sous-jacente. Dans un service de machines virtuelles classique, le client gère le système d'exploitation invité, les logiciels installés, les applications, les données et les paramètres d'accès.

Ce contrôle est utile lorsqu'un traitement exige un système d'exploitation particulier, un logiciel spécialisé ou une configuration qu'une plateforme managée ne prend pas en charge. Cela peut concerner des environnements de développement, des applications existantes, le calcul scientifique ou l'apprentissage automatique.

Le travail ne s'arrête pas au démarrage de l'instance. Il faut appliquer les correctifs du système invité, protéger les identifiants, surveiller l'utilisation, gérer les sauvegardes et tester la restauration. Le fournisseur peut proposer des services de gestion supplémentaires : l'IaaS ne signifie donc pas que tout l'environnement est sans gestion. Vérifiez les tâches incluses et celles qui reviennent à votre équipe.

Platform as a Service : PaaS

Le PaaS fournit un environnement pour développer et exécuter des applications. Le fournisseur gère l'infrastructure, les systèmes d'exploitation et les environnements d'exécution ou composants intermédiaires pris en charge. Les développeurs se concentrent sur le code, les paramètres applicatifs, les données et les accès.

Une équipe qui crée une application web ou une API peut choisir le PaaS pour éviter de maintenir des machines virtuelles. Certains services de bases de données managées relèvent aussi de ce modèle. Le seul intitulé ne précise toutefois pas si le réglage des performances, les mises à jour, l'adaptation de la capacité ou la restauration sont automatiques, configurables ou facturés séparément.

La contrepartie est un contrôle réduit sur les couches gérées. Les langages, versions, méthodes de déploiement et intégrations disponibles peuvent orienter la conception de l'application. Vérifiez les conséquences du retrait d'une version et le travail nécessaire pour changer de plateforme. Pour Kubernetes managé, examinez la répartition réelle : la gestion du plan de contrôle n'implique pas forcément celle des nœuds de travail ni de l'exploitation des applications.

Software as a Service : SaaS

Le SaaS fournit une application exploitée par son prestataire. Les clients l'utilisent dans un navigateur, une application cliente ou via une API, sans installer ni maintenir les couches techniques sous-jacentes. La messagerie, la collaboration documentaire, la gestion de la relation client, la comptabilité et la gestion de projet sont des usages courants.

Le client conserve des décisions importantes. Les administrateurs gèrent les comptes, autorisations, règles de partage, intégrations et informations saisies dans le service. Les appareils et les identifiants doivent être protégés. Les personnes chargées des achats doivent comprendre les conditions de conservation, de suppression, d'export et du contrat.

Le SaaS laisse généralement le moins de contrôle direct sur la technologie de l'application et son calendrier de mise à jour. Il peut réduire le travail d'exploitation si le produit répond au besoin, mais une fonction absente peut imposer de modifier un processus métier ou de choisir une autre application.

La place du serverless et du Function as a Service

Les services serverless confient au fournisseur le provisionnement des serveurs et une grande partie de la gestion de la capacité. Les serveurs existent toujours. Le client utilise un environnement d'exécution ou un service managé sans exploiter en continu les machines sous-jacentes.

Le Function as a Service, ou FaaS, est une approche serverless : du code s'exécute en réponse à une requête ou à un événement. Une fonction pourrait, par exemple, valider un fichier qui vient d'être envoyé puis transmettre ses détails à une file de messages. Les fonctions AWS Lambda en sont un exemple. Le serverless comprend aussi d'autres services managés d'exécution et de données.

Pour une API événementielle, une automatisation ou un traitement intermittent, cette approche peut retirer une part utile du travail d'infrastructure. Elle ne supprime pas la conception applicative, la surveillance, la gestion des accès ni le traitement des échecs. Examinez le démarrage, les limites d'exécution, la concurrence, le réseau et les tests locaux. La facturation et l'adaptation de la capacité varient : le terme serverless ne garantit ni une réduction de la capacité à zéro ni une facturation uniquement par requête.

IaaS, PaaS et SaaS : comparaison

Ce tableau présente des répartitions courantes. Le serverless y figure comme approche d'exécution supplémentaire, pas comme quatrième modèle de services du NIST. Le contrôle et le travail d'exploitation concernent le client.

Modèle	Service reçu	Gestion du fournisseur	Gestion du client	Contrôle	Travail d'exploitation	Usage courant
IaaS	Calcul, stockage et réseau configurables	Infrastructure physique et virtualisation	Système invité, logiciels, traitements, données et accès	Élevé sur l'environnement invité	Système et traitements	Logiciels ou calculs spécialisés
PaaS	Plateforme applicative managée	Infrastructure, système et composants pris en charge	Code, paramètres applicatifs, données et accès	Dans les choix proposés par la plateforme	Applications	Applications web et API
SaaS	Application prête à l'emploi	Application et couches techniques associées	Utilisateurs, paramètres, données, appareils et intégrations	Configuration du produit	Administration et intégration	Applications métier standard
Fonctions serverless	Environnement d'exécution de fonctions	Serveurs et infrastructure d'exécution	Code, événements, autorisations, données et surveillance	Dans les limites d'exécution	Fonctions et enchaînement des traitements	Événements et automatisation

Le nom du modèle est un point de départ pour évaluer un service. Comparez la documentation des responsabilités aux réglages et outils dont votre équipe dispose réellement.

Les modèles de déploiement : qui utilise l'environnement

Les modèles de déploiement décrivent l'accès à l'infrastructure cloud et la relation entre les environnements. Ils ne précisent pas si le client reçoit des machines virtuelles, une plateforme de développement ou une application prête à l'emploi.

Cloud public

Un cloud public met son infrastructure à la disposition du public. Un fournisseur l'exploite et propose ses services à des clients. « Public » décrit la disponibilité du service, pas une autorisation de consulter les données des clients.

Les clients peuvent obtenir des ressources sans posséder le matériel sous-jacent. Les services peuvent partager une infrastructure physique, tandis que les fournisseurs peuvent aussi proposer de la capacité dédiée ou des options d'isolation. Le cloud public ne signifie ni que tous les traitements partagent un même serveur physique ni que tous les services sont nécessairement accessibles par l'internet public.

Vérifiez les régions, les contrôles d'accès, la connectivité, les prix, les quotas et l'assistance. Posséder moins de matériel peut être utile, mais le coût total dépend de l'utilisation, des transferts, des services managés et du travail d'exploitation. La dépendance au prestataire et les conditions de sortie méritent aussi un examen.

Cloud privé

Un cloud privé est réservé à une organisation, qui peut le mettre au service de plusieurs équipes internes. Il peut fonctionner dans ses locaux ou ailleurs. L'organisation, un tiers, ou les deux peuvent le gérer.

Le cloud privé peut permettre des configurations propres à l'organisation et davantage de contrôle sur un environnement. Cela peut compter pour des besoins inhabituels de matériel, d'intégration ou de gouvernance. Il implique aussi de planifier la capacité et d'attribuer les responsabilités d'exploitation, assurées en interne ou achetées à un prestataire.

La virtualisation d'un ensemble de serveurs ne suffit pas à créer un cloud privé. L'environnement doit présenter les caractéristiques du cloud, comme le libre-service, la mutualisation, l'élasticité et la mesure de l'utilisation. L'usage exclusif ne rend pas non plus un environnement intrinsèquement plus sûr : l'architecture, la configuration, les accès, la maintenance et les compétences déterminent le résultat.

Cloud communautaire

Un cloud communautaire sert un groupe défini d'organisations partageant des préoccupations, comme une mission de recherche, une politique de sécurité ou des exigences de gouvernance. Les membres, un tiers ou les deux peuvent l'exploiter, dans leurs locaux ou ailleurs.

Des établissements de recherche pourraient, par exemple, créer un cloud commun avec des règles d'accès et de traitement des données partagées. L'élément déterminant est l'accord de la communauté sur ses exigences. Plusieurs clients sans lien entre eux chez un même fournisseur public ne constituent pas automatiquement un cloud communautaire.

Un financement et des politiques communs peuvent être utiles, mais les participants doivent clarifier les décisions et les responsabilités. Les choix de services, les désaccords sur le financement, les changements de membres et les priorités divergentes peuvent limiter l'environnement. Le cloud communautaire reste l'un des quatre modèles du NIST, même lorsqu'une comparaison commerciale l'omet.

Cloud hybride

Selon le NIST, le cloud hybride réunit au moins deux infrastructures cloud distinctes, privées, communautaires ou publiques par exemple, reliées par des technologies permettant la portabilité des données et des applications. Chaque cloud conserve son identité.

L'usage du terme dans le secteur est souvent plus large et peut inclure des systèmes classiques sur site reliés à des services de cloud public. Précisez le sens retenu dans une architecture ou un contrat. Utiliser un serveur local et une application en ligne sans lien entre eux ne décrit pas la manière dont ces environnements travaillent ensemble.

Une architecture hybride pourrait conserver un jeu de données dans un environnement privé tout en confiant des traitements approuvés à un service public. Elle peut aussi accompagner une migration progressive ou un plan de reprise. Cela exige des contrôles d'identité, des connexions réseau, des modalités de transfert, une surveillance et des procédures testées. L'étiquette hybride ne rend pas une application portable et ne crée pas de capacité disponible à la demande.

Multicloud et cloud hybride

Le multicloud consiste à utiliser les services de plusieurs fournisseurs cloud. Il décrit le choix des prestataires, tandis que le cloud hybride décrit une combinaison d'environnements. Il ne figure pas parmi les quatre modèles de déploiement initiaux du NIST, même si certaines présentations actuelles le classent avec eux.

Une organisation qui utilise un SaaS chez un fournisseur et des machines virtuelles de cloud public chez un autre est en multicloud. Un cloud privé relié à un cloud public peut être hybride sans faire appel à plusieurs fournisseurs externes. Un environnement privé relié à des services publics de deux prestataires peut être à la fois hybride et multicloud.

Les raisons de choisir plusieurs fournisseurs comprennent la disponibilité dans certaines régions, des capacités différentes, des exigences d'achat ou des systèmes hérités d'une acquisition. Les coûts comprennent des contrats, contrôles d'identité, factures, compétences et outils de surveillance supplémentaires.

Le multicloud ne garantit pas la résilience. Si une application essentielle fonctionne uniquement chez le fournisseur A, un service sans rapport chez B ne la maintient pas disponible lorsque A tombe en panne. La résilience exige une architecture, une synchronisation des données, de la capacité disponible et des procédures de reprise testées pour cette application. La portabilité dépend, elle aussi, des formats, des API, des dépendances et de l'effort de migration.

Comparer les modèles de déploiement

La dernière ligne décrit une stratégie qui peut se combiner aux modèles précédents. Le contrôle et le travail dépendent des services et des accords d'exploitation retenus.

Modèle ou stratégie	Exploitant	Utilisateurs	Organisation	Contrôle du client	Travail d'exploitation	Motif courant	Limite principale
Cloud public	Fournisseur	Clients issus du public	Infrastructure cloud exploitée par le fournisseur	Dans les limites du service	Selon le modèle de services	Obtenir des ressources sans posséder le matériel	Dépendance au prestataire et au service
Cloud privé	Organisation, tiers, ou les deux	Une organisation	Cloud exclusif, sur site ou hors site	Peut inclure les choix d'infrastructure	Capacité et exploitation à attribuer	Besoin spécifique de contrôle ou d'intégration	Compétences et capacité nécessaires
Cloud communautaire	Membres, tiers, ou les deux	Communauté définie	Cloud partagé pour des exigences communes	Partagé par la gouvernance	Responsabilités convenues ensemble	Mission ou politiques communes	Coordination entre organisations
Cloud hybride	Exploitants des environnements reliés	Utilisateurs autorisés des environnements	Clouds distincts reliés ; certains usages du terme incluent d'autres systèmes locaux	Selon le composant	Intégration et exploitation entre environnements	Relier certains traitements et données	Complexité du réseau et de l'intégration
Stratégie multicloud	Plusieurs fournisseurs et l'équipe cliente	Utilisateurs autorisés de l'organisation	Services de plusieurs prestataires	Selon le service et le fournisseur	Plusieurs outils, contrats et contrôles	Capacités ou conditions d'achat différentes	Davantage de dépendances à gérer

Cloud distribué et edge computing

Le cloud distribué concerne les lieux d'exécution des services et leur coordination. La définition d'IBM décrit des services de cloud public répartis sur plusieurs sites physiques sous gestion centralisée. D'autres prestataires peuvent employer le terme différemment. Vérifiez le fonctionnement concret derrière l'intitulé.

L'edge computing place le traitement près des utilisateurs, appareils ou sources de données. Il décrit un emplacement plutôt que la propriété ou la frontière d'un service. Une installation en périphérie peut appartenir à un environnement privé, public, hybride ou distribué.

Distribué ne signifie pas nécessairement décentralisé. Une infrastructure peut occuper plusieurs sites tout en étant contrôlée par une seule organisation. Aucun de ces termes ne remplace l'IaaS, le PaaS, le SaaS ou les modèles de déploiement.

Comment les classifications se combinent

Voici quelques exemples hypothétiques :

• IaaS public : une équipe d'ingénierie loue des machines virtuelles et installe son logiciel de simulation.
• PaaS privé : une équipe interne exploite une plateforme applicative sur le cloud privé de l'organisation pour ses développeurs.
• SaaS sur infrastructure publique : une entreprise utilise une application comptable dont le prestataire s'appuie sur un cloud public. L'entreprise reçoit du SaaS ; le prestataire peut consommer de l'IaaS ou du PaaS en dessous.
• Services hybrides : une organisation relie une infrastructure de cloud privé à une plateforme applicative publique managée, avec des règles explicites de circulation des données.
• Services multicloud : une entreprise achète un logiciel collaboratif, une base de données managée et des machines virtuelles chez différents fournisseurs. Chaque service a sa propre répartition des tâches.

Ce sont des organisations possibles, pas la promesse que chaque produit prend en charge toutes les combinaisons. Vérifiez le lieu de déploiement, les intégrations et les licences des services concernés.

Comme exemple concret d'infrastructure, Compute with Hivenet fournit des instances dont les clients contrôlent l'environnement et les logiciels. Le stockage objet compatible S3 de Hivenet constitue un service de stockage distinct. Les clients gèrent toujours l'utilisation des données et des identifiants d'accès par leurs applications. Les responsabilités propres aux produits comptent davantage que l'attribution d'un même modèle à tous les services de stockage.

La responsabilité partagée reste à examiner

Le passage de l'IaaS au PaaS puis au SaaS confie généralement davantage de couches techniques au fournisseur. La matrice de responsabilité partagée de Microsoft illustre ce déplacement, tandis que les clients conservent des responsabilités importantes pour les données, identités, accès, paramètres et appareils.

Pour chaque service, précisez qui réalise les mises à jour, contrôle les accès, surveille les incidents, configure les sauvegardes et teste la restauration. Examinez aussi la conservation, la suppression et les exports utilisables. Le guide de sécurité du cloud présente les contrôles à étudier.

Un nom de modèle technique ne détermine pas les obligations juridiques et ne prouve pas la conformité. Les données, usages, juridictions, contrats et contrôles mis en place doivent être examinés. Les services managés réduisent certaines tâches d'exploitation ; l'organisation doit toujours les choisir, les configurer et les superviser.

Quel type de cloud computing choisir ?

Partez d'un traitement et de ses exigences. Choisissez d'abord la capacité nécessaire, puis le déploiement et l'exploitation qui peuvent la fournir. Une entreprise peut employer plusieurs modèles selon ses besoins.

1. Définissez ce que vous devez recevoir. Pour une application métier prête à l'emploi, examinez le SaaS. Le développement d'une application peut se prêter au PaaS. Le besoin de configurer le système ou des logiciels spécialisés oriente vers l'IaaS.
2. Précisez le contrôle nécessaire. Notez les versions, accès matériels, réseaux, fenêtres de mise à jour et intégrations exigés. Distinguez les besoins réels des préférences qui ajoutent du travail sans améliorer le traitement.
3. Attribuez le travail d'exploitation. Assurez-vous qu'une personne peut assumer chaque responsabilité du client, y compris pendant un incident. Si votre équipe ne peut pas maintenir un système de façon sûre, la souplesse d'une machine virtuelle peut être un mauvais compromis.
4. Précisez les exigences de données et de localisation. Incluez le traitement, le stockage principal, les sauvegardes, les journaux, les accès administratifs et les sous-traitants. Le guide sur la localisation des données cloud explique pourquoi un nom de région ne suffit pas.
5. Testez la connectivité et les performances. Vérifiez la latence, la bande passante, le fonctionnement hors ligne, les volumes transférés et les dépendances entre services. Rapprocher le calcul d'un appareil n'aide que si l'application peut exploiter cette organisation.
6. Comparez un coût d'exploitation réaliste. Incluez l'utilisation prévue, la capacité inactive, les transferts, l'assistance, les licences, le temps de travail et la migration. Aucun modèle de déploiement n'est automatiquement le moins cher.
7. Préparez les changements et la sortie. Testez un export ou une migration. Vérifiez les formats utilisables, les dépendances aux API, la portabilité des configurations, les modifications contractuelles et le travail à prévoir si une fonction disparaît.

Terminez par une répartition écrite des responsabilités, une estimation de coût liée au traitement et un test limité qui couvre les pannes et la reprise. Ces résultats seront plus utiles que le seul nom d'un modèle cloud.

Questions fréquentes

Quels sont les principaux types de cloud computing ?

Précisez d'abord la classification. Le NIST distingue trois modèles de services, IaaS, PaaS et SaaS, et quatre modèles de déploiement, public, privé, communautaire et hybride. Les premiers décrivent la capacité fournie et la répartition de sa gestion ; les seconds décrivent l'organisation et l'utilisation de l'infrastructure.

Quelle est la différence entre IaaS, PaaS et SaaS ?

L'IaaS fournit une infrastructure configurable. Le PaaS propose un environnement managé pour créer et exécuter des applications. Le SaaS fournit une application exploitée par son prestataire. En allant de l'IaaS au SaaS, le fournisseur gère généralement davantage de couches techniques, tandis que les clients restent responsables de leur utilisation du service.

Le serverless est-il un quatrième modèle de services cloud ?

Certaines classifications actuelles le présentent ainsi, mais il ne fait pas partie des trois modèles initiaux du NIST. Il décrit des approches qui confient au prestataire le provisionnement des serveurs et la gestion de l'infrastructure d'exécution. Le FaaS est une forme de serverless ; les termes ne sont pas exactement synonymes.

Le multicloud est-il identique au cloud hybride ?

Non. Le multicloud utilise plusieurs fournisseurs. Le cloud hybride relie des environnements différents. Une architecture peut être les deux, et aucun de ces noms ne garantit à lui seul la migration ou la reprise des traitements entre les environnements.

Une organisation peut-elle utiliser IaaS, PaaS et SaaS ensemble ?

Oui. Elle pourrait choisir du SaaS pour la comptabilité, du PaaS pour une application client et de l'IaaS pour des calculs spécialisés. Chaque service demande un examen de ses responsabilités et dépendances.

Le cloud distribué est-il une alternative au cloud public ou privé ?

Il décrit une organisation technique répartie entre plusieurs lieux. Pour comprendre un service distribué, identifiez aussi les utilisateurs autorisés, l'acteur qui le contrôle, la capacité fournie et les tâches qui reviennent au client.