Qu'est-ce qu'un PaaS ? Le Platform as a Service face à l'IaaS, au SaaS et à Kubernetes

Le PaaS (Platform as a Service) est un modèle cloud dans lequel vous confiez votre application, sous forme de code source ou d'image de conteneur, à un fournisseur qui la fait tourner. La plateforme en fait le build, la déploie, la met à l'échelle et exploite les serveurs, les systèmes d'exploitation et les réseaux sous-jacents. Vous restez responsable de l'application, de sa configuration et de ses données.

La définition la plus citée vient du National Institute of Standards and Technology américain (NIST SP 800-145). Avec un PaaS, vous déployez vos propres applications sur l'infrastructure du fournisseur, mais vous ne gérez ni ne contrôlez l'infrastructure cloud sous-jacente, y compris le réseau, les serveurs, les systèmes d'exploitation et le stockage (dans l'original : « not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage »). Vous contrôlez en revanche les applications déployées et, éventuellement, certains paramètres de l'environnement d'hébergement.

Ce que prend en charge un PaaS

La liste exacte varie selon le fournisseur, mais un PaaS complet couvre l'essentiel de ce qui suit :

• Builds : il transforme un dépôt Git en image exécutable, soit avec des buildpacks qui détectent votre langage, soit à partir d'un Dockerfile que vous committez.
• Déploiements : il met en ligne les nouvelles releases, souvent à chaque push sur une branche, et conserve un historique de ce qui a tourné et quand.
• Mise à l'échelle : ajouter des réplicas ou augmenter la taille se fait par un réglage, sans installer de nouveau serveur.
• TLS et domaines : chaque app reçoit un nom d'hôte, et la plateforme émet et renouvelle les certificats de vos propres domaines.
• Logs et métriques : les logs d'exécution et des graphiques de CPU et de mémoire, sans exploiter votre propre stack de logs.
• Bases de données managées : PostgreSQL, MySQL ou un cache à côté de l'app, avec réplicas et backups en option.
• Serveurs et systèmes d'exploitation : appliquer les correctifs sur les hôtes, remplacer le matériel défaillant et maintenir le réseau en service.

Ce qui reste à votre charge

Un PaaS supprime le travail d'infrastructure, pas la responsabilité de votre produit. Vous restez responsable de :

• Votre code et ses dépendances, y compris la mise à jour des bibliothèques quand une vulnérabilité est publiée.
• La configuration et les secrets : variables d'environnement, clés d'API et droits d'accès des membres de votre équipe.
• Vos données : le schéma, les migrations, l'activation des backups et le test d'une restauration.
• Le dimensionnement et le coût : le nombre de réplicas et l'offre que vous choisissez, qui déterminent votre facture.
• La sécurité applicative : authentification, validation des entrées et accès au dashboard.
• La localisation : la région dans laquelle tournent votre app et ses données.

PaaS, IaaS, SaaS, serverless et Kubernetes comparés

Ces modèles diffèrent par ce que vous confiez et ce que vous gardez. Une comparaison approximative :

Modèle	Vous apportez	Le fournisseur gère	Vous gérez encore	Usage typique
IaaS	Machines virtuelles, disques, réseaux	Matériel, virtualisation, datacenters	Système d'exploitation, runtime, déploiements, mise à l'échelle, correctifs	Contrôle total, logiciels anciens ou spécifiques
PaaS	Code source ou image de conteneur	Serveurs, OS, builds, déploiements, routage, souvent les bases de données	Application, configuration, données	Apps web, API, workers
SaaS	Rien à déployer	Toute l'application	Paramètres, utilisateurs et vos données dans l'app	Logiciels métier standard
Serverless (FaaS)	Fonctions	Exécution par événement ou par requête, mise à l'échelle selon la demande	Code des fonctions, cold starts, limites de durée et de taille	Charges événementielles, avec des pics
Kubernetes	Images de conteneur et manifestes	En service managé : le control plane	Nœuds, deployments, ingress, configuration du scaling, CI/CD, logs	Grandes infrastructures avec une équipe plateforme

L'IaaS vous fournit des machines virtuelles et vous laisse le reste. Le NIST le décrit comme la mise à disposition de « processing, storage, networks, and other fundamental computing resources » (capacité de calcul, stockage, réseaux et autres ressources informatiques fondamentales) sur lesquelles vous pouvez exécuter le logiciel de votre choix, y compris le système d'exploitation.

