How to get autoscaling right
Most teams know this matters. Fewer have decided who owns it. The short answer to autoscaling is that it is mostly a sequence of small decisions, not one big one.
The bill is a design document: it tells you exactly what your architecture actually does. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
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. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- Scaling up is easy, scaling down safely is the hard part
- A slow dependency will not scale with you
- Write down the decision so the next person does not re-litigate it
A slow dependency will not scale with you. This is the sort of thing that compounds, quietly, in both directions. Write the reasoning down alongside the decision, because the reasoning is what changes first.
A reasonable first step
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 any of that sounds like a description of your current setup, it is fixable.