Comparing Operator Frameworks

Hello!

I am doing a thesis about comparing different operator frameworks using certain metrics. One of these metrics is documentation. I am interested in what developers are specifically looking for in the documentation when choosing an operator framework. If any has any previous experience in this area it would be helpful if you could give any input.

We have done the backup research and found motivation in previous papers for specific documentation metrics. But those have been open source general. So my line of thinking was I would like to get operator specific metrics, even though they would perhaps be similar.

The frameworks we have looked all the frameworks we could find but we have boiled it down are: The Operator Framework, Kubebuilder, KOPF, Kudo, Java Operator SDK, Shell Operator, Charmed Operator Framework

4 Likes

Interesting project! A very general answer, but if I were looking around for other frameworks, the things I’d be looking out for in docs are: what the framework is for, the context you use it in (eg: K8s, VMs, other), basic examples, and reference documentation. I think we’ve got most of that now in our Charmed (Python) Operator Framework docs: Juju | Juju SDK Documentation

1 Like

I’m not sure if maybe @jamesbeedy or @erik-lonroth have experience with multiple operator framework and could provide some insight into what they look for when scouting for one :slight_smile:

1 Like

I have no experience from tbe frameworks you list. @interfectorem123

But I typically look for:

  • System Architecture of the framework
  • Reference docs
  • Example code
  • Tutorials
  • Clear path of education from beginner to expert

Hope it helps.

Thanks! You included some things I did not think about!

What other operator frameworks (if any) do you have past experience of?

1 Like

I can’t say I’ve spent much time with other frameworks. I discarded something released by VMware some years ago since it was crap by any possible standard. But apart from that, I have no other experience.

@jamesbeedy might have more?