Les fondamentaux du cloud computing
IaaS vs. PaaS vs. SaaS
Le partage complet des responsabilités entre les 3 modèles de service côte à côte, les indices de mots-clés qui identifient chacun dans un scénario, et le piège classique qui attrape ceux qui supposent que monter dans la pile est toujours une amélioration.
- Comparer le partage complet des responsabilités entre IaaS, PaaS et SaaS, couche par couche
- Appliquer des indices de mots-clés pour identifier le bon modèle de service dans un scénario
- Expliquer pourquoi monter dans la pile échange du contrôle contre du confort plutôt que de simplement s'améliorer
- Évaluer un scénario face à ses contraintes pour choisir le modèle de service adapté
Les nommer est facile. Les distinguer est la vraie compétence
Vous savez maintenant définir IaaS, PaaS et SaaS individuellement. Ce n'est pas, en soi, une compétence utile : presque personne ne vous présente un service en demandant "qu'est-ce que c'est ?" dans le vide. Ce qui est vraiment testé, à l'examen comme sur le terrain, c'est un scénario avec des contraintes, une équipe, une échéance, une exigence de conformité, et la question de savoir lequel des 3 modèles lui convient. C'est là que cette leçon met son effort.
La pile complète, côte à côte
| Couche | IaaS | PaaS | SaaS |
|---|---|---|---|
| Réseau, serveurs, virtualisation | Fournisseur | Fournisseur | Fournisseur |
| Système d'exploitation | Vous | Fournisseur | Fournisseur |
| Runtime et middleware | Vous | Fournisseur | Fournisseur |
| Code de l'application | Vous | Vous | Fournisseur |
| Données et votre propre configuration | Vous | Vous | Vous |
Lisez le tableau colonne par colonne plutôt que ligne par ligne et le schéma saute aux yeux : chaque étape d'IaaS vers SaaS déplace exactement une couche de plus de "vous" vers "fournisseur". Les données et votre propre configuration sont la seule ligne qui ne bouge jamais, quel que soit le modèle choisi.
Le piège : un compromis, pas un classement
Il est tentant de lire ce tableau de gauche à droite et de conclure que SaaS est simplement le meilleur modèle, puisque le fournisseur fait le plus de travail. Cette conclusion est fausse, et c'est exactement le piège que pose une question d'examen. Ce que SaaS gagne en confort, il le dépense en contrôle. Vous ne pouvez pas installer une bibliothèque personnalisée sur les serveurs de Gmail, faire tourner votre propre code sur l'infrastructure de Salesforce, ni choisir une version différente du kernel pour Microsoft 365. IaaS vous rend tout ce contrôle, au prix de gérer vous-même le système d'exploitation, le runtime et l'application. Aucune extrémité du tableau n'est "meilleure". Chacune correspond à un ensemble différent de contraintes.
Indices de mots-clés pour les scénarios
Les scénarios d'examen disent rarement "IaaS" ou "PaaS" directement. Ils décrivent une contrainte, et la contrainte pointe vers le modèle.
| Le scénario dit... | Pointe vers |
|---|---|
| "Contrôle total du système d'exploitation", "version précise du kernel", "accès root" | IaaS |
| "Se contenter de déployer le code", "pas de gestion serveur", "se concentrer sur l'application" | PaaS |
| "Aucune installation", "utiliser dès la sortie de la boîte", "aucun développeur dans l'équipe" | SaaS |
Exemple chiffré : 2 scénarios, 2 réponses
Une équipe commerciale de 12 personnes a besoin d'un CRM opérationnel la semaine prochaine et n'a aucun développeur pour en construire un. Rien dans ce scénario ne mentionne du code, de l'infrastructure ou une personnalisation au-delà de la configuration. Cette absence est l'indice : c'est un scénario SaaS, et un outil comme Salesforce convient, pas quelque chose qu'une équipe construirait de zéro.
Changez maintenant la contrainte. Une entreprise fintech opère sous une réglementation qui l'oblige à contrôler le niveau exact de correctifs du système d'exploitation sur chaque serveur, jusqu'à la version du kernel, et à appliquer les correctifs de sécurité selon son propre calendrier plutôt que celui d'un fournisseur. PaaS et SaaS retirent tous les deux le système d'exploitation des mains du client, exactement le contrôle que cette réglementation exige. Cette seule exigence écarte les 2, et laisse IaaS comme seul modèle qui convienne.
Même question sous-jacente dans les 2 cas : jusqu'où ce scénario vous oblige-t-il à remonter dans la pile. La réponse de l'équipe commerciale est "pas du tout". La réponse de l'entreprise fintech est "jusqu'au kernel".
Le lien avec la responsabilité partagée
Ce même partage couche par couche est le fondement du modèle de responsabilité partagée, couvert en détail dans le domaine Sécurité et fiabilité de ce cours. Ce que vous apprenez ici, quelle couche vous appartient et quelle couche appartient au fournisseur, est exactement la question à laquelle ce modèle répond pour la sécurité en particulier. Vous n'apprenez pas une nouvelle idée là-bas. Vous appliquez celle-ci à une nouvelle question.
Où cela vous mène
Une seule question sépare ces 3 modèles dans n'importe quel scénario : jusqu'où dans la pile la situation exige-t-elle que le fournisseur intervienne. L'accès root et le contrôle du kernel vous tirent vers IaaS. Se concentrer sur la livraison de code sans gestion serveur vous tire vers PaaS. Aucune installation et aucun développeur en interne vous tirent vers SaaS. Le prochain sujet de ce domaine laisse les modèles de service derrière lui et passe aux briques que chacun d'entre eux fait tourner : régions, calcul, stockage, bases de données et réseau.