4 ms·
systemd will happily health check a service, restart it when it fails and so on. The basics don't need much. Auto-scaling is something I'm suspicious of. I saw
by thu2111 6y ago
systemd will happily health check a service, restart it when it fails and so on. The basics don't need much.
Auto-scaling is something I'm suspicious of. I saw many experiments with that at Google when I worked there, under the name of elasticity. They found the same thing GitLab found here: it's really hard and the expected savings often don't materialise. Even in 2012 their elasticity projects were far more advanced than what Kubernetes or AWS provide.
Most cloud auto-scaling efforts appear to be driven by the high base costs charged by the cloud providers in the first place. I've seen a few cases where simply moving VMs to cheaper colo providers saves more money than auto-scaling VMs or using managed Kubernetes in AWS/Azure.
- secondcoming 6y agoI found AWS's autoscaling offering be better than GCP's, in that you could use custom CloudWatch metrics as a basis for scaling logic rather than just the standard metrics (CPU usage, latency, etc) GCP does offer custom metrics, but I couldn't figure out how to tie them to the LB scaling logic.