Serverless, explained without the jargon

The version of this that works is simpler than the version most people imagine. Here is serverless without the vocabulary that usually surrounds it.

The bill is a design document: it tells you exactly what your architecture actually does. Assume whoever inherits this will have half your context and none of your patience.

The short version

Excellent for spiky, event-shaped workloads. The teams that handle this well are rarely the ones with the biggest budgets. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The teams that handle this well are rarely the ones with the biggest budgets.

Cold starts and vendor coupling are the real trade-offs. The reasoning matters more than the rule, because the rule has exceptions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where to go from here

Cost modelling matters more here than anywhere else. The cost of getting this wrong is rarely visible on the day it happens. Doing this properly once is usually cheaper than doing it approximately three times.

How to tell if yours is fine

Operability is a feature, and it has to be built rather than bought. Three things worth confirming about serverless before you move on:

• Someone can say what the current setup is without going to look
• Excellent for spiky, event-shaped workloads — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.