Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects • Hacker News Board

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#61

Post by ignoramous » Mon, Mar 15, 2021, 4:56 PM UTC

tw04 wrote: post #47

jodrellblank wrote: post #31

Earlier quoted context omitted.

This recent interview with Werner Vogels[1] touches on S3 design priorities as well: https://cacm.acm.org/magazines/2021/3/250706-a-second-conver... https://news.ycombinator.com/item?id=26365873 [1] which you commented on, but others might not have seen.

>Most of our customers, if they have on-premises systems—if they're lucky—can store two objects in the same data center, which gives them four 9s. If they're really good, they may have two data centers and actually know how to replicate over two data centers, and that gives them five 9s. But eleven 9's, in terms of durability, is just unparalleled I have a tough time taking him seriously reading this - I'm not sure i…

> I don't know of a single enterprise customer that doesn't have their data replicated to two datacenters, and then backed up to some other medium (tape or disk-based backup appliance) for anything business critical.

You snipped out the part of the quote that answers your question.

"Most of our customers, if they have on-premises systems—if they're lucky—can store two objects in the same data center, which gives them four 9s. If they're really good, they may have two data centers and actually know how to replicate over two data centers, and that gives them five 9s. But eleven 9's, in terms of durability, is just unparalleled. And it trumps everything."

> I don't know of a single enterprise customer that doesn't have their data replicated to two datacenters...

Except, in AWS' case, each AZs (Availability Zones) is made up of upto 8 DCs (Data Centers), and each full-region has at least 3 AZs and 2 Transit Centers. Amazon S3 replicates data to 3 different AZs (which, I am guessing, is in addition to replicating it across DCs in a single AZ for 'eleven 9s').

With S3 cross-region replication durability may shoot up to 'sixteen 9s'? 100% durability, if it exists, is something the major Cloud providers are yet to offer?

ref: https://maisonbisson.com/post/object-storage-prior-art-and-l...

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#62

Post by astuyvenberg » Mon, Mar 15, 2021, 4:59 PM UTC

luhn wrote: post #59

astuyvenberg wrote: post #43

Earlier quoted context omitted.

When people talk about avoiding vendor lock in with AWS, they tend to talk in terms of using k8s or another compute abstraction layer. But I think the real lock-in lies in services like S3, making so many workflows simple and intuitive (while controlling your data, which is where the real lock-in lies)

Yeah, even if you don't use any vendor-specific features, there's data gravity—It's hard to move your data from one location to another. AWS and others increase this cost even further by making egress so expensive.

Precisely - vendor lock-in generally happens at the data level. For example, AWS finally turned off their last Oracle DB server only a year or two ago.

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#63

Post by dna_polymerase » Mon, Mar 15, 2021, 5:01 PM UTC

> All of those decisions remain valid and code written on launch day will still work just fine today.

And this is why GCP will never come close to AWS.

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#64

Post by gabagool » Mon, Mar 15, 2021, 5:11 PM UTC

PaulHoule wrote: post #25

I am worried. We will start having trouble with random UUID collisions when we have made 2^64 of them, which is a huge number. It's about as many iron atoms as are in an iron filing. It is also about 200,000 times 100 trillion, so AWS is just 18 doubling times away from the UUID system breaking down.

Is there any specific reason one could not just put two UUID-4's alongside one another?

Also as another commenter mentioned, if they are tied to a namespace prefix, that delays collisions.

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#65

Post by weird-eye-issue » Mon, Mar 15, 2021, 5:46 PM UTC

tpmx wrote: post #49

weird-eye-issue wrote: post #20

Earlier quoted context omitted.

There is no way

It's obviously technically possible .

"Technically possible" that they do it, sure. But I would disagree it is possible that it is S3's "secret sauce".

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#66

Post by tpmx » Mon, Mar 15, 2021, 9:12 PM UTC

weird-eye-issue wrote: post #65

tpmx wrote: post #49

Earlier quoted context omitted.

It's obviously technically possible .

"Technically possible" that they do it, sure. But I would disagree it is possible that it is S3's "secret sauce".

Because?

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#67

Post by weird-eye-issue » Mon, Mar 15, 2021, 9:21 PM UTC

