Modèles de services cloud : IaaS, PaaS, SaaS et serverless

Les services de cloud computing se distinguent par ce que le fournisseur livre et les parties du système que votre équipe continue d'exploiter. L'infrastructure en tant que service (IaaS) fournit des ressources informatiques. La plateforme en tant que service (PaaS) fournit un environnement pour déployer des applications. Le logiciel en tant que service (SaaS) fournit une application prête à l'emploi. Les services serverless donnent accès à des capacités gérées sans approvisionner de serveurs individuels.

Ce choix influe sur le travail quotidien : qui installe les mises à jour, intervient en cas de panne applicative, contrôle les accès, restaure les données et vérifie la facture. Partez du contrôle nécessaire à votre traitement, puis déterminez quelles tâches opérationnelles un fournisseur peut prendre en charge.

Trois modèles formels de services cloud, plus le serverless

La définition du cloud computing du NIST précise trois modèles de service : IaaS, PaaS et SaaS. Les comparaisons actuelles ajoutent souvent le serverless comme quatrième catégorie pratique. Il est utile de le présenter à côté des autres modèles, mais il ne constitue pas un quatrième modèle dans cette définition du NIST.

Le serverless recoupe les services de plateforme et dépasse le cadre des fonctions. La fonction en tant que service (FaaS) correspond à l'exécution de code déclenchée par des événements au sein de cette catégorie plus large. Une base de données serverless n'est pas une fonction, et une plateforme applicative gérée peut proposer des options d'exécution serverless.

Ces catégories aident à comprendre le périmètre d'un service. Elles ne prouvent pas qu'un produit est moins cher, plus sûr ou plus capable de monter en charge qu'un autre. Ce sont ses contrôles, ses limites et ses conditions d'exploitation qui déterminent s'il convient au travail prévu.

Ce que le fournisseur gère et ce qui vous revient

Une pile technique simplifiée comprend les centres de données, le matériel physique, les réseaux, le stockage de données, l'abstraction des ressources, les systèmes d'exploitation, les environnements d'exécution, les applications et les données. Les utilisateurs, les autorisations et les appareils connectés interagissent avec plusieurs de ces couches.

Dans un service de cloud public, le fournisseur exploite l'infrastructure physique comprise dans le service. Passer de l'infrastructure aux plateformes gérées puis aux logiciels prêts à l'emploi transfère généralement davantage d'exploitation logicielle au fournisseur. Cela réduit aussi les choix techniques de bas niveau accessibles au client.

La répartition ne se résume pas à une ligne nette entre toutes les responsabilités. Un fournisseur peut entretenir le système de stockage pendant que vous décidez qui peut lire un objet. Il peut exploiter un moteur de base de données pendant que vous concevez les requêtes et fixez la durée de conservation des enregistrements.

Les recommandations de Microsoft sur la responsabilité partagée distinguent les couches exploitées par le fournisseur des responsabilités du client en IaaS, PaaS et SaaS. Le traitement des données, les accès utilisateur, la configuration du service et la sécurité des appareils utilisés pour se connecter nécessitent toujours des responsables. Un service plus largement géré ne supprime pas ces décisions.

IaaS : une infrastructure avec davantage de contrôle client

L'infrastructure en tant que service fournit des ressources comme des machines virtuelles, des volumes de stockage et des réseaux virtuels. Ces services apportent la puissance de calcul et les connexions sur lesquelles vous construisez une application. Vous pouvez construire un environnement logiciel sur ces ressources sans acheter ni entretenir vous-même le matériel physique.

Sur une machine virtuelle classique autogérée, le fournisseur exploite l'hôte et la plateforme de virtualisation. Votre équipe choisit et entretient le système d'exploitation invité, installe les dépendances, déploie les applications, configure le réseau du traitement et protège les identifiants et les données. La supervision de l'application et la préparation de sa reprise font aussi partie de ce travail.

