Serverless: When It Fits and When It Bites

What serverless actually buys you

Strip away the marketing and serverless — Functions-as-a-Service plus the managed event, queue, and storage services around it — sells three concrete things. First, no server management: no operating system to patch, no capacity to provision, no autoscaling group to tune. Second, scale to zero: when nothing is calling your code, you run no instances and pay nothing for compute. Third, pay-per-use billing: you are charged per invocation plus GB-seconds of memory-time, not for idle capacity waiting on traffic.

Those are real advantages, and for the right workload they are transformative. But each one is also a boundary condition. Scale to zero is worthless if your workload never goes idle. Pay-per-use is a bargain at low volume and a penalty at sustained high volume. And "no server management" quietly relocates operational complexity into distributed tracing, cold-start tuning, and provider-specific plumbing rather than removing it. Serverless does not eliminate the hard parts of running software; it moves them. The engineering question is always whether that trade lands in your favor for a specific workload — not whether serverless is good in the abstract.

Where serverless is a genuinely good fit

Some workloads are almost purpose-built for FaaS, and forcing them onto always-on servers means paying for idle capacity you rarely use.

• Event-driven processing. A file lands in object storage, a message hits a queue, a webhook fires, a database row changes. A function wakes, does one unit of work, and exits. The execution model matches the workload exactly, and scale to zero means you pay only when events actually arrive.
• Spiky and unpredictable traffic. Campaign launches, seasonal peaks, and bursty batch fan-out are worst-case for owned capacity and best-case for FaaS. The platform absorbs a jump from ten to ten thousand concurrent executions without you pre-provisioning for the peak and eating the cost the other 51 weeks of the year.
• Glue and integration code. The connective tissue between systems — reshaping a payload, calling three APIs, writing to a datastore, emitting a notification — is where serverless shines. This is orchestration you do not want to run a dedicated fleet for, and it is the backbone of most automation pipelines.
• Scheduled and low-frequency jobs. A nightly report or an hourly sync that runs for seconds has no business holding a server open around the clock.

Figure: serverless earns its keep as event-driven glue — each trigger spins up work on demand, then the whole pipeline scales back to zero.

The common thread is intermittent, event-shaped work. When utilization is naturally low or wildly variable, paying per invocation beats paying for a server that sits mostly idle. On a public cloud platform this is where the economics are lopsidedly in serverless's favor.

Where serverless bites

The same properties invert on workloads that are steady, latency-sensitive, or long-running.

• Sustained high throughput. A service that runs thousands of requests per second, all day, never goes idle — so scale to zero never triggers, and pay-per-use becomes pay-per-request forever. At that volume, per-invocation and GB-second charges routinely cross above the cost of a right-sized, always-on container fleet. You are renting by the second something you now use full-time.
• Latency-sensitive request paths. Cold starts add unpredictable delay to the first request against a new instance (more on that below). For a user-facing path with a tight tail-latency budget, that jitter shows up in your p99 and is hard to fully engineer away.
• Long-running jobs. Most FaaS platforms cap a single execution at roughly 15 minutes. Video transcoding, large ETL runs, model training, and anything that needs to hold state for hours simply do not fit and have to be chopped into orchestrated steps — added complexity that often erases the simplicity you came for.
• Heavy, chatty stateful work. Functions are stateless and short-lived, so anything needing large in-memory caches, persistent connections, or connection pools fights the model. Database connection exhaustion under a burst of thousands of concurrent functions is a classic serverless outage, usually solved by bolting on a connection proxy.

The operational tax: cold starts, observability, and lock-in

The parts that bite hardest are rarely on the pricing page.

Cold starts

When a request arrives and no warm instance exists, the platform provisions a new execution environment, loads your runtime, and initializes your code before the request runs. That cold-start penalty is small for lightweight runtimes and can reach a second or more for heavy dependency graphs, large deployment packages, or functions inside a private network. You can mitigate it — provisioned concurrency, smaller packages, lighter runtimes, keeping functions warm — but every mitigation either costs money or reintroduces the always-on posture you were trying to escape. Cold starts are manageable; they are not free.

Observability

A monolith you can attach a debugger to. A hundred functions triggered by a dozen event sources you cannot. Serverless pushes you toward distributed tracing, correlation IDs, and structured logs as table stakes rather than nice-to-haves, because a single user action may fan out across many short-lived executions with no long-lived process to inspect. Budget for the tooling and the discipline up front; retrofitting observability after an incident is painful, and "it works on my machine" does not survive a fan-out failure at 3 a.m.

Vendor lock-in

This is the quiet one. Your function code may be portable, but the value of serverless lives in the surrounding managed services — the event bus, the queue, the identity and permission model, the API gateway, the deployment tooling. Those bindings are provider-specific, and the more of them you adopt, the more a migration becomes a rewrite rather than a redeploy. Frameworks and open runtimes reduce the blast radius, but be honest that deep serverless adoption is a bet on one provider's ecosystem. Where portability matters, a deliberate cloud infrastructure strategy — abstraction layers, infrastructure as code, containers where they make sense — keeps that bet from becoming a cage.

The cost crossover nobody models

Serverless pricing feels free at low volume and becomes a line item nobody forecasted at high volume. The failure mode is predictable: a workload starts as a handful of daily invocations, succeeds, and grows into millions of executions a day while still billed per invocation. Because there is no server to point at, the cost hides in a per-request meter that only reveals itself on the invoice.

Model the crossover before you commit:

1. Estimate steady-state volume, not launch-day volume — invocations per month, average duration, and memory allocated.
2. Compute the FaaS bill from per-million-request and GB-second rates at that sustained volume.
3. Compute the always-on alternative — a right-sized container or VM fleet that carries the same load at realistic utilization.
4. Find the break-even and check which side of it your projected growth puts you on in twelve months, not today.

Below the crossover, serverless is cheaper and simpler. Above it, a container platform is usually both cheaper and more predictable. The mature pattern is a blend: FaaS for the event-driven and spiky edges, containers or managed instances for the steady core, and — where latency to the user is the constraint — edge computing to push lightweight logic closer to where requests originate.

Deciding well

Serverless is a sharp tool, not a default. It fits event-driven, spiky, and glue workloads so well that not using it there is a mistake — and it bites steady, latency-sensitive, and long-running workloads badly enough that forcing them onto FaaS is an equally clear mistake. The teams that win with serverless are the ones that pick the boundary deliberately, instrument for observability from day one, and model the cost crossover before growth makes it a surprise.

If you are weighing serverless against containers for a specific workload, or trying to explain a cloud bill that grew faster than your traffic, talk to our cloud team. We will model the crossover with your real numbers and place each workload where the architecture and the economics actually agree.