Serverless has been around long enough that the hype and the backlash have both cooled. In 2026 the honest position is in the middle: it is excellent for some workloads, expensive and awkward for others, and the decision comes down to a few specific properties of your traffic and your team.
Cold starts: smaller than the discourse
Cold starts are the first objection everyone raises and usually the least important one. For a typical Lambda on a modern runtime, a cold start is tens to low hundreds of milliseconds. It only matters at the edge of a latency-sensitive synchronous path. If that is you, provisioned concurrency removes it for a price, and keeping your package small and your initialisation lean does most of the rest. For async and batch work, nobody notices a cold start at all. The real culprit is heavy dependencies in the init path, not the platform itself.
Cost: where the curve crosses
Serverless bills per request and per millisecond, which is wonderful when traffic is spiky or low and brutal when it is high and steady. There is a crossover point where a constantly busy Lambda fleet costs more than the equivalent always-on containers on Fargate or EC2. We have seen teams save real money moving a hot, predictable path off Lambda, and other teams save just as much moving a bursty, idle-most-of-the-day service onto it.
Serverless is cheapest exactly where servers are most wasteful: spiky, unpredictable, or mostly-idle traffic.
The cost that does not show on the invoice is operational. You stop paying for patching, capacity planning, and scaling logic. For a small team that absence is worth a lot, often more than the compute line item itself.
Lock-in: real, but priced honestly it is fine
Your function code is portable. Everything around it (the event sources, IAM, the API Gateway config, the Step Functions definitions) is not. That is genuine lock-in. We do not pretend otherwise. What we push back on is the idea that lock-in is automatically bad. You are trading portability for the managed services that make the platform worth using, and for most businesses that trade is correct, because the cost of staying portable is paid every day and the cost of migrating is paid maybe once.
When we reach for it
- Event glue, webhooks, scheduled jobs, and anything reacting to S3 or queue events.
- New products with unknown traffic where paying for idle capacity is pure waste.
- Spiky workloads where autoscaling containers would lag the demand.
- Not for steady high-throughput services, heavy long-running compute, or sub-10ms latency floors.
Serverless is a tool with a clear shape. Match it to bursty, event-driven, or low-volume work and it is the cheapest, lowest-operations option on the board. Force it onto a hot steady-state service and you will pay more for less control. Decide on the traffic, not the trend.