What the cloud actually is
Before any service names, any AWS-vs-Google debate, any Kubernetes — one plain definition. Cloud computing is renting computers, storage, and networking from a provider, on demand, over the internet, and paying only for what you use. That sentence contains the whole idea. Everything in this guide is an elaboration of it.
The before-picture: why renting won
To feel why the cloud exists, picture how you'd run a web app without it. You buy a physical server — a computer with no monitor, designed to run continuously in a rack. You pay for it up front (thousands of dollars), find somewhere with power and cooling and a fast internet connection to put it, install an operating system, and keep it patched and alive yourself. If your app suddenly gets popular, you can't add capacity until you buy and ship another server — weeks later. If it flops, you've bought hardware you don't need. This is on-premises ("on-prem") computing: you own the metal.
The cloud replaces that with renting. The provider — Amazon, Google, Microsoft, and others — has already bought hundreds of thousands of servers and put them in giant buildings called data centers. You rent a slice for as long as you need it: a few minutes, a month, years. Need ten more servers for a traffic spike? You ask for them over an API and they exist in seconds. Don't need them at 3 a.m.? Give them back and stop paying. That shift — from a big up-front capital expense (buying hardware, "capex") to a pay-as-you-go operating expense ("opex") — is the core economic reason the cloud took over.
:::note "The cloud is just someone else's computer" This phrase is sometimes used to mock cloud hype, but it is literally accurate and a genuinely useful mental model. There is no magical substance called "cloud." There are real servers, in real buildings, owned by the provider, that you rent and control remotely. Hold on to this — it demystifies almost everything that follows. :::
Virtualization: how one computer becomes many
How can a provider rent you "a server" in seconds when buying a real one takes weeks? The trick is virtualization — software that lets one powerful physical computer pretend to be many smaller, independent computers. Each pretend computer is a virtual machine (VM): it has its own operating system and behaves exactly like a standalone server, but it's really just a slice of a bigger machine, isolated from its neighbors by the virtualization software (the hypervisor).
When you "launch a server" in the cloud, you're almost always getting a VM carved out of a physical host the provider already owns and powered on. That's why it's instant and why it's cheap to give back: nothing was built, a slice was allocated. Virtualization is the foundational technology that makes renting-by-the-second possible.
The three service models: IaaS, PaaS, SaaS
Not all cloud renting happens at the same level. The classic way to organize it is by how much the provider manages for you versus how much you manage yourself. There are three layers, and you'll hear these acronyms constantly.
- IaaS — Infrastructure as a Service. You rent the raw building blocks: virtual machines, virtual disks, virtual networks. The provider keeps the physical hardware and data center running; you install the operating system, the runtime, your app, and you handle patching and scaling. Most control, most responsibility. Example primitive: a bare Linux VM.
- PaaS — Platform as a Service. You rent a platform that runs your code without you managing the servers underneath. You hand it your application; it handles the OS, the runtime, scaling, and patching. Less control, far less to operate. Example: a service where you
git pushyour app and it just runs. - SaaS — Software as a Service. You rent finished software, used through a browser, managing nothing technical at all. Gmail, Dropbox, and Slack are SaaS. As a cloud engineer you mostly build on IaaS and PaaS and consume SaaS.
A standard way to picture the trade-off is the "pizza as a service" analogy: cooking at home (on-prem), take-and-bake (IaaS), delivery (PaaS), and dining out (SaaS) all get you fed, but each hands off more of the work.
Reading left to right, the provider takes over more and more of the stack and you take over less. There is no "best" layer — picking the right one for a given job is a recurring decision you'll make throughout this guide.
:::tip Durable vs dated The IaaS/PaaS/SaaS split is durable — it has organized cloud thinking for fifteen-plus years and isn't going anywhere. The specific products in each layer (which VM family, which PaaS) are dated and get renamed constantly. Learn the layers; treat the product names as examples. :::
The five traits that make something "cloud"
A widely cited definition (originally from the U.S. standards body NIST) says cloud computing has five essential characteristics. They're worth knowing because they're exactly the properties on-prem lacks:
- On-demand self-service — you provision resources yourself, instantly, without filing a ticket and waiting for a human.
- Broad network access — you reach it over the internet, from anywhere, with standard tools.
- Resource pooling — the provider's huge shared pool of hardware serves many customers, each isolated from the others (this is virtualization at scale).
- Rapid elasticity — you can scale up and down quickly, even automatically, to match load.
- Measured service — usage is metered, so you pay only for what you actually consume.
If a thing has all five, it's genuinely "cloud." If a vendor just renames their old hosting as "cloud" but you still wait days for capacity and pay a flat yearly fee, it isn't — it's marketing.
Why it matters
The cloud is rented computing: real servers in real data centers, sliced up by virtualization, provisioned instantly over an API, and billed by usage. The IaaS / PaaS / SaaS ladder tells you how much of the stack you keep versus hand to the provider, and the five traits (self-service, network access, pooling, elasticity, metering) are what separate genuine cloud from rebranded hosting. Every later chapter is a deep dive into one part of this picture — and they all rest on the same mental model: someone else's computers, rented by the second, driven by an API.
The natural next question is: if it's the provider's hardware but your app and data, who is responsible when something goes wrong? That precise division of labor is the single most important security and operations concept in the cloud, and it's the subject of the next lesson.
Where this leads: the IaaS/PaaS/SaaS line you draw decides how much you must operate yourself — it reappears in Core Services and again in every "managed vs self-hosted" decision.