For a long time “serverless” was a word I nodded at in meetings without really holding anything behind it. It sounds like there are no servers, which can’t be right, because something has to run the code. So I left it vague, the way you do with words that feel like they’d take an afternoon to unpack.
It did take an afternoon. Here’s the version I wish someone had given me.
What “serverless” actually means
There are still servers. You just never touch them. You don’t pick a machine size, you don’t patch the operating system, you don’t keep anything running and waiting. You hand AWS your code, and it runs that code only when something calls it, then goes quiet again.
Two things follow from that, and they’re the whole appeal:
- You pay for what runs, not for what waits. If nobody uses your thing at 3am, it costs nothing at 3am. No idle machine ticking up a bill.
- It scales without you. One request or ten thousand, AWS just runs more copies of your function. You didn’t plan for the traffic; it handled itself.
Plain version: you stop renting a kitchen that’s always on, and start paying per dish, cooked only when someone orders.
The smallest real thing I could picture
Abstract definitions never stick for me, so I went looking for the smallest complete thing you could actually build serverless. A contact form turned out to be perfect: someone fills it in, you save the message. Tiny, but it touches every piece.
Walking it left to right:
- S3 holds the actual web page, the HTML, CSS, and a bit of JavaScript. No server is “serving” it; it’s just files sitting in storage that the browser downloads. (This is the part that first broke my brain: a website with no web server.)
- API Gateway is the front door for the form submission. The browser sends the message here over HTTPS, and Gateway checks it’s allowed and passes it on. I’d met this one before; it’s the same front desk from the last post.
- Lambda is the little bit of logic in the middle. It wakes up only when API Gateway calls it, takes the form data, tidies it up, and writes it somewhere. When it’s done, it disappears again.
- DynamoDB is where the message lands and stays. It’s a managed database you also never run, you just read and write to it, and AWS keeps it alive and scaled.
That’s the whole thing. Nothing is “on” between visitors. The first form submission of the day spins Lambda up from cold; the rest reuse it; overnight it all costs essentially nothing.
What clicked for me
The shift wasn’t the individual services, it was realizing the shape of a serverless app is just “a front door, a small function, and somewhere to put the data,” with no machine humming underneath holding it all together. Once I saw that shape, half the architectures I’d been nodding at in discovery suddenly had a skeleton I could trace.
It also reframed cost in a way my sales brain liked. For a small or bursty workload, serverless is often the honest answer: the customer pays for usage, not for a server sitting idle most of the day. That’s a real thing to be able to say in a conversation, not just a buzzword to drop.
Quick reference, for future me
| Piece | What it does | Plain version |
|---|---|---|
| S3 | Stores the static page files | A folder the browser downloads from |
| API Gateway | Receives the form request | The front desk |
| Lambda | Runs the logic on demand | A cook who only shows up per order |
| DynamoDB | Stores the submitted messages | The notebook it all gets written into |
Same honest caveat as always: I’ve traced this end to end and stood up the small pieces, but I haven’t run a real one in front of users yet. The picture in my head just got a lot more specific, though, and that’s exactly the direction I want it moving.