►
From YouTube: Stateful and Stateless Workloads (The Podlets, Ep 9)
Description
The purpose of today’s show is coming to a deeper understanding of the meaning of ‘stateful’ versus ‘stateless’ apps, and how they relate to the cloud native environment. We cover some definitions of ‘state’ initially and then move to consider how ideas of data persistence and co-ordination across apps complicate or elucidate understandings of ‘stateful’ and ‘stateless’. We then think about the challenging practice of running databases within Kubernetes clusters, which effectively results in an ephemeral system becoming stateful. You’ll then hear some clarifications of the meaning of operators and controllers, the role they play in mediating and regulating states, and also how important they are in a rapidly evolving but skills-scarce environment.
For the show notes and transcript: https://thepodlets.io/episodes/009-stateful-and-stateless
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Hosts
https://twitter.com/carlisia
https://twitter.com/bryanl
https://twitter.com/joshrosso
https://twitter.com/mauilion
https://twitter.com/apinick
B
C
B
D
B
Awesome
alright,
so
we've
got
a
pretty
good
cast
this
week,
so,
let's,
let's
dive
right
into
it,
I
think
one
of
the
first
things
that
we've
been
talking
a
bit
about
is
you
know
the
concept
of
of
what
makes
an
application,
stateful
and,
of
course,
in
Reverse
what
makes
an
application
state
list.
So
maybe
we
could
try
to
start
by
discerning
those
two,
maybe
starting
with
stateless
I,
want
to
take
that
on
well,.
A
I
I
I'm
gonna
jump
right
in
I'm.
I
have
always
been
a
developer,
as
opposed
to
some
of
you
or
all
you
who
have
system
system,
admin,
backgrounds
and
the
first
time
that
I
heard
the
stateless
app
I
was
like.
Why
I'm
talking
about
that?
Wasn't
recent?
Ok,
it
was
a
long
time
ago,
but
it's
just
like
there
was
a
knot
in
my
hands
like.
Why
would
I
have
a
stateless
app
like
if
you
have
an
app
you're
gonna
need
States
like
I?
A
D
Before
you
go
into
it's
a
great
point,
whenever
we
start
with
apps
or
we
start
developing
apps,
we
think
of
an
application,
an
application
does
everything
it
takes
input
and
it
does
stuff
and
it
gives
output.
But
now,
in
this
new
world,
where
we
have
lots
of
apps
big
apps
small
apps,
we
start
finding
that
there's
apps
that
only
talk
and
coordinate
with
other
apps
and
they
don't
do.
D
A
It's
more
like
when
they
envisioned
in
my
head.
Yes,
you
said
it
brilliantly.
Brain
is
almost
like
a
process
like
at
when
I
started,
visioning
this
world
of
stateless
apps.
To
me,
it's
like,
why
do
you
we?
Why
do
we
even
call
them
apps?
Why
don't
we
just
call
them
a
process?
They
just
like
shifting
data
back
and
forth,
but
they
not
talk
to
me
at
the
beginning.
Apps
were
always
like
they
went
together.
I
think.
E
It's
also
I
think
frequently
people
think
of
applications
that
have
only
locally
relevant
state
stuff
that
is
actually
not
going
to
persist
to
disk
but
like
maybe
held
in
memory
or
or
maybe
only
relevant
to
the
type
of
connection.
That's
coming
through
that
application,
also
as
stateless,
which
is
interesting
because
there's
still
some
state
there
but
the
it's
about,
but
the
the
premise
is
that
you
could
lose
that's
and
not
lose
the
functionality
of
that
code.
C
E
D
State,
that's
that
word
state
is
one
of
those
words
that
we
use
to
sound
smarter
than
we
actually
are
95%
of
the
time
and
that's
a
number
I
just
made
up
when
people
are
talking
about
state,
they
mean
databases
yeah,
but
you
know
there's
other
types
of
state
as
well.
If
you
maintain
local
cash,
that
needs
to
be
persistent
it
you
have
local
files
that
you
are
that
you're
dealing
with
like
you're
opening
files
that
still
states
so.
A
A
A
All
right
so
now
we
have
this
worlds.
Where
we
talk
about
stateless
apps
and
stateful
apps.
Are
there
even
stay
for
apps,
like
that?
We
call
that
a
basis
now,
if
we
have
a
system
where
we
have
one
stateless
app
over
here
and
those
states
are
stateless
app
over
there
and
then
we
have
the
database
that's
connected
to
the
two
of
them.
Are
we
calling
the
databases
States
for
app
or
is
the
whole
thing
we.
A
D
This
is
very
much
high
state.
Is
it
as
an
app
would
state
I'm
very
much
definition
yeah,
it's
literally
it's
the
epitome
of
a
stateful
app,
but
but
then
you
also
have
these
apps
that
talk
to
databases
as
well,
and
they
might
have
local
data
like
data
that
they
start
a
transaction
and
then
complete
it
or
they
have
a
long
distributed,
typed
and
transaction.
So
any
apps
that
revolve
around
database
if
they
store
local
data,
whether
it's
within
a
transaction
or
something
else,
there's
still
there's
still
staple
apps.
E
Yep
anything,
that's
gonna,
modify
anything
to
modify
input
data
or
do
compute.
You
know
or
modify
state
that
has
to
be
persisted
in
some
way.
I
think
is
a
stateful
app,
even
though
I
think
I
do
think
it's
confusing
because
of
what
I
don't
as
I
said
before.
I
think
that
there
are
a
bunch
of
applications
that
we
think
of,
like
not.
Everybody
considers
spark
jobs
to
be
stateful
right.
E
Spark
jobs,
for
example,
are
something
that
would
kind
of
bring
bring
data
in
mutate
that
data
in
some
way
produce
some
output
and
then
and
go
away
and
the
benefit,
and
and
even
in
that,
the
definition
there
is.
That
spark
would
generally
push
the
resulting
data
into
some
other
external
system.
So
it's
interesting
because
in
that,
in
that
model,
right
spark
is
not
considered
to
be
a
stateful
app,
because
the
spark
job
could
fail
go
away.
E
Get
we
created
to
pick
up
pick
up
the
pieces
where
it
left
off
or
just
redo
that
work
until
all
of
the
work
is
done,
and
so
you
know
in
many
cases
people
consider
that
to
be
a
stateless
application
and
that's
I.
Think,
like
the
crux.
In
my
opinion,
the
crux
of
the
confusion
around
what
a
stateful
and
stateless
application
is
is
that
people
frequently
needs
like
they?
A
C
B
B
I
feel
like
a
lot
of
the
customers.
I
work
with
you
know
if
the
application
can
get
killed,
even
if
it
had
some
type
of
local
state
right,
they
still
refer
to
it
as
stateless,
usually
to
me
at
least
when
we
talk
about
it,
you
know
because
they
think
you
know,
I
can
kind
of
restart
this
application
and
I'm
not
too
worried
about
losing
whatever
it
may
have
had.
Let's,
let's
take
a
sh
for
simplicity,
right
and
I
think
that
kind
of
leads
us
into
an
interesting
question.
B
We've
talked
a
lot
on
this
podcast
about
cloud
native
infrastructure
and
cloud
native
applications,
and
it
seems
like
since
the
inception
of
native
there's
always
been
this
push
that,
like
a
stateless
app
is
the
best
candidate
to
rhyme
or
the
easiest
candidate
to
run
and
I'm
just
curious.
If
we
could
dive
into
that
for
a
moment
like
why,
in
the
cloud
native
infrastructure
area,
has
there
always
been
this
push
for
running
stateless
applications?
Why.
D
Before
before
we
dive
into
that,
we
have
to
realize-
and
this
is
just
a
problem
with
our
whole
ecosystem.
This
whole
cloud
native,
we're
very
hand
wavy
and
our
and
our
descriptions
for
things,
there's
a
lot
of
ambiguous
descriptions
and
state
is
one
of
those.
So
just
keep
that
in
mind
that,
when
we're
talking
today
we're
just
trying
to
get
through
this
committee,
which
we're
we're
really
just
talking
about
these
things
that
store
data
and
what
nets
the
state.
D
So
just
keep
that
in
mind
that
you're
listening
to
this,
but
when
it
comes
to
distributed
systems
in
general,
the
easiest
system
is
a
system
that
stores
that
doesn't
need
coordination
with
any
other
system.
And
if
it
happens
to
die,
that's
okay,
we
can
just
restart
it.
So
people
like
to
start
there,
it's
the
easiest
thing
to
start
with
yeah.
C
It's
gonna,
that's
basically
I
was
going
to
say
like
if
your
application
needs
to
tie
into
other
applications.
It
becomes
significantly
more
complicated
to
like
implement
it,
at
least
for
your
first
time
in
in
your
system,
so
like
these
small
applications
that
only
they
don't
care
about
anybody
else,
they'd
just
taken
data
or
not,
they
just
do
whatever.
Those
are
super
easy
to
start
with,
because
you're
just
like
here
start
the
stuff.
Who
cares
like
whatever
happens,
that
it
happens,
that.
A
D
D
Is
there
is
a
service
at
the
beginning
that
collects
that
search
and
it
federates
to
search
over
many
different,
probably
clusters
of
computers,
so
they
can
actually
do
the
search
currently
that
app
that
actually
coordinates
that
all
that
work
is
a
stateless
act
most
likely
and
all
it
does
is
just
splits
it
up
and
allows
one
more
if
you
use
to
do
the
work.
So
probably
if
it
goes
away,
probably
not
a
problem,
you
probably
have
ten
more
of
them.
A
A
A
E
What
we
frequently
talk
about
in,
like
the
cognitive
space
is
like,
if
you
know
that
you
have
a
stateless
up,
if
you
can
just
create
20
of
them
and
not
have
to
worry
about
the
coordination
of
them
right,
they
are
all
workers,
they're
all
gonna,
take
input.
You
could
spread
the
load
across
those
20
and
in
an
identical
way
and
not
worry
about
which
one
you
landed
on.
That's
stateless
application,
a
stateful
application
is
a
very
different
thing.
E
You
have
to
have
some
coordination,
you
have
to
say,
you
know
how
many
databases
can
you
have
on
a
back-end
right
and
and
because
you're
persisting
data
there,
you
have
to
be
really
careful
about
like
making
sure
that
you
only
have,
but
that
you
only
write
to
the
master
database
or
through
the
writing
database
right
and
you
could
read
from
any
of
the
any
of
the
any
other
members
of
that
database
cluster.
That
sort
of
stuff
right.
A
Demising
Dahlia
sorry,
it
may
seem
that
we
are
going
so
deepen
into
this
like
differentiate
between
stateful
and
stateless,
but
this
is
so
important
because
clusters
are
usually
designed
to
be
ephemeral,
so
ephemeral
means.
Obviously
you
know
they.
They
die
down.
They're
brought
back
up
or
the
the
nodes,
and
you
should
not.
You
should
worried
the,
as
least
as
possible,
with
the
state
of
things
and
then
going
back
to
what
Josh
was
saying
when
we
are
in
this
called
native
world.
A
A
A
D
My
state
is
available
when
I
need
it
or
actually
you
know
what
I'm
not
even
use
that
word
state
making
sure
my
data
is
available
wherever
I
need
it
and
when
I
need
it.
So
this
is
without
getting
I.
Don't
want
to
go
too
deep
in
right
now,
but
this
is
actually
a
huge
problem
in
the
kubernetes
community
in
general,
and
we
see
it
because
there's
been
lots
of
advice
given
don't
run
things
like
databases
in
your
clusters
and
then
there's.
B
And
I
want
to
dovetail
on
that
Brian,
because
it's
something
that
we
see
all
the
time
like
I
feel
like
when
we
first
started
setting
up
what's
called
him
clusters,
but
in
our
case
it
was
kubernetes
right.
We
always
saw
that
that
data
level
always
being
delegated
to
like,
if
you're
in
Amazon
some
service
that
they
hosted
and
so
on,
but
now
I
think
more
and
more.
The
customers
at
least
I'm,
seeing
I'm
sure,
Nikolas
and
Duffy
they're
interested
in
doing
exactly
we
just
described
cockroach,
is
an
example.
B
I
literally
just
worked
with
recently,
and
it's
just
interesting
how
much
more
thoughtful
they
have
to
be
about
their
cluster
operations.
Going
back
to
what
you
said:
Carly
SIA,
it's
not
as
easy
as
just
like
trashing,
a
clustered
instantiating,
a
new
one
anymore,
but
they're
used
to
they
need
to
be
more
thoughtful
about
keeping
that
data
integrity
intact.
Through
things
like
upgrades
and
disaster
recovery.
E
E
D
D
Definitely
this
is
why
we're
seeing
more
people
creating
operators
around
managing
data,
like
I've,
seen,
operators
for
bringing
databases
up
inside
of
kubernetes
I've
seen,
operators
that
actually
can
bring
up
resources
outside
of
kubernetes
using
the
Quran,
easy
I,
and
the
interesting
thing
about
this
is
that
I
look
at
both
solutions
and
I
said:
I
still,
don't
know.
If
the
answer
is,
and
that's
great,
that
means
we
have
lots
to
learn
about
the
problem
and,
and
at
least
we
had
some
Pat's
board
actually.
C
That
kind
of
reminds
me
of
the
first
time
I
ever
heard
the
word
stateful
or
Salus,
so
I'm,
an
infrastructure
guy
was
around
the
discussion
of
operators,
which
you
know
that's
there's
only
a
couple
years
ago
when
operates
were
first
introduced
at
core
OS
and
something
we
were
like.
Oh
well.
This
is
how
you
now
operate
like
a
stateful
like
mechanism
inside
of
kubernetes
like
this
is
our
the
way
forward
that
we
want
to
propose
and
I
was
just
like
cool.
C
B
Let's
talk
about
exactly
that,
because
I
think
these
patterns
were
starting
to
see
are
coming
out
of
the
needs
that
we're
all
talking
about
right.
So
we've
seen
at
least
in
the
kubernetes
community.
A
lot
of
push
for
these
different
constructs
like
something
called
a
staples
that
which
isn't
that
important
right
now,
but
then
also
like
an
operator.
So
maybe
we
can
start
by
defining
like
what
is
an
operator
like?
What
is
that
pattern?
And
why
does
it
relate
to
staple
apps,
I.
A
A
D
D
Based
on
that
CR
DS
configuration
that's
what
an
operator
is
exactly
right:
conflate
this
they're
in
there
Red
Hat
created
the
operator
SDK
and
and
then
you
have
a
cute
builder
and
you
have
a
meta
controller
which
can
help
you
build
operators,
and
then
we
actually
sometimes
complain
and
call
CR
these
operators
and
that's
pretty
confusing
for
everyone.
So
once
again,
don't
let
developers
name
anything.
C
A
You
are
developing
an
app
for
kubernetes
if
you're
extending
kubernetes
you.
You
are
ok,
you
might
not
use
here
at
this,
but
if
you
are
using
CR
Z's
you,
you
need
a
controller
right,
because
how
are
you
do
actions?
So
then,
however,
it
every
app
that
has
a
CRT,
because
the
alternative
to
having
CR
Z's
is
just
using
the
API
directly
without
crazies
to
reflect
your
resources.
So
if
you're
creating
series
to
reflect
your
resources,
you
need
controllers.
So
all
of
those
apps
that
have
share
these
are
operators.
D
There's
a
way
there
is
a
way
you
can
actually
just
create
a
CR
V
and
use
a
CRT
for
data
storage.
You
know
door
states
and
you
can
actually
query.
You
can
actually
query
the
kubernetes
api
for
that
information.
You
don't
need
a
controller,
but
we
we
couple
them
with
controllers
a
lot,
so
you
perform
action
based
on
that
state.
We've
saved
2,
XE
d,
duffy.
A
E
We
should
I
want
to
back
up
just
for
a
moment
and
talk
about
the
controller
pattern
and
what
it
is
and
then
go
from
there
to
operators,
because
I
think
it
makes
it
easier
to
get
in
your
head.
So
control
pattern
is
like
you
know.
It
is
effectively
a
way
to
understand,
desired,
state
and
real
state
and
provide
some
logic
or
business
so
or
that
will
allow
you
to
converge.
Those
two
states
right,
your
actual
state
in
your
desired
state,
and
this
is
a
pattern
that
we
see
used
in
almost
everything
within
a
distributed
system.
E
It's
like
with
it
and
Cooper
need
is
within.
Most
of
the
kind
of
you
know,
more
interesting
systems
that
are
out
there.
This
control
pattern
describes
a
pretty
good
way
of
actually
managing
managing
application
flow
across
distributed
systems
now,
operators
when
they
were
initially
introduced
operators
when
they
were
initially
introduced.
We
were
talking
about
that.
This
is
a
slightly
different
thing.
Operators,
oh
I,
hate
my
microphone,
sorry
existing,
alright,
so
operators
when
we
introduced
the
idea,
was
came
more
from
like
the
operation
of
burden
of
these
stateful
applications
like
things
like
databases
and.
E
Some
stuff,
and
with
the
database
like
sed,
for
example,
you
have
a
you-
have
a
whole
bunch
of
operational
and
runtime
concerns
around
managing
the
lifecycle
of
that
of
that
system.
Right.
How
do
I
add
a
new
member
to
the
cluster?
What
do
I
do
when
a
member
dies?
How
do
I
make
action
right
right
now?
E
That's
somebody
like
myself,
waking
up
at
2:00
in
the
morning
and
working
through
a
run
book
to
basically
make
sure
that
that
service
remains
operational
through
the
night,
but
the
idea
of
an
operator
was
to
take
that
control
pattern
that
we
described
earlier
and
make
it
wake
up
at
2:00
in
the
morning
to
fix
this
stuff
right.
We're
gonna,
actually
codify
the
operational
knowledge
of
managing
the
the
burden
of
these
up
of
these
stateful
applications
so
that
we
don't
have
to
wake
up
to
in
the
morning
to
do
it
anymore.
D
Yeah
that
makes
sense
remembering
back
at
cube
con
years
ago.
I
know
it
wasn't
one
in
Seattle,
where
Brandon
Phillips
on
stage
talking
about
operators.
He
basically
was
saying
if
we
think
about
like
sis
hop
system
operators,
it
was
a
bit.
It
was
a
way
to
basically
automate
or
capture
the
knowledge
of
our
system,
administrators
in
scripts
or
in
a
process
or
in
code.
All
the
operators
knew.
E
We're
gonna
have
to
get
to
a
place
where
we
are
able
to
automate
the
burden
of
managing
those
applications,
because
there
just
aren't
enough
of
us
to
be
able
to
support
the
the
load
that
is
coming.
You
know
like
there
just
aren't
enough
people
on
the
planet
that
do
this
to
be
able
to
support
that,
and
so
that's
the
thing
that
excites
me
most
about
the
operator
pattern
is
that
it
gives
us
a
place
to
start.
E
C
C
With
people
apps,
we
keep
kind
of
bring
them
come
back
to
say
flage,
because
state
flaps
are
hard
and
say:
Lesseps
are
easy
and
you
know
we
created
all
these
mechanisms
around
operating
things
with
state,
because
of
how
just
complicated
is
to
make
sure
that
your
data
is
ready,
accessible
and
has
integrity.
That's
the
big
one
that
I
keep
not
thinking
about
as
a
like
sis.
Ops
person
coming
into
the
Deverill
data
integrity
is
so
important
and
making
sure
that
your
data
is
exactly
what
it
needs
to
be
and
was
the
last
time
you
checked.
C
It
is
super
important.
It's
only
something
I'm
really
starting
to
Drock
and
that's
why
I
like
these
things,
like
operators
and
all
these
mechanisms,
that
we
keep
creating
and
recreating
and
recreating
keep
coming
about
it,
because
making
sure
that
you're,
stateful
apps
have
the
right
data
at
the
right
time
is
so
important.
So.
D
So
if
your
cluster
splits
into
two
for
some
reason,
you
won't,
actually
they
don't
be
bad,
and
this
is
why
it's
hard.
This
is
why
people
have
written,
basically
lots
of
PhD
dissertations
on
on
the
subject,
and
this
is
why
we
are
talking
about
this
here
today
is
because
managing
state,
and
particularly
man
and
distributed
state,
is
actually
a
very,
very
hard
problem.
But
there's
software
out
there
that
will
help
us
and
kubernetes
is
definitely
part
of
that
and
stateful
sets
are
definitely
part
of
that
as
well.
Yeah.
B
D
B
D
You
can't
have
home
free,
it's
literally
impossible,
so
depends
like
if
you
have
like,
if
you
have
on
my
sequel,
server
and
you're,
using
my
sequel
to
actually
to
actually
serve
data
out
of
this
you're,
going
to
most
likely
get
consistent,
consistency
and
availability.
If,
if
you,
if
you
have
it
replicated,
you
might
not
have
partition
tolerance.
So
that's
something
to
think
about
and
there's
different
databases,
and
this
is
actually
one
of
the
reasons
why
there
are
different
databases.
C
That's
a
that's
an
interesting
point
and
something
that
I
had
recently
just
been
thinking
about
like
why
there's
some
different
type
of
databases-
I
just
didn't
know-
and
it
was
like
I
only
recently
heard-
of
cap
there
as
well.
Just
before
you
mentioned
it,
I,
don't
like
wow,
that's
so
fascinating
the
whole
thing
where
yeah
you've
only
you
know
pick
to
you
can't
get
three
Josh
to
kind
of
go
back
to
your
question
really
quickly.
C
I
think
the
partition
tolerance
is
the
one
that
we
throw
away
the
most
we're
willing
to
not
be
able
to
segregate
our
database
as
much
as
possible,
because
the
scene
air
is
too
important.
I
think
at
least
if
I'm
saying
like
I'm,
gonna,
City,
shirt
and
SAT
is
not
partition.
Tolerant,
it's
bad
at
it.
Well,.
D
This
is
why
Google
introduced
spanner
and
spanner
okay,
and
some
situations
can
get
three
with
with
trade-offs
and
a
lot
of
really
really
smart
stuff.
But
most
people
don't
can't
run
this
scale,
but
we
do
need
to
think
about
partition
tolerance,
especially
with
data.
Whenever,
let's
say
you
have
your,
you
run
a
store
and
you
have
multiple
instances
across
the
world
and
someone
makes
the
someone
buy
something
from
inventory.
What
does
your
inventory
look
like
at
any
particular
point,
and
you
don't
answer
my
question
of
course,
but
think
about
that.
E
A
Well,
I
feel
that
I'm
clear
on
well
I
think
I
need
to
qualify
your
question
better
for
me.
If
you
asking,
if
I
understand
what
it
means,
I
understand
what
it
means,
but
I
actually
was
thinking
to
ask
this
question
to
all
of
you.
Do
you
because
I
don't
know
the
answer?
If
that's
the
question,
you're
asking
me
I
want
to
put
that
to
the
group:
do
you
recommend
people
as
in
like
now-ish,
to
run
stateful
workloads?
A
We
need
to
talk
about
what
workloads
mean
to
run
stateful,
apps
or
database
inside
if
they're
running
a
kubernetes
cluster,
if
they're,
if
they're
planning
for
that
do,
you
are,
as
experts
recommend
that
they
should
already
be
looking
into
doing
that
or
they
should
be
running
for
now.
They're
stay
for
apps
or
databases
outside
of
the
cloud
native
ecosystem
and
just
connecting
the
two,
because
if
that's
what
your
question
was
I
don't
know.
D
I'll,
take
this
first
I
think
that
we
should
be
spending
lots
more
time
than
we
are
right
now
and
coming
up
with
compute
community
tested
solutions
around
using
stateful
sets
to
their
best
ability,
and
what
that
means
is.
Let's
say
if
you
are
running
a
database
inside
of
kubernetes
and
you're,
using
a
stable
set
to
manage
manage
this.
What
we
do
need
to
figure
out
is
what
happens
when
my
database
goes
down.
D
A
D
B
Yeah
and
for
me,
I
think,
with
working
with
customers
at
least
kubernetes
oriented
folks,
when
they're
trying
to
introduce
kubernetes
as
their
orchestration
part
of
their
overall
platform,
I'm,
usually
just
trying
to
kind
of
need
them
where
they're
at,
if
they're
new
to
kubernetes
in
distributed
systems
as
a
whole.
If
we
have
stateless,
let's
call
them
maybe
simpler.
B
Applications
to
start
with
I
generally
have
them
lean
into
that
first,
because
we
already
have
so
much
in
front
of
us
to
learn
about
I
think
it
was
either
Brian
or
Duffy
who
says
like
it
introduces
a
whole
a
whole
bunch,
more
complexity.
Right,
you
have
to
know
what
you're
doing
you
have
to
know
how
to
operate
these
things.
So
if
they're
new
to
kubernetes
I
generally
will
buy
a
start
and
stateless
still.
A
Just
to
qualify
where
you
said
Josh,
because
you
spoke
like
an
expert
but
I'm
like
I,
still
have
beginners
years.
You
said
something
that
sounded
to
me,
like
you
recommend
that
they
go
stateless.
So
that's
how
he
sounded
to
me
like
that.
So
what
you're
really
saying
is
that
they
take
out
the
stainless
parts
of
what
they
have,
which
they
may
already
have,
what
they
might
have
to
change
and
put
these
statements
that
you're
not
suggesting
that,
oh,
you
can
do
stateless
stay
for
anymore.
A
B
B
Still
work
with
a
lot
of
people
who
are
very
new
to
these
distributed
systems,
concepts
and
to
take
on
running
stateful
workloads.
If
we
could
just
delegate
that
to
some
other
layer
like
outside
of
the
cluster,
that
could
be
a
better
place
to
start,
at
least
in
my
experience.
Nicolas
enough,
you
might
have
different.
C
Oh
talk
to
you
basically
like
nailed
it
like
what
I
was
going
to
say
it's
like
if
the
team
is
that
I'm
working
with
is
interested
in
taking
on
the
complexity
of
maintaining
their
databases.
There
are
staple
sets
and
making
sure
that
they
have.
You
know
data
integrity
and
availability,
then
I'm
all
for
them
using
kubernetes.
C
E
So
you
have
to
really
be
careful
about
the
different
models
that
you're
evaluating
when
trying
to
think
about
how
to
manage
a
stateful
application
like
a
database.
There
are,
you
know,
I
think
this
is
actually
why
you
know
we
operate.
The
topic
of
an
operator
came
up
kind
of
earlier,
which
was
that,
like
there
are
a
lot
of
primitives
within
kubernetes
in
general,
that
provide
you
a
lot
of
capability
for
managing
things
like
stateful
applications,
but
they
may
not
entirely
suit
your
needs,
and
so
because
of
the
complexity
of
a
stateful
application,
you
have.
A
And
I
know
just
from
working
with
Valera,
which
is
a
tool
for
doing
backup
and
recovery
in
migration
of
coronaries
clusters.
I
know
that
we
we
back
up
volume.
So
if
you
have
something
mounted
on
the
volume
we
can
back
that
up.
So
so
I
know
from
for
fact
that
people
are
using
that
so
to
to
back
up
stay
for
workloads.
We
need
to
talk
about
workloads,
but
in
any
case
one
thing
to
I.
A
D
A
But
let
me
let
me
say
something
so
yeah
we
can
I
think
we
should
do
an
episode
on
on
that.
Maybe
maybe
not.
We
should
do
an
episode
on
get
ops
type
of
thing
for
related
things,
because,
even
though
you
these
are
say
place
by
I,
don't
want
to
get
into
it.
You
you,
your
cluster
will
change
states.
You
can
recover
it
and
stuff
from
like
a
fresh
version,
but
as
he
goes
through
a
life
cycle,
it
will
change
states
and
you
might
want
to
keep
a
state
I.
Don't
know.
A
I
am
NOT
the
expert
on
in
the
area,
but
let's
talk
about
workloads,
Brian.
Why?
Like?
Okay,
let
me
just
let
me
start
talking
about
workloads.
I,
never
heard
the
term
workload
until
I
came
into
the
cloud
native
world
and
that
was
about
a
year
ago
or
when
I
started
looking
into
this
face
more
closely,
maybe
a
little
bit
before
a
year
ago,
and
it
took
me
forever
to
understand
what
our
workload,
what
is
now
I
understand,
especially
today
we
were
talking
about
it
a
little
bit
before
we
started
recording
so.
D
So
this
is
one
of
those
terms
and
I'm
sure
if
I
go
asks
any
ex
coolers
about
this
they'll
probably
agree.
This
is
a
google
turn
that
we
actually
have
zero
context
about.
Why
it's
a
turn
I'm
sure
we
could
ask
mining,
they
would
tell
us,
but
we're
clothes
to
me.
Personal,
are
anything
that
ultimately
creates
a
pod,
so
deployments
create
replica
sets
create
pop.
That's
that
whole
thing
is
a
work
load.
That's
how
I
look
at
it
so.
D
Well,
once
again,
these
words
don't
make
any
sense
to
us,
because
they're
google
terms,
but
I
think
that
a
pod
is
part
of
the
workload
like
the
deployment
is
part
of
the
workload
like
a
replica
set
is
part
of
your
workload.
Workload
is
the
is
the
term
that
encompasses
those
entire,
that
entire
set
of
objects,
I,
think
it'll
work
load.
E
Isn't
I
think
of
a
workload
as
a
subset
of
an
application,
so
when
I
think
of
an
application
or
like
you
know,
a
set
of
micro
services,
I
might
think
of
each
of
the
services
that
make
up
that
entire
application
as
a
workload
and
I
think
it's
that
way,
because
that's
generally
how
I
would
divide
it
up
to
Brian's
point
in
two
different
deployments
or
different
stateful
sets
or
different.
You
know:
that's
that
sort
of
stuff
right
in
thinking
of
them.
Each
is
their
own
autonomous
piece
and
all
together,
they
form
an
application.
A
A
core
network
inside
deployments
will
always
run
in
the
pods,
which
is
super
confusing.
If
you
not
looking
at
these
things,
the
so
people
understand,
because
it
took
me
forever,
there's
nothing
that
the
connection
between
you
know
a
workload,
a
deployment
in
the
pods,
so
parts
contain.
If
you
have
a
deployment
that
you're
going
to
shift
kubernetes
I,
don't
know.
If
shift
is
the
right
word
you're
going
to
run
on
kubernetes,
it
definitely
run
somewhere
in
some
in
some
artifacts
and
artifact
is
called
a
part.
C
Yeah
kind
of
fun
come
back
to
what
Debbie
said
really
quickly.
We're
going
to
meet
was
always
a
process
kind
of
like
not
just
a
pun,
necessarily
but
like
whatever
it
is
that
you're,
like
I,
just
need
to
get
this
to
run
whatever.
That
is
to
me
that
was
always
a
brick
load,
but
I
think
I'm,
I
think
I'm
wrong,
I
think
I'm
oversimplifying
it
well.
It
looks
like
whatever
your
process
is
yeah.
D
D
The
reason
I
bring
this
up,
and
this
is
probably
a
great
definite.
This
is
probably
a
great
idea
for
a
future
show
is
about
all
the
jargon
and
terminology
that
we
use
in
this
land
that
we
just
take
as
everyone
knows
it,
but
we
don't
all
know
it
and
just
be
a
great
conversation
to
have
around
that.
But
the
reason
I
was
bringing
a
full
workload.
Thing
is
because
when
we
think
about
workloads-
and
then
you
can't
have
state
without
workloads
and
I,
just
wanted
to
make
sure
that
we
tied
those
two
things
together.
D
D
C
B
E
C
You
do
have
like
product
priority
and
preemption
and
if
you
don't
set
those
things
up
properly
or
if
there's
just
like
a
total
failure
of
your
system
at
large,
your
saiful
application
can
just
go
down
at
any
time
and
then
how
do
you
reconcile
the
outage
and
data?
Whatever
data
that
might
have
gotten
lost?
Those
sort
of
things
become
significantly
more
complicated
in
a
environment
like
kubernetes,
where
you
don't
necessarily
have
access
to
a
clan
line
to
run
the
commands
to
recover
as
easy
you
may
not.
This
is
a
yes.
D
And
you
know
understand
what
databases
do
disk
is
slow,
whether
are
you
having
where
you
have
spinning
disk
or
you
have
dysfunction
all
like
SSD.
So
what
databases
do
do
in
a
lot
of
cases?
Is
they
store
things
in
memory?
So
if
it
goes
away,
didn't
get
stored
and
then
in
other
cases,
what
databases
do
is
they
have
these
huge
transaction
logs?
Maybe
they
write
them
out
files
and
they
process
the
transaction
log
whenever
they
have
CPU
time
so
if
a
database
dies
just
suddenly?
D
B
Yeah
and
going
back
to
like
kubernetes
as
an
example
like
we
are
living
in
this
newer
world,
where
things
can
get
rescheduled
and
moved
around
and
killed
and
their
eyepiece
change
in
things.
So
it's
see
it's
like
this
environment
is,
should
I,
say,
more
ephemeral
right
and
those
types
of
considerations
becoming
be
more
complex.
Mm-Hmm.
C
E
One
more
part
to
the
whole
stateful
stateless
thing
that
I
think
is
important,
that
it's
important
to
cover,
but
I,
don't
know,
probably
be
able
to
cover
it
entirely
in
the
time
that
we
have
left,
and
that
is
from
the
network
perspective
right,
you
think
about
the
types
of
connections
coming
into
an
application.
We
refer
to
some
of
those
connections
as
stateful
and
stately.
Do
you
think
that's
something
you
tackle
in
our
remaining
time
or
why.
E
These
things
is,
you
would
have
multiple
of
them
and
you
would
have
some
intelligence
in
the
way
that
you
were
routing
connections
down
to
those
applications
that
would
discuss
that
would
describe
the
ability
to
ensure
that
when
you
know,
Bob
accesses
a
website
and
he
authenticates
he's
going
to
authenticate
to
one
specific
instance
of
this
application
and
the
intelligence
up
in
the
front
end
is
going
to
handle
the
routing
to
make
sure
that
Bob's
connection
always
comes
back
to
that
same
instance.
This
is
an
older
pattern.
E
It's
been
around
for
a
very
long
time
and
it's
certainly
the
first,
with
the
way
that
we
first
could
have
learned
to
scale
applications
before
we
decided
to
break
into
maker
services
and
kind
of
handle
a
lot
of
this
routing
in
a
more
in
a
more
resilient
way.
That
was
kind
of
one
of
the
early
versions
of
how
we
do
this
and-
and
that
is
a
pretty
good
example
of
a
stateful
session
in
that
there
is
actually
some
like.
E
Perhaps
bob
has
authenticated
and
he
has
a
cookie
that
allows
him
to
you
know,
provide
allow
it
allows
him
that
when
he
comes
back
into
that
particular
application,
a
lot
of
the
you
know
settings
his
browser
settings,
whether
he's
using
the
dark
theme
or
the
light
theme.
That
sort
of
stuff
is
persisted
on
the
server
side
rather
than
inside,
rather
than
on
the
client
side.
And
so
there's
a
lot
of
that
that
that
that's
kind
of
what
I
mean
by
staples
stateful
sessions.
E
We've
managed
to
keep
the
state
either
with
the
client
we're
handling
State
on
the
on
the
browser
side
of
things
rather
than
on
the
server
side
of
things
and
so
you're,
not
necessarily
you're,
not
necessarily
gaining
anything
by
pushing
that
connection
back
to
the
same
specific
instance,
but
just
to
a
service
that
it's
more
widely
available,
and
there
are
lots
of
examples
of
this
I
mean
about
Brian's
example
of
Google
earlier
right,
like
obviously
when
I
come
back
to
Google
there's
there
are
some
things.
I
wanted
to
remember.