Hacker News Reader

Comment by blaisio | Hacker News Reader

This is interesting for a few reasons. IMHO, the original deprecation plan was reasonable. Not generous, but reasonable. Especially compared to what other cloud providers (eg. Google Cloud) have done. It did seem like a diversion from their normal practice of obsessively supporting old stuff for as long as possible, but it really wasn't too bad.

Responding to feedback, publicly, and explaining what they were trying to do and why they needed to do it, is incredibly refreshing.

This seems like a big PR win for AWS. I'm left trusting and liking them more, not less.

View on HN

How was the original plan “reasonable”? S3’s FAQ talks about durability in terms of tens of thousands of years https://aws.amazon.com/s3/faqs/. To honor that claim, AWS has the burden to support v1 URLs until the end of the internet.

Storage durability has nothing to do with this. Changing how you access data saved in storage is a reasonable change to keep up with the evolution of networking technologies.

The change here was deprecating an access pattern, not destroying data or anything remotely similar.

The distinction is academic if you don't have the ability to change the URL.

Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h...

And thousands of other books like that.

Did they discuss that with Amazon prior to publishing? That seems like a completely silly assumption to make for a product that’s been around for only 13 years.

Also every AWS book out there that has instructions on how to install the AWS CLI uses the v1 URL! You know why? Because that’s the official URL! https://twitter.com/dvassallo/status/1125502432924975104?s=2...

Why would they think/assume that URLs have infinite durability? If you buy a floppy disk with some data, it's very likely that you can still get the data that it holds if you manage to get a Floppy Disk Drive. But you cannot expect any change in the evolving conditions that allow you to get a floppy disk driver.

It's very likely that there would be something that replaces URLs in the future.

Amazon promise seems to be that they will always keep your data integrity and keep it accessible. The way I see is that they will be moving my data to newer or better storage types and will keep my data unchanged regardless of any technology change.

To keep with the analogy, Amazon's promise here is that they will always keep the data that you originally stored in your floppy disk, but they cannot promise to give it back to you in a floppy disk. Next year they might give it back to you in a CD and the year after in a cartridge.

The data has been always there, intact. They are just giving it to you in a different medium.

Testing some of the other, non-s3 links in that bibliography, they're also all dead.

I'm not supporting the old deprecation policy, in fact I thought it was insane. But if anyone publishes a URL assuming that it won't disappear they've not been paying attention. If the peace corps just migrated to Azure instead the links would also die.

We're arguing over semantics. Here's the exact quote from the page you linked:

> designed to provide 99.999999999% durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001% of objects. For example, if you store 10,000,000 objects with Amazon S3, you can on average expect to incur a loss of a single object once every 10,000 years

They are referring to durability as corruption in the underlying data store due to known storage-technology risks. If they were to take into account all other risks, they would also have to include the risks of nuclear war, cyber warfare, the US government classifying your organization as a terrorist threat, etc etc.

It's pedantic, but durability has little to do how the object is routed. The object is still there.

That's not being pedantic.

A move operation is representationally an atomic copy and delete.

The original object is clearly no longer there.

It's clear cut breaking backwards compat for no reason at all.

I don't even know why they aren't supporting both API versions indefinitely it doesn't really make any sense it's literally a url rewrite/301 for anything hitting the old domain. Want to avoid our bottleknecked legacy LBs for better performance? Hit the new LBs. Hell even the sdk doing this upfront will alleviate a crap tonne of legacy requests.

People need to stop allowing corps making breaking backwards compat so nonchalantly it's unprofessional. And on top of that, AWS has a really good track record of maintaining backwards compat, allowing them to get away with this is just asking for more down the line.

Could you please clarify what Google Cloud did in comparison? I'm not arguing, just want to know more about Google Cloud.

It is good to see them modifying their plan. I get the need to have stable APIs but the reciprocal challenge of updating APIs to handle new use cases and scale better.

The think that I wish companies would do in this case is the following. Set a hard date for when the change will happen (hopefully giving at least 18 months). Then, send a weekly (monthly) report detailing the number of things a customer has that isn't compliance. For example, every week AWS could send a report summary to the account holder of any URL accessed via the path structure. They could then login to see more details. A lot of systems are sprawling and people are busy putting out fires so a constant reminder and hard end date keeps it top of mind for people so you don't end up working through the weekend trying to get something back up and running. I wish Apple would do this for deprecated APIs (e.g.), email me regularly that I have an app in the store that is using deprecated APIs and they will stop working on date X.

Reply on news.ycombinator.com