serverless · cloud · architecture

What is serverless, exactly?

The word is a marketing term that has stuck, and it misleads almost everyone the first time. Serverless does not mean there is no server. It means you never see one: you do not choose its size, install its updates, or decide how many of them to run. Someone else does all of that, and you are billed for what your code actually did.

What it actually removes

On a VPS you rent a machine. It exists whether or not anyone visits, you pick its RAM and vCPU, you patch its kernel, and you decide when to add a second one. Every one of those decisions is yours, and so is every hour of the bill.

Serverless removes the machine as a unit you reason about. You hand the platform a piece of code and a trigger, an HTTP request, a message on a queue, a file landing in storage, and the platform arranges for that code to run when the trigger fires. How many copies run, and on what, is not your problem and not your decision.

That is the whole trade, stated plainly: you give up control over the runtime in exchange for never operating it.

The two families

Functions as a Service is the part people mean first. You deploy a single function, the platform runs it per event, and it is gone again. AWS Lambda, Google Cloud Functions and Azure Functions are the familiar examples.

Managed serverless services are the larger and less discussed half: databases, queues, object storage and search that bill per request or per unit of work rather than per provisioned instance. Most real serverless systems are mostly this, with a modest amount of function code holding the pieces together.

Billing, and why scale to zero is the headline

A rented machine bills for wall-clock time. It costs the same at three in the morning with no visitors as it does at peak. Serverless bills per invocation plus the resources that invocation consumed while it ran.

The consequence is scale to zero: with no traffic, there is nothing running and nothing to pay for. For a side project, an internal tool used twice a week, or a spiky workload that is idle most of the time, this is the genuine advantage, and it is large.

The same mechanism runs in the other direction under load. The platform starts as many concurrent copies as the events demand, without you configuring an autoscaler, which is the second real advantage.

The constraints the pitch leaves out

Cold starts. When no copy of your function is warm, the first request pays for initialising the runtime and your dependencies before your code runs at all. Smaller bundles and lighter runtimes reduce it. Providers sell pre-warmed capacity, which works and which quietly undoes scale to zero, since pre-warmed means paid for while idle.

Statelessness. Nothing you keep in memory or on local disk is guaranteed to be there next time. Two invocations may land on different instances, and an instance disappears whenever the platform decides. State belongs in a database or an object store, always.

Execution limits. A single invocation has a maximum duration and a memory ceiling. Long batch jobs and anything holding a connection open for hours are a poor fit, and hitting the limit is not a warning but a failure.

Coupling. The function body is usually portable. The event shapes, the identity model and the surrounding managed services are not, and that is where moving later actually costs.

Where the cost curve crosses

Per-invocation billing is cheap when the machine would have been idle and expensive when it would have been busy. Below a certain steady load, serverless wins easily. Above it, you are paying a premium per unit of work for elasticity you are no longer using, and a modest always-on server is cheaper and more predictable.

The honest rule is to look at the shape of the traffic rather than its volume. Spiky, occasional and unpredictable favours serverless. Steady and continuous favours a machine you rent by the month, and at that point the operational work you took back is a fair price for a bill that stops surprising you.

If your workload turns out to sit on the steady side, a VPS is the plain answer, and Docker plus a small amount of discipline gets you most of the reproducibility that made serverless attractive in the first place.

The short version

Serverless means the servers are somebody else's problem, not that they are absent. You gain scale to zero, automatic concurrency and no patching. You accept cold starts, statelessness, execution limits and a bill that follows usage rather than time. It fits bursty and intermittent work, and it stops fitting when the traffic becomes steady enough that a rented machine would have been busy anyway.