Quand ce modèle convient : une application nécessite un accès système, un environnement précis, des paquets ou pilotes personnalisés, ou un serveur de base de données ou de modèles autogéré. Les traitements GPU peuvent également nécessiter un contrôle direct des bibliothèques et des dépendances. Le guide Hivenet sur les machines virtuelles GPU examine ce cas d'usage.

Points à vérifier : privilèges d'accès, images prises en charge, persistance du stockage, options réseau, disponibilité du matériel et conséquences de l'arrêt ou de la suppression d'une instance. L'IaaS peut donner accès à des capacités partagées ou dédiées. Le nom du modèle ne garantit ni du matériel physique dédié ni un niveau d'isolation particulier.

Le compromis : vous gardez davantage de contrôle sur la pile logicielle et davantage de travail pour la maintenir. Déplacer une application compatible entre machines virtuelles peut être possible, mais le réseau, les services d'identité, les images et les données demandent toujours un travail de migration. La portabilité doit être testée.

PaaS : déployer des applications sur une plateforme gérée

La plateforme en tant que service fournit un environnement pour créer, déployer et exécuter des applications. Le fournisseur gère une plus grande partie de l'infrastructure sous-jacente, du système d'exploitation, de l'environnement d'exécution, des composants intermédiaires et des outils de déploiement. Votre équipe fournit le code applicatif ou un paquet pris en charge, puis configure son exécution.

Microsoft Azure App Service est, par exemple, une plateforme gérée pour les applications web, les services backend mobiles et les API REST. L'environnement d'exécution, le système d'exploitation, la méthode de déploiement et le plan de service déterminent les possibilités offertes à une application donnée.

Le client doit toujours entretenir son code et les dépendances qu'il fournit, configurer les accès, protéger les secrets, gérer les données et superviser le comportement applicatif. La gestion de l'environnement par le fournisseur ne prouve pas que votre code est sûr ni que ses requêtes de base de données seront performantes.

Quand ce modèle convient : l'équipe souhaite déployer une application et la plateforme prend en charge son environnement d'exécution, ses dépendances, son réseau et son processus de livraison. Administrer les serveurs sous-jacents ajouterait du travail sans apporter un contrôle utile à l'application.

Points à vérifier : versions de langage disponibles, politique de mise à jour de l'environnement d'exécution, stockage persistant, déploiement et retour arrière, mise à l'échelle, connectivité privée, journaux et possibilités d'export. Une plateforme peut ajuster la capacité selon des règles configurées sans permettre à chaque composant applicatif d'évoluer indépendamment.

Le compromis : moins d'administration serveur, mais davantage de dépendance aux fonctions prises en charge par la plateforme. Si l'application exige un composant système indisponible, une modification du noyau ou un accès libre à l'hôte, ce périmètre de gestion peut ne pas convenir.

SaaS : utiliser une application exploitée par le fournisseur

Le logiciel en tant que service fournit une application prête à l'emploi par un navigateur, une application cliente ou une API. La messagerie web, les documents partagés, la comptabilité, la gestion de projets, la gestion de la relation client et les outils de support client en sont des exemples courants.

Le fournisseur exploite l'application et sa plateforme, y compris les mises à jour prévues par le service. Votre organisation gère son utilisation : comptes, autorisations, partage, données, intégrations, configuration, achats et usages acceptables. Certains produits SaaS nécessitent aussi un logiciel client local, qui doit être entretenu sur les appareils concernés.

Quand ce modèle convient : un produit existant répond au besoin et développer ou exploiter son remplacement apporterait peu de valeur. Une équipe cherchant un agenda partagé a généralement besoin d'une planification fiable et de contrôles d'accès, plutôt que de choisir le système d'exploitation du serveur.

Points à vérifier : rôles administrateur, suppression des utilisateurs, conservation des données, historique des versions, possibilités de récupération, formats d'export, autorisations des intégrations et fonctions incluses dans le plan choisi. Confirmez ce qu'il advient des données à la fermeture d'un compte ou à la fin d'un abonnement.

