Modèles de service cloud
IaaS, PaaS et SaaS un par un, puis la comparaison qui les distingue.
Chaque fournisseur cloud regroupe ce qu'il vend dans l'un de 3 modèles de service, et la différence entre eux n'est pas un détail technique. Elle décide de la part de la pile que vous gérez vous-même, de la vitesse à laquelle vous pouvez livrer, et du contrôle que vous gardez. Ce sujet couvre l'Infrastructure as a Service, le Platform as a Service et le Software as a Service individuellement, puis met les 3 côte à côte pour que vous sachiez les distinguer dans un scénario, pas seulement les nommer isolément.
Ce que couvre ce sujet
- Infrastructure as a Service (IaaS) : du calcul, du stockage et du réseau bruts, avec le système d'exploitation et tout ce qui est au-dessus laissé à votre charge, livrés par des produits comme AWS EC2, Azure Virtual Machines et Google Compute Engine
- Platform as a Service (PaaS) : une plateforme qui fait tourner votre code sans vous demander de gérer des serveurs ou un système d'exploitation, livrée par des produits comme AWS Elastic Beanstalk, Heroku et Google App Engine
- Software as a Service (SaaS) : une application complète entièrement gérée par le fournisseur, de Gmail à Salesforce en passant par Slack, et l'architecture multi-tenant qui la rend abordable
- Une comparaison complète des 3 modèles côte à côte, les indices de mots-clés qui identifient chacun dans un scénario, et pourquoi monter dans la pile est un compromis plutôt qu'une simple amélioration
Pourquoi c'est important
Presque toutes les décisions du reste de ce domaine supposent que vous savez placer un service dans l'un de ces 3 modèles. Les régions, le calcul, le stockage et les bases de données, couverts dans le prochain sujet, sont tous des briques qui apparaissent aussi bien dans des produits IaaS que PaaS ou SaaS, et savoir dans quel modèle vous êtes vous dit ce dont vous êtes réellement responsable.
Les questions d'examen dans ce domaine demandent rarement une définition. Elles décrivent une contrainte, un accès root à un kernel, une équipe sans développeur, une exigence de simplement livrer du code, et attendent que vous sachiez vers quel modèle cette contrainte pointe. Prenez l'habitude de ce schéma ici, et le modèle de responsabilité partagée du domaine Sécurité et fiabilité vous paraîtra une extension de quelque chose que vous connaissez déjà, pas une idée nouvelle.