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.
Essence only · One picture per idea · Learn the words
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 cloud is just 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.
The cloud 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.
Renting beats buying for most people
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. Renting flips that: no big upfront cost, no idle hardware, and someone else handles the physical side. 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.
On-demand: get 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.
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 spectrum.
The spectrum: 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 offerings sit on a spectrum 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.
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.
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.
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: scale 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.
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.
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. Cloud cost surprises are common precisely because it's so easy to spin things up and so easy to forget them. The flip side of "pay only for what you use" is "you pay for everything you use" — so you have to watch the meter.
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.
Regions put compute around the world
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.
Availability zones survive a failure
A bank keeping copies of its records in several separate buildings — if one floods, the others carry on and nothing is lost. Redundancy is the whole point.
Within a region are multiple availability zones — physically separate data centres — so you can run copies of your system across them. If one zone loses power or fails, the others keep serving, and your app stays up. This is redundancy: no single building, machine, or zone is a fatal single point of failure. Spreading across zones is how cloud systems achieve high availability — staying up through failures that would take down a single location.
Near the user, and 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.
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. Together they let a global service feel local everywhere and survive 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.
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.
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. The provider does the unglamorous, hard operational work, and you get the capability ready to use.
Less ops, more focus on your 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: every hour not spent keeping a database alive is an hour spent on the thing that's actually your product. Running infrastructure reliably — backups, scaling, security patches, 3am failures — is hard, specialised work, and for most teams it's not their value. Offloading it to the provider 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.
Convenience versus control and lock-in
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 — and the more deeply you adopt their specific services, the harder it is to leave, which is 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, the same judgement as choosing between a managed API and self-hosting.
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 it's triggered, handling all the machines, scaling, and capacity invisibly. 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.
It scales to zero and bills per request
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.
The trade-offs: cold starts and fit
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.
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 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, 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.
- 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?
- cloud / on-demand — renting someone else's computers, available in seconds. - IaaS / PaaS / SaaS — raw machines, a ready platform, finished software. - elasticity / pay-as-you-go — scaling with demand, and billing for what you use. - region / availability zone / redundancy / availability — placement for speed and surviving failure. - managed service — infrastructure the provider runs for you. - serverless / scale to zero / cold start — just your code, on demand, with a startup delay. - vendor lock-in — the cost of being tied to one provider's specific services.
- 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.
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.