Serverless Functions (FaaS)

The most useful lie in cloud computing

“Serverless” is a marketing word that picks a fight with reality, and the fight is the point. Of course there are servers. There are racks of them, humming in data centers, running your function the instant a request arrives. What “serverless” really announces is a transfer of responsibility: the provider now owns the machine, the operating system, the patching, the scaling, and the bill for idle time. You own the code and nothing else.

Once you read the word that way - as a statement about ownership, not infrastructure - the entire model snaps into focus. Every strength and every limitation of Function-as-a-Service is a downstream consequence of that one trade.

Code that runs when summoned and costs nothing when silent

The mental model I hand to every engineer new to FaaS is a vending machine. A coin goes in - an HTTP request, a file upload, a timer firing - and a single unit of work comes out. Then the machine goes dark and costs nothing until the next coin. There is no opening the shop in the morning and no closing it at night. There is only a sequence of discrete, billed transactions.

This is genuinely different from renting a server. A virtual machine is a shop you pay to keep lit whether or not a customer ever walks in. A container is a slightly cheaper shop on a shared street that you still have to staff and size. A function is a vending machine that materializes at the moment of demand and dissolves afterward. When ten customers arrive at once, ten machines appear. When none come, you owe nothing.

That property - scaling seamlessly to thousands and honestly to zero - is the headline feature. It is also why serverless is so cheap for the workloads it suits: the webhook handler that fires a hundred times a day, the nightly report, the thumbnail generator that wakes only when someone uploads a photo. Running any of those on an always-on server is like leasing a warehouse to store a single envelope.

The consequences you cannot wish away

But the vending-machine model exacts a price, and pretending otherwise is how serverless projects fail.

Because the machine materializes on demand, the first request after a quiet spell pays for it to wake up. That is the cold start - usually tens to a few hundred milliseconds while the environment provisions, the runtime loads, and your initialization code runs. For an asynchronous batch job, nobody notices. For a latency-critical, user-facing API at high volume, it can be the difference between a snappy product and a sluggish one.

Because the machine forgets everything between coins, your function is stateless. Nothing you put in memory or on local disk is guaranteed to survive to the next invocation, and concurrent requests run in entirely separate environments. Anything that must persist belongs in an external store. Engineers who try to keep a cache or a session in local memory are fighting the platform and will lose intermittently, which is the worst way to lose.

And because each concurrent request gets its own environment, a humble idea like a database connection pool becomes a hazard. Five hundred simultaneous invocations can open five hundred connections to a database that was sized for fifty. The fix exists - connection proxies, serverless-native data stores - but the trap is invisible until production traffic finds it.

The real cost is not the one on the invoice

There is a crossover point that every team should compute and almost none do. At low or spiky volume, FaaS is dramatically cheaper than idle servers. At sustained, high-throughput volume, the per-invocation premium adds up and a well-utilized container quietly wins. Serverless is not the cheap option; it is the option that prices convenience honestly, and convenience stops being a bargain once you are buying it millions of times an hour.

The deeper cost is strategic. Your handler code is portable, but everything around it - the trigger configuration, the permission model, the managed queue, the proprietary database, the observability stack - binds you to one provider. A serious serverless application is deeply entangled with its cloud. That entanglement is not automatically a mistake. It is a deliberate trade: you accept dependence in exchange for velocity and the disappearance of an entire category of operational work. The failure is not making the trade. The failure is making it by accident and discovering the depth of the entanglement only when someone proposes a migration.

Where this leaves the working engineer

The mature posture toward serverless is neither evangelism nor disdain. It is placement. Reach for FaaS when work is event-driven, intermittent, individually short, and stateless, and when your team would rather ship features than babysit infrastructure. Reach for containers and virtual machines when work is steady at scale, long-running, stateful, or ruthlessly latency-sensitive. Most real systems want both: serverless for the glue and the spiky edges, something heavier for the steady core.

Serverless did not eliminate the server. It eliminated the part of server ownership that never appeared in your job description - the patching, the capacity planning, the paying for silence. What remains is a sharper question than “which technology,” and it is the question that actually earns its keep: for this specific workload, who should own the machine? Answer that honestly, workload by workload, and the architecture mostly designs itself.