Autoscaling, explained without the jargon

Every audit we run turns up some version of this. Here is autoscaling without the vocabulary that usually surrounds it.

The bill is a design document: it tells you exactly what your architecture actually does. Budget a little time for it every quarter and it never becomes a project of its own.

The short version

Scaling rules need testing under real load, not in theory. The cost of getting this wrong is rarely visible on the day it happens. Check it against what you would want a competitor's site to get wrong.

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.

Scaling up is easy, scaling down safely is the hard part. None of that requires a large budget, only a decision and someone to own it. If it only works because one person remembers to do something, it does not work yet.

Making it stick

A slow dependency will not scale with you. There is a version of this that is over-engineered, and it is worth avoiding. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The short version

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about autoscaling before you move on:

• Someone can say what the current setup is without going to look
• Scaling rules need testing under real load, not in theory — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.