[throwaway894345]

> At $dayjob we have the same mentality and as a result have a load of managed read replicas that are never used for anything (not reporting, not read only queries, not backups because $cloud handles it) that cost every month.

Obviously "let RDS manage your database" doesn't require egregious read replicas. The decision to use read replicas or not is completely orthogonal to whether you use RDS to manage them.

[dwedge]

> Obviously "let RDS manage your database" doesn't require egregious read replicas

Of course not, but an easy checkbox, a best practice AWS or terraform guide and someone doing AWS certified X associate makes it easier to happen without anyone ever really discussing it.

> The decision to use read replicas or not is completely orthogonal to whether you use RDS to manage them.

Assuming you're talking about letting RDS manage anything, then sure - apart from it being more likely to slip through the net if nobody has to configure them. Database is just an expensive cost nobody necessarily drills into.

However if you mean the decision to let $cloud manage the replicas (and keep the primary managed), that totally depends on the cloud and the options. For example have you ever tried having a primary in GCP Cloud SQL but the replica not in cloud SQL?

[throwaway894345]

> Of course not, but an easy checkbox, a best practice AWS or terraform guide and someone doing AWS certified X associate makes it easier to happen without anyone ever really discussing it.

I'm defending your employer or their mindset, I'm just disagreeing with your claim that this follows from the parent's cost analysis claims. It _seems_ like your organization's problems are precisely because they _weren't_ doing the kind of cost analysis that the parent advocated. In other words, nothing in the parent's comment advocated for blindly following some Terraform guide. It feels unfair to the parent to suggest that their mindset caused your organization problems when it seems like your organization's problems were caused by _not having_ the parent's mindset.

[ktaraszk]

They won't let you. It's part of their business to keep you locked in.

[throwaway894345]

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”.

[dwedge]

> 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.

So no, I am talking about lock in.

[throwaway894345]

A company not going out of their way to make it expedient for you to transition off of their cloud isn’t “lock in”.