Stop Writing Operators

• Should this operator be written at all?

• Should I write it?

• What functions should my operator perform?

• What API permissions will my operator need to perform those functions?

• What framework should I write my operator in?

- Pretty serious

- Not like, we-can't-be-friends-unless serious though

Are you saying operators are bad?

- No! Operators are good!

...in the proper places

"...application-specific operational knowledge encoded into software that leverages the powerful Kubernetes abstractions to run and manage the application correctly..."

Meant for managing stateful apps

- All operators are controllers but NOT all controllers are operators!

- A controller that does nothing stateful is just a controller (and that's OK)

No statefulness

- or-

Kubernetes has all the necessary state handling

Creating an operator is over-abstracting the problem

You now have an extra component susceptible to failure

- No: microservices remain abstracted from one another. Operators inherently don't.

Not trying to manage state at all is easier to do safely

Top-level controller implements the management primitives

You write declarative config to implement your operator logic

No longer limited in scale or architecture by needing to fit into the cluster

- But you will still have to manage RBAC, and handle authentication

...and its state has to be managed inside Kubernetes

Definitely not ideal

Engage the app maintainers as early and often as possible

- They might even be willing to take on smaller state-handling feature requests

Your app can take fuller advantage of Kubernetes features

- The operator provides state handling to run your app in older versions of k8s

- The operator provides functions for your app that have not landed in Kubernetes yet

This is fine on a temporary basis

You should not write an operator for things until:

- you've spent as long recovering from failure or dealing with lack of management

- as it would reasonably take you to write the operator

Failure is where we learn

- Learning from failure is even more critical when we automate

Is that all you're doing?

- If so, look at some of the non-operator methods of handling these tasks first

An operator with no forward compatibility assurance is a time sink waiting to happen

Don't assume 1.x means SemVer-level stability is in effect

The app owner knows their app better than anyone

...in fact, they might already be writing what you need

• Get started looking at the operator landscape

• Can you write in one of your preferred languages?

• Does its model fit both into your environment and into your head?

• Does the framework maintainer provide framework-related services you want to use?

• Maintain loose coupling

• Remember, no code is often better

• Write what you know (then stop)