<i>But mostly it’s because the cloud has been so darned reliable.</i><p>Or because the cloud has offered such a good value proposition for cheap and easy scaling with demand.<p>And anyway, it's unfair to rail on people who "should have had a redundancy plan" when the service they pay money for is one with a redundancy service included in it (availability zones) which has unexpectedly also failed.<p><i>Our point stands, for engineers to consider all likely scenarios when building redundancy and not assume anyone – even Amazon – can provide 100.0% uptime. </i><p>Your point appears to be "If you don't have 100% uptime then it's all your fault and you should have planned for it you lazy idiot, everyone should blame you. Also you can never have 100% uptime so people should stop blaming Amazon.". Do you have more of a point than that?
Cloud = Virtualization. Creating redundancy within the same virtual ecosystem is idiotic, as the article points out. Any hardware or virtualization software failure would throw your redundancy out the window. You need to have your virtual eggs in very different baskets, in different geographical locations, with different providers.
All hosts are vulnerable to outages, be it in the cloud, typical shared hosting or self managed racks in a data center.<p>Shit is going to happen with your host. To say it's a problem with the cloud is unfair.
Isn't the primary benefit in cloud servies reliability? If one of the largest cloud services has an Achilles heel, doesn't that defeat its purpose?<p>I was under the impression if one of the clusters were to be unavailable, the nearest mirror would resume responsibility. This should include distribution services as well.