AWS S3 SDK breaks its compatible services
1–10 of 91 posts
Re: AWS S3 SDK breaks its compatible services
#2Many S3-compatible services are recommending that their users use the S3 SDK directly, and changing the default settings in this way can have a direct impact on their users.
This is wholly predictable; AWS isn't in the business of letting other companies OpenSearch them.
Re: AWS S3 SDK breaks its compatible services
#3I'm not sure what the other option is here? Keep old defaults and hope users update?
I wouldn't be happy to find out they did it /just/ to break third-party S3 providers but it seems like it's an easy enough thing to turn it off right?
I'm just not sure how comfortable I am with the phrasing here (or maybe I'm reading too much into it).
Re: AWS S3 SDK breaks its compatible services
#4Another case of Hyrum's Law, where the entire functionality of the S3 SDK and any competing service provider borrowing from it becomes Amazon's problem to fix at their own cost. Maybe it's time for a non-Amazon but S3 API compatible library to emerge among the other cloud storage providers offering S3 compatible APIs. OpenDAL looks interesting. Also another reminder to run thorough integration tests before updating your dependencies.
Re: AWS S3 SDK breaks its compatible services
#5Another case of Hyrum's Law, where the entire functionality of the S3 SDK and any competing service provider borrowing from it becomes Amazon's problem to fix at their own cost. Maybe it's time for a non-Amazon but S3 API compatible library to emerge among the other cloud storage providers offering S3 compatible APIs. OpenDAL looks interesting. Also another reminder to run thorough integration tests before updating y…
The problem here is that if you're providing a public s3 compatible object storage system, you likely have a number of users using the aws sdk directly. It's not your dependencies, it's your users' dependencies that caused the issue.
Re: AWS S3 SDK breaks its compatible services
#6Okay, but I'd never expect an AWS SDK to remain backwards compatible with third-party services and would be leery about using an AWS SDK with anything but AWS. It's on the third parties to keep their S3-compatible API, well, compatible.
On the client side, you just have to pin to an older version of the AWS SDK till whatever compatible service you're using updates, right?
Also, this is the first I've heard of OpenDAL. Looks interesting:
It's had barely any discussion on HN:
Re: AWS S3 SDK breaks its compatible services
#7As a user of S3, but not any service with an S3 compatible API, this execution of the change is perfect for me as I get the benefits with 0 effort - including needing to learn about the availability of the feature.
AWS is beholden first and foremost to their paying customers, and this is the best option for most S3 customers.
Re: AWS S3 SDK breaks its compatible services
#8Many S3-compatible services are recommending that their users use the S3 SDK directly, and changing the default settings in this way can have a direct impact on their users. This is wholly predictable; AWS isn't in the business of letting other companies OpenSearch them.
I don’t think that the article at least state it was malicious. Also some (major?) businesses benefits exist when your company sets the standards for a large market
Re: AWS S3 SDK breaks its compatible services
#9Another case of Hyrum's Law, where the entire functionality of the S3 SDK and any competing service provider borrowing from it becomes Amazon's problem to fix at their own cost. Maybe it's time for a non-Amazon but S3 API compatible library to emerge among the other cloud storage providers offering S3 compatible APIs. OpenDAL looks interesting. Also another reminder to run thorough integration tests before updating y…
The problem here is that if you're providing a public s3 compatible object storage system, you likely have a number of users using the aws sdk directly. It's not your dependencies, it's your users' dependencies that caused the issue.
Which you told them to use.
Re: AWS S3 SDK breaks its compatible services
#10As a user of S3, but not any service with an S3 compatible API, this execution of the change is perfect for me as I get the benefits with 0 effort - including needing to learn about the availability of the feature. AWS is beholden first and foremost to their paying customers, and this is the best option for most S3 customers.
[flagged]