Express course · No. 25
'The cloud' sounds abstract, but it's just renting someone else's computers instead of buying your own — and paying only for what you use, scaling up and down on demand. Serverless goes further: you stop thinking about the machines at all and just run your code. Learn the words and the cloud stops being a buzzword and becomes a clear set of trade-offs between convenience, control, and cost.
19 concepts · a diagram for each · cheat sheet at the end
Strip away the mystique and the cloud is a simple business idea: use computers you don't own. Everything else is detail about how much of the work the owner does for you.
The map: 19 concepts in six groups
A metro map: first you see the whole set of lines, then you ride station by station.
Every concept in this course falls into one of six groups. Each group answers its own question: what the cloud is at all, how much the provider does for you, how capacity and the bill grow, where your code physically runs, which pieces you can hand to the provider whole, and how to run code with no servers to mind.
How to read this course
A passport: the same fields for everyone, so they're easy to compare.
Every concept gets the same treatment: its English name (remember it — it's the term in AWS, Google Cloud, and Azure docs), a picture from everyday life, a diagram, and a card with fields: what it is, example, catch, and related concepts. The main idea of the course: every cloud buzzword is a point on the scale of "how much someone else does for you" — and the price you pay for it.
Cloud Computing — the cloud is someone else's computers
A taxi instead of buying a car: the vehicle is real and the trip is real, but you don't own, park, insure, or maintain it — you just use it when you need it.
Cloud computing is computers in someone else's data centre that you rent over the internet, instead of buying and running your own. When your app runs "in the cloud," it runs on real, physical machines — they just belong to a provider like Amazon, Google, or Microsoft, who handles the building, the power, the hardware. You get computing power as a service, the way you get electricity, without owning the power plant.
- What it is
Renting someone else's computers over the internet instead of buying your own.
- Example
A website runs on AWS servers: Amazon looks after the building, power, and hardware; you look after your code.
- Catch
The servers haven't gone anywhere — they're just someone else's. You trade ownership for dependence on a provider.
- Related
The base of the whole course; how much the provider does is decided by IaaS / PaaS / SaaS.
CapEx → OpEx — renting instead of buying
You don't build a power station to run your home — you plug into the grid and pay for what you use. Owning the whole plant only makes sense at enormous scale.
Owning servers means buying expensive hardware up front, guessing how much you'll need, and running a room full of machines whether or not you use them. That's capital expenditure (CapEx). Renting flips it: no big upfront cost, no idle hardware, and someone else handles the physical side — that's operating expenditure (OpEx). For almost everyone, that trade — turning a huge upfront purchase into a pay-as-you-go bill — is why the cloud won. You spend money as you use the resource, not years before.
- What it is
Swapping a big upfront hardware purchase (CapEx) for a running bill for usage (OpEx).
- Example
A startup doesn't buy a rack of servers just in case — it pays for a couple of cloud machines while customers are few.
- Catch
At enormous, steady scale your own hardware can come out cheaper — like your own power plant.
- Related
- Made possible by On-demand and Pay-as-you-go.
On-demand — resources in seconds
Turning on a tap and water flows instantly — no waiting weeks for a delivery, no plumbing project. The supply is there the moment you ask.
The defining feature is that resources are on-demand: you can spin up a new server, database, or whole environment in seconds with a few clicks or a line of code, and shut it down just as fast. Compare that to ordering, waiting for, and installing physical hardware. This instant self-service access is what makes the cloud feel less like buying machines and more like turning a tap — capacity whenever you ask for it.
- What it is
Start or stop a resource yourself in seconds — no tickets, no waiting for a delivery.
- Example
Need a test environment for a day — spin it up with a line of code in the morning, delete it in the evening.
- Catch
Just as easy to spin up and forget — hence surprises on the bill (Bill shock).
- Related
- The base for Elasticity and Serverless.
The cloud is renting someone else's computers on demand instead of buying your own. You turn a huge upfront purchase into pay-as-you-go, and get capacity in seconds.
Cloud services come in layers, distinguished by one thing: how much the provider manages versus how much you do. Three initials name the main points on that scale.
Cloud Service Models — the scale of how much they run for you
Getting a meal: rent a kitchen and cook it all yourself, get a kitchen with ingredients prepped, or just order the finished dish delivered. Same dinner, wildly different effort.
Cloud service models sit on a scale from "you manage almost everything" to "you manage almost nothing." At one end you rent raw machines and do the rest; at the other you just use finished software. The famous way to remember it is "pizza as a service" — make it from scratch, take and bake, or have it delivered. The three named layers — IaaS, PaaS, SaaS — are points along that line.
- What it is
The scale of how many layers (from hardware to app) the provider runs, and how many you do.
- Example
Your own server room → IaaS → PaaS → SaaS: each step shrinks what you're responsible for.
- Catch
The more they do for you, the less control you have — convenience is never free.
- Related
Points on the scale: IaaS, PaaS, SaaS; furthest of all — Serverless.
IaaS and PaaS — raw machines or a ready platform
Renting an empty workshop where you install every tool yourself (IaaS), versus a fully-equipped workshop where you just bring your project and start (PaaS).
IaaS (Infrastructure as a Service) rents you raw building blocks — virtual machines, storage, networking — and you install and manage everything on top: maximum control, maximum work. PaaS (Platform as a Service) hands you a ready environment where you just deploy your code and the provider runs the servers, scaling, and patching underneath: less control, far less work. The choice is how much of the plumbing you want to own.
- What it is
Renting virtual machines, disks, and network; the OS, runtime, and app are yours.
- Example
A virtual machine on AWS EC2: you install the software, configure the system, and keep it updated yourself.
- Catch
- Maximum control = maximum work: patching and scaling are on you.
- When to use
- When you need full control over how everything is set up.
- Related
- The bottom of Cloud Service Models; above it — PaaS.
- What it is
A ready platform: you bring code, the provider runs servers, scaling, and patching.
- Example
Push to Heroku or a similar platform — and the app runs, with no servers to configure.
- Catch
Less control: you live by the platform's rules and depend on what it supports.
- When to use
- When you just want to deploy code and not think about machines.
- Related
- Between IaaS and SaaS; a cousin of Managed Service.
SaaS — finished software you just use
You don't grow wheat or bake to get a sandwich at a café — you just order and eat. Someone else did every step before it reached you.
SaaS (Software as a Service) is the far end: finished software you simply use over the internet, with the provider running absolutely everything — Gmail, Slack, your CRM. You manage nothing but your own data and settings. Most software you use daily is SaaS. As a builder you consume SaaS for the parts you don't want to build, and you build on IaaS or PaaS for the parts that are your product. Knowing the layer tells you who's responsible for what.
- What it is
A finished app over the internet; you manage only your data and settings.
- Example
- Gmail, Slack, a CRM — nothing to install or maintain.
- Catch
- Almost no control: the provider decides how the software works.
- When to use
- For everything that isn't your product.
- Related
- The top of Cloud Service Models; the opposite of IaaS.
Cloud layers differ by how much the provider runs for you: IaaS is raw machines you manage, PaaS is a ready platform for your code, SaaS is finished software you just use.
The cloud's superpower is that capacity isn't fixed. It grows and shrinks with your need, and you pay for what you use — which is a gift and, if you're careless, a trap.
Elasticity — up for the spike, down after
A concert venue that could add a thousand seats for the big night and remove them the next morning — capacity that matches the crowd, never wasted on an empty hall.
Elasticity is the cloud's ability to add resources when demand spikes and remove them when it falls. A sale, a viral moment, a busy hour — the cloud spins up more servers to handle it, then scales back down after, so you're not paying for capacity you don't need. With owned hardware you'd have to buy for your busiest moment and let it sit idle the rest of the time. Elasticity matches what you run to what you actually need, minute by minute. The mechanism that does it automatically is called autoscaling.
- What it is
- Capacity grows for a demand spike and shrinks when it passes.
- Example
- During a sale the shop runs on ten servers, at night on two.
- Catch
Scaling with no ceiling can blow up the bill on its own (Bill shock).
- Related
Needs On-demand; paid for through Pay-as-you-go; its extreme form is Scale to Zero.
Pay-as-you-go — a meter, not a purchase
A utility bill: you pay for the electricity you actually used this month, not a flat fee for owning the grid. Use more, pay more; use nothing, pay nothing.
The cloud bills like a utility: pay-as-you-go, charging for the compute, storage, and traffic you actually consume. No upfront purchase, no paying for idle capacity — the meter runs only while you use the resource. This is what makes the cloud accessible: you can start tiny and cheap, and your costs grow with your usage instead of being a huge bet placed before you have any customers. The bill tracks reality.
- What it is
Paying for the compute, storage, and traffic you actually consumed.
- Example
A small project costs pennies while it has few users; traffic grows — the bill grows.
- Catch
- "Pay only for what you use" = "pay for everything you use."
- Related
- The money side of CapEx → OpEx and Elasticity.
Bill Shock — the meter cuts both ways
A taxi meter is fair on a short ride and frightening if you forget it's running for hours — the same per-use pricing that saves you money can quietly run up a fortune.
Pay-as-you-go is a double edge. The same metering that saves you money when usage is low can produce a shocking bill when something runs away — a process left on, a runaway scale-up, a mistake that loops. That surprise is called bill shock. It's common precisely because it's so easy to spin things up and so easy to forget them. Hence the rule: you have to watch the meter — for example with a budget alert that fires when spending crosses a limit.
- What it is
- An unexpectedly huge cloud bill because something ran away.
- Example
A test server left on for a month; a loop in the code calling a paid service over and over.
- How to avoid
Monitor spending like performance; set budget alerts and scaling ceilings.
- Related
The flip side of Pay-as-you-go, On-demand, and Elasticity.
Elasticity scales capacity up for spikes and down after; pay-as-you-go charges only for what you use. The same meter that saves money can run up a shock bill — so watch it.
The cloud isn't one place — it's data centres spread across the world. Where your stuff runs affects both how fast it feels and how well it survives a failure.
Region — compute near the user
A delivery company with warehouses on every continent ships to each customer from the nearest one — faster for everyone than mailing everything from a single hub.
Providers run data centres in regions all over the globe. You choose where your application runs, and putting it in a region near your users cuts latency — the data has less distance to travel, so the app feels faster. A European app served from a European region beats one served from across an ocean. Region choice is the geography lever: place your compute and data close to the people using them.
- What it is
A group of a provider's data centres in one part of the world that you pick for your code.
- Example
- An app for Europeans is deployed in a European region.
- Catch
One region is one place: users on the other side of the world get it slower.
- Related
Inside a region are several Availability Zones; together they give High Availability.
Availability Zone — survive one building failing
A bank keeping copies of its records in several separate buildings — if one floods, the others carry on and nothing is lost.
Within a region are multiple availability zones — physically separate data centres. You run copies of your system across several zones at once. If one zone loses power or fails, the others keep serving, and your app stays up.
- What it is
- A physically separate data centre inside a region.
- Example
App copies in three zones: one loses power — the other two keep working.
- Catch
It only protects you from one building failing if you actually run copies in several zones.
- Related
Part of a Region; a building block of Redundancy / High Availability.
Redundancy and High Availability — near the user, resilient to failure
A shop with branches in every city, and each branch backed by a second nearby — close to customers and tough against any one location going dark.
Redundancy means no single building, machine, or zone is a fatal single point of failure. What you get from it is high availability — staying up through failures that would take down a single location. The two ideas combine into the core of cloud architecture: place compute in regions near your users for speed, and spread across zones for resilience. A global service feels local everywhere and survives the inevitable hardware failure somewhere. You're no longer betting your whole product on one machine in one building — you're spread out by design, which is most of what "the cloud is reliable" actually means.
- What it is
The system stays up through failures because every part has a copy somewhere else.
- Example
A global service: a region in Europe and one in the US, each with copies in two zones.
- Catch
- Copies cost money and add complexity — every copy is on the bill.
- Related
- Built from Region (speed) and Availability Zone (resilience).
Regions put your compute near users to cut latency; availability zones spread it across separate data centres for redundancy — close to people, resilient to any one failure.
Beyond renting machines, the cloud will run whole pieces of infrastructure for you — a database, a queue, a cache — so you can use them without operating them. That convenience is a real trade.
Managed Service — let the provider run the hard parts
A serviced apartment where someone else handles the plumbing, heating, and repairs — you just live there, instead of being your own building superintendent.
A managed service is infrastructure the cloud provider runs for you — a managed database, message queue, or cache — handling the setup, scaling, backups, patching, and failover. You use it through an interface and never touch the machines underneath. Instead of becoming an expert in operating a database reliably at scale, you rent that expertise.
- What it is
A database, queue, or cache the provider sets up, scales, backs up, and patches for you.
- Example
Managed Postgres (for example AWS RDS) instead of your own database on a virtual machine.
- Catch
- Less control and a tie to the provider (Vendor Lock-in).
- Related
Removes Undifferentiated Heavy Lifting; the next step is Serverless.
Undifferentiated Heavy Lifting — less ops, more product
A food truck owner who buys bread from a bakery instead of milling flour — they focus on the meals that are their actual business, not on becoming a baker too.
The point of managed services is focus. Running infrastructure reliably — backups, scaling, security patches, 3am failures — is hard, specialised work, and for most teams it's not their value. This kind of work is called undifferentiated heavy lifting — heavy work that doesn't set you apart from competitors. Every hour not spent keeping a database alive is an hour spent on the thing that's actually your product. Offloading it lets a small team punch far above its weight, building features instead of babysitting servers. This is a huge part of why modern products ship fast with small teams.
- What it is
Hard operational work everyone needs, but that doesn't make your product special.
- Example
Backups, security patches, and 3am database failures — instead of working on features.
- Catch
- If operations are your value, handing them off is a mistake.
- Related
- The reason to pick Managed Service and Serverless.
Vendor Lock-in — convenience versus control
A prepared meal kit is wonderfully convenient — until you want to change one ingredient and find the kit decides the recipe. Convenience is paid for in control.
The trade is real: a managed service gives up some control and ties you to that provider's way of doing things. The more deeply you adopt their specific services, the harder and costlier it is to leave. That's vendor lock-in. You're choosing convenience and speed now against flexibility and independence later. Often it's the right call — but make it knowingly, keeping the truly critical pieces swappable. It's the same judgement as choosing between a managed API and self-hosting.
- What it is
The deeper you are in one provider's services, the costlier it is to leave.
- Example
The app is wired to the provider's unique APIs — moving means a rewrite.
- How to live with it
Accept lock-in knowingly; keep the truly critical pieces portable.
- Related
- The price of Managed Service and Serverless.
Managed services let the provider run the database, queue, or cache, so you focus on your product instead of operations. The trade is less control and some vendor lock-in.
The furthest step of "don't manage the machines" is serverless: you provide just your code, and the cloud runs it on demand, scaling and billing per request. It's powerful for the right shape of work.
Serverless — just your code, no servers to mind
A meeting room you book by the half-hour: you don't own it, heat it, or clean it — you just show up, use it, and it's gone from your mind the moment you leave.
Serverless lets you run code without managing any servers at all. You hand the provider a function — a small piece of code — and it runs that function whenever an event triggers it: a request, a file upload, a schedule. It handles all the machines, scaling, and capacity invisibly. This flavour is also called FaaS (Function as a Service). There are still servers, of course; you just never think about them. It's the logical end of the cloud journey: from owning machines, to renting them, to not even being aware of them.
- What it is
You hand over a function; the provider runs it on every event and manages all the machines.
- Example
An AWS Lambda function compresses an image every time a user uploads one.
- Catch
Cold Start, a poor fit for long steady work, and lock-in to the provider.
- When to use
- Short event-driven tasks, bursty load.
- Related
The far end of Cloud Service Models; it scales to zero (Scale to Zero).
Scale to Zero — zero requests, zero cost
A motion-sensor light: off and costing nothing when the room is empty, instantly on the moment someone enters. You pay for the light only while it's actually lit.
Serverless scales to zero: when no one is using your function, nothing runs and you pay nothing; when requests pour in, it spins up as many copies as needed automatically. You're billed per request and per fraction of a second of compute, not for an idle server waiting around. This is ideal for spiky, occasional, or unpredictable work — you get effortless scaling and pay nothing during the quiet, which a constantly-running server can't match.
- What it is
With no requests nothing runs and the bill is zero; under a rush, copies start on their own.
- Example
An internal report called a couple of times a day costs almost nothing.
- Catch
After a quiet spell, the first request waits for startup (Cold Start).
- Related
- The extreme form of Elasticity and Pay-as-you-go.
Cold Start — the price of nothing running
That motion-sensor light has a tiny flicker of delay as it switches on — fine for a hallway, annoying if you needed instant, constant brightness.
Serverless isn't free of trade-offs. A function that's been idle has a cold start — a brief delay while the provider spins it up — which can hurt latency-sensitive work. It fits short, event-driven tasks better than long-running or steady high-traffic ones, where a constantly-running server can be simpler and cheaper. And it leans on provider-specific services, so lock-in applies. Serverless is a sharp tool for the right job — bursty, event-driven, scale-to-zero work — not a universal default.
- What it is
The delay on the first request while the provider wakes an idle function.
- Example
A rarely used function answers its first request noticeably slower than the next ones.
- How to live with it
For latency-sensitive work or steady traffic, use a constantly-running server.
- Related
- The price of Scale to Zero in Serverless.
Serverless runs just your code, scaling to zero and billing per request — ideal for bursty, event-driven work. Watch for cold starts and lock-in; it's a sharp tool, not a default.
The cloud is a toolbox of trade-offs, not a single right answer. Using it well is matching each piece to the model that fits, and staying aware of the two things that bite: the bill and lock-in.
Match the model to the need
You don't use a delivery truck for the school run or a bicycle for a house move — you pick the vehicle that fits the trip, not one default for everything.
There's no single right layer. Use SaaS for capabilities that aren't your product, managed services to offload undifferentiated heavy lifting, serverless for bursty event-driven work, and raw machines (IaaS) when you need full control. The skill is matching each part of your system to the model that fits its needs — control where it matters, convenience where it doesn't. A good cloud architecture is usually a deliberate mix, not one model applied everywhere.
Watch the bill and beware lock-in
Renting is freeing until you stop reading the statements — and the most comfortable rental is the one designed so you can never move out.
Two things consistently bite cloud users. First, the bill: easy on-demand resources mean costs can creep or spike unnoticed (bill shock), so you monitor spending the way you monitor performance. Second, lock-in: the deeper you wire into one provider's unique services, the harder and costlier it is to leave. Neither means avoid the cloud — they mean use it with eyes open: track the meter, and keep your genuinely critical, portable pieces from becoming permanently welded to one vendor.
How it all connects
A jigsaw: each piece means little alone; together they make the picture.
The concepts in this course are one system. Cloud computing is renting instead of owning. Three branches grow from it. The first is money: on-demand enables elasticity, which is paid for through pay-as-you-go, and the meter has a dark side — bill shock. The second is how much is done for you: IaaS → PaaS → SaaS, managed services, and serverless, which scales to zero at the cost of cold starts and vendor lock-in. The third is where things run: region, availability zones, and together — high availability.
- Rent or own — does on-demand, pay-as-you-go fit better than buying hardware?
- Which model per piece — IaaS, PaaS, SaaS, serverless — for the control you need?
- Does it scale elastically with demand, up for spikes and down after?
- Region and zones — compute near users, spread for resilience?
- Managed or self-run — is operating this part actually your value?
- The bill and lock-in — am I monitoring spend and keeping critical pieces portable?
- You rent on demand and pay for use instead of buying for your busiest hour.
- Each piece uses the model that fits — from raw machines to serverless.
- Your system scales elastically and runs in regions near users, spread across zones.
- You offload undifferentiated work to managed services and focus on your product.
- You monitor the bill and keep critical pieces portable against lock-in.
Cheat sheet: all 19 concepts
Rented computers
- Cloud Computingthe cloud
Renting someone else's computers over the internet instead of buying your own.
- CapEx → OpExrent instead of buy
A huge upfront hardware purchase becomes a pay-as-you-go bill.
- On-demandself-service
Start or stop a resource yourself, in seconds.
Service models
- Cloud Service Modelspizza as a service
The scale of how many layers the provider runs, and how many you do.
- IaaSInfrastructure as a Service
Raw virtual machines, disks, and network; everything on top is yours.
- PaaSPlatform as a Service
A ready platform: you bring code, the provider runs the servers.
- SaaSSoftware as a Service
Finished software; you manage only your data and settings.
Elasticity and money
- Elasticityautoscaling
Capacity grows for a spike and shrinks after.
- Pay-as-you-gousage-based billing
You pay for the compute, storage, and traffic you actually consume.
- Bill Shocksurprise bill
An unexpectedly huge bill when something runs away. Cured by monitoring spend.
Where it runs
- Regionlatency
Data centres in one part of the world; closer to users means lower latency.
- Availability ZoneAZ
A separate data centre in a region; copies across zones survive a failure.
- High Availabilityredundancy
No single point of failure: the system stays up through failures.
Managed services
- Managed Servicemanaged DB, queue, cache
A database, queue, or cache the provider runs for you.
- Undifferentiated Heavy Liftingops that don't set you apart
Hard operations that don't make your product special — worth handing off.
- Vendor Lock-inprovider lock-in
The deeper you are in one provider's services, the costlier it is to leave.
Serverless
- ServerlessFaaS
Just your code; the provider runs it on every event.
- Scale to Zeroper-request billing
No requests — nothing runs and nothing is billed.
- Cold Startstartup delay
The delay on the first request while a function starts after being idle.
The cloud is renting compute on demand, in layers from raw machines to serverless. Use it well by matching each piece to the right model — and keeping an eye on the bill and lock-in.