[operator-whitepaper] Version 2 of Operator Whitepaper

[thschue]

trafficstars

The current version of the operator whitepaper is around one year old, and there might be things that could be added or changed in the whitepaper (use-cases, examples).

Action Items:

• [x] Discuss if we want to create an updated version
• [ ] Find out what we want to add (create issues)
• [ ] Update the Whitepaper (create parts as issues)

FYI: @Jenniferstrej, @OmerKahani, @AlexsJones (and what do you think about this?)

[thschue]

As discussed in the last tag meeting, we will create an updated version of the whitepaper. If someone has some ideas for improvement, comment here and/or create an issue for the change.

[AlexsJones]

I would welcome opening this up for a version 2. We could potentially cover these areas:

• State of the union with Operators ( their usage throughout the industry compared to previous paper )
• New Operator patterns
• Extension/Deep dive of some of the areas within the original document ( How is data and configuration now thought of within Operators in the context of integrity, security, regulation etc) .
• Operators at the edge, IoT

[joshgav]

Let's consider the relationship of the operator pattern to the GitOps pattern. I posit that GitOps depends on operators. That is, for a declaration in a git repo to successfully result in an artifact running in a cluster requires an intermediary - a reconciling operator - that watches the source and reconciles the target to it. An operator therefore is a service capable of watching declarations and reconciling targets to them. GitOps depends on many operators, and true GitOps maturity perhaps implies that all target artifacts are controlled by operators.

Per this view, we would think of the likes of ArgoCD and Flux as generic operators which can reconcile many custom business apps and components. We would view bespoke Kubernetes controller-managers, Operator Framework operators and provider services like Azure's Resource Manager as highly-specific operators which reconcile highly-specified resource types like databases, networks and identities. Both would be needed to enable GitOps processes.

A corollary statement could be that generic GitOps tools like Flux and ArgoCD bring the operator pattern to "the rest of us" - the "rest of us" being folks who benefit from a complete-yet-configurable reconciliation/operator/GitOps framework. Those who want more control could graduate to a bespoke operator built with Operator Framework.

[AlexsJones]

generic GitOps tools like Flux and ArgoCD bring the operator pattern to "the rest of us"

I think that's really interesting, I also feel that GitOps operators could be viewed as ways of assimilating external state into the cluster, therefore by distinction we are acknowledging there are categories of Operator behaviour - something not yet explored.

It's an interesting area to explore and really would be great to invite folks such as @scottrigby and others into the conversation.

[roberthstrand]

I also feel that GitOps operators could be viewed as ways of assimilating external state into the cluster, therefore by distinction we are acknowledging there are categories of Operator behaviour - something not yet explored.

I think this sounds like a fun thing to explore.

[thschue]

Created a meeting for catching up on ideas/topics for the update: https://community.cncf.io/events/details/cncf-tag-app-delivery-presents-tag-app-delivery-operator-whitepaper-v2/

[grzesuav]

@thschue I cannot join the meeting, but I can think of :

• operator performance, how to write operators which both are fast and do not overkill the API server
• multi-cluster operator patterns, do exist any library / tooling which can help with that