Le compromis : un accès rapide à une application existante, avec peu de contrôle sur ses fonctions, son infrastructure et son calendrier de mise à jour. Un abonnement prévisible ne garantit pas une facture totale stable si le nombre d'utilisateurs, le stockage, l'usage ou les options nécessaires changent.

Ne supposez pas que les données d'un SaaS sont automatiquement récupérables. Le service peut ne conserver que certaines versions ou exclure certaines données de la récupération. La distinction entre synchronisation et sauvegarde est particulièrement importante pour les applications de fichiers.

Serverless et FaaS : une exécution gérée avec des limites définies

L'informatique serverless permet d'utiliser une couche d'exécution ou de service gérée sans approvisionner ni administrer des instances de serveur individuelles. Le travail s'effectue toujours sur des serveurs physiques. L'approvisionnement et la mise à l'échelle passent par les contrôles et les limites du service.

La fonction en tant que service exécute des fonctions en réponse à des événements : requête HTTP, envoi de fichier, message ou horaire programmé. L'arrivée d'une image peut, par exemple, déclencher du code qui crée une miniature et enregistre le résultat.

Le client fournit le code, les dépendances, les autorisations, la configuration des événements et la logique applicative. Il doit aussi traiter les erreurs, superviser les résultats et comprendre les nouvelles tentatives. Des événements répétés peuvent produire un travail répété si l'application n'est pas conçue pour les gérer correctement.

L'entretien de l'environnement d'exécution varie selon le mode de livraison du code. La documentation des environnements d'exécution AWS Lambda précise que les clients restent responsables de la mise à jour du code de leurs fonctions et de leurs dépendances. Avec des images de conteneur, ils doivent reconstruire et redéployer les images pour intégrer les mises à jour pertinentes. Le cycle de vie des versions prises en charge demande également un suivi.

Quand ce modèle convient : traitement d'événements, petites tâches backend, automatisations programmées et charges irrégulières respectant les limites d'exécution et de ressources. D'autres services serverless peuvent aussi prendre en charge des applications de plus longue durée. Évaluez donc le produit précis, sans étendre les limites des fonctions à tout le serverless.

Points à vérifier : durée d'exécution, mémoire, concurrence, environnements disponibles, délai de démarrage, réseau, nouvelles tentatives, visibilité opérationnelle et stockage de l'état. Les démarrages à froid et les limites de concurrence peuvent affecter le temps de réponse. Augmenter la capacité d'une fonction n'augmente pas nécessairement celle de la base de données qu'elle appelle.

Le compromis : moins de gestion d'instances, avec une dépendance plus forte aux interfaces d'exécution et d'événements. La facturation peut inclure les requêtes et le temps d'exécution, mais « serverless » ne promet pas l'absence de coût au repos. Les tarifs de Lambda comprennent, par exemple, la concurrence provisionnée, qui facture la capacité configurée ainsi que l'exécution dans ce mode.

IaaS, PaaS, SaaS et serverless en un coup d'œil

• IaaS : vous obtenez une infrastructure. Le fournisseur exploite la plateforme physique ; vous exploitez généralement le système invité et la pile applicative. Ce modèle offre un large contrôle système pour les environnements personnalisés et les traitements autogérés.
• PaaS : vous obtenez une plateforme applicative. Le fournisseur exploite davantage l'environnement d'exécution et de déploiement ; vous gérez le code, les données, les paramètres et les accès. Il convient au développement dans les contraintes prises en charge.
• SaaS : vous obtenez un logiciel prêt à l'emploi. Le fournisseur exploite l'application ; vous gérez son utilisation, les utilisateurs, les données, le partage, les intégrations et la sortie du service. Il convient lorsqu'un produit existant répond au besoin.
• Serverless ou FaaS : vous obtenez des capacités ou une exécution gérées. Le fournisseur approvisionne les ressources d'exécution ; vous gérez le code ou les requêtes, les autorisations, les événements et le comportement applicatif. Le FaaS convient aux tâches déclenchées par événements, dans ses limites.

