Serverless Is Not No Server

There is still a machine. You just gave up the right to know anything about it.

The Abstraction Is Real; the Infrastructure Is Not

"Serverless" is a billing and operations model, not a statement about hardware. When you deploy a function to AWS Lambda, Google Cloud Functions, or Azure Functions, your code runs on a physical server in a provider datacentre. What you have relinquished is not the server itself but every operational handle that comes with it: placement, OS version, patch timing, neighbour workloads, and the network path to everything else. The server exists; you are simply not on the invitation list.

That loss of visibility has three operational consequences worth taking seriously.

Cold starts. A function that has not been invoked recently runs on no pre-warmed instance. The provider must allocate a container or microVM, pull your runtime, load your code, and then execute it. That sequence — commonly measured in tens to hundreds of milliseconds, occasionally more for heavyweight runtimes like Java — is the cold start. For latency-sensitive workloads, it is a real penalty, not a footnote. You can mitigate it with provisioned concurrency or keep-alive pings, but both cost money and partially defeat the claim that you only pay for execution.

Execution limits. Functions run under hard ceilings on duration, memory, and concurrent instances. These vary by provider but they are non-negotiable at runtime. A workload that occasionally needs to run for twelve minutes, or that needs to hold a large working set in memory, may simply not fit the model — and discovering that ceiling in production, not in a design review, is the expensive version of the lesson.

State management. A function instance is disposable and typically short-lived. It carries no guarantee of persistence between invocations, and you cannot assume the same instance will handle two requests from the same user. Any state — session data, partially computed results, connection pools — must live outside the function, in a cache, a database, or object storage. Architects who come from always-on services sometimes build this assumption in quietly and then spend days debugging why containers versus functions behave so differently under the same load pattern.

The model genuinely suits event-driven, short-burst, stateless work. It is a poor fit for long-running processes, latency-critical hot paths, and anything that needs fine-grained control over its execution environment. Knowing which situation you are in before you commit is, as usual, the whole job.