More likely it’s just not worth going out of their way to support niche deployments like that. I’ve been using various clouds for years, I’ve done half a dozen cloud migrations, currently working at a multicloud org—the vendors aren’t doing much to lock us in. They very much enable us to move platforms by offering things like bulk data transfer tools, standard application runtimes like Kubernetes, workload identity federation (use external identities as principals in the cloud provider’s IAM system, etc).
Like I have no doubt that they’re all greedy bastards, but they aren’t doing much to lock people in. The people who complain about lock in are usually talking about “cloud providers making their services so much easier to use than bespoke platforms on bare Linux hosts such that no one will want to go back to the latter”.
> Like I have no doubt that they’re all greedy bastards, but they aren’t doing much to lock people in.
A few years ago we were trying to do a live migration from on-prem into GCP (mostly to have GCP as a failover option but move everything there if on-prem went down). We configured an async GCP slave from the on-prem cluster and once running it was easy. Multi-TB migration straight into CloudSQL with seconds of downtime.
Before we signed this off, we also tested the reverse - getting back from CloudSQL into on-prem. Turns out you couldn't (at the time, I'm not sure about currently) use CloudSQL as master for an external slave, only a slave to an external master. You could migrate the data in with no downtime, to get it back out was a multi-TB transfer. The door only opens one way.
Like I have no doubt that they’re all greedy bastards, but they aren’t doing much to lock people in. The people who complain about lock in are usually talking about “cloud providers making their services so much easier to use than bespoke platforms on bare Linux hosts such that no one will want to go back to the latter”.