[ashtonkem]

You might accept it, but I wouldn’t. Telling product owners that their timelines have been pushed because our cloud provider is removing something we depend on again is not a conversation I want to have.

Large enterprises are complicated beasts, and they value stability a lot. Even removing a single feature might cause dozens of teams to drop everything in order to go and fix the mess that someone else made. Why risk it? Especially if the alternative is someone who will wait to release a feature until it’s more than half baked and support it for a decade or more?

[etxm]

I said “on occasion,” not time after time.

I think purging some of the lower quality services from a catalog of over 175 (AWS) services would be a net positive, because orgs wouldnt come along and build on top of sore ice that may not be as extensible as you need it two quarters from now.

[sturgill]

I disagree. Perhaps AWS should be more selective in what they choose to launch, but once a service is launched you should have a very compelling reason to deprecate it. This creates a positive feedback loop that AWS is safe —- in the sense that if you build on top of their services you know that they will continue to be around.

It makes the AWS dashboard a bit more cluttered, but if you use one of AWS’ half-baked services you know it will be around for as long as you want. Maybe you outgrow it; that’s fine. You can opt to move off, but AWS won’t force your hand.

There’s a ton of value in that stability. Your MySQL server running on EC2 still works today if you haven’t migrated to RDS. And if you migrate to RDS, you can be confident that it will be around until well after you’ve moved to your next job.

Ironically, this is related to Golang’s strong 1.X backwards compatibility guarantee. Knowing that what works today will work tomorrow has tremendous value. You don’t have to wake up and migrate everything from vendor to modules. You can build on ECS today and have confidence ECS will be around tomorrow.