Le SaaS se situe à l'autre extrémité : vous utilisez l'application finie du fournisseur dans le navigateur ou via une API, sans rien déployer.

Le serverless, au sens des fonctions, exécute votre code sous forme de petites fonctions déclenchées par des événements ou des requêtes HTTP et facture selon la demande réelle. Le livre blanc de la CNCF sur le serverless note que la plupart des runtimes limitent la taille ou la durée d'exécution de chaque fonction, et que le démarrage après une période d'inactivité peut être lent. Un PaaS, lui, fait généralement tourner votre app comme un processus toujours actif.

Kubernetes est un orchestrateur de conteneurs, et sa propre documentation indique que Kubernetes « is not a traditional, all-inclusive PaaS », autrement dit que ce n'est pas un PaaS traditionnel tout-en-un. Il ne déploie pas de code source, ne fait pas le build de votre application et n'inclut pas de bases de données comme services intégrés. Il fournit des briques pour construire des plateformes. Lisez PaaS vs Kubernetes pour une comparaison plus détaillée.

Quand un PaaS convient

• Vous développez des apps web, des API ou des workers en arrière-plan dans un langage courant.
• Personne dans votre équipe n'a pour métier d'exploiter des serveurs ou des clusters, et vous préférez ne pas encore recruter pour cela.
• Vous voulez une nouvelle version en ligne quelques minutes après un merge, avec des logs et des métriques déjà en place.
• Vous avez besoin des bases de données, du stockage et de l'app au même endroit, sur une seule facture.

Quand il ne convient pas

• Vous avez besoin d'un noyau personnalisé, de matériel spécifique ou d'un contrôle bas niveau du réseau. Une machine virtuelle ou du bare metal convient mieux.
• Votre logiciel attend un accès root, un système d'init complet ou des paquets installés avec des scripts de mainteneur. Un Dockerfile peut couvrir une partie de ces besoins ; certains logiciels ne tournent bien que sur une VM.
• Vous faites tourner des charges importantes et stables et disposez déjà d'une équipe plateforme. Exploiter votre propre infrastructure peut alors être rentable.
• Votre code tourne quelques secondes par jour en réponse à des événements. Une plateforme de fonctions peut coûter moins cher.
• Vous avez une exigence légale ou de conformité que les régions ou les certifications du fournisseur ne permettent pas de satisfaire.

Comment évaluer un PaaS

Régions et localisation des données

Vérifiez où tournent réellement l'app, la base de données, les backups et les logs, et si vous pouvez choisir cela service par service. Vérifiez aussi où se trouvent le control plane du fournisseur et les données de compte, et dans quel pays l'entreprise a son siège. Pour les données personnelles de personnes situées dans l'UE, les deux questions comptent.

Services inclus

Regardez ce qui est fourni avec la plateforme et ce qui nécessite un tiers : bases de données, stockage objet, e-mail, CDN, logs et métriques, environnements de preview. Chaque add-on d'un autre fournisseur, c'est un contrat de plus, une facture de plus et un sous-traitant ultérieur de plus.

Modèle de tarification

Les plateformes facturent par instance, à la seconde d'exécution, par requête ou par utilisateur (seat), et certaines mesurent en plus la bande passante, les minutes de build ou le volume de logs. Estimez un mois avec vos chiffres réels, y compris la base de données et un second environnement pour le staging.

Portabilité

La dépendance au fournisseur (lock-in) se cache généralement dans le build et la configuration, pas dans le code. Préférez une plateforme qui construit des images de conteneur standard à partir d'un Dockerfile ou de Cloud Native Buildpacks : le lifecycle des buildpacks exporte une image OCI, le même format que celui qu'exécutent les autres plateformes de conteneurs. Gardez la configuration dans des variables d'environnement, et utilisez des moteurs de base de données standard que vous pouvez exporter (dump) et restaurer ailleurs. Partir devient alors une migration, pas une réécriture.

La place de Nodion

Nodion est un PaaS exploité par Nodion GmbH, dont le siège est à Stuttgart, en Allemagne. Vous déployez depuis Git avec un Dockerfile ou les propres Cloud Native Buildpacks de Nodion, ou à partir d'une image préconstruite. Chaque app dispose de processus, de logs, de métriques et de domaines, les apps Git peuvent ouvrir des environnements de preview, et vous pouvez rattacher Postgres, MySQL, Valkey et ClickHouse managés dans l'onglet Environment de l'app. Vous choisissez la région par service, par exemple EU Central à Francfort. Consultez Applications pour en savoir plus.