Hardware Basics #8: Cloud — From Owning to Renting, from On-Prem to IaaS / PaaS / SaaS
In #7 we said virtualization split one server into many and became the foundation of the cloud. Now we sort out the picture above that: the cloud itself. People sometimes sum it up as “someone else’s computer,” but from this series’ point of view there’s a more precise phrasing: it turned the hardware we’ve covered from owning to renting. Let’s break it down by who owns what and where, and by how far up the stack you rent.
Where this post sits in the Hardware Basics series:
- #1 Four resources that run a computer — CPU / Memory / Storage / Network
- #2 CPU — Cores / Threads / Clock / Cache, and what a vCPU really is
- #3 Memory — RAM, the hierarchy, and what happens when swapping starts
- #4 Storage ① Devices — HDD / SSD / NVMe and IOPS / Throughput / Latency
- #5 Storage ② Layout and connection — RAID and DAS / NAS / SAN
- #6 Network — Bandwidth and latency, from the NIC to the data center
- #7 Virtualization and containers — How one physical server becomes many
- #8 Cloud — From owning to renting, from on-prem to IaaS / PaaS / SaaS ← this post
- #9 Reading cloud instance specs — Choosing to match the workload
What the cloud is — from owning to renting #
In the old days, running a service meant buying hardware. You ordered servers, received and installed them, arranged power, network, and cooling, and prepared for failures. You had to buy resources generously in advance, and money was tied up in whatever sat spare.
The cloud turns that hardware into something you rent. You create it the moment you need it, pay for what you use, and delete it when you no longer need it. Thanks to the virtualization of #7, you don’t rent a whole physical server but slice off exactly the size you need. The concept at a non-developer level was also covered in IT Literacy #3; this post goes one level deeper, through the lens of hardware ownership and rental.
Who owns it, and where #
Ownership and placement of hardware don’t fall on a single dividing line. Three steps clarify where the cloud stands.
| Way | Hardware owner | Where it sits | Operational burden |
|---|---|---|---|
| On-premises | you own it | your building / server room | power, cooling, hardware — all yours |
| Colocation | you own it | a leased space in someone’s data center | hardware yours, building/power theirs |
| Cloud | the provider owns it | the provider’s data center | hardware operation is the provider’s |
On-prem holds everything yourself, so control is strong but the burden is large. Colocation rents only the building and power and keeps the hardware yours. The cloud rents the hardware itself, so you focus only on what to put on top of it.
The abstraction layers — IaaS / PaaS / SaaS #
When you rent cloud services, the key question is “how much of the hardware is still visible to you?” The higher the layer you rent, the more the four resources from #1 are hidden, and the less you need to manage.
- IaaS (Infrastructure as a Service) — you rent virtual servers, storage, and network. You pick the instance type from #9 yourself and bring up everything from the OS. EC2 is here. The four resources show up directly as a spec sheet.
- PaaS (Platform as a Service) — you rent a runtime to put your application on. The provider manages the OS and hardware; you bring only the code. The hardware is barely visible.
- SaaS (Software as a Service) — you rent finished software. You use only the features, and every layer below is hidden. Gmail or Slack is here.
IaaS PaaS SaaS
App you you provider
Runtime you provider provider
OS you provider provider
Hardware provider provider provider
(4 resources) (visible as a spec sheet) (hidden)Higher layers are more convenient but cede control; lower layers give more freedom but add more to manage yourself. The place where this series’ hardware knowledge applies most directly is IaaS, where the four resources surface as a spec sheet.
Deployment models — public / private / hybrid #
The cloud also splits by who uses it.
| Model | Meaning | Where used |
|---|---|---|
| Public | a provider’s resources shared by many customers | most general services |
| Private | a cloud one organization uses exclusively | strict regulation / security |
| Hybrid | on-prem and public together | sensitive data inside, the rest in the cloud |
| Multicloud | several providers together | avoiding lock-in to one provider |
Areas where regulation forbids putting data outside go private or hybrid. The data-sovereignty constraints discussed in AWS Basics #1 connect to this choice.
The cloud isn’t always cheaper #
The cloud’s strength is paying for what you use instead of buying in advance. Startup cost is near zero, and you can scale up quickly even under sudden traffic.
But if you run a workload that keeps resources fully used for a long time, renting can end up costing more than buying. On top of that, hidden charges add up — like the egress cost from #6. The cloud isn’t simply “always cheap” — it’s a model that lets you pay only for what you need and change it quickly.
Common pitfalls #
“The cloud is cheap, no question” #
A workload that stays fully used can be cheaper to buy outright. The cloud’s cost structure helps when traffic is uneven or you need fast scaling.
“On the cloud I don’t need to know hardware” #
As long as you use IaaS, you pick the instance type yourself, and that is choosing the four resources. Not knowing hardware leads to over- or under-provisioning.
“PaaS/SaaS still gives me full control” #
The higher up you rent, the more fine-grained control passes to the provider. Convenience and control are a trade.
“I don’t need to worry about egress” #
Traffic leaving the cloud is charged, and the cost of pulling data out when switching providers is nothing to ignore either. It always comes up in discussions of multicloud and avoiding lock-in.
Wrap-up #
What we covered:
- The cloud turned hardware from owning to renting. The virtualization of #7 is its foundation.
- By ownership and place, the operational burden drops in the order on-prem → colocation → cloud.
- IaaS, PaaS, SaaS split by how far the hardware is visible. The four resources surface most directly in IaaS.
- Deployment models split into public, private, hybrid, multicloud, with regulation and lock-in avoidance dividing the choice.
- The cloud isn’t always cheap — it’s a model to pay for what you need and change it fast.
Next — reading instance specs #
If you use the cloud as IaaS, you end up picking an instance type yourself — and that is where everything this series has built up about the four resources comes together. The final post, #9 Reading cloud instance specs — Choosing to match the workload, dissects a name like c5.xlarge and walks through how to read a spec sheet by vCPU, memory, storage, and network to choose a type that fits the workload.