[not_kurt_godel]

One "downside" of AWS is we've rolled a lot of custom solutions like this, at significant time/expense, only to have them be made obsolete by eventual native feature support. So we get left with a mixture of legacy systems using the custom solution and newer ones using native support and it makes things more complicated. It's actually a good problem to have in many ways, and basically unavoidable in many circumstances, but an interesting dynamic nonetheless. Reminds me of interstellar wait calculation[0] - do we defer dependent features until there's native support, or forge ahead knowing there's a likelihood of being 'overtaken'?

[0] https://en.m.wikipedia.org/wiki/Interstellar_travel#Wait_cal...

[joemag]

Another way to look at it: customers like you, who build custom work arounds to some problem, influence our decision that a particular problem is important enough to be solved.

[not_kurt_godel]

Yup, and that's overwhelmingly a good thing! The one thing I will say is that AWS does tend to lean on this attitude a bit too much, IMO, with a tendency to ignore common sense about what people will inevitably need, thus causing the kind of thrash I described when it could have been avoided. It is erring on the right side of delivering vs waiting generally, but the balance could stand to be fine tuned.

[cortesoft]

Nothing is forcing you to switch from your custom solution to the native support. If you don't switch, you are in the same situation as if they native solution was never invented.

[y4mi]

Nothing except every new hire that complains having to learn it instead of the native solution.

It's just like the parent said very much a first world problem/ good problem to have, as it's a situation which only exists if you're in a very productive team