2 ms·
I haven't see that work out in practice, I've suspected that's mostly marketing fluff at this point. Anyone have counter examples? We considered autoscaling we
by 8organicbits 4y ago
I haven't see that work out in practice, I've suspected that's mostly marketing fluff at this point. Anyone have counter examples?
We considered autoscaling web backends once. You've got to worry about capacity issues. You don't want a load spike only to discover EC2 has run out of the instance type you use. I've seen that issue 3-4 times in AWS now and it's painful when it causes downtime. Your app needs to have spikey load for the pricing to work, for us, even a strong day/night cycle didn't give enough "off time" to cover the higher hourly prices. Cloud vendors give steep discounts for always on usage. Your load also can't be too spikey, as spinning nodes up and down takes time. Making nodes start quickly can be a dedicated project.
I think we also looked into moving CI/CD servers to on demand, but some engineers worked too late into the night and others were up early. IIRC the "off period" was long enough to provide some cost savings, but not high enough to justify engineering cost.
Something like Lambda doing a "scale to zero" with a generous free tier looks cheap, but if you ever need to scale up you'll find it's quite expensive and your stuck with a weird architecture that's hard to move to something traditional. It is cool when an app fits the Lambda free tier, but that's not a good model for companies paying very large cloud bills.
The problem is that someone needs to do capacity planning, someone needs to buy servers. AWS has to pay the cost of an unutilized server by... keeping the hourly cost of on demand servers/cloud functions high.