Hacker News Reader

IMO these two examples might just be cases they were not optimizing for, and didn't want to invest engineering time (and future support) into something seldomly used.

They are seldomly used because they are difficult to use.

They are difficult to use because using them means loss of money.

Combined with other entrapping features means the all features that help escaping the ecosystem are seldomly used. So any individual products off boarding features are even less used.

These are also features that don't use more than once.

So of course when a product manager looks at usage metrics they see this feature is seldomly used and continue to deprioritize improving it.

Self-fulfilling prophecy.

“Made it easier for customers to migrate to our competitors” isn’t a great look on your review.

“Made our customers happy by allowing them to easily migrate to a self-hosted redis instance in AWS so they were able to build their business and brought in twice as much traffic”.

Your comment echos the crux of the article. Yes, this probably wasn’t an explicit goal for AWS, but the end result is that people aren’t using Amazon’s products because they’re the best, they’re just using them because it’s harder to change or more expensive not to (when it could be cheaper if the playing field was level).

> Your comment echos the crux of the article. Yes, this probably wasn’t an explicit goal for AWS, but the end result is that people aren’t using Amazon’s products because they’re the best, they’re just using them because it’s harder to change or more expensive not to (when it could be cheaper if the playing field was level).

I think you hit the nail on the head, at least regarding my own experiences.

Most of the time when a colleague says “hey we can use X service because Y” in AWS, the “Y” is something along the lines of “because it’s just easier to use Z with it,” where “Z” is another AWS service.

AWS has many impressive tools. That doesn’t mean they’re built with friendliness in mind. Their tools are meant to provide value for money, but a lot of that value is predicated on using other tools they provide. They’re building a platform, not -your- platform.

We learned that lesson early on with my business. We ultimately replaced all but 2-3 AWS services with third parties that were actually best-in-class, and kept the 2-3 from AWS that AWS can honestly say are best in class. It was ultimately more expensive and kludgy to build everything on AWS rather than diversify our stack.

When you see the same case across many cloud providers, data easy to get in and hard to get out, you start to get the point.

It’s “data gravity,” as Dave McCrory put it a long time ago. Make it easy to put your data and workloads on a cloud, the “gravity” makes it hard to escape. The more you have the harder (more expensive) it is to break the pull.