►
From YouTube: Stop Writing Operators - Joe Thompson, HashiCorp
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Stop Writing Operators - Joe Thompson, HashiCorp
Since the introduction of the operator pattern by CoreOS in 2016, operators and even operator coding frameworks have proliferated seemingly without limit. But *should* you write an operator? If not, what should you be doing instead? In this session, Joe Thompson gives a quick overview of the state of the operator ecosystem, points out situations where writing and using them may not be ideal, and offers opinions on alternatives that may be more effective for maintaining your applications. You'll leave with the knowledge to be confident that whether you choose to write an operator or not in any given situation, you're making the correct choice.
https://sched.co/ekAR
A
All
right,
let's
get
this
started,
my
name
is
joe
thompson
and
today
I'm
asking
you
to
stop
writing
operators
relax.
What
I
really
mean
is
stop
writing
operators
by
default
for
managing
kubernetes
apps.
Now,
of
course,
when
I
say
something
like
that,
naturally
people
wonder
who's
this
guy,
although
some
people
use
a
different
word
than
guy,
and
why
do
I
care
what
he
thinks
about
operators
as
a
roundabout
answer
to
that
question?
Here's
some
basic
info
on
me
and
that
qr
code
has
my
contact
info
embedded
in
it
as
well.
A
A
In
september,
devon
goodwin
at
red
hat,
wrote
a
blog
post
called
when
not
to
write
a
kubernetes
operator.
Then
later
that
same
month,
the
new
stack
published
an
article
titled
kubernetes
when
to
use
and
when
to
avoid
the
operator
pattern,
which
extensively
quoted
several
people
about.
Why
writing
an
operator
is
more
of
a
last
resort
than
a
preferred
solution
and
what
distinguishes
operators
from
other
things
and
then
a
week
after
the
new
stack
article,
I
got
the
notice
that
this
talk
was
accepted
for
kubecon.
A
A
So
you're
writing
or
adopting
an
app
to
deploy
in
kubernetes,
and
you
need
to
have
some
way
to
manage
its
operation.
This
is
where
a
lot
of
people
start
asking
themselves
questions
about
operators
like
what
functions
should
my
operator
perform?
What
api
permissions
will
my
operator
need
to
perform
those
functions?
A
A
First
of
all,
if
nobody
leaves
here
thinking,
I'm
completely
wrong
about
something
I
said
then
I'll
feel
like.
I
didn't
challenge
the
status
quo
enough,
but
even
though
I
phrase
things
very
emphatically
here,
I
understand
there
are
cases
where
people
will
write.
Operators,
I
think,
are
unnecessary
for
what
might
be
good
and
sufficient
reasons.
A
A
Now,
some
of
what
I'm
saying
in
this
talk
will
indeed
apply
to
stateless
crd
controllers
as
well,
but
mostly
I'm
going
to
be
talking
about
stateful
application
operators
and
what
a
quagmire
they
can
be.
So
I
wanted
to
try
to
reset
the
conversation
for
an
instant
and
bring
some
focus
back
to
a
useful
distinction.
A
So
first
question:
should
an
operator
for
a
given
application
exist.
I
think
in
several
cases
it
shouldn't
the
mental
model.
I
use
to
think
about
these
cases.
Is
operators
are
sort
of
like
an
adapter
that
you
use
to
plug
old
vga
displays
into
new
monitors
that
only
have
digital
inputs,
sure
it
works,
but
it's
not
as
efficient
or
functional
as
it
could
be.
A
Now,
when
do
you
not
want
an
operator?
There
are
basically
three
sets
of
circumstances
worth
talking
about
here
case.
One
there's
no
state
that
needs
managing
either
the
app
is
not
stateful
or
everything
stateful
about
it
can
be
properly
managed
without
outside
intervention
using
the
available
kubernetes
primitives.
There's
really
nothing
for
an
operator
to
do
here.
You
might
go
ahead
and
write
a
crd
for
it
to
make
everybody's
life
easier,
but
kubernetes
and
the
app
together
can
handle
everything
that
needs
handling.
You
might
not
even
need
a
crd
controller,
just
a
well-written
helm
chart.
A
It's
a
judgment,
call
there.
It's
really
up
to
you,
but
there's
a
retrospective
case,
that's
worth
mentioning
which
I'll
go
into
later,
and
it
has
to
do
with
that
clause.
I
snuck
in
there
about
available
kubernetes
primitives,
so
you
may
in
fact
end
up
writing
an
operator
with
my
approval
here
and
really
isn't
that
the
only
approval
that
matters
next
time
you
want
to
write
some
code
and
your
scrum
product
owner
says
no
tell
them.
A
A
A
A
A
If
you're
writing
the
app
you
have
the
latitude
to
eliminate,
or
at
least
minimize,
that
attack
surface,
that
leaves
everything
else.
The
app
is
stateful
with
complex
functional
needs
related
to
its
statefulness.
You
don't
maintain
it
and
none
of
the
available
alternatives
for
managing
it
inside
or
outside
kubernetes
are
viable.
A
But
before
you
jump
on
this,
let's
look
at
what
some
of
those
alternatives
are.
Okay,
what
can
you
do?
Instead
of
writing
an
operator
to
make
managing
your
application
deployments
easier,
well,
trivially,
you
can
write
a
crd
controller.
Remember
a
basic
crd
controller.
Doesn't
try
to
manage
anything
statefully
that
alone
eliminates
a
lot
of
destructive
failure
modes
but,
as
noted,
a
lot
of
the
above
advice
applies
equally
well
to
crd
controllers,
so
saying
write
one
of
those
instead
isn't
where
I
want
to
stop
this
section,
because
it
doesn't
address
most
of
those
things.
A
A
This
would
be
the
case,
for
example,
if
what
you're
dealing
with
is
a
bunch
of
one-off
issues
that
you
never
see
twice
or
if
what
you
have
is
so
lightly
touched
that
it
would
take
longer
to
automate
its
operations
than
to
just
do
them.
There's
an
xkcd
cartoon
for
everything
in
tech-
and
this
is
a
great
one.
I
keep
on
my
wall
that
details
this
in
chart
form.
A
If
what
you're
automating
is
a
routine
change,
a
popular
model
for
kubernetes
change
management
is
the
git
ops
model.
This
was
first
described
in
detail
by
weaveworks.
You
manage
your
cluster
by
applying
an
as
code
model
to
it
and
to
everything
running
in
it
in
a
cluster
external
development
environment.
A
In
the
most
trivial
case,
this
could
be
just
writing
a
helm,
chart
or
other
templated
artifact
to
deploy
and
maintain
your
app
then
maintaining
and
using
that
as
part
of
your
ci
cd
workflow,
you
can
add
layers
of
other
management
as
well,
for
example,
using
terraform
to
manage
both
the
deployment
of
your
helm,
charts
and
changes
to
the
clusters
you
deploy
them
on.
This
gives
you
a
single
source
of
truth
about
every
change
to
every
app
you
run
and
potentially
every
cluster.
A
There
are
now
several
frameworks
that
take
a
no
code
approach
to
writing.
Operators
like
kudu
generally.
These
are
some
kind
of
top
level
controller
that
implements
operator
primitives.
In
that
sense,
it's
the
actual
operator,
rather
than
the
code
you
write,
then
you
write
a
config
file
of
some
kind
to
implement
your
specific
application
operations.
A
A
A
One
of
the
issues
I
mentioned
with
kubernetes
operators
is
since
they're
running
inside
kubernetes.
They
take
resources
away
from
other
workloads
in
the
cluster,
but
they're
also
limited
themselves
by
the
cluster's
total
resource
availability
and
by
the
inherent
scale
limitations
in
representing
things
as
crds
and
storing
them
in
ncd.
A
You
can
end
up
needing
to
scale
up
your
cluster,
not
to
handle
additional
workloads,
but
just
to
give
your
application
operator
breathing
room,
move
that
operator
outside
and
not
only
are
you
no
longer
limited
by
running
in
the
kubernetes
cluster.
You
now
gain
some
additional
flexibility
in
architecting
your
manager.
A
A
All
right
we've
talked
about
when
an
operator
isn't
needed
and
what
you
can
do.
Instead,
when
is
one
needed,
I
hear
you
asking
two
primary
cases
case
number
one
when
you
don't
maintain
a
stateful
app
and
you
have
to
manage
its
statefulness
on
its
own
behalf
inside
kubernetes,
not
the
ideal
situation
to
be
sure,
but
sometimes
you
just
gotta,
do
the
thing
get
real
familiar
with
whatever
system
the
app
maintainers
use
to
raise
issues
because
you'll
be
using
it
in
proportion
to
how
complex
the
app
is
to
manage.
A
A
A
A
One
of
the
best
illustrations
of
how
hard
this
part
of
operators
is.
Ironically,
is
the
etcd
operator
core
os
wrote
to
introduce
the
concept
it
turned
out
that
running
at
cd
in
kubernetes.
In
an
automated
fashion
was
so
complex
and
had
so
many
hard
to
anticipate
and
hard
to
recover
failure
modes
that
one
of
the
hope,
four
goals
of
the
scd
operator
to
make
etcd
and
the
kubernetes
control
plane
totally
self-hosted
was
abandoned.
A
Somebody
out
there
is
thinking,
but
I
have
these
routine
tasks
that
I
need
to
automate.
I
don't
spend
a
lot
of
time
recovering
from
failure
of
them,
but
I
do
spend
a
lot
of
time
doing
them
shouldn't.
I
automate
that
with
an
operator,
I'm
not
saying
you
shouldn't
ever
do
that,
but
I
think
if
that's
all
you're
doing
you
shouldn't
automatically
look
to
an
operator
as
the
default
way
to
do
it.
The
other
options
I
covered
earlier
often
work
better
for
routine
changes.
Like
that
reason,
number
two:
you
shouldn't
write
a
needed
operator.
A
A
You
can
end
up
in
a
situation
where
you
have
to
update
your
operator
every
time
the
application
updates
and
that's
less
useful
than
just
adding
the
code
into
the
application
itself
and
maintaining
it
there.
It
might
be
a
third-party
application
that
you
can't
just
do
that
with
and
we'll
talk
about
that
in
a
minute,
but
in
general
avoid
avoid
avoid
writing
operators
for
non-stable
apps.
A
This
is
a
minimum,
not
a
maximum
again.
If
that
app
is
at
one
point
x,
it
doesn't
mean
it's
actually
stable,
because
not
everybody
out
there
is
following
semver
and
not
everybody
who
claims
to
be
actually
is
trust,
your
gut
and
take
anything
that
looks
like
a
compatibility
violation
seriously
when
deciding
how
you
feel
about
it
reason
number
three
for
you
not
to
write
code.
That
needs
writing.
It's
someone
else's
app
and
you
haven't
engaged
with
the
team
that
maintains
it.
A
Yet
the
app
maintainer
will
generally
know
best
what
the
dependencies
involving
that
app
statefulness
are,
and
this
is
critical
information.
You
need
to
write
an
operator
well,
you
may
also
find
out
there's
either
one
already
in
progress
or
there
are
features
coming
that
eliminate
the
need
for
an
operator
entirely,
in
which
case
your
best
move
may
be
to
sit
tight,
stay
engaged
with
the
process
on
that
code
and
wait
for
that
release.
A
A
The
first
thing
you
need
is
a
good
understanding
of
crds
and
controllers
and
to
have
a
look
around
at
the
operator
building
landscape.
The
kubernetes
documentation
has
lots
of
good
info
on
this
and
even
links
to
some
frameworks
for
building
your
operator.
The
ancestral
custom
controller
frameworks
are
kube
builder
and
meta
controller.
A
Does
the
framework
allow
you
to
write
in
a
language?
You
know
well
I'd
be
very
skeptical
of
trying
to
get
started
on
both
a
language
and
a
framework.
At
the
same
time,
the
tools
you
know
best
will
tend
to
be
the
tools
you
do
your
best
work
with.
In
most
circumstances,
many
frameworks
require
you
to
write
and
go,
and
if
you
don't
have
a
lot
of
go
expertise,
that's
a
recipe
for
bugs
and
extra
stress.
A
Does
the
frameworks
model
of
the
world
make
sense
to
you
and
fit
in
with
the
rest
of
your
operations?
For
example,
meta
controller
is
a
little
unusual
in
that
it
has
you
write
your
custom
code
as
web
hooks.
It
can
call
if
this
is
how
you
already
do
everything
or
it
feels
right
to
you
and
doesn't
conflict
with
other
requirements.
A
Great
meta
controller
may
be
a
good
choice.
If
not
things
may
change
later
and
another
operator
you
write,
may
be
a
perfect
fit
for
meta
controller.
Then,
are
there
ecosystem
services?
The
frameworks
maintainer
provides
around
it
that
you
want
to
take
advantage
of,
for
example,
consider
the
operator
framework
in
operatorhub.io
here,
although,
strictly
speaking,
you
don't
have
to
write
your
operator
in
the
operator
sdk
to
get
listed
on
the
hub.
Doing
so
does
make
passing
the
criteria
for
getting
listed,
basically
automatic.
A
A
Lastly,
when
it
comes
to
actually
sitting
down
and
writing
your
operator,
I
want
you
to
keep
three
things
in
mind:
maintain
loose
coupling.
You
should
not
need
to
update
your
operator
for
every
update
of
the
application.
It
manages
it's
fine
if
the
app
gains,
major
new
features
that
need
to
be
managed
in
the
operator,
but
there
should
not
be
a
routine
need
to
update
the
operator
as
part
of
an
app
upgrade.
A
Less
is
more.
This
is
what
the
third
or
fourth
time.
I've
said.
You
should
write
no
code
whenever
possible.
That's
because
I
really
really
mean
that.
Not
only
should
you
seek
to
write
as
little
code
in
the
operator
as
possible,
you
should
actively
push
code
out
of
it
whenever
you
can
either
in
favor
of
leveraging
new
features
in
kubernetes
that
make
it
unnecessary
or
into
the
operator,
managed
app
write.
What
you
know.
It's
not
just
good
advice
for
novelists,
it's
good
for
programmers
too.
A
This
means
not
only
writing
in
a
language
and
framework
that
are
familiar
and
understandable
to
you.
It
means
beginning
with
automating
the
processes
you
understand
the
best
that
have
the
biggest
impact
as
you
work
out.
These
cases,
you'll
learn
the
application's
behavior
better
and
you
can
add
other
lesser
used
operations
more
confidently,
but
don't
forget
what
I
said
in
the
last
point
only
write
what
you
need
to
in
the
operator.
A
This
slide
has
references
and
further
reading.
I
know
you
can't
click
on
the
links
in
video,
but
don't
worry
there
will
be
a
link
to
these
slides
coming
up
and
with
that.
Thank
you
very
much.
This
is
the
link
I
promised
that'll.
Take
you
to
the
slides
for
this
talk
or
you
can
scan
that
handy
qr
code
right
there
and
I
believe
we
now
have
some
time
for
q
a
if
anyone
has
questions.