Serverless or traditional servers?
Serverless means you pay per call and skip managing servers, while traditional hosting means paying for capacity around the clock. Serverless wins for uneven or low load; traditional hosting wins for high, steady load. Weigh in cold starts and vendor lock-in before you choose a hosting model.
Serverless versus traditional hosting is fundamentally a question of how you pay for, and take responsibility for, computing power. Behind the technical terms sits a simple fork in the road: rent capacity each time you need it, or keep capacity running and pay for it. Here’s the comparison in terms of cost and responsibility.
The two models
Traditional hosting means you have servers – your own or rented in the cloud – running around the clock. You pay for the capacity whether it’s used or not, and you (or your vendor) are responsible for installing, scaling, and maintaining them. You get full control and full predictability, but also full responsibility.
Serverless flips that around. The cloud provider manages the servers, your code only runs when it’s called, and you pay per execution. The servers still exist – “serverless” is partly a misleading label – but they’re not your problem. You skip operations and scaling, in exchange for giving up some control.
The difference in responsibility is half the story. The other half is the economics, and that’s where it gets concrete.
The economics: pay per call vs. pay for capacity
The core idea is simple. Serverless is pay-per-call: when the service sits idle it costs close to nothing, and at a peak it scales up automatically and you pay for just that traffic. Traditional hosting is pay-for-capacity: the server costs the same around the clock, whether it handles a thousand calls or none at all.
Which one is cheapest is decided by the shape of the load. Two worked examples make it clear:
- Uneven load. An internal reporting service that runs a few times a day. Serverless only costs for those runs – in practice, pocket change. A server running around the clock for the same job means paying for 24 hours to use it for minutes.
- Steady, high load. A popular API that receives millions of calls a day, evenly spread out. Here the sum of all the per-call fees can exceed what a handful of servers running constantly would have cost. With predictable, heavy load, capacity you keep running often wins.
| Load profile | Usually cheapest |
|---|---|
| Low or uneven (bursty, infrequent) | Serverless |
| High and steady (constant traffic) | Traditional hosting |
| Unpredictable with sharp peaks | Serverless (scales automatically) |
The downsides of serverless: cold starts and lock-in
Serverless sounds almost too good in the uneven case, so it’s worth being honest about the price.
Cold starts. When a function has sat unused, it has to start up on the next call, and that first execution gets a delay. For a background job it doesn’t matter. But for a user-facing service where response time is felt immediately, that extra delay on the first call can be a real annoyance.
Vendor lock-in. Serverless services are often tightly woven into a specific cloud provider’s way of working. If you build a lot of your logic that way, you become dependent on that particular platform, and moving later becomes a bigger project. It’s manageable, but it’s a commitment to enter with your eyes open.
Which workloads belong where
Roughly speaking: serverless suits the event-driven and the uneven. Background jobs, scheduled tasks, APIs with sporadic or heavily varying traffic, and new services where you don’t know the volume yet – all of that thrives in a model that costs based on usage and scales on its own.
Traditional hosting suits the heavy and steady. Services that run constantly, that are sensitive to the slightest delay, or where you want full control and a completely predictable monthly cost, belong on capacity you keep running. It’s also entirely possible to mix the two – running a steady core traditionally and putting bursty jobs on serverless.
So there’s no universally right answer, just a fit against how your system is actually loaded. If you’d like help reading your load profile and working out what it means for the bill, we at Weapp are happy to look at the hosting choice together before you lock in a model.
Frequently asked questions
What does 'serverless' actually mean?
Serverless doesn't mean there are no servers – it means the cloud provider manages them for you. Your code only runs when it's called, and you pay per execution instead of for uptime. The servers still exist, but they're not your responsibility – you skip installing, scaling, and maintaining them.
When does serverless become cheaper than traditional hosting?
When the load is uneven or low. If you pay per call, a service that's mostly used in bursts costs almost nothing when idle, and scales automatically at peaks. A traditional server is billed around the clock whether anyone uses it or not, which gets expensive for rarely used workloads.
When does traditional hosting win instead?
With high, steady load. When a service is used constantly and heavily, the fixed cost of a server running around the clock can be lower than paying per call for millions of calls. With predictable, heavy load, capacity you own is often more economical than capacity you rent each time.
What are cold starts and why do they matter?
A cold start is the delay when a serverless function starts up from idle after sitting unused. The first call can take noticeably longer before the code responds. For background jobs it doesn't matter, but for a service where every millisecond is felt by the user, it can be a real problem.
What does vendor lock-in mean with serverless?
Serverless services are often tightly bound to a specific cloud provider's way of working. If you build a lot of logic that way, it becomes harder and more expensive to move to another provider later. It's not disqualifying, but it's a risk to weigh before you build heavily on a single platform.