Three myths about serverless

Teams tend to reach for this after something has already gone wrong. A few things about serverless that get repeated more often than they get checked.

The bill is a design document: it tells you exactly what your architecture actually does. The version that survives contact with a real deadline is the simple one.

“It only matters for big sites”

Excellent for spiky, event-shaped workloads. None of that requires a large budget, only a decision and someone to own it. It is the sort of thing that looks like polish right up until it costs you an enquiry.

“We can deal with it after launch”

Sometimes true, usually expensive. That sounds obvious written down. It is still the thing most often skipped.

“Our platform handles it”

Cost modelling matters more here than anywhere else. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What this looks like day to day

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
• Cold starts and vendor coupling are the real trade-offs — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.