Serverless got a reputation problem a few years back - cold starts, vendor lock-in, debugging pain - that a lot of engineering teams still hold against it, even as the actual constraints have shifted considerably. The honest 2026 take: serverless is genuinely excellent for a specific, common class of workload, and genuinely wrong for another, and the skill worth having is telling the two apart rather than picking a side in the debate.
What’s actually different now versus the early criticism
Cold start latency - historically the biggest practical complaint - has improved substantially across major providers, and provisioned concurrency options exist specifically for latency-sensitive functions that can’t tolerate any cold start delay. The ecosystem has also matured around the debugging and observability tooling that used to make serverless genuinely painful to troubleshoot in production. It’s not a solved problem entirely, but it’s a meaningfully different starting point than the “serverless is immature” conversation from a few years ago.
Where serverless still clearly wins
- Spiky, unpredictable traffic. Workloads with genuine traffic variance - promotional spikes, viral moments, seasonal demand - benefit enormously from paying only for actual execution rather than provisioning for peak capacity that sits idle most of the time.
- Event-driven, asynchronous work. Background jobs, webhook processing, file processing triggered by uploads - anything naturally structured as “an event happened, run this function” fits the serverless model almost perfectly with minimal architectural friction.
- Low-to-moderate, intermittent traffic APIs. Internal tools, admin APIs, and services without constant high traffic often cost dramatically less running serverless than maintaining always-on infrastructure sized for capacity they rarely use.
Where we steer clients away from it
Sustained high-throughput workloads with predictable, constant traffic are usually cheaper on traditional always-on infrastructure - the per-invocation pricing model that makes serverless economical for spiky traffic works against you at high, sustained volume. Latency-critical paths where even optimized cold starts introduce unacceptable variance - certain real-time or trading-adjacent systems - still favor dedicated, always-warm infrastructure. And workloads with long-running, stateful processes (not naturally broken into short, stateless function executions) fight against the serverless execution model rather than working with it.
What “edge orchestration” actually adds to this picture
The newer development worth understanding is running serverless functions at edge locations - geographically distributed points of presence - rather than a single regional deployment. For genuinely latency-sensitive, globally distributed user bases, this meaningfully reduces round-trip latency by executing logic physically closer to the user, rather than routing every request back to one central region. This is a real advantage for global consumer applications; it’s mostly irrelevant complexity for an application serving a single geographic market, where the added architectural complexity of edge deployment isn’t buying you anything a standard regional deployment doesn’t already provide.
The honest architecture recommendation
Most real applications aren’t purely one or the other - the pattern we actually build most often is a hybrid: core, high-throughput services on traditional infrastructure (containers on ECS or Kubernetes) with serverless functions handling the genuinely event-driven, spiky, or asynchronous pieces around them. Treating “serverless vs. traditional” as a single architecture-wide decision usually produces a worse outcome than matching each workload to the model it actually fits.
We architect this mix as part of our cloud infrastructure work, based on the actual traffic and workload characteristics of each part of a system, not a blanket philosophy. Get in touch if you’re trying to figure out which parts of your system would actually benefit from going serverless.