What is serverless?
Serverless is an operating model where the cloud vendor runs the servers for you and you pay per execution instead of per uptime. The servers exist, but they're not your responsibility. Zero traffic costs close to zero and spikes scale automatically. It suits event-driven jobs and APIs with uneven load, with cold starts as a downside.
Serverless comes up everywhere in conversations about modern operations, but the word is confusing – it sounds like servers have disappeared. They haven’t. Here’s what serverless actually means, how the economics work, and when it’s the right choice.
Servers exist – but not as your problem
Serverless is an operating model where the cloud vendor takes care of the servers for you. Your code still runs on real servers somewhere, but you never need to see them, install them, update them, or worry about whether they can handle the traffic.
The name should be read as “serverless for you,” not “without servers.” The difference from traditional operations is who carries the responsibility. With your own server, you (or your vendor) have to keep it alive, secure, and appropriately sized. With serverless, you hand all of that off and just think about your code – the vendor makes sure it runs when called and scales automatically.
That frees the team from an entire category of work. But the real difference shows up in the economics.
The economics: zero traffic costs close to zero
Perhaps the most appealing property of serverless is how you pay. Instead of paying for capacity around the clock, you pay per execution – for what actually happens.
The consequence is striking. A service nobody is using right now costs practically nothing in practice; there’s no server ticking away idle. And when traffic suddenly arrives, maybe in a sharp spike, the platform scales up on its own and handles the load. You pay for that spike, but you skip both keeping expensive capacity on standby and risking the service falling over once there’s real pressure.
| Situation | What it costs |
|---|---|
| No traffic | Close to zero – nothing sits idle costing money |
| Sudden spike | Scales up automatically, you pay for the usage |
| Steady, very high load | Can end up more expensive than a server running around the clock |
The downside sits in the bottom row: under very high and steady traffic, the sum of all the small fees can end up bigger than what running capacity would have cost. Serverless is cheap for the uneven, not automatically for everything.
Typical use cases
Serverless shines brightest where the workload is event-driven or uneven – where capacity would otherwise mostly sit waiting.
- Event-driven jobs. Code that should run when something happens: a file gets uploaded and needs processing, a payment comes in and needs registering, a row gets added and needs forwarding.
- Scheduled tasks. A nightly job that compiles reports or cleans data. It runs once a day – keeping a server running around the clock for that would be wasteful.
- APIs with uneven load. An interface whose traffic varies sharply over the day or week, where you want to avoid guessing capacity in advance.
In all these cases, the match is natural: you pay for work that actually gets done, and you avoid both over-provisioning and under-provisioning.
A note on cold starts
An honest overview has to mention cold starts. When a serverless function has sat unused for a while, it “falls asleep,” and the next call has to wake it up – which adds a small extra delay before the code responds. After that it’s fast again until it rests once more.
For a background job, it doesn’t matter if the start takes a bit extra. But for a service where a person is waiting for a real-time response, that delay on the first call can be noticeable, and it’s worth weighing in. It’s rarely a dealbreaker, but it’s a property worth knowing about.
Altogether, serverless is a powerful tool for the right workload, with economics that reward the uneven. It doesn’t replace traditional servers for everything – it’s a complement that makes some things cheaper and simpler, and others more expensive. Want to know if it suits your services? At Weapp we’re happy to look at the operating model together before you choose a path.
Frequently asked questions
Does serverless mean there are no servers?
No, and the name is a bit misleading. The servers still exist and run your code, but they're the cloud vendor's responsibility, not yours. You never need to install, update, or scale them. The point isn't that the servers disappear, but that they become someone else's problem – you just focus on your code.
How does the economics of serverless work?
You pay per execution instead of for capacity around the clock. If the service sits idle, it costs close to nothing, and when traffic arrives it scales up automatically and you pay for that usage. That makes serverless cheap for things that run rarely or unevenly, and it opens the possibility of costly surprises under very high, steady load.
What does serverless suit best?
Event-driven jobs and workloads with uneven load. A background job that runs when a file is uploaded, a scheduled nightly job, or an API whose traffic varies sharply are typical cases. Where capacity would otherwise mostly sit waiting, serverless shines, because you only pay when something actually happens.
What is a cold start?
A cold start is the delay that occurs when a serverless function wakes up after sitting unused. The first call has to wait a little extra while the code spins up. For a background job it goes unnoticed, but for a service where a user is waiting for a real-time response, that extra delay can be noticeable.
Is serverless always cheaper than regular servers?
No. It's cheap under low or uneven load, but under high and steady traffic, the sum of all the per-execution fees can end up more expensive than a server running constantly. Which one pays off depends on the shape of the load, so it's worth calculating against the actual pattern before choosing.