“Autoscaling” is a bit of a misnomer. What AWS calls “Auto Scaling Groups” is perhaps better named “managed instance groups” in GCE and “VM Scale Sets” in Azure. In all three cases, the most important details are that the cloud has a definition of the application you intend to run and a number of instances it’s expected to keep running at all times.
Yes, you can tie metrics into it to change the target number of instances1, but the first detail to get right is defining what should be running.
All of these factors have been complicated inside Triton, so I put together a team to approach it from the outside via Triton’s public APIs.
Just like Triton, we built everything as open source and you can find the repos in GitHub2, and Paul Stack presented our work at Hashidays. His talk is recorded, presented here with a transcript.
This is a rabbit hole worth exploring: The field of control theory formally dates back to this 1922 paper on gyroscopic autopilot for boats by Nicolas Minorsky in which he established the theoretical foundations for PID controllers. But as often happens, gyroscopic autopilots were invented, in common use, and had even made the leap from boats to planes long before the theory had been formalized. Autopilots were basically mechanical computers that took a set point, made an observation, and took action in response.
The inventor and leading manufacturer of autopilots was Sperry Corporation, which acquired the team that built the ENIAC and the first UNIVAC. At Sperry, the team commercialized the UNIVAC series of computers. A small piece of the UNIVAC name lives on now in Unisys, which acquired Sperry and the UNIVAC team in 1986. PID controllers live on as the fundamental theory underlying metrics-based autoscaling. ↩︎
See Triton Service Groups, tsg-cli, and tsg-infrastructure for the core, as well as webconsole-tsg and tsg-graphql for the web console bits. You can also read the preview documentation for service groups and instance templates Terraform resources. ↩︎