[a13xb]

> Not trying to be negative, I'm a fan of how much power AWS gives you.

I am.

I find AWS API incredibly baroque and has a lot of historic baggage. I suspect a lot of this complexity is a result of an accumulation of features made by multiple people in multiple teams over the years and inertia of customers relying on it, so there is (understandably) no will to change it.

[plange]

Classic mistake. Except it's not really a mistake, but a conscious decision by whoever was in charge at the time (with the main focus probably being growing the company and not hurting current customers).

How do we fix that though? Standards seem like the only solution but they either don't move fast enough or the early birds (in this case amazon, but another prime example is microsoft) become so entrenched they set the standard themselves.

My own answer up until now has been to work in linux and open standards jobs (now kubernetes) but this requires increasing amounts of effort.

[samstave]

I'd say that the best way to "fix" it - is to have new iterations/versions of an entire region that comes online with an updated stance on all aspects of environment management: deployment/security/auth etc..

Let new infra come up in the new region with auth-gateways to allow the new to talk to the old and vs versa...

maybe you put an S3 mirror of data from new-bucket-type to an old-bucket-type for RO data access from within the old region for data created in the new...

old users can make functional requests of the new api - but cannot manipulate anything directly...

Or some such model -- but role out wholly new regions and sunset old over time. (A new region can be us-east-3 next to us-east-2 and can sit in the same physical location to allow for in-house data transit on AWS' part, etc.)