6 ms·

This is interesting for a few reasons. IMHO, the original deprecation plan was reasonable. Not generous, but reasonable. Especially compared to what other cloud

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.

DVassallo 7y ago
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/ https://aws.amazon.com/s3/faqs/. To honor that claim, AWS has the burden to support v1 URLs until the end of the internet.
- whoisjuan 7y ago
  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.
  - mantap 7y ago
    The distinction is academic if you don't have the ability to change the URL.
  - DVassallo 7y ago
    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=https://s3.amazonaws.com&hl=en&sa=X&ved=0ahUKEwiA2tek3o3iAhWYHjQIHVOjDSwQ6AEIKjAB#v=onepage&q=https%3A%2F%2Fs3.amazonaws.com&f=false https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
    - draw_down 7y ago
      Using URLs you don't control in a book is just a bad idea all around. If you're reading a book some years after its publication, a URL that still does work will be the exception.
    - oconnore 7y ago
      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.
      - DVassallo 7y ago
        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=21 https://twitter.com/dvassallo/status/1125502432924975104?s=2...
    - whoisjuan 7y ago
      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.
    - kalleboo 7y ago
      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.
- nemothekid 7y ago
  It's pedantic, but durability has little to do how the object is routed. The object is still there.
  - deleted 7y ago
    [deleted]
  - lugg 7y ago
    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.
EugeneOZ 7y ago
Could you please clarify what Google Cloud did in comparison? I'm not arguing, just want to know more about Google Cloud.
- deleted 7y ago
  [deleted]
snarf21 7y ago
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.

DVassallo 7y ago

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/ https://aws.amazon.com/s3/faqs/. To honor that claim, AWS has the burden to support v1 URLs until the end of the internet.

whoisjuan 7y ago
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.
- mantap 7y ago
  The distinction is academic if you don't have the ability to change the URL.
- DVassallo 7y ago
  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=https://s3.amazonaws.com&hl=en&sa=X&ved=0ahUKEwiA2tek3o3iAhWYHjQIHVOjDSwQ6AEIKjAB#v=onepage&q=https%3A%2F%2Fs3.amazonaws.com&f=false https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
  - draw_down 7y ago
    Using URLs you don't control in a book is just a bad idea all around. If you're reading a book some years after its publication, a URL that still does work will be the exception.
  - oconnore 7y ago
    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.
    - DVassallo 7y ago
      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=21 https://twitter.com/dvassallo/status/1125502432924975104?s=2...
  - whoisjuan 7y ago
    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.
  - kalleboo 7y ago
    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.
nemothekid 7y ago
It's pedantic, but durability has little to do how the object is routed. The object is still there.
- deleted 7y ago
  [deleted]
- lugg 7y ago
  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.

EugeneOZ 7y ago

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

deleted 7y ago
[deleted]

snarf21 7y ago

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.