The Trade-offs Nobody Tells You About Going Serverless

"Serverless" is one of those words that sells itself before anyone asks what it actually means for their project. No servers to patch, automatic scaling, pay-per-execution pricing - it sounds like a strict upgrade over the alternative. In practice, we've shipped serverless architectures that were the right call, and we've talked clients out of serverless when it would have quietly hurt them six months later. The difference comes down to trade-offs most pitches skip over.

The Part That's True: Operational Simplicity

Serverless does remove a real category of work. No provisioning servers, no patching operating systems, no capacity planning for traffic you're guessing at. For a startup validating an idea, or a feature with unpredictable, spiky usage, this is a genuine advantage - infrastructure stops being a project of its own.

That's the part every serverless pitch leads with, and it's earned.

Cold Starts Are Real, and They Show Up at the Worst Time

A serverless function that hasn't run recently has to spin up before it can respond. For a background job, that delay is invisible. For a user-facing API endpoint, a cold start can mean a multi-second delay on exactly the kind of low-traffic-then-sudden-spike pattern serverless is supposed to handle well. We've had to specifically architect around this -keeping critical paths warm, or avoiding serverless entirely for latency-sensitive endpoints - which eats into the "it just works" promise.

Costs Are Unpredictable in a Way Traditional Hosting Isn't

Pay-per-execution sounds like it should always be cheaper. At low-to-moderate, spiky traffic, it usually is. But at sustained high traffic, the per-invocation cost can end up higher than a reserved server instance running the same workload continuously. We've seen this catch clients off guard after launch - the bill that made sense in staging looks very different once real usage settles in. Estimating serverless cost accurately means modeling actual usage patterns, not just comparing sticker prices.

Debugging Changes Shape

Traditional server debugging usually means SSH in, tail a log, reproduce locally. Serverless debugging means stitching together logs across dozens or hundreds of short-lived function invocations, often across multiple services you don't directly control. Distributed tracing becomes mandatory, not optional, and the tooling investment to make debugging tolerable is a real, upfront cost that's easy to underestimate when scoping a serverless project.

Vendor Lock-In Is Deeper Than It Looks

Serverless functions rarely exist in isolation - they're wired into a specific provider's event triggers, permissions model, and adjacent managed services. Moving a serverless architecture between cloud providers later is a meaningfully bigger undertaking than moving a containerized application, because the "glue" logic is often provider-specific by design. This isn't a reason to avoid serverless, but it is a decision that should be made with eyes open, not discovered during a later migration.

Long-Running Processes Don't Fit the Model

Most serverless platforms cap execution time per invocation. That's fine for request-response APIs and event handlers. It's a real constraint for long-running jobs - large batch processing, certain video or file transformations, anything that doesn't naturally break into short units of work. We've had to route these workloads to traditional compute even in an otherwise serverless architecture, which means "serverless" often ends up meaning "serverless where it fits," not "serverless everywhere."

How We Actually Decide

We look at three things before recommending serverless: traffic shape (spiky and unpredictable favors serverless; steady and high favors traditional or containerized hosting), latency sensitivity (cold starts matter more the closer you are to the user), and how much of the workload is naturally short-lived versus long-running. Serverless is often the right answer for parts of a system and the wrong answer for others - the strongest architectures we've built are usually a deliberate mix, not an all-in bet either way.

That's the same evaluation we apply internally when we decide how to run pieces of Zoraz AI itself - some of it serverless, some of it not, based on the same trade-offs above rather than which approach sounds more modern.