Serverless computing is often presented as the evolution of cloud: no servers to manage, pay only for what you use, infinite scalability. All of this is technically true. It is also incomplete. Serverless creates different problems, not zero problems.
This article maps the genuine trade-offs.
What serverless solves
Infrastructure operations. You do not manage servers, patch OS, handle capacity planning, or respond to infrastructure failures. This is genuinely valuable for teams without ops expertise.
Bursty workloads. Functions scale from zero to thousands in seconds. For workloads where traffic is unpredictable, this is powerful. An API hit 10 times a day should cost almost nothing. An API hit 100,000 times on a busy day should scale automatically.
Per-invocation cost. You pay for actual compute time, not for idle capacity. A function running 100 milliseconds costs 1/10th of a function running 1 second.
Polyglot environments. Functions in different languages running side by side. No language lock-in beyond individual functions.
What serverless creates
Cold starts. The first invocation of a function is slow — sometimes multiple seconds — because the runtime has to boot. Subsequent invocations are fast. For latency-sensitive workloads, this is a real problem.
Timeout limits. AWS Lambda has a 15-minute execution timeout. Azure Functions is similar. Some workloads cannot be decomposed to run in 15 minutes.
Concurrency limits. You have a limit to how many instances can run in parallel. You can increase it but it has hard ceilings and increased cost.
Complexity of distributed debugging. Tracing a request through 10 Lambda functions is harder than reading logs from a single service. Your observability needs to be good or you are blind.
Cost surprises. The per-invocation model often results in higher costs than expected when workloads spike. A DDoS attack can cost hundreds of pounds in minutes.
Operational overhead. Serverless does not eliminate operations. It shifts operations from infrastructure to application monitoring and cost management. The cognitive overhead is similar.
When serverless is right
APIs with bursty traffic. A REST API that gets a spike during a particular time and is quiet otherwise. Serverless scales to zero cost when idle and to handle the spike when it happens.
Scheduled jobs. A job that runs nightly or weekly. No idle cost. Pay only when it runs.
Event-driven processing. An upload triggers image processing, an event triggers a workflow. Each function runs for a few seconds, then stops.
Prototypes and MVPs. Get to market fast without managing infrastructure.
Low-traffic services. If your service gets 10 requests per day, serverless costs almost nothing. A traditional server costs the same regardless.
When serverless is wrong
Real-time systems. Anything where 500ms response time is too slow. Cold starts are often seconds.
Long-running processes. Batch jobs that run for hours. 15-minute timeouts prevent this.
Stateful applications. Workloads that need local state, persistent memory, or connections pooling are hard on functions. Each invocation is a fresh start.
Throughput-optimized workloads. Systems designed to process massive volumes of data where efficiency matters. Serverless overhead often makes these more expensive than traditional servers.
Cost-sensitive sustained workloads. A workload that runs 24/7 is cheaper on a reserved instance than on serverless function invocations.
The hidden costs
Egress and storage. Functions read and write data to databases and storage. The cost of those is often higher than the function cost itself.
Instrumentation. You need logging, tracing, error tracking on every function. Tools like Datadog add cost on top of compute.
Complexity. Splitting work across multiple functions adds architectural complexity. Systems become harder to change because the boundaries are fixed.
Lock-in. Functions written for AWS Lambda are hard to move to Google Cloud or Azure. Not impossible, but the refactoring is significant.
Debugging. Local development of multiple functions is harder than traditional services. Testing requires mocking or containers.
The cost model reality
The AWS Lambda pricing is 0.20 per million requests, plus 0.0000166667 per GB-second. This sounds cheap (it is) until you do the math.
A function that runs for 500ms on 256MB costs 0.000008333 per invocation. 1 million invocations cost £1.67. If your function is running 24/7 at constant traffic, it costs more on Lambda than on a reserved instance.
Serverless is cheaper than a reserved instance only if:
- The workload is bursty, not sustained.
- The function is short-running (sub-second).
- The traffic is unpredictable.
For sustained predictable workload, calculate the cost of a reserved instance and compare. Often reserved instances win.
A practical decision framework
Ask these questions in order:
Is the traffic bursty or sustained? Bursty = serverless might win. Sustained = reserved instance probably wins.
How long does the function run? Under 1 second = serverless is efficient. 1-15 seconds = serverless is fine. Over 15 seconds = you need a different model.
How latency-sensitive is it? Sub-100ms required = cold starts are a problem. 500ms+ acceptable = serverless is OK.
Can the workload be decomposed into independent functions? If yes, serverless is easier. If not, it becomes convoluted.
How mature is your observability? If you have good logging, tracing, and debugging, serverless is manageable. If not, it becomes a debugging nightmare.
The honest summary
Serverless is a powerful tool for particular workloads: bursty, event-driven, short-running, latency-tolerant. For those workloads, it often reduces operational overhead and cost.
Serverless is a poor fit for sustained workloads, long-running processes, or workloads where latency matters.
The middle ground — where a team inexperienced with ops tries to move everything to serverless — is where the problems emerge. Teams end up with higher costs, harder debugging, and the same operational overhead shifted to a different layer.
Serverless is not worse than traditional servers. It is just different trade-offs. Choose based on your workload, not on trend.