►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
You Might Just be a Functional Programmer Now - Cornelia Davis, Pivotal
The declarative programming model of Kubernetes is markedly different from what most developers are used to. That the API is a set of resources rather than a list of methods on objects is a bit mind bending. But this programming model is not entirely new – rather, it smacks quite heavily of functional programming. Functional programming had mostly been relegated to academic endeavors until recently. What’s changed that is that our apps are now distributed systems and are simply too complex for us to reason about without help. Kubernetes helps. In order to effectively use Kubernetes to deploy and manage your workloads you need to understand some of the principles of functional programming and how they surface in K8s. In this session I will cover these underlying principles of the K8s programming model so that you can up the robustness and manageability of your application deployments.
https://sched.co/MPXT
A
Well,
good
morning,
everyone
we're
gonna,
go
ahead
and
get
started.
Hope
you
all
enjoy
the
keynotes
this
morning
my
name
is
Tim
Hendricks
I'm
from
open
policy
agent
and
steer
and
I'm
your
track
host
for
the
next
couple
of
presentations.
Just
a
reminder:
we're
gonna
have
the
usual
set
up
for
this
talk.
So
five
minutes
for
Q&A
at
the
end,
I'll
run
around
with
a
microphone.
If
you
have
questions
and
don't
forget
to
rate
the
session
by
logging
into
sched
at
the
end
of
the
talk.
A
B
Thank
you
for
coming,
because
I
thought
it
was
gonna
feel
like
there's
10
of
us
in
this
room
that
holds
14-under
people,
and
so
I'm
delighted
that
you're
here
and
I
hope
to
make
it
worth
your
while
I
am
hoping
that
this
is
going
to
be
a
really
fun
presentation.
I
do
think
it's
kind
of
funny.
I
am
call
out
to
the
person
who's
sitting
in
the
last
row
on
the
last
seat,
how
you
doing
big
room
plenty
of
room?
Alright.
So
let's
get
started.
B
B
Okay,
about
what
I
expected
it
looks
like
maybe
about
10,
15
%.
So
I
think
this
is
going
to
be
really
fun,
so
that's
really
cool.
Let
me
tell
you
a
little
bit
about
myself
and
I
do
self-identify
as
a
functional
programmer,
which
is
why
I
have
been
so
in
crate,
crazy,
incredibly
delighted
with
kubernetes
over
the
last
couple
of
years
as
I've
gotten
involved
I,
like
many
of
you
started
out,
I
was
studying
computer
science
quite
a
number
of
years
ago.
B
Thirty
years
ago,
I
think
I,
graduated
thirty
years
ago,
from
university,
I
went
to
Cal
State
University
Northridge,
which
is
in
the
Greater
Los
Angeles
area,
because
it
was
in
the
Greater
Los
Angeles
area
that
curriculum
for
computer
science
was
really
focused
on
getting
people
ready
for
industry
and
what
that
meant
was
iterative
programming
languages,
unfortunately
very
much
the
same
way.
It
still
is
today,
maybe
fortunately,
maybe
unfortunately
we'll
get
into
that
in
a
little
bit
more
detail.
B
The
languages
that
I
programmed
in
I
programmed
a
little
bit
in
high
school
I
used
basic
in
high
school
basic
when
it
still
had
line
numbers.
Some
of
you
may
never
have
seen
that
I
programmed
in
Pascal
anybody
else.
Fortran
COBOL
EDA
yeah.
These
are
all
the
languages
that
I
programmed
in
all
imperative
languages
and
if
you
don't
know
exactly
what
I
mean
by
that
I'm
going
to
go
into
a
little
bit
more
of
an
example
and
I
went
into
industry
and
I
worked
for
a
number
of
years.
B
Small
town,
30,000
people
in
southern
Indiana,
very
research,
oriented
school
and
when
I
went
there,
I
studied
programming
languages
and
theoretical
computer
science
for
three
years,
I
did
my
qualls
in
theoretical
computer
science
and
in
the
interesting
thing,
when
you
do
something
like
theoretical
computer
science
and
programming
languages,
is
that
you
learn
it
from
a
very
mathematical
standpoint
and
it
turns
out.
The
math
is
a
lot
easier
with
functional
programming
than
it
is
iterative.
And
that's
really
the
theme:
that's
the
thing!
B
That's
going
to
the
undercurrent
that's
going
to
cut
through
this
entire
presentation
in
at
Indiana
University.
When
I
was
there
I
think
it
may
have
changed,
but
when
I
was
there,
we
taught
scheme
as
the
first
language
that
we
taught
to
our
undergraduates
coming
in
I
was
a
teaching
assistant.
While
I
was
there
and
that's
the
first
language,
we
taught
them,
and
there
was
some
really
interesting
things
that
all
maybe
touch
upon
as
we
go
through.
The
presentation.
B
B
It
started
the
print
copies
started,
shipping
the
day
before
yesterday,
so
I
just
finished
it
and
if
you're
interested
there's
a
discount
code
there
for
40%
I'll
put
this
up
again
at
the
end,
the
discount
code,
if
you're
interested
the
book
is
an
architectural
book.
So
it's
all
about
cloud
native
patterns,
things
like
scale
out
statelessness,
retries,
retry,
storms
circuit
breakers
service
discovery
all
that
stuff,
but
very
much
from
a
focus
of.
Why
are
you
doing
these
patterns?
The
patterns
themselves
aren't
that
hard.
B
But
if
you
understand
the,
why
behind
them,
you'll
be
able
to
use
them
a
lot
more
effectively.
So
that's
a
that's
what
the
book
is
about
all
right
without
further
ado,
let's
jump
into
it
and
that's
a
blank
screen
and
what
R
is
I.
Remember
where
we're
going
so
when
I
started,
programming,
I
actually
started
programming,
embedded
systems
and
what
we
had
in
embedded
systems
was.
B
Once
where
we
had
two
processors-
and
we
actually
had
out
on
the
whiteboard
where
the
communication
points
were
going
to
be-
and
we
actually
timed
how
long
it
was
going
to
take
to
run
a
certain
piece
of
code
over
on
this
processor
so
that
we
could
then
hand
over
to
this
other
processor
that
was
going
to
do
in
a
number
of
things,
I
see
a
couple
of
people
nodding.
So
this
is
somewhat
familiar,
so
we
started
having
multi
processors
or-
or
you
know,
maybe
even
multi-threading.
So
we
added
that.
B
Then
we
started
having
us
so
multi-threading,
and
then
we
added
multiple
processors
and
now
we're
all
distributed
systems.
Programmers
agreed
right,
the
internet
happened
and
we
all
program
distributed
systems.
Part
of
our
logic
runs
in
the
browser.
Part
of
it
runs
on
that
mid
tier,
which
used
to
be
a
single
machine,
but
now
is
a
whole
bunch
of
different
machines.
That's
one
of
the
things
that
characterizes
the
cloud
so
we're
all
distributed
systems
programmers
now,
thirty
years
ago
there
that
was
just
very
niche.
So
what
has
happened
to
programming
languages
over
the
course
of
this?
B
Well
in
the
beginning?
I.
Even
did
a
little
bit
of
assembly
programming
to
really
optimize
all
of
the
the
the
processing
that
you
could
do
on
that
single
processor.
But
arguably,
when
you
start
going
into
multiple
threads
programming,
us
in
assembly
gets
really
hard,
so
you
have
to
use
some
higher-level
languages
that
maybe
know
some
things
about
threads
and
those
types
of
things.
So
you
see
a
whole
host
of
languages
here.
B
What
is
interesting
is
that,
as
we've
all
become
distributed
systems,
programmers
we've
started
to
see
popularity
emerge
for
a
new
category
of
languages
and
those
are
the
functional
languages
so
that
earlier
languages
were
all
imperative
languages
and
that's
what
again
I
learned
about
30
years
ago,
but
these
newer
languages
are
fall
into
the
category
of
functional
languages.
Okay,
so
that's
for
functional
programming
and
there's
a
couple
of
reasons
for
that,
but
I'll
go
into
that
in
just
a
moment.
I
want
to
show
you
an
example.
B
So
for
those
of
you
who
really
don't
are
thinking
like
okay,
eglee
I
understand
the
difference
between
imperative
and
functional.
Let
me
give
you
a
little
bit
of
a
review
and
I
want
to
do
so
with
an
example.
So
when
I
initially
started
doing
some
of
this
work,
my
son
was
taking
my
son,
who
graduated
with
a
degree
in
computer
science.
I
am
so
happy.
B
He
was
doing
a
class
in
bioinformatics
and
one
of
the
projects
that
he
needed
to
work
on
it
was
they
were
taking
the
human
genome
and
they
were
doing
some
sequencing
on
that
and
what
they
needed
to
do
was
take
the
genome
and
break
it
down
into
segments,
and
then
they
process
each
one
of
the
segments
of
course,
they're
doing
it
in
parallel,
and
then
they
merged
the
results
together.
There
was
an
algorithm
that
they
were
doing
there,
and
so
the
first
step
was
to
take
this
really
long
string
and
break
it
down
into
segments.
B
But
if
the
segments
were
too
small,
then
the
processing
that
happened
within
a
single
segment
wasn't
really
meaningful
anymore.
There
wasn't
enough
data,
so
after
breaking
into
smaller
segments,
he
wrote
an
algorithm
to
merge
together
segments
that
were
too
small.
So
what
you
see
here
is
you
see?
The
range
is
on
segments.
B
The
first
segment
is
5
long
0
through
5
non-inclusive
than
5,
through
17
17,
through
20
and
so
on,
and
so
what
we
want
to
do
is
we
want
to
merge
this
together
into
segments
that
have
a
minimum
size
well,
actually
initially,
and
so
that's
what
we're
gonna
do
here.
Sorry
I'm,
stealing
my
thunder,
so
this
is
going
to
be
the
output
0
through
5
is
too
small
17
through
20
s
too
small
and
we're
gonna
merge
them
together.
So
let's
look
at
a
couple
of
different
ways
of
doing
that.
B
The
first
thing
that
my
son
did
was
he
wrote
it
in
Python
and
he
wrote
it.
Despite
my
by
my
best
efforts,
he
wrote
it
wrote
it
in
an
iterative
style
and
rather
than
stepping
through
the
code,
let
me
show
you
pictorially
what
this
algorithm
effectively
does
starts
out
with
the
first
array
of
the
segments
and
it
does
a
scan
it
finds
one
that
is
too
short
and
it
merges
it
into
the
next
moves.
The
cursor
over
finds
another
one.
That's
too
short
merges
it
in
moves
the
cursor
over
and
now
the
cursor.
B
The
counter
is
one
beyond
the
end,
that
was
the
exit
criteria
for
the
loop
and
you
get
this
answer.
But
you
know
what
there's
actually
a
bug
in
that
algorithm,
which
gets
me
to
the
point
of
some
of
the
characteristics:
the
hallmarks
of
iterative
programs,
they're
sequential
you
control
every
step.
Remember
that,
because
that's
one
of
the
important
things
that
when
I
start
to
characterize
it
in
the
kubernetes
lens
that
you
don't
you
no
longer
control
every
step,
that's
one
of
the
big
differences.
B
So
with
imperative
you
you're
you
control
every
step
and
you
have
side
effects.
You've
got
variables
and
what
you
end
up
with
is
hairy
edge
cases
and
it's
difficult
to
parallel
eyes
because
you
have
shared
state.
So
how
are
you
going
to
coordinate
all
of
these
different
threads
that
are
working
together
on
shared
State?
So
it's
very
difficult
to
parallel
eyes
and
in
fact,
that
algorithm
that
I
just
showed
you
a
moment
ago
had
a
bug
in
it.
It
worked
out
because
the
last
segment
happened
to
be
long
enough.
B
If
the
last
segment
in
the
end
had
been
too
short,
we
would
have
had
an
error
in
that
program.
Okay,
so
would
have
crashed.
So
instead,
if
we
take
that
approach
in
a
functional
style,
sorry
I'm
double
clicking
here.
I've
written
the
same
algorithm
in
scheme
and
what
you
see
here
is
that
there
are
no
side
effects.
It's
entirely
immutable
and
the
way
that
it
works
is
very
interesting.
We're
gonna
start
with
the
same
thing
and
what
we
do
is
we
peel
off
the
in
scheme
or
list?
B
We
call
it
the
car,
you
haven't
done
your
schemer
list
and
a
lisp
in
a
long
time.
We
peel
off
the
head
of
the
list.
Then
we
make
a
recursive
call
on
the
rest
of
the
list
and
we
trust
that
we're
gonna
get
the
right
answer.
Doesn't
that
sound
a
little
bit
like
inductive
proofs,
assume
n?
Then
you
can
prove
n
plus
1,
so
we
make
the
recursive
call.
We
assume
we're
getting
back
the
list
and
then
we
finish
our
processing
where
we
do
a
merge
and
we
get
the
final
result.
B
So
that
is
a
fundamentally
different
approach.
There's
no
bugs
in
this
particular
particular
algorithm.
Now
the
homeworks
of
functional
programming
men
are
that
they're
declarative
you're,
not
doing
every
step
in
the
sequence
yourself
you're.
Taking
this
leap
of
faith
and
saying
the
recursive
calls
gonna,
give
me
something
back
and
I'm
not
worried
about
how
it
does
it,
and
so
that's
a
much
more
declarative
approach.
There's
no
side
effects.
B
This
is
some
work
that
I've
been
doing
with
a
colleague
and
Industry
colleague
of
mine,
who
many
of
you
probably
know
by
name
it's
Jane
Kim
who's,
one
of
the
co-authors
of
the
Phoenix
project,
and
he
has
been
going
through
this
transition
of
from
it.
Being
an
iterative
programmer
to
a
functional
programmer,
and
this
is
a
quote
that
I
got
from
him,
which
is
he
had
a
program
that
he
wrote
that
took
3,000
lines
of
objective-c?
B
B
So
it
allows
you
to
write
more
compact
code.
The
real
point
here
is
that
this
iterative
model
in
the
functional
model
there
are
two
different
models
not
only
of
programming,
but
also
of
the
way
that
we
think
and
that's
the
question
that
I'm
gonna
pose
is
what's
the
model
that
we're
going
to
use
to
reason
with
in
iterative
versus
functional
programming.
B
To
sum
it
up
on
the
left-hand
side,
we're
doing
iterative
on
the
right
hand,
side,
declarative,
left-hand
side,
mutable,
state,
two
immutable
state
and
we'll
see
how
that
comes
up
again,
looping
to
recursion,
and
it's
not
really
functional
programming.
But
it
is
a
modern
programming
practice
that
shows
up
in
the
kubernetes
space
that
I
want
to
talk
about,
which
is
the
difference
between
libraries
compiled
in
and
something
like
aspect
oriented
programming
in
dependency
injection.
B
B
We
want
to
allow
our
software
to
do
some
of
that
reasoning
for
us,
if
you
remember
the
transition,
if
I
had
to
do
write
my
programs
and
assembly-
and
that
was
the
model
that
I
thought
in
I,
wouldn't
be
able
to
solve
the
same
level
of
complexity
in
those
problems
all
right.
So,
let's
ship
now,
let's
turn
our
view
I'm
just
looking
at
the
time.
Great.
B
The
whole
point
here
is
that
we
can't
we
with
distributed
systems.
We
can
no
longer
reason
about
every
detail
that
we
used
to
reason
about.
Our
systems
are
just
too
complex,
so
we've
shifted
the
model
and
that's
one
of
the
most
powerful
things
in
kubernetes.
Yes,
it's
a
container
Orchestrator,
that's
great.
It
knows
how
to
schedule,
but
it's
all
of
the
other
things
that
it
does,
that
I'm
gonna
touch
upon
in
this
talk
that
make
it
even
more
powerful
all
right.
B
What
we're
going
to
look
at
is
on
the
imperative
side.
We
have
scripted
deployments
now.
We
have
declarative
deployments,
everybody's,
probably
pretty
familiar
with
that
now,
hopefully
you're
not
just
doing
a
coop
cuttle
run,
you
are
using,
manifests
in
doing
declarative,
manifest
and
declarative
deployments.
In
the
olden
days
we
might
have
SSH
tin
to
a
box,
never
anymore.
We've
got--we've
works,
for
example,
down
there
that
has
on
its
poster
behind
there's
Vera.
B
So,
instead
of
having
a
entire
platform,
we're
even
doing
that
within
cloud
foundry
cloud,
foundry
used
to
be
a
little
bit
more
middleware
or
like
it,
had
everything
baked
into
that
platform.
Now
we're
starting
to
put
some
of
that
capability
into
sidecars
and
I'll
talk
about
how
that
works.
So
again,
it's
all
about
the
model.
B
Okay,
so
let's
jump
into
each
one
of
those,
this
one
I'm
going
to
go
through
fairly
quickly
because
I
think
it's
pretty
familiar
to
all
of
you
in
this
kubernetes
space.
So
of
course,
here
I
have
my
kubernetes
notes
and
when
I
want
to
do
a
deployment
of
my
application,
no
longer
do
I
say
stand
up
this
node
deploy
the
app
here
stand
up.
This
node
deploy
the
app
here
even
with
you
know,
imperative,
even
with
imperative
automation.
What
I
simply
say
is
here's
my
topology.
B
You
know,
gets
down
to
a
base
case,
so
things
in
functional
language
is
like
lazy
evaluation.
That
say
you
know
what
I'm
gonna
defer
the
execution
of
this
entire
stack
of
function
of
recursive
calls
until
I
actually
need
them
instead
of
doing
them.
When
you
say
you
want
me
to
do
them,
I
know
better.
I
can
do
an
optimization
for
you,
so
that
is
what
kubernetes
is
doing
so
that,
when
you
oh
and
with
compliance,
there's
an
example
here
with
daemon
sets.
Of
course
it
does
that
on
the
nodes
as
well.
B
The
whole
notion
there
is
that
the
control
loop
is
the
place
where
you
can
do
optimizations
and
because
you
are
following
functional
principles
like
immutability
like
declarative
configurations,
it
allows
you
to
put
more
intelligence
into
the
reconciliation
loops
that
are
in
kubernetes
and
notice.
That
I
said
loops
for
some
of
you
who
are
new
to
kubernetes.
B
You
might
be
just
thinking
about
the
replica
set
controller,
but
there's
a
lot
of
reconciliation
loops
in
kubernetes
I,
sometimes
like
to
say
that
kubernetes
is
just
a
system
of
a
whole
bunch
of
it's
it's
a
registry
of
a
whole
bunch
of
infinite
loops
that
are
all
running
and
doing
reconciliation.
Okay,
that's
really
at
the
core
of
the
architecture,
and
that's
really
the
point
here
and
notice
here
that
I
also
had
a
node
go
away
and
we
can
in
fact
even
use
control
loops
to
recover
those
nodes.
B
We
do
that
today,
with
PKS
using
Bosh,
and
you
saw
Joe
Beda
talk
in
the
keynote
yesterday
about
cluster
API,
same
basic
idea,
reconciliation,
loops
for
the
clusters
themselves
and,
of
course
here's.
My
point
is
that
you
have
multiple
reconciliation,
loops
and
they're
all
independent
okay.
So
this
is
a
little
bit
like
functional
programming.
I'm
gonna
go
through
this
very
quickly.
I
already
talked
about
this.
You've
got
the
base
case
and
then
that
recursive
call
is
a
little
bit
of
a
leap
of
faith.
B
When
you
make
the
recursive
call,
you
don't
worry
about
how
it's
actually
getting
the
answer.
You
just
trust
that
it's
getting
the
right
answer
and
then
you
just
go
on
your
way.
Alright,
so
that
was
declarative.
Let's
now
move
on
to
a
mutable
infrastructure,
so
there's
a
couple
of
things
that
are
really
interesting
about
immutable
infrastructure.
So
in
the
olden
days
we
had,
we
certainly
had
pipelines.
B
So
that's
the
first
step
and
we've
had
pipelines
for
a
long
time
so
that
we
aren't
having
a
human
being
sitting
at
a
console
saying:
oh,
let
me
do
an
AWS
get
machine
and
then
I'm
gonna
do
it.
You
know
I'm
gonna
SSH
into
the
box
and
I'm
going
to
start
executing
some
commands,
apt-get
s--
and
things
like
that.
B
I
at
least
have
all
of
that
in
a
pipeline
which,
by
the
way,
is
imperative,
so
I've
got
provision
and
configure
and
then
deploy
and
then
configure
my
apps
so
provision
the
infrastructure
configure
the
infrastructure,
deploy
the
app
configure
the
app
and
notice
that
I've
got
the
little
git
icons
in
there.
So
my
configurations
are
all
source
code
controlled
right,
we're
all
doing
that.
B
But
one
of
those
that
I
have
seen
in
customer
sites
over
and
over
is
that
it's
slow
to
provision
a
new
VM,
it's
slow
to
provision,
a
new
VM,
remember,
I,
said
and
actually
Tim
said
when
he
introduced
this-
that
we're
going
to
look
at
some
of
the
principles
of
kubernetes
and
containers
from
a
functional
lens
and
immutability
is
one
of
those
things.
Well.
B
The
fact
that
we
immutability
is
really
important
for
repeatability
right
everything
comes
from
get,
everything
is
repeatable,
but
what
happens
is
if
there's
a
step
in
your
pipeline
that
takes
too
long,
then
we
start
putting
in
shortcuts.
So
I
worked
with
a
customer
once
who
discovered
that
they
had
all
sorts
of
shortcuts
where
they
actually
weren't
starting
from
scratch.
They
were
leaving
VMs
in
place,
and
so
they
were
getting
configuration
drift
all
over
the
place.
B
So
if
we
go
back
to
this
picture,
then
the
first
thing
that
I
want
to
do
is
I
want
to
take
the
first
two
steps
and
I
will
totally
admit
that
this
has
a
bias
hat
on
it,
because
I
come
from
a
platform
vendor
and
we've
seen
the
value
of
platforms.
Now
this
is
a
friendly
audience
because
we're
all
here
talking
about
a
platform
for
building
platforms
right,
so
everybody
buys
that
platforms
helped
us
here.
B
So
what
we
want
to
do
is
we
want
to
take
the
first
couple
of
steps
and
push
those
down
into
a
configured
platform
like
kubernetes.
That
still
leaves
the
deploying
configure
step
on
the
right-hand
side.
So
what
we
do
now
is
for
that,
deploy
and
configure.
We
can
start
leveraging
containers
it's
now
going
to
take
milliseconds
instead
of
five
minutes,
and
so
some
of
those
shortcuts
that
I
talked
about
before
you
no
longer
need
those.
B
Do
that
whole
step
and
I'm
going
to
do
it
earlier
in
the
process
that
I'm
gonna
leverage
things
like
helm,
get
and
image
repositories
like
harbor
I
can
do
all
of
that
stuff
that
I
used
to
do
a
deployment
time.
I
can
do
it
before
and
in
the
DevOps
community
and
I
spend
a
lot
of
time
in
the
DevOps
community.
We
talk
about
shift
left.
So
what
this
means
is
that
I
can
do
all
of
this
very
early
on
in
my
development
cycle.
B
So
that
deployments
then
are
a
no-brainer
and
easy
deployments
are
an
important
part
of
writing
cloud
native
software
and
cloud
native
practices.
So
you
might
be
thinking
well.
What
does
all
of
that
have
to
do
with
imperative
and
functional
models?
Okay,
you're
telling
me
about
kubernetes,
but
come
on
bring
this
back
to
functional
models.
So
let's
take
a
look
at
that
when
we
did
state
the
the
previous
way.
Remember,
there's
the
counter
there.
B
The
way
that
worked
was
that
we
were
constantly
moving
state
around
Anne,
muting
state
and
all
of
that
stuff,
and
in
the
end
we
really
have
no
idea.
We
have
the
final
answer,
but
we
have
no
idea
how
we
arrived
at
that
final
answer,
because
all
of
that
history
is
lost
if,
instead
on
the
imperative
side,
we
end
up
looking
at
things
and
so
here's
the
point
is:
how
do
you
prove
the
correctness?
Remember
I
said
that
that
algorithm
had
a
bug
in
it.
B
So
if
you're
allowing
for
side
effects,
how
do
you
ever
prove
the
correctness
of
a
piece
of
software?
It's
very
difficult,
if
not
impossible,
so
other
influences
plus
a
state-based
a
mutant
mutation
based
algorithm
and
you
end
up.
You
can't
prove
the
correctness
of
that.
If,
on
the
other
hand,
you
take
a
functional
approach,
this
is
what
your
functional
execution
looks
like.
Remember,
it's
a
whole
bunch
of
recursive
calls
and
each
one
of
the
frames
on
the
stack
are
immutable
frames
and
then
to
actually
achieve
the
answer.
B
You're
just
playing
through
that
call
stack
to
get
the
answer.
So
the
call
stack
and
again
it's
just
going
my
my
animations
aren't
usually
that
slow,
I
don't
know
what's
going
on,
the
frames
are
immutable
and
what
we're
gonna
do
is
play
through
the
call
stack
to
get
the
final
answer.
Okay,
so
that
is
you
see
kind
of
you
see,
at
least
at
a
gut
level,
the
kind
of
parallels
that
are
going
on
there,
okay,
so,
okay,
there's
a
funky
animation,
obviously
didn't
double
triple
check
these
last
night.
B
Sorry,
and
so,
if
you
draw
that
parallel,
the
container
images
are
a
bit
like
your
stack
frames
and
your
interpreter
kubernetes.
The
controller
is
a
little
bit
like
the
the
execution,
through
the
call
stack
so
great.
Thank
you
all
right.
So
let
me
push
forward.
There's
another
place
that
we're
seeing
this
pattern.
B
Just
like
the
call
stack
we
talked
about
a
moment
ago,
and
then
we
can
play
through
each
one
of
those
things
to
get
to
a
to
other
sources.
So
there's
a
whole
other
talk
there
all
right.
Let
me
quickly
go
through
these
last
two
things,
and
that
is
ephemeral
containers.
Now
this
is
a
story
that
I
can
tell
very
quickly.
Everybody
here
is
familiar
with.
B
So
we
know
that
these
containers
are
immutable
and
that
we
have
container
images
that
we
can
spin
up.
Let
me
share
with
you
a
super
cool
use
case
about
this
yeah
and
here's
the
thing
malware.
A
bad
actor
comes
in
and
drops
malware
into
my
system,
and
we
know
that
a
lot
of
the
breaches
out
there
are
caused
from
malware
that
went
undetected
for
months
at
a
time
and
then
the
bad
actor
moves
away
goes
away,
and
so
we
can't
detect
the
bad
actor
anymore,
but
the
malware
is
still
there.
B
Okay,
there
we
go
bad
actor
goes
away.
So
how
do
containers
help
you
with
this?
So
again,
remember
the
difference
was
long-running
state
versus
immutable,
ephemeral
containers.
Well,
here's
what
one
of
our
customers
at
cloud
foundry
does
because
we're
a
container
based,
not
quite
kubernetes
based
yet
because
we
predate
kubernetes
but
its
container
based
what
they
do
is
proactively
they
without
knowing
whether
there's
malware
or
not.
They
do
this.
B
They
on
a
periodic
basis,
just
throw
away
the
container
and
stand
up
a
new
one
if
there
was
malware
on
it,
it's
gone
now.
If
there
was
no
malware
on
it,
cool
there's
still
no
malware
on
it
and
they
not
only
do
that
at
the
container
level,
but
they
also
do
it
at
the
host
level.
So
they
throw
away
the
host
stand
up
a
new
host.
So
if
there
was
malware
on
it,
it's
gone
and
the
container
is
stood
up
and
it's
clean.
So
they
do
this
proactively.
B
They
repaved
their
environment
and
they're
able
to
do
this
because
of
the
containers
that
they
have
I'm,
suggesting
that
you
do
that
very
often
this
particular
customer
in
US
Wells
Fargo,
because
they
talk
about
it
very
publicly.
They
do
it
every
three
days.
Lance
wants
to
do
it
so
that
he
does
it
every
single
day.
He
doesn't
want
a
container
in
his
infrastructure
to
live
longer
than
a
day,
which
is
super
cool.
All
right,
I
hear
I
have
one
minute
left,
so
let
me
wrap
it
up
and
I
will
stick
around
afterward.
B
We
can
go
out
in
the
hallway
and
I'll
answer,
questions
there.
Finally,
on
the
sidecars
thing
I'm
going
to
flip
through
this
very
very
quickly-
and
that
is
oh,
let
me
skip
through
this
slide,
because
I
really
just
want
to
talk
about
here.
We've
got
our
containers,
and
now
what
we
want
to
do
is
without
actually
having
to
insert
something
into
the
code
itself.
B
What
we
want
to
do
is
we
want
to
take
advantage
of
cross-cutting
concerns
like
routing
like
auditing,
like
certain
security
things,
and
we
do
that,
of
course,
with
sidecars
and
there's
there's
personas
here
that
care
about
that.
So
this
is
this
is,
for
example,
your
auditor.
That
cares
about
that.
The
way
that
we're
going
to
do
that,
of
course,
is
in
the
pod,
so
a
pod.
B
This
is
why
pods
have
more
than
one
container
in
them,
or
certainly
one
of
the
great
use
cases
is
that
I
can
have
my
application
container
and
I
can
have
my
sidecar
okay.
So
that's
that
and
of
course
we
can
do
that
using
things
like
daemon
sets.
We
can
do
that
at
the
host
level
as
well,
and
that's
what
I'm,
showing
you
in
this
picture.
B
B
Yes,
this
is
the
final
thought
that
I'm
gonna
leave
you
with
is.
If
we
take
a
look
and
we
go
all
the
way
back
to
the
functional
programming
metaphor,
if
you
remember
those
things
were
declarative
and
at
the
top
here
we
see
declarative
deployments.
Well,
that
was
a
hallmark
of
functional
programming.
We
had
immutability
well
immutable
infrastructure.
Immutability
is
a
hallmark
of
functional
programming,
ephemeral
containers
that
you
can
use
to
that.
You
can
then
recreate
and
compose.
That
is
where
it
the
parallel
is
to
recursive
and
then
sidecars.
B
They
look
an
awful
light
lot
like
aspect
oriented
programming,
so
I
hope
that
was
kind
of
a
fun
look
between
functional
programming
and
iterative,
programming
and
kind
of
the
parallels
into
our
kubernetes
world
I'm
going
to
go
ahead
and
put
up
the
last
slide,
while
I
step
off
the
stage
and
start
to
maybe
answer
a
few
questions.
Apologies
for
not
having
time
thanks!
So
much
have
a
great
day.