Comparison
Horizontal autoscalingvsVertical autoscaling
Horizontal autoscaling
traffic doubled and the replica count went from four to nine on its own, a minute or two after it needed to.
Adding and removing copies of a workload automatically based on a metric — CPU, memory, queue depth, request rate. It is the standard elasticity mechanism and it works well for stateless request handlers whose load metric is honest. Its two constant problems are lag, because the metric arrives after the traffic did, and flapping, which is why cooldown windows exist and why a scale signal tied to a lagging indicator makes things worse.
Full entry →Vertical autoscaling
something watched the workload for a week and rewrote its requests, and traditionally had to restart it to apply them.
Adjusting a workload's requests and limits automatically from observed usage, rather than changing how many copies there are. It solves the request-guessing problem that wrecks bin packing, and it is most useful on workloads that cannot be scaled out at all. Historically it required a restart to take effect, which is why many teams run it in recommendation-only mode and let humans apply the numbers.
Full entry →