Hacker News Reader

Comment by donatj | Hacker News Reader

I am old enough that I still remember people including myself being perplexed why s3 didn't ship with an FTP adapter. They FINALLY added the option in 2020, 14 years late.

I do think the storage "space" could use some disruption. I use s3 every day at work, and my general feeling is that the entire permission system is more complicated than 99% of apps actually need, to the point of being dangerous; I think the complexity has absolutely contributed to so many people getting it wrong and leaking data.

An alternative where the only options were public and private, exclusively set at the bucket level would be good enough for 95% of users and simple enough to rarely get wrong.

View on HN

This is classic feature bloat of a product that's been around for a while. Some customer wants a really niche feature so product adds a new option for it. It's just one new option so the experience isn't that different. Rinse and repeat hundreds of times and nobody stops the think of the cumulative effect on the 99% of customers who don't need those features.

I was going to say that the cloud now has to be all things to all people; it feels like a reason that products cycle in and out of fashion. I'm not a heavy cloud user, but in my memory, AWS was extremely simplistic back when it debuted - it was a few core services and lacked a lot of features enterprises required which in my mind gave it a sort of "toy" quality I think and was one of the reasons I was a bit of a cloud skeptic. The "S" in a lot of AWS services (to include one of the "S"'s in S3) actually stands for simple, but clearly things have moved on a bit.

This is true for all of Amazon's products. They enshitified everything by being beholden to never-ending customer requests for more fine knobs. Their products have a serious "let's just bolt this on" vibe. There is no theme or reason to it.

AWS went from "just push a couple of buttons and you are running in the cloud without a dedicated sys admin" to "you are going to have to hire a team of cloud admins because no one understands all the options and costs anymore".

Compare AWS to DigitalOcean, for example - the difference in simplicity is mind-blowing.

It's just different maturity stages of different products. It's very hard not to add features when your bottom line depends on it.

There is a middle ground, however, between Amazon's "let's pile on more stuff until it's incomprehensible" and Google's "ah let's just kill the whole thing".

The latter will really get your customers torqued, the former is going to make some customers not get exactly what they want.

Maybe in the early days this would have made sense, but the cloud vendor lock in is so strong that I seriously doubt most customers even have the leverage. "Add this feature or we are walking to Linode"?

I don't think so. It just seems like a broken product design culture, where the managers need to add features non-stop, so they can make some slides and get their raises. Big company problems, to be sure, but still disfunctional.

> Rinse and repeat hundreds of times and nobody stops the think of the cumulative effect on the 99% of customers who don't need those features.

Does it cost anything to not use features you do not need?

Last time I checked, all the so-called niche features were stashed in hierarchical option lists, outside of the happy path. You need to purposely want to dig into, say, file access, bucket access metrics, storage strategies, object versioning, etc to actually get to them.

It costs time whenever a coworker has toggled the wrong setting and you must debug.

It costs time whenever some coworker asks for something impossible, and says something like "Have you really checked all the options?"

> It costs time whenever a coworker has toggled the wrong setting and you must debug.

Why do you have team members toggling settings at random at will?

If that's a real problem with your organization, you have far more pressing problems than the number of options offered by a service you consume.

Everywhere I've worked had either people who made mistakes, people who made unrealisic demands, or both.

I guess you'd be the type with unrealistic demands.

the cost is usability. When there's dozens of options you don't need or care about, you have to spend the time to understand what they are to realize you don't need them

Complexity without ease of use costs. S3 kind of forces you to use those features. If all you wanted was just a public/private access, you're forced to read into the complexity of S3's complex permission system.

So, to be fair, yes it costs to not use features you do not need in this case.

You literally pay by the hour to use S3, and you also pay the hours you spend trying to understand the permissions and modify settings, so it literally costs to not use the features you do not need in this case. I'm trying to make an argument, I'm not saying you pay much, but I answered your question, and you do pay, either by time, or money.

> S3 kind of forces you to use those features.

Not really. In order to set bucket request metrics not only you need to explicitly set your bucket to be open to the world but you also need to dig down the options to explicitly enable them along with a metrics filter of what objects you cover.

Object versioning is disabled by default and you need to go way out of your way to enable them at a specific level.

You also need to go way out of your way to set another object storage class.

None of these features are enabled by default. You need to turn them on and configure to start using them.

While that's true, they might have made it easier for customers if they decided not to deprecate bucket ACLs. They are even hypocritical there in the sense that their own product (Control Tower) uses bucket ACLs whereas they tell customers not to use them. ACLS were ultra-simple - mosltly READ, WRITE, FULL_CONTROL - very little margin for error.

Of course you still have complexity as you have the bucket owner, object owner and requester which might be 3 different entities, but still mentally easier to grasp than policies with dozens of options you need to read documentation for to understand what they are for and what the consequences of using them are.

Absolutely agree. The ideas of 'publically accessible' files on S3 is so convoluted and the copy is not at all clear despite them adding all-caps in multiple places...

And then policies are an attempt (I think) at simplifying permissions to a bucket with one declaration, but in practice what I see are people copy-pasting decades-old (really!) policies from other projects because most of us just need to get a private file store up and running.

Platform exhaustion - I have to know so much about AWS to not make a huge mistake that it takes away from my actual product development work that my company expects out of me.

Reply on news.ycombinator.com