Cloud Computing Fundamentals
Platform as a Service (PaaS)
The service model that takes the operating system and runtime off your plate, so you push code and the platform runs it, with AWS Elastic Beanstalk, Heroku, and Google App Engine as the products that deliver it.
- Define Platform as a Service (PaaS) using the NIST framework
- Identify which layers move from customer to provider between IaaS and PaaS
- Contrast deploying the same application through IaaS and through PaaS
- Explain the boundary between PaaS and the serverless model covered later in this course
What if you never wanted to touch the operating system at all
The previous lesson ended with you owning an EC2 instance: patching its OS, installing a runtime, configuring a firewall. Now picture a solo developer with a web app to ship by Friday and zero interest in any of that. They do not want to choose an AMI, size a load balancer, or read a patch changelog. They want to hand over code and have it run. Platform as a Service is the model built for exactly that handoff.
The NIST definition, in practice
NIST defines PaaS as the capability to "deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider." The consumer does not manage the underlying infrastructure, including network, servers, operating systems, or storage, but does control the deployed application and, often, configuration settings for the environment that hosts it.
Read that against the IaaS definition from the last lesson and the shift is precise: the operating system, which was yours in IaaS, now belongs to the provider. What is left for you is the application itself and the settings around how it runs.
Who manages what, updated
| Layer | IaaS | PaaS |
|---|---|---|
| Networking, servers, virtualization | Provider | Provider |
| Operating system | You | Provider |
| Runtime and middleware | You | Provider |
| Application code | You | You |
| Data | You | You |
The whole shift is in one row: the operating system and runtime cross the line from "you" to "provider." That is the entire difference between the 2 models, and it deserves more attention than a single row suggests, because it is exactly the line an exam scenario tests.
Real products that deliver PaaS
- AWS Elastic Beanstalk: packages EC2 instances, a load balancer, and auto-scaling behind one deployment, still built on AWS's IaaS underneath, but you never touch those pieces directly
- Heroku: you run
git push heroku main, and Heroku detects your language, installs dependencies, and deploys, with zero server configuration for standard frameworks - Google App Engine and Azure App Service: the same trade, upload code, the platform runs it
Worked example: the same app, 2 ways
Shipping a small Ruby web app through EC2 means launching an instance, installing Ruby and its dependencies, configuring a web server, attaching a load balancer, and setting up an auto-scaling group, several separate steps, each one yours to get right and keep patched. Shipping the same app through Heroku means running git push heroku main. Heroku reads the code, recognizes it needs a Ruby runtime, builds it, and starts serving traffic, all from that 1 command.
That is not a smaller version of the same job. It is a different job: you stopped managing infrastructure and started managing only your application.
The misconception: PaaS is not "zero infrastructure decisions"
It is tempting to assume PaaS removes infrastructure thinking completely. It does not. You still pick a dyno or instance size, still set environment variables, and still pay for the capacity you have allocated whether or not it is handling traffic right now, a Heroku dyno you provision keeps running, and keeps billing, until you scale it down yourself. A model that only charges for the moment your code actually executes is a different idea again, serverless computing, and this course covers it later in the Modern Cloud Architectures topic. PaaS narrows your infrastructure job. It does not delete it.
The boundary ahead: PaaS versus SaaS
PaaS still asks you to write the application. That is the line the next lesson erases entirely.
Where this leaves you
PaaS trades some of the control IaaS gave you for speed: you stop managing servers and start shipping code straight to a platform that runs it. The next lesson covers what happens when even the code is no longer yours to write.