4 ms·

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

by jvans 2y ago

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.

silverquiet 2y ago
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.
renegade-otter 2y ago
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.
- mping 2y ago
  It's just different maturity stages of different products. It's very hard not to add features when your bottom line depends on it.
  - renegade-otter 2y ago
    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.
chipdart 2y ago
> 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.
- Arnt 2y ago
  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?"
  - chipdart 2y ago
    > 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.
    - Arnt 2y ago
      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.
- jvans 2y ago
  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
- eksapsy 2y ago
  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.
benterix 2y ago
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.

by jvans 2y ago

silverquiet 2y ago

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.

renegade-otter 2y ago

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.

mping 2y ago
It's just different maturity stages of different products. It's very hard not to add features when your bottom line depends on it.
- renegade-otter 2y ago
  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.

chipdart 2y ago

> 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.

Arnt 2y ago
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?"
- chipdart 2y ago
  > 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.
  - Arnt 2y ago
    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.
jvans 2y ago
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
eksapsy 2y ago
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.

benterix 2y ago

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.