You trigger a function. It runs for 340 milliseconds. You get a bill for $0.0000021. No server hums in a rack somewhere with your name on it. That's the pitch, anyway — and it's a genuinely good pitch. It's also the reason I once spent an entire weekend chasing a timeout error that turned out to be a 15-minute hard ceiling nobody had told me about.
Serverless computing benefits and limitations aren't a tidy list you can absorb in five minutes. The benefits are real, but they're conditional. The limitations are real too, and they bite hardest exactly when your project starts succeeding. Let me walk you through what I've learned from shipping serverless workloads in production, including the parts that went badly.
Key Takeaways
- Serverless means the cloud provider manages provisioning, scaling, and patching — you manage code and configuration only.
- You pay per invocation and per compute duration, which makes idle workloads nearly free but can make steady high-volume traffic surprisingly expensive.
- Cold starts are the most common practical complaint, and their severity depends heavily on runtime, package size, and language.
- Execution timeouts create hard architectural limits. AWS Lambda caps a single invocation at 15 minutes, and that ceiling shapes what you can build.
- Serverless shines for event-driven, bursty, or unpredictable workloads. It struggles with long-running processes and predictable, constant load.
- Debugging distributed serverless systems is genuinely harder than debugging a monolith, and I say that as someone who prefers serverless.
What "serverless" actually means (and why the word is misleading)
The name is a lie, and everyone in the industry knows it. There are servers. Thousands of them. You just never see them, never patch them, and never get paged at 3 a.m. because one of them ran out of disk.
What you actually get is a contract: the provider handles infrastructure, and you handle logic. Concretely, that means no capacity planning, no operating system updates, no load balancer configuration. You write a function, attach a trigger, and the platform decides how many copies to run and where.
FaaS is only one shape of serverless
Most discussions collapse serverless into Functions-as-a-Service — AWS Lambda, Azure Functions, Google Cloud Functions, Cloudflare Workers. That's the most visible form, but it isn't the only one. Managed queues, object storage with event triggers, and managed database tiers all share the same core property: you don't manage the underlying machine.
This distinction matters because the limitations differ by shape. A function has a timeout. A managed queue doesn't. If you only think in functions, you'll assume serverless can't do something it can actually do perfectly well.
Execution is event-driven by default
An HTTP request arrives. A file lands in a bucket. A message shows up in a queue. Something triggers your code, it runs, it finishes, it disappears. There is no persistent process waiting around between requests.
That statelessness is the source of both the elegance and the pain. Because nothing persists, scaling is trivial — the platform just spins up more isolated copies. Because nothing persists, you can't keep anything in memory between invocations, and you end up bolting on external state stores for things a single long-running process would have handled for free.
The serverless benefits that actually hold up under scrutiny
Not every advertised benefit survives contact with production. These are the ones I've found to be real, consistently, across different projects.
The billing model is transformative for idle workloads
If your service sits idle 90% of the time, serverless is close to free. I ran an internal tool handling maybe 4,000 requests a month and the bill was under a dollar. The equivalent always-on container would have cost me somewhere in the region of $15 to $20 a month just to exist.
That gap is the whole argument. You stop paying for capacity you reserved but didn't use. For internal tools, webhooks, scheduled jobs, and low-traffic APIs, the economics are almost embarrassing for the alternative.
Scaling stops being your problem
A project I worked on got mentioned in a moderately popular newsletter. Traffic went from roughly 200 requests an hour to something like 40,000 in a single afternoon. Nothing broke. Nobody was paged. I found out because I looked at the dashboard out of curiosity.
That's the benefit people undersell. It isn't that serverless scales higher than a well-tuned cluster — it does, but so can a cluster. It's that scaling requires zero human intervention at the moment it matters, which is usually the moment you're least prepared.
Operational burden drops meaningfully
- No OS patching, ever
- No capacity planning meetings
- No idle-instance monitoring
- Runtime updates handled by the provider, sometimes whether you want them or not
- Fewer credentials to rotate, because there are fewer machines
That last point is easy to overlook. Every server you don't own is a set of access keys you don't have to manage.
The limitations that bite, and when
Here's the thing about serverless limitations: they're mostly invisible until your workload changes shape. Then they arrive all at once.
Cold starts are a real tax, and the size varies wildly
When no instance of your function is warm, the platform has to initialize one. That initialization takes time — and the time depends on the runtime, the size of your deployment package, and how many dependencies you've dragged along.
A lean function in a compiled language might cold-start in tens of milliseconds. A function carrying a large framework and a pile of libraries can take over a second. That second lands on a real user, at the worst possible moment, because cold starts happen when traffic is lowest and then again when it suddenly spikes.
I'll admit I underestimated this. My first serverless API felt instant in testing. Then a colleague in another region reported the first request of the morning felt sluggish. It wasn't the network. It was a cold start, and I'd never measured for it.
Execution timeouts are hard walls, not soft limits
AWS Lambda terminates a function at 15 minutes. Azure Functions and Google Cloud Functions have their own ceilings. This isn't a configuration you can raise — it's the architecture.
Anything genuinely long-running has to be restructured. Large file processing, video transcoding, multi-step data pipelines: you break them into chunks, chain them, and stitch the results together. Doable. But you're now writing orchestration logic that a single long-running process would have handled with a simple loop, and orchestration logic is where bugs live.
Costs can invert at scale
The per-invocation model stops being cheap once your traffic becomes steady and heavy. A function running continuously under high load can cost more than a reserved instance doing the same work, sometimes substantially more.
| Workload pattern | Serverless fit | Why |
|---|---|---|
| Sporadic internal tool | Excellent | Idle time costs nothing |
| Bursty public API | Strong | Scales without intervention |
| Event processing pipeline | Good, with orchestration | Chunking required for long jobs |
| Constant high-volume service | Weak on cost | Per-invocation pricing adds up fast |
| Long-running computation | Poor fit | Timeout ceilings force restructuring |
I've watched a team migrate a steady-traffic service to serverless for the scalability story and end up paying noticeably more per month. They kept it anyway, because the operational savings were worth the premium to them. That's a legitimate trade — but it should be a deliberate one, not an accident.
Debugging distributed functions is genuinely harder
One request can touch five functions, two queues, and a database. When something goes wrong, you're reconstructing a story from separate log streams that don't automatically share a correlation ID unless you've built that in from day one.
Real talk: this is the limitation I'd rank highest in day-to-day pain, above cold starts and above cost. Cold starts are a performance problem you can measure. Debugging a broken distributed flow at 11 p.m. is a morale problem.
Vendor lock-in is more subtle than people claim
The function code itself is usually portable. What isn't portable is everything around it — the identity model, the event schema, the queue semantics, the deployment tooling. Moving a mature serverless application between providers is a project, not a config change.
Whether that matters depends entirely on your situation. If you're building something you intend to run for a decade, it's worth weighing early. If you're validating an idea, it's noise.
How to decide whether serverless fits your project
Ask yourself three questions, in this order.
- Does my workload have meaningful idle time, or is it bursty and unpredictable?
- Can every unit of work reliably finish inside the platform's timeout?
- Do I have the observability tooling to trace requests across functions before I need it, not after?
Three yeses: serverless is probably the right call, and you'll feel the benefit within the first billing cycle. Two yeses: it can work, but plan around the gap deliberately. One or zero: you're likely better served by containers or a small always-on instance, and there's no shame in that.
Frequently asked questions about serverless computing
Is serverless computing cheaper than traditional hosting?
It depends entirely on your traffic shape, not on the model itself. For workloads that sit idle most of the time, serverless is dramatically cheaper because you pay nothing while nothing runs. For services under constant, heavy load, per-invocation pricing can exceed the cost of a reserved instance handling the same traffic. The honest answer is that serverless is cheaper for intermittent work and often more expensive for steady work.
What are the main drawbacks of serverless computing?
The most commonly cited ones are cold-start latency, execution timeouts that cap how long a single function can run, unpredictable costs at high volume, difficulty debugging requests that span multiple functions, and some degree of dependency on a specific provider's surrounding services. Of these, timeouts and debugging friction tend to cause the most architectural rework.
Can serverless handle production workloads?
Yes, and it handles many of them well — particularly event-driven APIs, background processing, scheduled jobs, and anything with spiky demand. The constraint isn't scale, since the platform will scale further than most applications need. The constraint is workload shape: anything requiring a long-lived process, persistent in-memory state, or a single execution exceeding the platform's timeout needs to be redesigned before it fits.
The thing nobody tells you about serverless
The real trade isn't cost versus convenience. It's that you're exchanging control for the absence of a certain category of problem.
You stop worrying about servers. You start worrying about execution timeouts, cold-start budgets, function granularity, and the shape of your event contracts. That's not a worse set of worries — honestly, it's a better one, because it's closer to the actual product. But it is a different set, and nobody hands you the new list on the way in.
I still reach for serverless first on most new projects. Not because it's always right, but because the default failure mode is a slightly larger bill, and the alternative's default failure mode is a server you forgot to patch. I know which one I'd rather explain.
The interesting question isn't whether serverless is good. It's whether your workload has the shape the model was designed for — and until you've measured your own traffic honestly, you don't actually know.
