Wat is PaaS? Platform as a Service vergeleken met IaaS, SaaS en Kubernetes

Platform as a Service (PaaS) is een cloudmodel waarbij je je applicatie als broncode of containerimage aanlevert en de aanbieder die draait. Het platform bouwt, deployt en schaalt de applicatie en beheert de servers, besturingssystemen en netwerken eronder. Jij blijft verantwoordelijk voor de applicatie, de configuratie en de data.

De meest geciteerde definitie komt van het Amerikaanse National Institute of Standards and Technology (NIST SP 800-145). Met een PaaS deploy je je eigen applicaties op de infrastructuur van de aanbieder, maar beheer of controleer je de onderliggende cloudinfrastructuur niet, waaronder het netwerk, de servers, besturingssystemen en opslag (in het origineel: “not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage”). Wel heb je controle over de gedeployde applicaties en mogelijk over instellingen van de hostingomgeving.

Wat een PaaS overneemt

De precieze lijst verschilt per aanbieder, maar een volwaardige PaaS dekt het meeste hiervan:

• Builds: het platform maakt van een Git-repository een uitvoerbare image, met buildpacks die je taal herkennen of op basis van een Dockerfile die je commit.
• Deploys: het rolt nieuwe releases uit, vaak bij elke push naar een branch, en houdt bij wat wanneer draaide.
• Schalen: meer replica's of een groter formaat is een instelling, geen nieuwe server die je moet installeren.
• TLS en domeinen: elke app krijgt een hostnaam, en certificaten voor je eigen domeinen worden voor je uitgegeven en verlengd.
• Logs en metrics: runtime-logs en grafieken van CPU en geheugen, zonder dat je zelf een loggingstack draait.
• Managed databases: PostgreSQL, MySQL of een cache naast de app, met replica's en backups als optie.
• Servers en besturingssystemen: hosts patchen, defecte hardware vervangen en het netwerk draaiende houden.

Wat bij jou blijft

Een PaaS neemt het infrastructuurwerk weg, niet de verantwoordelijkheid voor je product. Jij blijft verantwoordelijk voor:

• Je code en de dependencies, inclusief het bijwerken van libraries als er een kwetsbaarheid bekend wordt.
• Configuratie en secrets: omgevingsvariabelen, API-sleutels en wie in je team ze kan zien.
• Je data: het schema, migraties, backups aanzetten en een restore testen.
• Omvang en kosten: hoeveel replica's je draait, welk plan je kiest en wat je daarvoor betaalt.
• Applicatiebeveiliging: authenticatie, inputvalidatie en toegang tot het dashboard.
• Locatie: in welke regio je app en de data draaien.

PaaS vs IaaS vs SaaS vs serverless vs Kubernetes

De modellen verschillen in wat je uit handen geeft en wat je zelf houdt. Een grove vergelijking:

Model	Jij levert	De aanbieder beheert	Jij beheert nog	Typisch geschikt voor
IaaS	Virtuele machines, schijven, netwerken	Hardware, virtualisatie, datacenters	Besturingssysteem, runtime, deploys, schalen, patches	Volledige controle, legacy of speciale software
PaaS	Broncode of een containerimage	Servers, OS, builds, deploys, routing, vaak databases	Applicatie, configuratie, data	Webapps, API's, workers
SaaS	Niets te deployen	De hele applicatie	Instellingen, gebruikers en je data in de app	Standaard bedrijfssoftware
Serverless (FaaS)	Functies	Uitvoering per event of request, schalen met de vraag	Functiecode, cold starts, limieten voor tijd en grootte	Eventgedreven workloads met pieken
Kubernetes	Container-images en manifests	Als managed dienst: het control plane	Nodes, deployments, ingress, schaalinstellingen, CI/CD, logging	Grote omgevingen met een platformteam

IaaS geeft je virtuele machines en laat de rest aan jou over. NIST beschrijft het als het leveren van “processing, storage, networks, and other fundamental computing resources” (rekenkracht, opslag, netwerken en andere fundamentele computerresources), waarop je software naar keuze draait, inclusief het besturingssysteem.

SaaS is het andere uiterste: je gebruikt de kant-en-klare applicatie van de aanbieder in de browser of via een API en deployt niets.

