Les fondamentaux du cloud computing
Platform as a Service (PaaS)
Le modèle de service qui retire le système d'exploitation et le runtime de votre charge, pour que vous poussiez du code et que la plateforme le fasse tourner, avec AWS Elastic Beanstalk, Heroku et Google App Engine comme produits qui le livrent.
- Définir le Platform as a Service (PaaS) selon le cadre du NIST
- Identifier les couches qui passent du client au fournisseur entre IaaS et PaaS
- Comparer le déploiement d'une même application via IaaS et via PaaS
- Expliquer la frontière entre PaaS et le modèle Serverless couvert plus loin dans ce cours
Et si vous ne vouliez jamais toucher au système d'exploitation
La leçon précédente vous laissait propriétaire d'une instance EC2 : à patcher son système d'exploitation, à installer un runtime, à configurer un pare-feu. Imaginez maintenant un développeur seul, avec une application web à livrer d'ici vendredi et zéro envie de faire tout cela. Il ne veut pas choisir une AMI, dimensionner un load balancer ou lire un changelog de correctifs. Il veut livrer du code et le voir tourner. Le Platform as a Service est le modèle construit exactement pour ce transfert.
La définition du NIST, en pratique
Le NIST définit PaaS comme la capacité de "déployer sur l'infrastructure cloud des applications créées ou acquises par le consommateur, réalisées avec des langages de programmation, des bibliothèques, des services et des outils pris en charge par le fournisseur". Le consommateur ne gère pas l'infrastructure sous-jacente, y compris le réseau, les serveurs, les systèmes d'exploitation ou le stockage, mais contrôle l'application déployée et, souvent, les paramètres de configuration de l'environnement qui l'héberge.
Relisez cela à la lumière de la définition d'IaaS de la leçon précédente et le changement est net : le système d'exploitation, qui était à vous en IaaS, appartient maintenant au fournisseur. Ce qu'il vous reste, c'est l'application elle-même et les paramètres qui entourent son fonctionnement.
Qui gère quoi, mis à jour
| Couche | IaaS | PaaS |
|---|---|---|
| Réseau, serveurs, virtualisation | Fournisseur | Fournisseur |
| Système d'exploitation | Vous | Fournisseur |
| Runtime et middleware | Vous | Fournisseur |
| Code de l'application | Vous | Vous |
| Données | Vous | Vous |
Tout le changement tient dans une seule ligne : le système d'exploitation et le runtime passent de "vous" à "fournisseur". C'est toute la différence entre les 2 modèles, et elle mérite plus d'attention qu'une simple ligne ne le laisse penser, parce que c'est exactement la frontière qu'un scénario d'examen teste.
Des produits réels qui livrent du PaaS
- AWS Elastic Beanstalk : regroupe des instances EC2, un load balancer et de l'auto-scaling derrière un seul déploiement, toujours construit sur l'IaaS d'AWS en dessous, mais vous ne touchez jamais ces pièces directement
- Heroku : vous lancez
git push heroku main, et Heroku détecte votre langage, installe les dépendances et déploie, sans aucune configuration serveur pour les frameworks standards - Google App Engine et Azure App Service : le même échange, vous envoyez du code, la plateforme le fait tourner
Exemple chiffré : la même application, 2 façons
Livrer une petite application Ruby via EC2 demande de lancer une instance, d'installer Ruby et ses dépendances, de configurer un serveur web, d'attacher un load balancer et de mettre en place un groupe d'auto-scaling, plusieurs étapes distinctes, chacune à votre charge et à maintenir. Livrer la même application via Heroku demande de lancer git push heroku main. Heroku lit le code, reconnaît qu'il faut un runtime Ruby, le construit et commence à servir le trafic, le tout depuis cette seule commande.
Ce n'est pas une version allégée du même métier. C'est un métier différent : vous avez arrêté de gérer l'infrastructure et commencé à gérer seulement votre application.
L'idée fausse : PaaS n'est pas "zéro décision d'infrastructure"
Il est tentant de supposer que PaaS retire toute réflexion sur l'infrastructure. Ce n'est pas le cas. Vous choisissez toujours une taille de dyno ou d'instance, vous configurez toujours des variables d'environnement, et vous payez toujours pour la capacité que vous avez allouée, qu'elle serve du trafic en ce moment ou non : un dyno Heroku que vous provisionnez continue de tourner, et de facturer, jusqu'à ce que vous le réduisiez vous-même. Un modèle qui ne facture que le moment où votre code s'exécute réellement est une autre idée encore, le Serverless, que ce cours couvre plus loin dans le sujet Architectures cloud modernes. PaaS réduit votre travail d'infrastructure. Il ne le supprime pas.
La frontière à venir : PaaS contre SaaS
PaaS vous demande encore d'écrire l'application. C'est exactement la ligne que la prochaine leçon efface entièrement.
Où cela vous mène
PaaS échange une partie du contrôle que vous donnait IaaS contre de la vitesse : vous arrêtez de gérer des serveurs et commencez à livrer du code directement à une plateforme qui le fait tourner. La prochaine leçon couvre ce qui se passe quand même le code n'est plus à vous d'écrire.