4 ms·

> How do you indicate that you want to provision some more because there's a big event coming up? You literally do not. As load starts to increase, you scale u

by voz_ 4y ago

> How do you indicate that you want to provision some more because there's a big event coming up? You literally do not. As load starts to increase, you scale up automatically. The word elastic has been used to represent this pattern in the last few generations of cloud and/or computing infra. What's the alternative? Manually ssh into some box and crank up mysql instance by hand? like its 1996?

Karunamon 4y ago
I think that only applies if the incoming load is gradual. Any sane elastic configuration has some timeouts and a measurement period meant to prevent unwanted scale-up just because of transient load, and during that time you can get hit hard enough to degrade/take down your service before your additional capacity has come online. It makes sense to get out in front of known massive load events before they hit your service. If I'm launching a new service that I expect to hit the front page of HN, I'm spinning up capacity first and asking questions later. A couple hours of running large instances or extra containers costs much less than potential lost sales from users getting timeouts.
samhw 4y ago
Yeah, I appreciate what 'auto' and 'scaling' signifies. I've implemented an autoscaler on a huge Kubernetes cluster in the past. That's precisely where my doubt comes from. I was about to write out a huge example, but I figure I'll just express the core logic simply. First, it takes a chunk of time to determine that increased traffic is not just random variance. Then it takes time to allocate and provision machines. And often the traffic spikes for you and for your co-tenants are not statistically independent, so the provider struggles to allocate machines in time when it most matters. And how much do you scale up? 10x right away? Can't do that: vastly expensive, and anyway it could be a retry storm exacerbating things. 2x and then go from there? Well, if your business is serving ads during the Superbowl break, that's not gonna work. Etc. This all starts to look increasingly absurd against the backdrop of being able to just push a button and do it yourself. I'm not suggesting never doing autoscaling. I'm just saying that wise men don't speak in absolutes, or make architectural decisions based on toy examples. Nor am I particularly bothered about whether I'm doing things "like it's 1996" - I'm not in the fashion business, so I'm purely interested in finding the optimal solution to my problem, and I couldn't care less whether it's flaming hot or whether it's from the Iron Age.

by voz_ 4y ago

Karunamon 4y ago

I think that only applies if the incoming load is gradual. Any sane elastic configuration has some timeouts and a measurement period meant to prevent unwanted scale-up just because of transient load, and during that time you can get hit hard enough to degrade/take down your service before your additional capacity has come online. It makes sense to get out in front of known massive load events before they hit your service. If I'm launching a new service that I expect to hit the front page of HN, I'm spinning up capacity first and asking questions later. A couple hours of running large instances or extra containers costs much less than potential lost sales from users getting timeouts.

samhw 4y ago

Yeah, I appreciate what 'auto' and 'scaling' signifies. I've implemented an autoscaler on a huge Kubernetes cluster in the past. That's precisely where my doubt comes from. I was about to write out a huge example, but I figure I'll just express the core logic simply. First, it takes a chunk of time to determine that increased traffic is not just random variance. Then it takes time to allocate and provision machines. And often the traffic spikes for you and for your co-tenants are not statistically independent, so the provider struggles to allocate machines in time when it most matters. And how much do you scale up? 10x right away? Can't do that: vastly expensive, and anyway it could be a retry storm exacerbating things. 2x and then go from there? Well, if your business is serving ads during the Superbowl break, that's not gonna work. Etc. This all starts to look increasingly absurd against the backdrop of being able to just push a button and do it yourself. I'm not suggesting never doing autoscaling. I'm just saying that wise men don't speak in absolutes, or make architectural decisions based on toy examples. Nor am I particularly bothered about whether I'm doing things "like it's 1996" - I'm not in the fashion business, so I'm purely interested in finding the optimal solution to my problem, and I couldn't care less whether it's flaming hot or whether it's from the Iron Age.