There are a lot of Postgres operators. Wondering if a CNCF endorsement would place it as the “by default” operator to use. Could this reasoning be extended to other databases and stateful applications?
The project has just been submitted to the CNCF Sandbox, it hasn't yet been accepted. There's a lot of road to be done. If we get accepted, we'll be honoured to adapt and contribute to the project until incubation.
However, what is important here though is that this is the first operator for Postgres whose IP is now owned by a vendor neutral and openly governed community - or at least aims to be based on the public GOVERNANCE policies. We look upon the CNCF for principles and values.
There is a need to standardize operators. Not only to streamline their usage, but also to ensure quality or at least give the community guidelines on what are the best practices to follow when building or using an operator.
That’s probably something the CNCF community should define.
There's definitely commonalities between operators for databases, not only with the same engine, but also different ones and similar primary/standby architecture.
I agree this is something we could somehow work together as a standard kind of spec, but probably we are still at an early stage of the process. My 2 cents.
Agree. Monitoring is a great example. Every DBMS server needs monitoring and it should be exportable to Prometheus. But the commonality ends pretty much ends there, at least in my experience. That's just single instances, too, not complex clusters.
That's another good example of why CNCF is important, as in that ecosystem live technologies that are becoming standard for everything related to infrastructure, including monitoring and alerting. Prometheus is an example, Open Telemetry is another one. When you are able to "interface" with one of these components, you've done your integration job.
From a Postgres standpoint, IMO, it is also important the concept of cluster - as that's what applications connect too - the operator hides the underlying complexity of managing the single instances. And .. also important monitoring sets of clusters from an infrastructure management PoV.
The sandbox submission is not an endorsement from CNCF. It only demonstrates the willingness of the maintainer to create a community-driven, vendor-neutral software following the guidelines defined by CNCF.
Operators seem like a mandatory element for a lot of stateful applications to be working. MySQL, Kafka, OpenEBS, Cassandra… all need an operator to ensure day-2 operations.
I am just wondering if CNCF could provide signals that could help end users pick the right operator among the many out there. They could start with the projects they have in their landscape…
Got it. That's an interesting point of view. I think it makes sense in the data workloads, especially in the database one. Consider for example how database workloads are still lagging behind in Kubernetes, and - most importantly - viceversa (Kubernetes is a hard topic IMO for traditional DBAs).
Operators are there to help in both cases, and this is the goal of our CloudNativePG operator.
IMO CNCF represents an opportunity for vendors of the same database engine to converge in a healthy community and provide the best operator for their platform. This is probably the first stage.
The second stage could be to study those operators (of different engines, like Postgres, MySQL, ...) and generalize commonalities in a sort of standard spec. Just an idea. Is this in line with what you are thinking?
However, what is important here though is that this is the first operator for Postgres whose IP is now owned by a vendor neutral and openly governed community - or at least aims to be based on the public GOVERNANCE policies. We look upon the CNCF for principles and values.
This is our commitment.