Serverless Explained: You Still Have Servers (Sorry)

"Serverless" is one of tech's most misleading names. There are absolutely still servers. What's gone is your need to think about them. Here's what it actually means and when it's the right call.

The real definition

With traditional hosting, you rent a server (or a virtual one), keep it running 24/7, and maintain it — patching, scaling, paying whether it's busy or idle. Serverless flips this: you just upload your code as functions, and the cloud provider runs them on demand, automatically scaling up and down, with no server for you to manage.

The billing is the magic

This is the headline benefit: you pay only when your code runs, often down to the millisecond. An idle traditional server still bills you; an idle serverless function costs nothing. For spiky or low-traffic workloads, that can be dramatically cheaper.

Traditional servers are like renting a car for the month; serverless is paying only for the minutes you actually drive.

Where serverless shines

• Spiky or unpredictable traffic. It scales to zero when quiet and up automatically when busy.
• Event-driven tasks. "When a file is uploaded, resize it." "When a form is submitted, send an email."
• Small APIs and glue code you don't want to babysit a server for.
• Fast starts for small teams — no infrastructure to set up.

Where it stings

• Cold starts. A function that hasn't run lately takes a moment to wake up, adding latency to that first call.
• Constant heavy traffic. If something runs non-stop, a regular server can be cheaper than per-invocation billing.
• Long-running jobs. Functions have time limits; big batch work may not fit.
• Vendor lock-in. Each provider's serverless flavour is a little different.

The takeaway

Serverless is brilliant for event-driven, spiky, or small workloads where you'd rather not run a server. For steady, heavy traffic, a traditional or cloud server may still win. Increasingly, serverless runs at the edge too, executing your code close to users for speed.