Cloud building blocks: compute, storage and network
Monday, 9:00: StayHub's first cloud bill since the Singapore region opened is €130,000, up from €96,000, while guests grew 8%. Karim wants to know where €32,000 went.
Every cloud sells the same handful of building blocks under different names. Learn the blocks once and you can build on any cloud.
- Problem
You need to run a hotel booking app: code that serves requests, a database, millions of hotel photos, nightly reports, and a network connecting them, without buying hardware.
- Why the simple system fails
Treating the cloud as 'rent a server and put everything on it' recreates a single fragile machine: photos fill the disk, the database dies with the VM, and you pay for idle capacity around the clock.
- Engineering concept
Decompose the system into compute, storage and network primitives, and pick for each piece the level of abstraction (raw VM, container, function, managed service) that matches its workload.
- Technology
Virtual machines, container platforms, functions; block, file and object storage; managed relational and NoSQL databases; virtual networks and load balancers. On AWS, Azure and GCP under different names.
- Trade-offs
Higher abstraction means less operational work and faster scaling, but less control, more provider-specific behaviour, and cost curves that can flip at high, steady load.
The problem
2 min- Karim · CTO€130,000 this month. Last month €96,000. Guests grew 8%. Singapore doesn't explain €32,000.
- Omar · On-call SRENo single huge line. Lots of VMs, fast disks, and a big serverless line.
- Lina · Senior engineer, your mentorGuess first; then we read the bill by building block.
The big idea
4 minMatch each workload's shape to the building block that's priced for it.
Nobody was careless: each choice made sense to whoever made it. Steady → always on. Bursty or nightly → scale to zero. Bytes users download → object storage behind a CDN.
How it works
5 min- 1Compute: three shapes
A is a whole computer rented by the hour, busy or not. A is your app in a standard box on managed machines. A function runs only when called, billed per call: great for spiky load, a premium on every call when load never stops.
- 2Storage: block and file
Block storage is one machine's disk: fast, editable, gone or copied per machine. File storage is a shared network folder.
- 3Storage: object
keeps whole files fetched by name over HTTP, one durable copy for everyone, practically unlimited. Photos, backups, exports.
- 4Network
A private network, and a move the bytes. StayHub's network side was fine this month.
- 5Managed services on top
A (or queue, or load balancer) is run by the provider: you set options, they handle servers, patches and failover mechanics. You still own schema, sizing and restore tests.
Watch a decision being made
4 minLina cuts €29,000 from the bill
About €32,000 of a €130,000 bill is unexplained. Find the waste without slowing anything for guests.
- 1Group the bill by building block
Cost tags per service, sorted by VM, disk, function, storage. Three lines stand out: report VMs €14,000, Singapore block disks €9,000, ranking functions €9,000.
Why: Sorted by team, mismatches hide. Sorted by block, they show where pricing and workload disagree.
- 2Describe each workload's shape
Report: 1.5 h a night, idle otherwise (about 6% useful). Photos: shared files, copied onto 20 VMs' 2 TB disks. Ranking: ~500 calls/s, never idle.
Why: The shape decides the block, not the technology people like.
- 3Pick the block that fits, and estimate
Report → scheduled job on VMs created for the run and deleted after: ~€1,000. Photos → the existing object storage + CDN: €0. Ranking → autoscaled always-on VMs: ~€2,000.
Why: An estimate shows which move to do first and guards against moves that save nothing.
- 4Check guests didn't pay for it
Compare ranking p95 and report finish time before and after; review the bill by block next month.
Why: A cheaper setup that slows search isn't a saving.
In real life
3 minNetflix: runs its services on AWS
- Has publicly described running its streaming services and backend on AWS
- Uses managed blocks to scale with demand
- Pays a premium for not owning data centres
Fits when demand swings and speed of change matters most.
Dropbox: storage on its own hardware
- Has publicly described moving most user files from Amazon S3 to its own system
- Storage is its core product, huge and steady
- Needed a large team to build and run it
Fits when one huge, steady workload is the business itself.
What goes wrong
3 minScale-in and redeploys replace instances; other instances can't see the files.
Pre-signed uploads straight to object storage, served by the CDN; instances stay disposable.
You pay 24 hours for 1.5 hours of work.
Scheduled jobs that exist only while running.
Pay-per-call is a premium on every request when there's never idle time.
Containers or VMs for steady load.
Trade-offs
3 min| Block | Fits | You pay |
|---|---|---|
| Virtual machines | OS-level control; steady load | Patching; idle capacity is easy to buy |
| Containers on a managed platform | Most web services and APIs | A platform to learn; idle replicas |
| Serverless functions | Spiky, event-driven, low-volume work | Cold starts; expensive at steady volume |
| Managed database | Almost always, until you have the expertise | A premium; fewer versions and extensions |
- Karim · CTOManaged PostgreSQL is €11,000 a month. Plain VMs: about €6,500. Let's run it ourselves.
- Omar · On-call SREThen backups, patching, failover and 3 a.m. disk alarms are ours. Nobody here has run Postgres failover in production.
- Karim · CTO€54,000 a year buys a lot of learning.
Your job as tech lead
4 minClaude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.
- Which compute block each workload gets, by shape: steady ranking → always-on VMs, the nightly report → a scheduled job, bursty thumbnails → functions.
- Where every file lives: uploads and photos in object storage behind the CDN, never on an instance's disk.
- How much monthly cost a change may add before it needs your sign-off.
Move StayHub's nightly partner report off the 18 always-on report VMs onto a scheduled job: our setup scripts create VMs at 01:00, the job runs, the VMs are deleted. Keep the output identical: same files, bucket and names. Don't touch the managed PostgreSQL or search ranking. Read from the read replica. Nothing on local disk except temp files. First show a plan: changed files, the schedule, what happens if a run fails halfway, and monthly cost before (about €14,000) and after. Then run it once in staging.
- The staging output matches last night's: same files, bucket and row counts.
- No local paths like
/var/app/uploadsfor anything that must survive the run. - The cost estimate is line by line (compute hours × price), against the €14,000 it replaces.
- It saves uploads or generated files on the instance's disk "for now".
- It moves a never-idle service to functions because they're "pay per use".
- It reports a saving it never calculated, or says "done" without running the job once.
Check yourself
2 min/var/app/uploads on whichever app instance handled the upload. What's the right fix?Next episode: a security scan finds StayHub's bookings database answering on a public IP address, and you have to work out how it got one.
Mark it complete to update your skill map.
Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Interactive simulation, Visual diagram, Analogy, Check your understanding, Practice ladder, Explain it yourself.
Technical deep dive
Lina cuts €29,000 from the bill
The monthly bill is €130,000 and about €32,000 of it is unexplained. Find the waste and fix it without slowing anything down for guests.
- 1Group the bill by building block
Use cost tags per service and sort by VM, block disk, function, object storage, database, network. Three lines stand out: report VMs (€14,000), Singapore block disks (€9,000), ranking functions (€9,000).
Why: Bills sorted by team hide mismatches. Sorted by block, they show where a pricing model and a workload disagree.
- 2Describe each workload's shape
Report: 1.5 h a night, idle the rest. Photos: shared files read by everyone. Ranking: ~500 calls/s on average, never idle.
Why: The shape (steady, bursty, nightly, shared) is what decides the right block, not the technology people like.
- 3Pick the block that fits
Report → a scheduled job on VMs created for the run and deleted after. Photos → the existing object storage + CDN; delete the disk copies. Ranking → always-on VMs with autoscaling.
Why: Scale-to-zero for nightly work, always-on for steady work, one shared copy for shared bytes.
- 4Estimate before moving
Report: €14,000 → about €1,000. Disks: €9,000 → €0. Ranking: €9,000 → about €2,000. Total saving about €29,000 a month.
Why: A rough estimate tells you which move is worth doing first (the report) and guards against moves that save nothing.
- 5Check guests didn't pay for it
Compare ranking p95 and report finish time before and after; review the bill by block next month.
Why: A cheaper setup that slows search isn't a saving. Measuring both money and speed proves the move.
| Block | File | Object | |
|---|---|---|---|
| Accessed as | A disk with a filesystem | A network folder | HTTP: PUT/GET by key |
| Shared by | One VM at a time (usually) | Many machines | Anyone with permission, anywhere |
| Latency | Sub-ms to low ms | Low ms | Tens of ms per request |
| Edit in place | Yes | Yes | No: replace the whole object |
| Typical use | OS disks, self-run databases | Legacy shared folders | Photos, backups, logs, exports |
Interactive simulation
Visual diagram
A hotel booking app built from generic cloud blocks. Each node notes the AWS / Azure / GCP equivalents.
Analogy
- Running a kitchenRenting an empty kitchenCloud building blocksA virtual machine
- Running a kitchenA shared kitchen; you bring recipesCloud building blocksContainers on a managed platform
- Running a kitchenA caterer, paid per dishCloud building blocksServerless functions
- Running a kitchenYour own fridge, bolted inCloud building blocksBlock storage
- Running a kitchenA warehouse of labelled cratesCloud building blocksObject storage
- Running a kitchenA pantry service that stocks and insuresCloud building blocksA managed database
Where the analogy breaks: you can't rent a kitchen for three seconds. In the cloud you can, which is why paying per use is so tempting for small or bursty jobs.
Check your understanding
Practice ladder
How much do the photos weigh?
Estimation Warm-upStayHub lists 6,000 hotels, each with 40 photos, stored in 3 sizes averaging 500 KB per stored file.
- How many GB is that?
- With illustrative prices of €0.02 per GB-month for object storage and €0.17 per GB-month for fast block disks, what does one copy cost per month in each?
- Singapore had a copy on each of 20 VM disks. What did that cost compared with one object-storage copy?
Finish Lina's block table
Design PracticeLina's table matches StayHub workloads to building blocks. Two rows are blank. Fill in the block and a one-line reason.
| Workload | Shape | Block | Why |
|---|---|---|---|
| Booking API | Steady, 200–900 req/s | Always-on VMs, autoscaled | Always busy; stateless replicas |
| Nightly report | 1.5 h a night | Scheduled job on VMs created for the run | Exists only while running |
| Thumbnails for uploads | ~2,000 uploads a day, in bursts | ___ | ___ |
| Bookings and payments data | Queried, transactional | ___ | ___ |
| Hotel photos | Shared files, read worldwide | Object storage + CDN | One copy, served near guests |
Where should invoice PDFs run?
Design PracticeEvery night, StayHub must generate about 6,000 invoice PDFs for partner hotels (one per hotel) and keep them for 10 years.
- Each PDF takes about 1 s of CPU.
- It must finish within 2 hours and retry failures.
- Nothing runs during the day.
- Hotels download their invoices from the extranet whenever they like.
Choose the compute, the storage and how hotels download the files. Estimate how many parallel workers you need.
Functions or containers for price alerts?
Decision StretchMaya wants a new feature: guests watch a hotel, and get a push notification when its price drops. Hotels' price updates arrive as events:
- On a normal day about 2 million price events, but 90% arrive between 06:00 and 08:00 when partner systems sync; the rest of the day is nearly idle.
- Each event takes about 30 ms to check against watchers.
- A notification can arrive a few minutes late.
Options: A, serverless functions triggered by the events; B, containers running all day, autoscaled.
Write a short decision: "We chose X over Y because…, accepting the risk of…".
Explain it yourself
Explain to a new teammate why the booking API runs on always-on, autoscaled machines, thumbnails run in functions, photos live in object storage, and bookings live in a managed database.