Thread

1. curuinor · 1789512623 · focus · HN ↗

   They guaranteed 11 9's durability, didn't they?

   e: Yep

   <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;s3&#x2F;storage-classes&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;s3&#x2F;storage-classes&#x2F;

   1. beejiu · 1789595396 · focus · HN ↗

      The SLA excludes force majeure.

      1. the8472 · 1789597464 · focus · HN ↗

         Making a probabilistic claim while excluding a factor that dominates those statistics is... is quite creative accounting.

         1. mpyne · 1789598879 · focus · HN ↗

            Are you saying that most data loss happens because your data center gets blown up in a shooting war? Like, AWS is the first digital service provider to lose data in decades?

            1. the8472 · 1789600366 · focus · HN ↗

               I&#x27;m saying that if you have eliminated more mundane failures like dying harddrives, cosmic rays and so on from your systems and your calculation ends up with 11 nines then actually those &quot;force majeure&quot; events are probable enough that they dominate whatever other residuals are supposedly hiding in those last 0.0000000001%.

               The region has seen a bunch of wars in the last 100 years, so the annual war-rate is &gt; 1%. Even if we generously add the assumption that only 1 in 100 wars affects a datacenter you can see that wars become a major source of correlated hardware failures that they need to solve to actually deliver that kind of reliability.

               1. ployable7 · 1789607549 · focus · HN ↗

                  You don’t want to blend probabilities like this, because the tactics you use as a consumer vary between the two. If you consider 11 9s like “object AFR”, you might build systems that are resilient to very occasional single object loss. And it’s useful to know at what rate that might occur.

                  Whereas with these force majeure events you’d want a complete DR setup, and it’s typically an async recovery. Here it is useful to understand the fault domain (single server or single building or multi-building) so you can plan.

                  Blending the two numbers doesn’t help you build better against the systems. And the force majeure events are rare enough that they won’t happen … until they do. I’m not sure that knowing the precise probability that Iran would attack a gulf nation would change the fact that if they do, you need to have a DR story.

                  1. the8472 · 1789645247 · focus · HN ↗

                     Seems like begging the question to me. You can&#x27;t blend the numbers because amazon didn&#x27;t blend the numbers. If they did and miraculously still arrived at 11 9s then that would also cover things such as wars and natural catastrophes, e.g. because they do offsite backups internally.

                     1. ployable7 · 1789651491 · focus · HN ↗

                        I’m not saying you can’t blend the numbers, I’m saying you shouldn’t blend the numbers. Because one number doesn’t communicate what you actually need to know to build.

                        You want to know how reliable the service is in steady state. For example it’s useful to know that S3 is effectively lossless in steady state whereas EBS volumes have an AFR of about 0.1%. You build your apps very differently between S3 and EBS knowing this. You can build highly resilient applications on each, but you code them differently, informed by these design goals.

                        You separately want to understand the failure modes that will require you to fully recover from backup. For example knowing that cloud storage is resilient to everything but region failure would inform you that your backups should be out of the region, not just a bucket in the same region. You don’t get that perspective from just a 9s number.

Unofficial Hacker News client; not affiliated with Y Combinator.