4 ms·
I'm not sure whether the OP is implying that Amazon is guilty of these fallacies or whether AWS's users are. Having worked at Amazon, I can attest that Amazon
by jzila 16y ago
I'm not sure whether the OP is implying that Amazon is guilty of these fallacies or whether AWS's users are.
Having worked at Amazon, I can attest that Amazon does take these issues into account, and many more. That said, the purpose of the services that failed isn't to guard against network partitioning at the data center cluster level. The services that were designed with cluster network partitions in mind are still up (S3, EBS, SQS, etc).
If you are renting instances in a specific data center, and you wish to have cross-cluster redundancy, it is your responsibility to build that into your distributed system. This is ultimately a question of whether you need to commit to an SLA higher than that of the service on which you depend. (It's more complicated than that, but that should suffice for simplicity's sake).
There are companies that built services on top of EC2 to mitigate these risks (e.g. Elastra), and there are competing solutions that provide application-level hosting that should guard against such partitions (e.g. Windows Azure).
- mindcrime 16y agoI'm not sure whether the OP is implying that Amazon is guilty of these fallacies or whether AWS's users are. I had AWS customers in mind, more than Amazon.com themselves. If you are renting instances in a specific data center, and you wish to have cross-cluster redundancy, it is your responsibility to build that into your distributed system. Exactly. It's easy, though, to build something on top of AWS (or Rackspace or whatever) and then stand back, marvel at it's magnificence; and forget that an outage - in a network segment or service that you don't control - can totally wreck your masterpiece.
- jzila 16y agoFair enough. As I mentioned in my earlier post, there are available solutions that mitigate the risks of these fallacies for AWS's customers. When you build on top of a networked service, you are taking a hard dependency on its SLA, and if you need something with greater reliability, it is your responsibility to provide the necessary redundancy.