Getting started with autoscaling
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to autoscaling for teams who have not touched it before.
The bill is a design document: it tells you exactly what your architecture actually does. If two people in the business would answer this differently, that gap is the actual problem.
What it costs to ignore
Scaling rules need testing under real load, not in theory. It is worth being explicit about, because assumptions differ quietly. If two people in the business would answer this differently, that gap is the actual problem.
Your first week
- Find out what is already in place
- Scaling up is easy, scaling down safely is the hard part
- Change one thing and measure it
A slow dependency will not scale with you. This is the sort of thing that compounds, quietly, in both directions. Assume whoever inherits this will have half your context and none of your patience.
In practice
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
- A slow dependency will not scale with you — 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.