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?
bipbip4242|3 years ago
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…
gbartolini|3 years ago
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?
Thanks!