Cette comparaison présente des répartitions habituelles. Une architecture de cloud computing peut combiner plusieurs modèles. Une plateforme gérée peut également proposer un déploiement serverless : les catégories ne sont donc pas toujours exclusives.

Les modèles de service sont distincts des modèles de déploiement

Les modèles de service décrivent ce qui est fourni et qui l'exploite. Les modèles de déploiement décrivent à qui un environnement est destiné et comment les infrastructures cloud sont organisées.

Le NIST distingue les clouds public, privé, communautaire et hybride. Un cloud privé est réservé à une organisation ; il peut être exploité par celle-ci ou par un tiers, sur site ou ailleurs. Un cloud public propose des services accessibles à un public général, avec des accès client contrôlés. Le cloud communautaire sert un groupe défini ayant des exigences communes. Le cloud hybride relie des infrastructures cloud distinctes.

Un cloud privé peut fournir de l'IaaS ou du PaaS. Un cloud public peut proposer une infrastructure, des plateformes, des applications prêtes à l'emploi et des services serverless. Comparer « cloud public » et « SaaS » revient donc à comparer deux dimensions différentes. Aucun choix de déploiement ne garantit à lui seul la conformité, la sécurité ou un emplacement acceptable pour les données.

Où se situent les autres produits « en tant que service » ?

Bases de données, stockage, sauvegardes, conteneurs, postes de travail et IA sont souvent vendus « en tant que service ». Ces noms décrivent des capacités plus précises, qui peuvent recouper les modèles principaux. Ils ne constituent pas tous des modèles formels supplémentaires.

Une base de données gérée peut transférer l'entretien du moteur au fournisseur tout en laissant au client la conception des schémas, les requêtes, les autorisations et les paramètres de reprise. Un service de conteneurs peut gérer le plan de contrôle tout en laissant au client une part importante du travail sur les nœuds et les applications.

Les recommandations de sécurité Amazon EKS décrivent, par exemple, des responsabilités différentes selon les nœuds autogérés, les groupes de nœuds gérés et les options d'exécution plus largement prises en charge. L'expression « Kubernetes géré » ne suffit pas à indiquer qui applique les correctifs à chaque nœud ou entretient chaque dépendance applicative.

Le guide d'évaluation des services cloud du NIST propose de vérifier la capacité par rapport à la définition et au modèle de service le plus approprié. Pour un achat, demandez ce que vous pouvez configurer, ce que le fournisseur exploite, ce qui est mesuré et ce que vous pouvez exporter en quittant le service.

Comment choisir un modèle de service cloud

Choisissez le niveau de gestion par le fournisseur qui correspond aux exigences du traitement. Un contrôle plus large est utile si vous en avez besoin ; sinon, il peut devenir une charge que votre équipe doit assumer sans bénéfice clair.

1. Définissez le résultat attendu. Précisez l'application, les données d'entrée, les utilisateurs, le résultat, les performances requises et les interruptions acceptables.
2. Identifiez le contrôle nécessaire. Vérifiez si vous avez besoin d'un accès au système d'exploitation, de pilotes précis, de dépendances personnalisées, d'une configuration réseau ou seulement d'une fonction applicative.
3. Attribuez les tâches d'exploitation. Désignez les responsables des mises à jour, des revues d'accès, de la supervision, des incidents, des sauvegardes et des tests de restauration. Vérifiez le temps et les compétences disponibles.
4. Testez les contraintes. Vérifiez environnements d'exécution, emplacements des données, capacité, intégration, mise à l'échelle et possibilités de reprise avec un traitement représentatif.
5. Comparez le coût complet. Incluez ressources de calcul ou exécution, stockage de données, requêtes, transferts, réseau, support, engagements et temps de travail technique. Vérifiez les capacités minimales et les frais qui persistent au repos.
6. Testez la sortie. Exportez des données représentatives et confirmez comment reconstruire l'application ou remplacer ses fonctions essentielles ailleurs.

Les questions de sélection d'un fournisseur proposées par Hivenet aident à traduire ces exigences en évaluation de service. Un test concluant doit établir que le traitement fonctionne, que les pannes peuvent être examinées et que l'équipe peut exploiter les parties qui lui reviennent.

