A practical checklist for serverless

There is no clever trick in this one, just a handful of decisions worth making deliberately. Run through this the next time serverless comes up.

The bill is a design document: it tells you exactly what your architecture actually does. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

The checklist

• Excellent for spiky, event-shaped workloads
• Cold starts and vendor coupling are the real trade-offs
• Cost modelling matters more here than anywhere else
• Someone is named as the owner
• There is a date to review it again

Why this earns attention

Excellent for spiky, event-shaped workloads. This is the sort of thing that compounds, quietly, in both directions. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

In practice

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

Pick the one that would hurt most if it failed, and start there.