Serverless in de zin van functies draait je code als kleine functies die door events of HTTP-requests worden aangeroepen, en rekent af op basis van het werkelijke gebruik. De whitepaper van de CNCF over serverless merkt op dat de meeste runtimes de grootte of uitvoeringstijd van elke functie beperken, en dat opstarten na een periode van inactiviteit traag kan zijn. Een PaaS draait je app daarentegen meestal als een continu actief proces.

Kubernetes is een systeem voor containerorkestratie, en de eigen documentatie zegt dat Kubernetes “is not a traditional, all-inclusive PaaS”: het is geen traditionele alles-in-één-PaaS. Het deployt geen broncode, bouwt je applicatie niet en bevat geen databases als ingebouwde diensten. Het levert bouwstenen voor platforms. Lees PaaS vs Kubernetes voor de uitgebreidere vergelijking.

Wanneer een PaaS past

• Je bouwt webapps, API's of background workers in een gangbare taal.
• Niemand in je team heeft als taak servers of clusters te beheren, en je neemt daar liever nog niemand voor aan.
• Je wilt een nieuwe versie een paar minuten na een merge live hebben, met logs en metrics al op hun plek.
• Je hebt databases, opslag en de app nodig op één plek, op één rekening.

Wanneer niet

• Je hebt een eigen kernel, speciale hardware of low-level controle over het netwerk nodig. Een virtuele machine of bare metal past dan beter.
• Je software verwacht root-toegang, een volledig init-systeem of packages die met maintainer-scripts worden geïnstalleerd. Een Dockerfile kan een deel daarvan opvangen; sommige software draait alleen goed op een VM.
• Je draait grote, stabiele workloads en hebt al een platformteam. Dan kan het lonen om je eigen infrastructuur te draaien.
• Je code draait een paar seconden per dag als reactie op events. Een functieplatform kan dan goedkoper zijn.
• Je hebt een wettelijke of compliance-eis waaraan de regio's of certificeringen van de aanbieder niet kunnen voldoen.

Hoe je een PaaS beoordeelt

Regio's en datalocatie

Controleer waar de app, de database, backups en logs echt draaien, en of je dat per dienst kiest. Controleer ook waar het control plane en de accountgegevens van de aanbieder staan, en in welk land het bedrijf gevestigd is. Voor persoonsgegevens van mensen in de EU zijn beide vragen belangrijk.

Inbegrepen diensten

Kijk wat bij het platform zit en waarvoor je een derde partij nodig hebt: databases, objectopslag, e-mail, CDN, logs en metrics, previewomgevingen. Elke add-on van een andere leverancier is een extra contract, een extra rekening en een extra subverwerker.

Prijsmodel

Platforms rekenen af per instantie, per seconde looptijd, per request of per gebruiker (seat). Sommige brengen daarnaast bandbreedte, buildminuten of logvolume in rekening. Schat de maandkosten op basis van je werkelijke gebruik, inclusief de database en een tweede omgeving voor staging.

Portabiliteit

Lock-in zit meestal in de build en de configuratie, niet in de code. Kies bij voorkeur een platform dat standaard container-images bouwt vanuit een Dockerfile of met Cloud Native Buildpacks: de lifecycle van buildpacks exporteert een OCI-image, hetzelfde formaat dat andere containerplatforms draaien. Houd configuratie in omgevingsvariabelen en gebruik standaard database-engines die je kunt dumpen en elders kunt terugzetten. Dan is weggaan een migratie, geen herschrijving.

Hoe Nodion hierin past

Nodion is een PaaS van Nodion GmbH uit Stuttgart, Duitsland. Je deployt vanuit Git met een Dockerfile of met de eigen Cloud Native Buildpacks van Nodion, of vanuit een vooraf gebouwde image. Elke app krijgt processen, logs, metrics en domeinen. Voor Git-apps kun je previewomgevingen aanmaken, en managed Postgres, MySQL, Valkey en ClickHouse koppel je op het tabblad Environment van de app. Je kiest de regio per dienst, bijvoorbeeld EU Central in Frankfurt. Zie Applicaties voor de details.