Un exemple pratique : une application de traitement d'images

Imaginons une petite équipe qui crée une application recevant des photos pour en produire des versions retouchées. En IaaS, elle pourrait installer les outils de traitement sur une VM et gérer son système d'exploitation, ses processus, ses connexions de stockage et sa reprise. Le PaaS pourrait héberger l'application si les bibliothèques requises et les limites de ressources conviennent.

Une fonction pourrait traiter l'arrivée d'un fichier si le travail respecte les limites d'exécution et si l'application gère les nouvelles tentatives. Un outil SaaS de retouche pourrait éviter de développer l'application, à condition que ses fonctions, ses conditions relatives aux données et ses possibilités d'export répondent au besoin.

Il s'agit de conceptions possibles pour un cas hypothétique, sans prédiction de performance. Une dépendance GPU personnalisée pourrait favoriser une instance ; une fonction applicative existante pourrait favoriser le SaaS. Le traitement détermine le contrôle utile.

Comment les services Hivenet se situent dans ces modèles

Compute with Hivenet propose une approche orientée infrastructure pour les traitements GPU ou CPU exécutés par le client. L'environnement disponible compte : la documentation Hivenet sur les VM et les conteneurs distingue le contrôle du système d'exploitation d'une VM des modèles de conteneur sans accès root. Toutes les instances ne donnent donc pas les mêmes privilèges système.

Inference API fournit un point d'accès à un modèle géré plutôt qu'un serveur de modèles exploité par le client. Celui-ci gère l'intégration, les requêtes, les données envoyées, les accès, l'évaluation et le traitement des résultats. Le modèle actuel de points d'accès dédiés facture la durée d'exécution des réplicas ; il ne faut pas le présenter comme une inférence serverless générique facturée au token ou dont la capacité descend automatiquement à zéro.

Le stockage objet compatible S3 fournit un stockage géré pour les données applicatives et les artefacts. Store et Send sont des applications de fichiers prêtes à l'emploi, plus proches du SaaS. Private AI est un parcours de déploiement accompagné dont le périmètre d'exploitation doit être établi pour le projet.

Ces services ont des responsabilités différentes. La présentation de l'architecture Hivenet explique leurs fonctionnements propres. Choisissez le service qui apporte les capacités et le contrôle nécessaires, puis confirmez ses limites documentées et les responsabilités d'exploitation.

Questions fréquentes

Existe-t-il trois ou quatre modèles de services cloud ?

Le NIST en définit trois : IaaS, PaaS et SaaS. De nombreux guides pratiques présentent le serverless comme une quatrième catégorie, mais celui-ci recoupe d'autres services gérés et ne constitue pas un quatrième modèle du NIST.

Le FaaS est-il identique au serverless ?

Le FaaS correspond à la partie du serverless qui exécute des fonctions en réponse à des événements. Le serverless comprend d'autres capacités gérées ; les termes ne sont donc pas interchangeables.

Quel modèle est le moins cher ?

Aucun ne l'est dans tous les cas. Comparez le même traitement, en incluant périodes d'inactivité, pointes de demande, transferts, support et travail d'exploitation. Une facture d'infrastructure plus faible peut être compensée par davantage d'administration.

Une application peut-elle utiliser plusieurs modèles ?

Oui. Une application peut utiliser une plateforme gérée pour son API web, une instance autogérée pour un traitement spécialisé et des fonctions pour les événements. Chaque connexion ajoute des décisions sur les autorisations, les transferts de données, la supervision et la reprise.

Un service géré inclut-il les sauvegardes et la reprise après sinistre ?

Uniquement les capacités prévues par le service et le plan choisis. Pour la continuité d'activité, vérifiez la conservation, les points de récupération, les procédures de restauration, les contrôles d'accès et le délai de reprise. La redondance de l'infrastructure du fournisseur ne prouve pas que les données de votre application peuvent être restaurées après une modification indésirable.