Five mistakes teams make with autoscaling

Every audit we run turns up some version of this. These are the ones we run into repeatedly when we audit autoscaling.

Operability is a feature, and it has to be built rather than bought. If it only works because one person remembers to do something, it does not work yet.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Scaling rules need testing under real load, not in theory
• Scaling up is easy, scaling down safely is the hard part
• Never checking whether the fix actually worked

A slow dependency will not scale with you. The reasoning matters more than the rule, because the rule has exceptions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Making it stick

How to tell if yours is fine

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 up is easy, scaling down safely is the hard part — 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.