Serverless: the questions we get asked most

We end up explaining this on discovery calls often enough that it deserved writing down. The questions about serverless that come up most often on our calls.

Cloud work rewards teams who automate early and punishes teams who click through consoles. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Do we need to care about this?

Excellent for spiky, event-shaped workloads. The reasoning matters more than the rule, because the rule has exceptions. Assume whoever inherits this will have half your context and none of your patience.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. There is a version of this that is over-engineered, and it is worth avoiding.

How do we know it is working?

Cost modelling matters more here than anywhere else. Small and consistent beats large and occasional here. If it only works because one person remembers to do something, it does not work yet.

How to tell if yours is fine

The bill is a design document: it tells you exactly what your architecture actually does. 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

Worth checking on your own setup before it becomes someone else's problem to fix.