Hacker News Reader

Comment by YawningAngel | Hacker News Reader

> Technical restrictions on interoperability. These are imposed by the leading firms that prevent some of their services working effectively with services from other providers. This means customers need to put additional effort into reconfiguring their data and applications to work across different clouds.

I'm not sure what they mean by this, anyone care to speculate?

View on HN

Sounds like a fancy way of saying vendor lock-in

Microsoft would never do vendor lock-in (:

I'd guess that migrating from any of the local cloud DB variations (Aurora say) is unduly hard once you've migrated to it. But that's just a guess. It is certainly a PITA to migrate, I know that for sure.

Cloud providers will always make their in-house offerings more attractive and easier to use compared to other (open standards) solutions. That's how you get locked in.

I agree with that, but given that a lot of the DBs on AWS and Azure are proprietary software (eg Cosmos and DDB) I'm not sure what ofcom proposes doing about that.

They don’t propose to do anything. They don’t even say that this feature in particular is illegal.

They merely say that after doing a market study, they noticed that: egress fees are significant, technical barriers to interoperability are in place and the discount structure based on committed spending is suspicious. From their point of view, that warrants an actual full investigation by the Competition and Markets Authority.

Considering that Aurora has either a Postgres or MySqL interfaces, you could just dump them using the standard tools.

That's probably not a great example of vendor lock-in.

This is true, but when you own a platform, you don't have to have nonstandard interfaces in order to lock a user in.

For example, they whack your self-hosted or other-vendor-in-AWS options with cross-AZ bandwidth charges that they exempt you from when using RDS.

Reply on news.ycombinator.com