4 ms·

Allow for an easy path to recovery, with near-zero downtime, when that PC-in-a-closet inevitably has some sort of failure. The nice thing about the fact that E

Allow for an easy path to recovery, with near-zero downtime, when that PC-in-a-closet inevitably has some sort of failure. The nice thing about the fact that EC2 instances are at least to some degree ephemeral is that it forces you, from the start, to have a solid backup/restore plan. And when an EC2 instance goes down, you can have another one booted within minutes, compared to the days/weeks that it might take to get another physical machine set up. That's not even to mention scaling issues; right now I'm managing a stack of over 50 EC2 instances, and it's easily manageable by a single person (most of those are in a load balanced array, and they'll come up and go down automatically as load dictates). I have no idea what I would do if I had to physically set up servers to handle this type of shifting load...

rhizome 15y ago
compared to the days/weeks that it might take to get another physical machine set up. Whaaaa? What does 50 EC2 instances correspond to in the hardware world, appwise (not environment)? Each of my Rails/Apache processes are about 75M (unoptimized, natch), which means 50 will sit OK in 4G RAM. Since that is laptop-caliber hardware capacity, I'm still not seeing the benefit in the server world (or even an 8G PC). From where I sit it seems to involve a lot of domain knowledge that is not relevant once you stop using EC2. Naturally, EC2 is totally great for spinning up and prototyping, but from my research its most compelling benefit is geographic dispersal, which can also be accomplished otherwise.