[martingxx]

> what can k8s do to AWS SaaSes (e.g. RDS, SNS, etc...)?

k8s has allowed us to not use RDS any more because we now host PostgreSQL inside k8s instead. It's a bit more overhead, but we're now portable and run in gcp too with the same k8s manifests and almost no porting effort.

So yeah, we escaped the lock-in.

And now we're not just tied to the AWS stuff and we're experimenting with cockroachdb and other products that aren't there "natively" in AWS, so beyond escaping lock-in, we're more ready to experiment with newer stuff.

[scarface74]

So you “escaped lock-in” at what cost? Did you save any money up front? Did you save Developer time or do you think their time is free because they are willing to work 60 hour weeks or spending time managing infrastructure instead of adding business value?

What is the fault tolerance of your hosted Postgres solution compared to Aurora?

[philliphaydon]

Everyone keeps talking about vendor lock-in. In regards to RDS you can still export your database and move somewhere else. But we use it because we don’t want to manage the database, we don’t want to worry about availability zones and syncing the data and failing over for updates. I don’t want to setup k8s instead and configure it and maintain it. That stuff is boring for me.

[marcinzm]

The vendor lock is is not the data in RDS, it's the ops code that sets up and integrates RDS with everything else you do. K8S allows you to use the same code to setup a database, or most anything else, in any cloud host.

[pbalau]

My only ops code is a thin wrapper over the secrets manager API, that converts from a secret to something Django orm or sqlalchemy can use to connect.

My pain point is db migrations, from version X to version Y. My bad to pick Django for our internal tooling web app and go with its orm. Fairly confident that I can change that to sqlalchemy easy, if I get the time for it.