Cloud Concepts — IaaS, PaaS, SaaS
What you'll learn
- Why the cloud took over the world
- The three service models: IaaS, PaaS, SaaS
- Key benefits: elasticity, pay-as-you-go
- The pizza analogy that makes it all click
Pizza as a Service 🍕
The three cloud models describe how much the provider handles for you. The classic way to understand them is making pizza:
- On-premises = make pizza at home. You buy everything, own the kitchen, do all the work. (Your own servers.)
- IaaS (Infrastructure as a Service) = buy a frozen pizza kit. The provider gives you the raw ingredients (virtual servers, storage, networking); you assemble and bake. You manage the OS and app. Example: AWS EC2. Maximum control, maximum responsibility.
- PaaS (Platform as a Service) = pizza delivery. You just say what you want; they cook and deliver; you provide the table and drinks. The provider manages servers and OS; you just deploy your code. Example: Heroku, Vercel, Google App Engine. Less control, way less hassle.
- SaaS (Software as a Service) = eat at a restaurant. You do nothing but enjoy the finished product. Fully managed software you just use. Examples: Gmail, Netflix, Google Docs, this very website.
The pattern: top to bottom, the provider does more and you do less.
Why the cloud won — the benefits are enormous:
- Pay-as-you-go — no huge upfront hardware cost; rent by the hour/second. A startup can launch for pennies.
- Elasticity — automatically scale up for a traffic spike (Black Friday!) and back down after, paying only for what you used. Owning servers means buying for your peak and wasting them the rest of the time.
- Global reach — deploy in data centers worldwide in minutes.
- No maintenance — the provider handles hardware failures, power, cooling, security patches.
That shift — from a huge upfront investment in machines you maintain, to a flexible utility you rent like electricity — is why nearly every modern company runs on the cloud.
Multi-cloud and the vendor lock-in trap 🔗
Once a company builds deeply on one provider's unique services, switching becomes painful — this is vendor lock-in. It's like renovating your kitchen entirely around one company's proprietary appliances: perfectly fine until you want to switch brands and discover nothing else fits the cabinets.
Lock-in happens gradually: you start using AWS's proprietary Lambda triggers, its specific database quirks, its unique networking setup — each convenient on its own, but together they make your app only runnable on AWS. Rewriting all of that to move to Azure could take months and cost a fortune.
Some companies respond with a multi-cloud strategy — deliberately spreading workloads across two or more providers (say, AWS and Google Cloud). Reasons include:
- Avoiding lock-in — negotiating leverage and a fallback if one provider raises prices or has an outage.
- Best-of-breed — using each provider's strongest service (e.g. one cloud's AI tools, another's database).
- Regulatory/geographic requirements — some countries require certain data to stay with a local or specific provider.
The trade-off is real, though: multi-cloud means your team must learn multiple platforms, duplicate tooling, and manage more complexity — often increasing cost and effort rather than reducing it. Most companies deliberately stay single-cloud and manage lock-in risk instead by favoring open standards (containers, Kubernetes, Terraform) that are easier to move between providers than each provider's proprietary services. Multi-cloud is a serious architectural decision, not a free win.
Build a service-model classifier. Write classifyModel(managesOS, managesApp) — both booleans meaning "does the customer manage the OS?" and "does the customer manage the app deployment?". Return "IaaS" if the customer manages both, "PaaS" if the customer manages only the app (not the OS), and "SaaS" if the customer manages neither. This is the exact decision tree used to categorize any cloud offering.
Real-world case study: Netflix's move to AWS 🔍
In 2008, a database corruption incident in Netflix's own data center halted DVD shipments for three days. That outage pushed Netflix to rethink owning its infrastructure entirely, and it began an eight-year migration of its whole streaming service to AWS — running on IaaS building blocks like EC2 and S3, the same services you learned about in this course.
By January 2016, Netflix had shut down its last owned data centers and moved 100% of its streaming infrastructure to the cloud. The payoff: Netflix can now automatically scale to handle enormous, unpredictable demand spikes (a new season dropping, a regional event) across 190+ countries, without ever buying a single physical server itself.
Netflix's story is often cited as the definitive proof that the cloud's elasticity and managed services can outperform even a tech giant's own data centers — while also illustrating vendor lock-in in practice: Netflix's architecture is now deeply built around AWS-specific services, a trade-off it accepted deliberately for the operational simplicity gained.
Question 1 of 7
Gmail and Netflix are examples of…
Question 2 of 7
You rent raw virtual servers and manage the OS yourself. That's…
Question 3 of 7
What is 'elasticity' in the cloud?
Question 4 of 7
The main financial benefit of the cloud is…
Question 5 of 7
What is 'vendor lock-in'?
Question 6 of 7
A cloud offering where the customer manages the app but NOT the OS is…
Question 7 of 7
Why did Netflix migrate fully to AWS by 2016?
Summary
- IaaS / PaaS / SaaS = provider does progressively more, you do less (pizza analogy)
- Cloud won on pay-as-you-go, elasticity, global reach, and no maintenance
- SaaS = use it; PaaS = deploy code; IaaS = manage the servers
- It's renting computing like electricity
Next: AWS Core Services — hands-on with the biggest cloud provider's building blocks.
Practice
Reading is not learning until you run something. Pick one.