tpmx wrote: post #66

weird-eye-issue wrote: post #65

Earlier quoted context omitted.

"Technically possible" that they do it, sure. But I would disagree it is possible that it is S3's "secret sauce".

Because?

... this is on you to prove it is their secret sauce. Throwing out some random feature and saying it is their secret sauce and putting the burden of proof on somebody else makes no sense.

But it would be because 1) they probably don't have many duped objects to begin with 2) the system to de-dupe items would be complex, error prone, increase latency, and just not worth it

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#68

Post by tw04 » Mon, Mar 15, 2021, 9:22 PM UTC

ctvo wrote: post #54

tw04 wrote: post #47

Earlier quoted context omitted.

>Most of our customers, if they have on-premises systems—if they're lucky—can store two objects in the same data center, which gives them four 9s. If they're really good, they may have two data centers and actually know how to replicate over two data centers, and that gives them five 9s. But eleven 9's, in terms of durability, is just unparalleled I have a tough time taking him seriously reading this - I'm not sure i…

Giving him the benefit of the doubt that he knows his own customers here. He said: > Most of our customers, if they have on-premises systems—if they're lucky—can store two objects in the same data center You said: > I don't know of a single enterprise customer that doesn't have their data replicated to two datacenters His customers don't equal your enterprise customers. You are both right most likely.

Given that part of what I do is help enterprise customers with cloud adoption, almost all of whom are fortune 500 (and on his radar), with an AWS presence, I strongly doubt it.

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#69

Post by tw04 » Mon, Mar 15, 2021, 9:27 PM UTC

ignoramous wrote: post #61

tw04 wrote: post #47

Earlier quoted context omitted.

>Most of our customers, if they have on-premises systems—if they're lucky—can store two objects in the same data center, which gives them four 9s. If they're really good, they may have two data centers and actually know how to replicate over two data centers, and that gives them five 9s. But eleven 9's, in terms of durability, is just unparalleled I have a tough time taking him seriously reading this - I'm not sure i…

> I don't know of a single enterprise customer that doesn't have their data replicated to two datacenters, and then backed up to some other medium (tape or disk-based backup appliance) for anything business critical. You snipped out the part of the quote that answers your question. "Most of our customers, if they have on-premises systems—if they're lucky—can store two objects in the same data center, which gives them…

>You snipped out the part of the quote that answers your question.

Replicating across two datacenters isn't "really good" though, that's considered table stakes.

>Except, in AWS' case, each AZs (Availability Zones) is made up of upto 8 DCs (Data Centers), and each full-region has at least 3 AZs and 2 Transit Centers. Amazon S3 replicates data to 3 different AZs (which, I am guessing, is in addition to replicating it across DCs in a single AZ for 'eleven 9s').

In AWS' case, the 8 DCs in an AZ are directly adjacent which isn't really useful for anything beyond metro (active/active) availability. I haven't seen a DR plan that doesn't have a hard requirement for the secondary copy of data to be outside of the metro loop/blast radius generally in a different state.

Re: Amazon S3’s 15th Birthday: 5,475 Days and 100T Objects

#70

Post by tpmx » Mon, Mar 15, 2021, 9:46 PM UTC

weird-eye-issue wrote: post #67

tpmx wrote: post #66

Earlier quoted context omitted.

Because?

... this is on you to prove it is their secret sauce. Throwing out some random feature and saying it is their secret sauce and putting the burden of proof on somebody else makes no sense. But it would be because 1) they probably don't have many duped objects to begin with 2) the system to de-dupe items would be complex, error prone, increase latency, and just not worth it

> 1) they probably don't have many duped objects to begin with

That's crap reasoning. You have no way of knowing that.

> 2) the system to de-dupe items would be complex, error prone, increase latency, and just not worth

Would it really be that complex? I kinda doubt that.

Read latencies wouldn't be affected - except being improved.

Write latencies - the deduplication can happen after the write has been confirmed, so no extra latency added.

Whether or not it's worth it - I think it's very hard to to estimate the deduplication factor. My guess is 1.5x. At that point it would save 33% storage. That would instanly make a whole lot of extra complexity worth it.