[jrockway]

For people on the cloud, you can buy new computers and sell them back in a period of time measured in hours, so that's how people are using these systems. It doesn't make a ton of economic sense to me in general, because your periods of high demand are going to be the same periods for everyone else in that datacenter (you want to serve close to your users to minimize latency, and most of the users in a geographical region go to work and sleep at the same times). That said, it's not priced like that. Having burstable core instances "always on" can end up being more expensive than buying guaranteed capacity instances for a short period of time.

I never auto-scale interactive workloads, but it's good for batch work.

Other people have different feelings. Consider the case where you release software multiple times a day, but it has a memory leak. You don't notice this memory leak because you're restarting the application so often. But the Winter Code Freeze shows up, and your app starts running out of memory and dying, paging you every day during your time off. If you had horizontal autoscaling, you would just increase the amount of memory that your application has until you come back and fix it. Sloppy? Sure. But maybe easier to buy some RAM for a couple weeks and not disrupt people's vacation. (The purist would argue their vacation was ruined the day they checked in the memory leak.) This gets all the more fun when the team writing the code and the team responsible for the error rate in production are different teams in different time zones. I don't think that's a healthy way to structure your teams, but literally everyone else on earth disagrees with me, so... that's why there's a product that you can sell to the infrastructure team instead of telling the dev team "wake up and call free() on memory you're not using anymore".