[softwaredoug]

For those terrified of an AWS dominated future, projects like this are crucial. The closer we can get to OSS based push button open source DB cluster in any cloud, the less we need fear AWS will host everything and lock us in to a walled garden of closed source AWS systems.

[derefr]

I feel like "OSS" is a bit of a misnomer in this case. Your DB cluster, to the degree that it's "production-grade", is partially managed by things like automated upgrade migrations, automatic backups, etc. Essentially, some (centralized!) team associated with the "OSS project" is acting as a devops team for the associated deployments of their project. It's almost as if this team had SSH access to each on-site cluster to ensure their continued smooth operation—but since they don't, they have to do all such maintenance in the form of pre-specifying repair/maintenence strategies, and then building expert-knowledge of when to apply those strategies into the DBMS software itself. But it's still a devops team sitting around doing this—not random contributors.

It's a similar thing with e.g. Ubuntu LTS releases. The core distro might be FOSS, but those branches are uniquely the result of a centralized, corporate devops maintainership ensuring that the silent, automatic security and kernel package upgrades go off without a hitch.

To be clear, I’m not saying you can’t join that maintainership; what I’m saying is that, unlike with a regular FOSS library or framework, or even a regular piece of FOSS daemon software like Apache, in the case of a DBMS, the software will only continue to run smoothly for as long as that maintainership is around to keep it running smoothly. There’s no such thing as a useful unmaintained DBMS, FOSS or not.

And, because of that, the “calculus of TCO” for DBMS projects changes a bit. Unlike regular software, where “proprietary” translates to “higher potential TCO” because of switching costs, in the DBMS case, the “proprietary” vs “open” distinction is nothing next to the “big, healthy maintainership” vs “small, ailing maintainership” distinction. Because, if the DBMS loses all its maintainers? Now you’re stuck maintaining it—at the core level—yourself (and learning how to do so in the process) until such time as you can migrate your data away from it.

Personally, for a production-grade DBMS, I’d trust a corporate-backed (or at least sponsored) product over one which is purely a volunteer effort any day.

[twic]

This is one place where Cloud Foundry genuinely shines. Part of the architecture of CF is that you have stateful data services provisioned using BOSH, CF's orchestration tool. BOSH can talk to a range of infrastructure providers (AWS, Azure, GCP, VMware). You tell BOSH what to provision using a 'release', and there are releases for, amongst other things, MySQL [1]:

https://github.com/cloudfoundry/cf-mysql-release

These releases are used in production by Pivotal, and are actively developed to that end, so they are genuinely production-grade. People have thought carefully about resilience, backups, security, etc. BOSH is a bit awkward, and these releases are tightly coupled to CF, but there's some great work in there.

[deboflo]

You are more likely to get locked in with kubernetes than with AWS. It’s easier to migrate out of highly decoupled, well documented systems piece by piece (AWS) than out of monolithic frameworks like k8s.

[derefr]

I don't see what the problem is with being locked into a "monolithic framework" as long as you can run your own copy of it.

You can take as much time as you like to migrate yourself away from k8s if you don't like it any more (physically migrate your system to your own site; pin the k8s version to prevent API changes; then start changing your code to be less coupled to k8s.)

Whereas, if AWS changes and deprecates a feature, you're on their schedule as to how long you have before your service will break.

[shaklee3]

That makes no sense. Kubernetes leveraged aws primitives (elb) if needed, and at its core, it deploys containers. As long as your application runs in a container, you aren't locked in.

[deboflo]

I think we can agree that Kubernetes does far more than schedule containers, even if “at its core” that’s what it does. How many lines of the 2e6 lines of code k8s project are directly related to scheduling containers? Very few. If a scheduler is all that is needed and you want to use any of the 3 different types of load balancers provided by AWS, a simpler architecture might be just to use AWS ECS. 500 lines of declarative Cloudformation or Terraform will do the job.

[shaklee3]

What features are you referring to specifically that lock you in? Sure, it's a large project. But most LOC are around being modular and pluggable, and adhering to standards (OCI, CNI, CSI). I can't think of anything that would be particularly difficult to move out of if needed.

[deboflo]

There isn’t sufficient separation between components within Kubernetes for ease of migrating piece by piece away from kubernetes. Documentation also plays an important role in migrations. I once counted the pages of documentation for Kubernetes vs AWS for equivalent functionality (VPC, ECS, Route53, etc) and AWS had 20 pages for every page of Kubernetes.

[alexandre_m]

One of the main value proposition of Kubernetes is that you're not locked in to any vendor or infrastructure providers.

If your application runs on K8s, then it's portable and it doesn't have to be aware of the environment or other system integration (e.g storage).

[softwaredoug]

By “lock in” I should have clarified I meant locked in to a proprietary ecosystem. Certainly being dependent on open source can be problematic if you’re not an active member of the community (or if the “community” is really just one company)