Serverless Computing: When It Shines and When It Bites

"Serverless" is a misleading name for a precise idea: you upload code, the platform runs it when something triggers it, scales it from zero to thousands of instances without your involvement, and bills you only for the milliseconds it ran. There are servers; you just never see, patch or pay for idle ones. A decade after AWS Lambda launched, serverless has matured into a well-understood tool with well-understood sharp edges — and the interesting question is no longer whether it works but which workloads it fits.

What counts as serverless

The category has broadened beyond functions:

• Functions as a service (FaaS): AWS Lambda, Azure Functions, Google Cloud Functions (now Cloud Run functions). Short-lived handlers triggered by HTTP requests, queue messages, file uploads, schedules or database events.
• Serverless containers: Google Cloud Run, AWS Fargate and App Runner, Azure Container Apps. You ship a container image; the platform scales it to zero and back. This has become the default for many teams because it removes the size, runtime and duration limits of functions.
• Edge functions: Cloudflare Workers, Vercel and Netlify functions, Deno Deploy. Lightweight runtimes executing in hundreds of locations, milliseconds from the user, ideal for routing, personalisation and API glue.
• Serverless data services: DynamoDB, Aurora Serverless, Neon, PlanetScale, BigQuery and the like — databases and queues that scale and bill on usage rather than provisioned capacity.

The common thread: no capacity planning, no idle cost, and operations reduced to code and configuration.

Where it shines

• Spiky or unpredictable traffic. A ticketing site, a viral launch, a nightly batch. Scale-to-zero means you don't pay for the 22 quiet hours.
• Event-driven glue. Resize the image when it's uploaded; index the record when it's written; notify the team when the alarm fires. Small, isolated units of work triggered by things happening.
• APIs and backends for small teams that can't or don't want to run infrastructure. A startup can serve millions of requests with no one on call for servers.
• Scheduled and background jobs that would otherwise justify a whole VM to run for five minutes a day.
• Prototypes and internal tools where operational simplicity outweighs everything else.

Where it bites

• Cold starts. A function that hasn't run recently needs its runtime initialised, adding anywhere from tens of milliseconds to several seconds (JVM and .NET are slowest, Go and Rust fastest). Providers now offer provisioned concurrency and snapshot-based restores (Lambda SnapStart) to mitigate, at a cost. For latency-critical paths, this remains the main objection.
• Cost at sustained load. Per-invocation pricing is a bargain at low volume and expensive at high, steady volume. A service handling thousands of requests per second around the clock is usually cheaper on containers or VMs. Do the arithmetic before and after.
• Execution limits. Maximum durations (15 minutes on Lambda), memory ceilings, payload sizes. Long-running or stateful work needs a different model or a workflow orchestrator.
• Local development and testing. Emulating cloud triggers locally is imperfect; teams often test in real cloud environments, which is slower and costs money.
• Observability. A request that touches a dozen functions and three queues is hard to trace without deliberate investment in distributed tracing and structured logging.
• Vendor lock-in. Function signatures, event formats and the surrounding services differ per provider. The code is portable in principle; the architecture usually isn't.
• Connection management. Thousands of short-lived function instances each opening a database connection will exhaust a relational database. Connection proxies (RDS Proxy and equivalents) or HTTP-based data APIs are required, not optional.

Patterns that work

Successful serverless systems tend to be asynchronous by default — HTTP requests do the minimum and hand off to queues; workers process events with retries and dead-letter queues for failures. They use workflow orchestrators (Step Functions, Durable Functions, Temporal) for multi-step processes rather than chaining functions by hand. They're defined entirely as infrastructure as code (SAM, CDK, Serverless Framework, Terraform) because the number of configured resources grows fast. And they treat idempotency as a requirement, because at-least-once delivery means every handler will eventually run twice.

Deciding

Serverless is the right default for event-driven work, variable load and teams that want to minimise operations. It's the wrong choice for latency-sensitive paths that can't tolerate cold starts, for sustained high-throughput services where per-request pricing dominates, and for long-running stateful processes. Most mature architectures mix it with containers — serverless for the edges and the glue, a long-running service for the hot core — and choose per workload rather than per organisation. The technology has stopped being a bet; it's now a tool with a known shape.