►
Description
There’s no such thing as vanilla Kubernetes in the same vein that there is no vanilla Linux; even if you start from source, you must custom build everything around it to make it production-ready. By looking at the past and the present, this talk will explore what it takes to build and operate Kubernetes in production, what alternatives you can buy, and extrapolates on industry trends towards “utility” services to explore what the future of Kubernetes might look like.
A
B
All
right
so
hi
everybody
I
apologize,
I
don't
have
twitch
up
and
running
in
front
of
me.
Folks
are
chatting
there,
so
someone
will
have
to
communicate
the
chat
to
me.
If
that's
the
thing
that
occurs,
while
I'm
going
through
all
this
here,
but
I'll
I'll
get
there
so
yeah
I've,
I've
done
the
wonderful
thing
of
building
a
nice
little.
Who
am
I
into
my
presentation?
B
So
you
get
visual
aid,
so
I
am
erin
aldridge
managed
to
open
shift
black
belts
here
at
red
hat
historically
through
a
lot
of
things,
I'm
also
tied
into
the
devops
days
community.
I
organized
started
the
hartford
event
for
that
and
I've
organized
for
both
new
york
city
and
boston
as
well.
So
if
you
saw
the
boston
event
last
year
that
was
online,
it
was
there.
B
I
also
host
the
tabletop
devops
thing
that
also
streams
here
on
twitch
with
using
desert
island
tv
care
about
some
mental
health
in
tech
is
another
corner
that
I
will
often
be
fouled
speaking
about
and
yes,
my
license
plate
actually
says
devops,
which
is
sort
of
shamelessly
stolen
from
matt
stratton,
but
he
lives
in
a
different
state
and
his
license
plate
changed
to
pedal
anyway.
So
it's
fine.
B
So
yes,
let's
jump
in
a
little
bit
here
and
talk
about
the
kubernetes
landscape
a
little
bit
and
simply
we're
talking
about
vanilla
kubernetes.
So
before
I
tell
you
that
it
doesn't
exist,
let's
actually
establish
what
it
is,
we're
talking
about
right
and
first
things.
First,
here
it
is
right.
We
found
vanilla,
kubernetes
already,
I'm
lying
to
you.
No,
but
it's
a
little
bit
more
seriously.
This
is
the
kubernetes
project
right.
B
You
can
find
it
online,
so
I
don't
mean
that
literally
this
thing
doesn't
actually
exist
in
the
world
on
the
internet,
but
there's
no
real
practical
use
for
it
doesn't
use.
It
doesn't
really
exist
in
practice.
So
there's
a
reason.
People
want
vanilla,
kubernetes
and
talk
about
it
right
often
the
myth
of
vanilla
kubernetes
is
portability
right.
If
you're
built
for
just
the
upstream
software
package,
you
should
be
able
to
work
everywhere.
B
Maybe
lock-in
is
a
concern,
so
you
don't
want
to
be
stuck
with
any
one
vendor.
You
won't
be
able
to
move
around
and
you
want.
You
know
cutting-edge
features
right
if
you're
consuming
upstream,
you
don't
have
to
wait
for
it
to
get
packaged
and
shipped
along,
but
these
don't
really
exist
in
practice,
and
so
let's
examine
what
it.
What
kubernetes
really
pertains
to
right
just
running
kubernetes
by
itself
already
is
going
to
take
a
bunch
of
different
services
right,
whether
it's
working
specifically
on
the
control
plane
or
working
on
the
node.
B
You
have
to
make
sure
that
cd
is
working,
make
sure
your
scheduler
is
running.
You
have
a
dupe
controller
manager,
you're
running
in
a
cloud
right.
You
need
the
cloud
controller
band.
Just
you
can
talk
back
to
the
cloud
services
apis
and
understand
all
that
and
that's
all
you
know
making
sure
you
have
your
kubelet,
your
food
proxy.
You
need
all
these
other
services
like
dns,
so
everything
knows
where
to
talk
to
each
other.
B
You've
got
your
underlying
infrastructure
right,
just
choosing
what
type
of
metal
to
run
it
on
or
what's
involved
in
that
is
going
to
be
a
choice
that
has
to
be
made.
How
do
you
want
to
automate
that
infrastructure?
Are
you
going
to
use
ansible
or
using
something
else
to
do
that?
You've
got
to
maintain
that
long
term,
as
we
all
know
like
infrastructure,
as
code
is
sort
of
saying
the
same
as
eventual
inconsistency
right.
So
we've
got
to
continue
to
maintain.
B
All
of
this
stuff
that
goes
on
for
it
and
we
even
have
to
make
a
choice
like
again
like
I
talked
about
container
runtime,
that's
a
choice
right!
You
don't
start
with
the
default
container.
Runtime
you
have
to
choose.
Do
you
want
container
d?
Do
you
want
prio
are
using
docker
for
it
or
actually
docker
is
not
really
it's
going
to
be
removed.
We're
not
going
to
support
docker
shim
anymore,
but
that's
been
pushed
back
a
little
bit
further,
so
you
can
still
use
it
for
right
now.
B
B
So
realistically
we
don't
have
extreme
portability.
You've
now
got
this
custom
tuned
infrastructure
that
can
only
run
your
your
apps
right
because
they're
built
for
that
environment
so
that
locked
in
yeah
you're
not
locked
into
any
given
vendor,
but
now
any
environment
that
you
move
to
is
going
to
have
to
look
pretty
similar
to
the
one
you're
operating
that
you've
custom
built
right.
You
have
to
continue
to
custom,
build
that
environment
everywhere
go
and
now
maybe
you
get
the
latest
features,
but
that
is
for
everything.
It's
also.
B
So
the
conversation
this
ends
up
being
is
a
lot
more
like
build
versus,
buy
right.
This
is
probably
a
conversation
you've
heard
of
before
I
kind
of
hope.
People
have
some
experience
and
understanding
of
the
build
versus
by
conversation,
because
we
do
this
all
the
time
right.
This
is
not
like
a
completely
unfamiliar
concept.
B
You
may
think
about
it.
You
do
it
every
day,
right
think
about
just
lunch
time.
Do
I
go
make
myself
lunch
or
do
I
go,
buy
it
and
there's
different
trade-offs
in
that
that,
and
I
feel
like
we
talk
about
it
so
much.
It
should
be
this
sort
of
settled
case
law
of
like
okay.
We
understand
the
process,
we
know
how
to
do
this
now,
let's
walk
through
every
scenario,
and
I
think
we
kind
of
do
so.
B
Let's
actually
examine
this
scenario,
understand
what
our
build
cases
and
our
bi
cases
are
and
kind
of
see
it
a
little
bit
more
closely
build
right.
So,
if
we're
building
the
software,
this
is
the
example
of
like
our
pure
vanilla,
straight
tapped
from
the
source.
Kubernetes
right,
we're
downloading,
compiling
source
might
be
the
extreme
example
of
building
yourself,
and
this
is
like
the
same
as
thinking
of
like
vanilla,
linux
right.
This
would
be
like
a
custom
compiled
distro
that
you're
pulling
right
from
source
code.
B
So
the
nice
thing
is
you
get
ultimate
freedom
right.
You
can
choose
every
little
detail.
Everything
can
be
custom
built.
It
can
work
specifically
for
the
application
or
use
case.
You
have
in
mind
it's
built
towards
purpose
right.
It
can
be
specially
tuned
there.
The
other
side
of
freedom
is
always
responsibility
like
if
you've
ever
seen
the
the
netflix
culture
deck.
They
talk
a
lot
about
freedom
and
responsibility
to
kind
of
go
hand
in
hand.
B
While
you
get
that
freedom
to
do
and
create
whatever
you
want,
you're
also
responsible
to
answer
for
it.
Why
you
made
those
choices,
and
you
have
to
have
deliberation
and
and
understand
all
of
that
right?
I
think
the
line
is
like
intention
without
strategy
is,
is
chaos
and
when
you
want
to
answer
to
your
c-suite
about
like
hey,
why
did
we
choose
this
package
for
implementing?
B
You
know
our
our
run
times
like?
Why
did
we
choose
docker?
If
that's
going
to
be
deprecated,
it
seems
like
that
was
a
lot
of
work
like
it.
Just
felt
right
at
the
time
is
probably
not
going
to
be
a
great
answer
to
deliver
in
that
conversation,
so
it
requires
a
lot
more
thought
and
choice
and,
as
we
all
know,
from
from
open
source
right
when
you
build
it
yourself,
it's
it's
free
as
in
puppies
right.
So
there's,
maybe
no
upfront
costs
you
can
do
without
paying
a
software
vendor.
B
You
don't
have
to
have
a
sales
conversation
or
a
procurement
process,
but
what
you're
saving
in
that
upfront
cost
you're
shoving
into
implementation
and
learning
right.
You've
got
engineers
that
now
need
to
become
experts,
you've
got
care
and
feeding
and
maintenance
that
needs
to
happen.
So
that's
kind
of
the
what
the
the
costs
are
of
our
built.
B
And
this
is
again
just
like
a
house
right,
you
can
custom,
build
a
house
there's
a
lot
of
choices
that
have
to
pay
or
you
can
build
one,
that's
already
standing
and
you
get
all
of
the
the
information
there.
The
example
for
extreme
build
in
our
case
might
be
managed
services
for
openshift,
something
like
rosa
that
just
launched
recently.
Red
hat
open
shifts
on
amazon
right.
So
this
is
often
opinionated
services.
B
So,
when
you're
buying
something
off
the
shelf,
all
those
implementation
details
have
been
chosen
right,
someone's
made
all
those
choices
ahead
of
time.
They
might
be
the
best
choices
for
them
or
the
best
choices
based
on
their
experience
in
the
industry.
But
all
those
choices
are
supported
and
tested.
They
are,
in
fact,
experts
making
those
choices
because
they
have
implemented
this
and
they're
building
it
for
multiple
customers.
B
You
get
some
level
of
being
able
to
go
back
to,
in
our
case,
red
hat
or
you
know,
whoever
has
built
the
product
and
say
hey,
I'm
having
some
challenges
with
it.
Can
I
get
support
and
they're
testing
it
not
only
with
their
own
internal
experts,
but
all
of
their
customers
continue
to
test
that
software
as
well
right.
B
B
So
how
do
we
examine
this
choice
right?
First,
obviously,
we
will
have
resource
constraints
if
you
have
more
time
than
money
like
that's
always
going
to
be
a
factor,
and
I've
been
in
those
organizations,
the
non-profits
in
the
small
organizations
that
really
just
cannot
get
the
the
lump
funding
to
buy
a
solution
that
they
want,
so
you're
forced
to
sort
of
become
experts
and
implement
it
at
that
point
and
that's
a
different
situation.
B
Largely
what
we're
talking
about
here
is,
if
we're
min
maxing
our
organizational
choices,
if
all
things
are
created
equal,
how
do
we
want
to
spend
money
versus
time,
and
the
key
here
is
always
to
focus
on
what
sets
you
apart
in
the
market
like?
Why
is
your
service
special?
Why
is
your
company,
your
organization,
the
best
one
to
do
what
it
is
you're
doing?
B
That's
the
kind
of
stuff
that
you
can't
buy
right,
because
that's
what
makes
your
organization
unique
makes
you
special
doing
the
thing
that
you
do
so
that's
really
where
we
want
to
spend
time
on.
That's
where
we
want
us
to
things
built
for
purpose,
things
that
are
going
to
enhance
your
specialization
are
going
to
make
you
stand
out
and
make
you
better.
That's
where
time
and
building
comes
in,
because
you're
not
going
to
be
able
to
buy
an
off-the-shelf
product
that
makes
you
unique
right.
B
Red
hat
couldn't
buy
an
off-the-shelf
operating
system
way
back
when
and
b
red
hat
right.
They
had
to
build
their
own
implementation
of
the
core
gnu
linux
operating
system
to
become
red
hat
like
to
offer
something
to
the
markets
interesting,
but
all
the
things
like
implementation
details,
whether
it's
how
you
host
your
applications
or
what's
our
process
for
delivering
into
production
a
lot
of
times,
you
can
buy
your
way
out
of
those
decisions
and
pay
someone
else
to
be
an
expert.
B
At
the
end
of
the
day,
you're,
probably
most
programmers
in
an
organization
aren't
getting
paid
to
be
kubernetes
experts
they're
getting
paid
to
deliver
value
to
their
customers
by
way
of
their
application
like
quickly
and
efficiently
and
have
it
worked
every
time.
So
all
those
implementation
details,
if
those
can
be,
we
just
buy
our
way
out
of
those
decisions.
In
that
time,
we
can
start
getting
more
ideas
into
production,
more
faster,
which
that's
the
technical
term
more
faster.
B
So
you
can
probably
guess
my
answer
to
this
almost
always
is
buy
right,
especially
if
we're
talking
about
something
like
infrastructure
or
kubernetes
like
buy
your
way
out
of
making
those
decisions
unless
like
if
this
is
not
a
core
component
of
r,
of
course,
the
exception
that
proves
the
rules.
I
think
this
is
a
good
story.
Is
the
company
data
dog,
if
you
don't
know
datadog,
they're
a
sas
monitoring
company
observability
company?
So
you
know
you
order
a
data
dog
off
the
internet.
B
You
install
clients
on
your
machines
and
they
bill
you
per
system
that
you
have.
You
know,
processing
data
or
you
get
billed
for
the
data
that
you're
keeping
or
processing-
and
I
I
don't
work
for
datadog,
so
I'm
not
going
to
push
them
any
further,
but
the
implementation
of
of
kubernetes
is
the
example
here
they
have
built
it
and
they
are
operating
their
own
kubernetes
for
a
reason
right.
B
They
made
this
choice
strategically
part
of
it
was
there
because
they're,
an
infrastructure,
monitoring,
company
understanding
how
kubernetes
works
and
understanding
the
ins
and
outs
and
what
you
care
about
and
what
it
looks
like
right
before
it
falls
over,
is
extremely
important
to
them
right.
They
want
to
know
how
their
customers
use
this
product,
so
they
can
offer
a
better
product.
B
Their
customers,
so
becoming
experts
in
kubernetes
is
actually
something
that
gives
them
value
the
other
side
of
it
is
they
started
early
enough
in
the
the
life
cycle
of
kubernetes
there
weren't
services
offered
for
it
right.
There
was
sort
of
the
project,
and
maybe
one
or
two
distributions
that
existed,
but
largely
they
were
jumping
in
extremely
early.
They
became,
or
you
know,
contributors
to
the
project.
I
remember
seeing
the
a
couple
of
talks
they
gave
here.
So
these
are
our
two
examples
of
some
of
the
talks.
They
talked
about
the
cost.
B
A
bit
of
you
know,
kubernetes
the
very
hard
way
right.
If
kelsey
hightower's
introduction
is
kubernetes
the
hard
way
they
talked
about
actually
practically
doing
that
in
production.
You
know
the
challenges
they
ran
into,
how
many
times
dns
broke
for
them,
because
it's
always
dns
how
many
times
containers
stop
being
contained
right.
All
of
these
weird
implementation
details
that
you
have
the
fact
that
they
had
to
contribute
to
the
core
project
in
order
to
get
the
services
that
they
needed
right.
B
They
had
to
actually
build
into
kubernetes
the
functionality
they
wanted
because
it
wasn't
there.
So
these
are
all
things
you
take
on.
If
you
choose
to
build
it,
obviously
they
had
a
good
cause.
It
got
them
where
they
are
now
now
they're
operating
extremely
large.
You
know
thousand
two
thousand
node
clusters
in
production
and
obviously
you
know
their
product
works
and
they
still
have
customers,
so
it
worked
out
well
for
them.
B
Okay,
great
so
the
exception
that
proves
the
rule.
You're,
not
data
dog,
you're,
probably
looking
at
buying.
Unless
again,
unless
you
know
offering
that
platform
is,
is
core
to
your
your
organization
or
you
have
other
resource
constraints.
So
what
are
our
options
right?
I
mentioned
distributions,
and
this
is
just
like
linux
right.
If
linux
is
vanilla,
you
gotta
build
it
all
yourself
or
you
can
get
a
distribution
you
need
to
get
it
already
built
with
a
lot
of
implementations.
B
Kubernetes
has
a
certification
right.
This
certified
kubernetes
is
making
sure
that
any
given
distribution
that
has
this
stamp
on
it
is
going
to
be
compatible
with
the
core
project.
So
any
application
that
should
run
in
before
kubernetes
should
run
on
anything.
That's
certified
kubernetes
effectively.
Taking
that
vanilla
purity
test
and
and
making
it
meaningless,
saying
this
contribution
is
fine
right.
It
passes
the
vanilla
test.
B
So
if
we're
going
to
certify
fresh
some
of
our
distributions,
let's
look
at
what
we've
got
here.
We
have
a
number
of
distributions
all
over
the
place,
whether
it's
openshift
or
rancher
or
aks,
or
what
have
you
and,
of
course,
they're
all
certified
right?
Why
wouldn't
you
be?
If
you
have
a
kubernetes
distribution,
you
have
to
be
certified
kubernetes
or
no
one
is
going
to
use
it.
B
So
just
this
standard
is
already
answering
some
of
this
purity
test
question
here
is
the
bit
that
they're
talking
about
this
is
sort
of
upstream
kubernetes
when
we're
certifying
kubernetes.
This
is
the
bit
we're
talking
about
we're
saying
whatever
product
we
have
here
is
compatible
like
it
has
all
these
components
and
they
all
work
the
exact
same
way
that
we
would
expect
them
to
also
take
a
look
at
distributions.
B
Let's
take
a
look
at
eks
right
that
runs
amazon's
own
version
of
kubernetes,
and
you
can
see
they've
added
a
lot
of
stuff
around
it.
Some
of
it
is
how
you
wrote
in
production.
Some
of
it
is
just
implementation.
Details
like
where
does
my
control
plane
live?
How
am
I
what
types
of
systems
I
use?
Am
I
using?
How
else
do
I
want
to
extend
that's
the
type
of
stuff
that
gets
stacked
around
it?
It
doesn't
actually
change
the
underlying
compatibility
of
the
application.
B
It's
still
completely
compatible
with
kubernetes,
and
has
that
certified
bit
right.
Google
kubernetes
engine
very
similar
process
right
as
far
as
a
cloud
provider
and
google
right,
the
originator
of
kubernetes
is
the
board
project
they're,
not
using
the
pure
product
right.
They
have
implementation
details
they've
made.
They
have
abstractions
that
they've
made
on
top
of
that
to
make
sure
that
they
can
get
their
monitoring
and
their
storage
wired
up
to
it
properly
to
their
services.
B
And,
of
course,
you
have
something
like
openshift
right,
openshift's
a
little
bit
different
because
we
have
this
product
as
it
doesn't
just
live
in
a
cloud.
It's
also
something
that
is
a
deliverable
product
that
someone
can
install
on-prem
it
kind
of
is
a
does
a
little
bit
more
than
just
the
control
plane.
So
you
see
here
kind
of
lives
inside
kubernetes,
but
largely
it's.
The
same
type
of
thing:
you've
got
an
openshift
cli,
that's
compatible
and
an
openshift
api.
That's
compatible
with
kubernetes.
B
So
that's
that's
that
right,
like
we've
got
these
products
that
are
certified
fresh
kubernetes
and
that
sort
of
covers
the
is
this
compatible
with
any
other
solution
that
I
would
build,
and
this
is
saying
yes,
we're
going
to
make
these
compatible
with
the
core.
So
anything
you
build.
If
you
want
to
have
that
portability
and
want
it
to
be
useful,
you
have
to
make
sure
your
custom
implementation
of
kubernetes
follows
all
these
certified
kubernetes
standards
or
you're,
going
to
have
lock
and
details
that.
B
So
this
also
brings
up
a
little
bit
of
an
interesting
point
that
I
want
to
get
into
with
these
different
services
to
go
back
a
little
bit.
Obviously,
like
I
said,
openshift
is
a
little
bit
of
a
different
product
and
these
are
pretty
much
live
in
the
managed
service
realm,
and
these
things,
like
you,
know,
xks
services
gke
in
this
managed
service,
realm
sort
of
represents.
B
Where
I
see
everything
going
so
I
want
to
take
a
minute
look
a
little
bit
into
the
future.
Look
at
a
map
of
where
we're
at
and
what's
been
happening
with
different
technologies
and
see
if
we
can
sort
of
say,
okay
given
all
of
this,
given
the
existing
landscape
of
build
versus
buying
what's
been
happening,
can
we
see
where
things
are
going
and
what
we're
looking
towards
next?
B
So
I
think
this
is.
I
just
read
this
article
recently,
and
I
think
this
is
a
great
example
of
the
evolution
of
organizations
and
service
offerings,
and
this
isn't
about
licensing
and
open
source
stuff,
which
is
an
entirely
different
kind
of
discussion.
I'm
happy
to
have,
but
not
the
point
I
want
to.
I
want
to
bring
in
about
this.
The
point
here
is
largely
about
how
mongodb
transformed
their
service
offering
to
to
move
down
market
right,
and
so
the
shift
is.
B
Do
we
want
to
offer
this
product
that
requires
handholding
and
installation
to
very
large
customers?
They
have
to
talk
to
our
sales
org
in
order
to
buy
it.
We've
got
all
this
large
process
to
implement
your
own
mongodb,
or
do
we
just
allow
people
to
consume
mongodb
on
our
cloud
service
right?
That's
the
shift
towards
individual
towards
the
ease
of
consumption
over.
You
know,
making
big
deals
and
packaging
it
all
up,
and
that
sort
of
thing
so
that's
been
a
shift
and
what
they
found.
B
This
article
gets
into
are
some
of
the
details
where,
even
though
mongo's
average
spend
per
customer
has
dropped
right,
so
each
customer
is
spending
less
money
on
average,
with
mongodb,
their
revenue
has
doubled.
In
that
time
so
what's
happening,
is
they
have
to
be
getting
this
extremely
long
tail
of
individual
consumers
and
everyone
wants
to
move
towards
this?
This
is
not
just
like
a
one-off
example.
B
This
is
how
we've
observed
markets
move,
so
this
is
kind
of
a
take
in
an
example
of
worldly
mapping,
which
is
again
a
another
whole
thing
that
we
can
get
into
and
is
not
the
scope
of
this
talk
so
I've
I've
got
some
resources
in
my
slide
deck
that's
published
online
or
I'm
sure,
maybe
another
part
of
the
discussion,
but
the
gist
we
want
to
get
at
here
is
largely
this.
This
red
line
is
largely
what
looks
like
the
x-axis
from
a
worldly
map.
B
It's
always
this
move
from
genesis
and
custom
build
all
the
way
through
commodity
and
I'm
waving
my
mouse
around,
although
I
have
no
idea
if
it
shared
on
the
screen,
so
I
may
be
like
me,
gesturing
at
nothing,
but
that's
all
right
I'll
hope
that
it's
useful
for
somebody.
Maybe
I
can
do
the
pointer
there.
We
go
genesis
over
here.
We
move
along
the
line
towards
commodity
and
utility.
B
This
line,
and
moving
forward
about
that
is
all
about
changing
the
ease
of
consumption.
Genesis
is
like
very
new
products
right.
This
is
when
you
want
to
design,
have
something.
That's
purpose
designed.
I
talked
about
this
when
you,
when
you
go
to
building
versus
buying
your
custom.
Build,
can
be
designed
for
a
very
specific
purpose
and
be
very
very
good
at
that,
but
it
takes
a
lot
of
time
to
actually
do
it.
We
probably
exist
somewhere
in
this
product.
B
Commodity
overlap
nexus
or
kubernetes
right
now
there
are
some
products
that
you
take
and
install
at
home,
and
there
are
some
that
are
being
hosted
and
the
cloud
kind
of
asks
a
lot
of
questions
about
whether
this
is
really
rental
or
something
you've
bought.
I
I
think
we
kind
of
lean
more
towards
this
area
right
now,
and
that's
obviously
designed
for
manufacture
right.
Our
goal
is
to
be
able
to.
How
can
I
get
this
out
of
the
door
consistently
and
get
widespread
distribution,
but
our
move
here
is
always
towards
consumption.
B
B
I
can
just
get
what
I'm
after
and
compute
has
moved
this
way
right,
we're
no
longer
rack
and
stacking
servers
for
like
proof
of
concept,
maybe
there's
reasons
to
run
stuff
on-prem
but
for
the
most
part,
we're
swiping
a
credit
card
asking
amazon
for
a
specific
type
of
compute
and
getting
it
delivered
over.
The
internet,
without
really
having
to
think
about
it
or
worry
about
it.
Everything
is
shifting
towards
utility
mongodb
is
showing
that
shift
services.
The
rise
of
sas
software
is
doing
that.
B
So
I
think
this
can
continue
to
go
things
like
the
xke
offerings
kind
of
live
in
this
commodity
utility
consumption,
but
they
exist
only
largely
for
the
control
plane
space.
How
you're
actually
implementing
your
worker
nodes,
how
you're
implementing
your
supply
pipelines
your
software
delivery?
How
do
you
want
to
implement
observability
in
your
stack?
How
do
you
want
to
do
all
this
stuff?
Where
do
you
want
to
run
it
all
these
questions
that
come
up
as
the
sort
of
okay?
B
Implementations
we're
starting
to
see
this
with,
like
the
open
shift
operators
right
things
that
exist
for
can
I
set
up
a
you
know:
supply
chain
of
software
with
a
given
pipeline
that
works
for
eighty
percent
of
my
use
cases
given
utilities
that
tie
in
for
eighty
percent
of
my
use
cases
so
for
most
applications
you
just
ask
for
a
ci
cd
and
and
get
it
out
the
door
rather
than
having
to
custom,
build
and
make
all
these
decisions
yourself.
So
I
think
that's
where
it's
going.
B
I
don't
think
I'm
the
only
person
that's
on
board
with
this.
You
know,
andrew
schaefer.
I
think
this
was
2019
so
last
year.
All
time
is
a
meaningless
flat
circle.
Now
serverless
is
the
target
of
every
devops
project.
He
said
this
at
you
know
his
devops
days
atlanta,
oh
my
my
where
it
was
got
cut
off
here:
okay,
it
was
devops
days
atlanta,
which
also
combined
map
camp,
so
worldly
mapping
and
serverless
days.
B
It
was
actually
a
really
apt
opportunity
to
talk
about
this,
but
this
is
absolutely
the
the
point
like
any
devops
product
have
been.
A
part
of
the
shift
has
always
been
towards
ease
of
consumption.
We're
gonna,
start
operationalizing.
Everything
make
sure
we
can
get
similar
results
consistently
over
time.
So
that's
a
lot
of
automation
and
all
the
stuff
we
talked
about
getting
rid
of,
toil
and
self-service
right.
All
that
self-service
is,
is
the
aim
serverless
being
the
ultimate
end
goal
of
hey
as
a
developer.
B
All
I
want
to
do
is
consume
run
my
code.
For
me,
I
want
to
be
able
to
give
instructions
to
a
system
and
have
it
do
those
instructions
I
think
low
code
no
code
is,
is
the
ultimate
example
of
that,
where
I
don't
even
have
to
learn
how
a
computer
talks,
I
just
say,
hey
here's
my
idea
for
doing
some
things
go.
Do
that
please
and
not
have
to
worry
about
all
the
underlying
implementation
details
so
yeah.
I
think
that's
the
direction.
It's
all
going
as
we're
going
to
continue
to
build
this.
B
We
have
to
think
about.
How
can
we
operationalize
our
platform
to
deliver
consistent
results
every
time
and
where
is
it
worth
spending
our
time
versus?
Where
is
it
worth?
Spending
our
money
again,
more
people
that
have
the
same
ideas.
This
is
from
a
few
years
ago,
from
kelsey
hightower
to
even
you
know,
kubernetes
enthusiast
at
google
who
said
kubernetes
a
platform
for
building
platforms.
B
It's
a
place
to
start
not
the
end
game
right
and
we're
going
to
start
seeing
continued
abstractions
and
those
platforms
being
operationalized
so
to
bring
it
around.
Maybe
the
reason
we
can't
find
just
plain,
vanilla,
kubernetes
practically
in
production,
is
that
it
isn't
an
ice
cream
right.
Kubernetes
is
a
part
of
a
sundae
right.
This
is
really
what
everyone
is
after.
We
want
all
of
these
components
stuck
together
and
just
plain
vanilla.
Ice
cream
doesn't
hit
us
a
whole
sunday.
B
So,
thank
you.
That's
the
rambling
rant
that
I
have
for
you
I'd
love
to
take.
You
know
additional
questions
and
chat
with
other
folks
to
see
where
these
ideas
are
interesting
and
people
want
to
learn
more.
Otherwise,
that's
kind
of
my
starting
off
point
and
the
speaking
link
at
the
top.
There
this
slide
deck
should
be
published
with
the
notes
attached
to
it,
so
folks
can
find
it.
A
Well,
thank
you
because
that
was
one
of
the
best
explanations
of
the
different
varieties
and
the
of
kubernetes
that
are
out
there.
I
still
now
I
want
the
sundae.
I
don't
just
want
chocolate
cuz.
I
want
the
sundae
and
it's
friday,
so
I'm
gonna
get
me
one
a
couple
of
interesting
things
popped
into
my
head
too,
and
if
you
pop
back
to
the
the
worldly
map,
yeah.
A
Just
one
of
the
things
like
and
especially
the
conversation
you
were
having
around
mongodb
as
a
service,
because
one
of
the
reasons
I
got
into
cloud
ages
ago,
like
eight
or
nine
years
ago,
was
heroku
right.
It
was
a
utility,
it
was
an
amazing
thing
and
then
it
everything.
So
it's
almost
I
kind
of
feel
like
we're
having
this
back
to
the
future,
realization
that
services
as
a
utility
and
the
ease
of
use
piece
is
really
one
of
the
key
things.
A
That's
gonna
one
make
money
for
people,
but
also
make
people
use
this
stuff
because
kubernetes
itself,
the
diy
vanilla
stuff,
is
you
install
it
and
then
then,
what
you
got
to
do
so
much
else
before
you
can
get
your
wordpress
app
running.
I
mean
wordpress
as
an
old
evangelist
was
like
the
go-to
thing
that
we
always
deployed
to
show
people
hey
it's
working.
You
know
back
in.
A
A
B
I
think
we're
able
to
start
taking
those
and
building
them
in
new
ways
build
new
abstractions
that
become
new
and
novel,
and
then
it
starts
all
over
again
right.
Well
now,
this
abstraction
is
custom
built.
We
have
to
implement
it
a
certain
way
and
as
we
start
to
operationalize
that
and
get
good
on
it,
we
start
to
distribute
it,
and
then
we
look
at
how
can
we
operationalize
it?
What
are
the
best
practices
to
do
it
right
and
get
it
working
time
and
time
again?
B
B
C
B
D
D
You
know
consumption
of
things
like
kubernetes
they're,
not
they're.
No
longer,
you
know
like
you
when
you
and
I
talked
earlier
right,
like
it
used
to
be
perfectly
like
the
people
who
were
early
adopters,
wanted
to
be
able
to
run
their
own
kubernetes,
and
you
know
late
adopters,
don't
want
that
they
want.
They
want
it
to
be
handled
for
them
so
like,
but
what
is
the?
What
is
the
open
source
community
going
to
do
about
this?
D
B
You
know,
I
think,
that's
actually
that's
a
really
good
point.
I
think
that
that
answer
gets
right
to
it
right,
it's
all
about
who
are
your
customers
and,
as
you
know,
an
open
source
community
that
can
be
a
lot
of
different
answers
right.
Some
of
our
customers
might
be
those
platforms
that
are
doing
those
implementation,
and
so
it
might
be.
You
know
some
of
that
type
of
stuff
that
people
who
are
doing
the
building
want
and
care
about,
but
as
well
right.
B
D
D
I
think
one
of
the
like
the
things
to
think
about.
As
far
as
like.
What's
different
this
time,
you
know
I
I
like.
I
think
that
platform
is
a
service
that
whole
pass
idea
and
especially
like
self-service
access
to
things
is,
is
like
from
a
from
a
different
time
than
we're
currently
in
it's
from
an
itil
based
kind
of
process,
driven
version
of
platforming,
whereas
now,
like
kubernetes,
isn't
always
being
used
like
that
anymore.
D
Kubernetes
is
like
a
platform
where
people
kind
of
can
co-create
things
together
that
that
it's
not
simply
like
give
me
access
to
a
machine.
You
know
containers
aren't
like
virtual
machines
in
many
ways,
and
so
there's
this
weird
way
of
thinking.
I
think
that
we
could
argue
that
the
commoditized
version
of
kubernetes
will
be
more
would
be,
would
be
an
evolution
over
a
pass
if
it
can
continue
to
co-create
value
as
a
platform,
as
opposed
to
just
be
self-service.
D
If
it
degrades
itself
into
simply
a
self-service
platform,
it
will
be
it'll
just
be
you
know,
another
version
of
those
print
access
to
primitives.
If,
on
the
other
hand,
it
keeps
on
evolving
and
shaping
itself
as
a
way
in
which
the
community
can
co-create
value
with
end
users-
and
you
know,
make
a
platform
where
there's
real,
effective,
shared
services,
it
will
be
a
different
kind
of
commodity.
I
guess
is
what
I
would
say.
I
don't
know
if
that
makes
any
sense,
but
that's
what
I
think
about
it.
B
No,
I
think
I
think
you've
got
some
there
and
I
think
that's
where
a
lot
of
the
value
of
something
like
open
shift,
having
its
roots
and
and
upstream
all
in
open
source
gives
it
a
lot
of
advantage
in
that
right.
There's
the
ability
and
any
approach
of
how
it's
shifting
more
towards
like
we
want
to
implement
new
stuff
we're
going
to
build
an
operator
for
that,
so
that
you
get
some
way
of
doing
that.
It's
providing
both.
You
can
do
this
totally
custom.
B
If
you
want
to-
and
you
can
implement
this
and
you
can
work
with
the
community
to
do
something
that
works
for
your
specific
purpose
and
do
something
that's
more
purpose-built
or
if
all
you
need
is
some
generic.
I
keep
using
pipelines
because
that's
the
other
thing
I've
been
working
on
lately,
so
they're,
just
like
floating
around
my
head.
You
just
need
some
generic
ci
cd
pipeline.
Here's,
our
implementation
of
it
right
use
the
operator.
D
That
that
to
me,
like
captures
a
lot
of
it,
because
this
like
without
starting
a
religious,
open
source
war
in
the
middle
of
this,
you
know
open
source,
isn't
just
the
licenses
and
it
isn't
just
access
to
free
stuff.
That's
not
what
the
open
source
processes
and
methodologies
that
have
been
developed
for
a
long
time.
D
Red
hat's
contributed
to
a
lot
of
this,
aren't
just
about
creating
free
stuff
they're
about
how
do
we
negotiate
the
best
common
set
of
features
and
functions
to
put
into
the
thing
that
we're
all
working
on
together
and
that
that
is
co-creation?
That's
what
co-creation
looks
like
to
the
extent
that
we
can
kind
of
keep
that
community
alive.
We
will
keep
alive
the
ability
to
kind
of
do
that
type
of
work
and
then
questions
about
how
do
you
operationalize
this
thing
become
a
separate
set
of
questions
right,
there's
up
there.
B
B
Getting
the
idea
like
a
lot
of
development,
is
the
process
of
like
codifying
the
knowledge
and
building
on
it
right
we're
going
to
do
a
lot
of
discovery
of
how
do
I
do
a
thing
and
then
I'm
going
to
capture
that
knowledge
of
how
I
do
with
things
that
I
can
just
do
that
repeatedly
over
and
over
yep
and
ops
tend
to
live
in
this.
What
is
the
best
way?
I
can
do
this
thing
and
I'm
gonna
do
a
lot
of
research
about
like
what
is
the
best
way.
I
can
do
this.
B
B
Maybe
it
was
a
script
that
was
poorly
maintained
on
one
sysadmins
laptop
right
like
this
was
how
knowledge
was
codified
until
we
had
this
great
merger
of
like
hey
what
if
we
learn
the
lessons
from
our
friends
across
the
street
and
start
to
like
codify
the
knowledge
that
we've
got
and
like
this
is
what
kind
of
builds
that
right.
So
it's
we
build
something
and
figure
it
out.
Then
we
operationalize
it.
Then
we
codify
that,
and
now
we
can
start
doing
it
again
right.
B
C
C
I
wrote
a
book
on
azure
functions,
you
know
and
for
it
for
a
little
time,
I
thought
that
you
know
serverless
was
going
to
be
a
big
thing,
that's
going
to
solve
a
lot
of
problems,
and-
and
I
don't
know
that
I
necessarily
think
that
anymore
and
I
feel
like
there's
there's
this
whole
like
the
idea
is
always
automating
everything
right
like
we
always
want
to
sort
of
remove
the
human.
I
know
j
bull
like
this,
remove
the
human
from
the
system
so
that
the
system
can
be.
C
Right
so
hold
on
what
I'm
saying
is
like
the
automating
everything
right.
Like
part
of
the
the
big
utopian
statement,
it's
like
we're
gonna,
get
to
the
point
where
everything
is
like
platform
as
a
service
or
like
managed
services
which
is
potentially
even
better
than
platform
as
a
service,
and
I
just
see
this
cycling
in
the
last
10
years
where
we
like,
we
get
a
little
bit
closer
and
then
we
kind
of
take
a
step
back
and
we
discover
that,
like
it
doesn't
answer
all
the
questions.
C
So
then
we
come
up
with
a
new
solution.
Right
kubernetes
is
a
new
solution
to
the
same
problem
that
we've
solved
already
before
that
and
and
we're
now
now
getting
to
commoditizing.
But
I,
like
part
of
me,
is
like
you
know:
are
we
answering
all
the
questions?
I
don't
think
we
are
so
you
know
who
knows
what's
going
to
come
around
the
the
block
and
try
to
solve
exactly
the
same
problem
again
with
a
different
in
a
different
shape
or
form
right?
C
A
So
we
know
it's
wonderful.
That
openshift
is
has
an
open
source
distribution
of
it,
okd,
which
you
know
I
will
flagrantly
promote
whenever
I
can.
But
I
think
the
bigger
thing
for
me
is
that
has
changed.
Games
is
the
involvement
of
end
users
and
not
just
us
going
out
and
asking
for
end
user
requirements
and
feedback
on
our
projects.
A
But
this
huge
co-collaboration
with
end
users,
like
some
of
our
customers,
amadeus
and
anthem,
and
other
folks
like
that
that
are
really
contributing
back
and
contributing
chunks
of
code,
sometimes
right
into
the
open
source.
So
that
has
so.
It
gives
me
hope
that
we're
just
not
going
to
iterate
on
the
next
technology
and
do
this
again
and
again
and
again,
though
I
kind
of
think
we
probably
will
do
that
too,
because
that's
our
nature.
A
But
it
gives
me
hope
that
whatever
the
next
thing
is
after
kubernetes
that
it
that
that
will
be
something
that
we
co-collaborate
more
closely
with
end
users
and
that
they
become
some
of
the
primary
drivers
of
these
open
source
projects,
as
opposed
to
vendor
base,
which
then
again
changes
the
relationship
of
vendors
to
end
users.
Because
we
always
you
know
like
to
think
of
ourselves
as
the
trusted
partners
who
you
come
running
to
when
you
need
a
patch
or
a
feature
or
a
function.
And
instead,
what
we're
getting.
A
Is
these
huge
code
donations
of
things
I'm
going
to
hit
on
envoy
for
my
example
here?
But
that
comes
back
in
that
we
then
incorporate
into
our
products.
So
this
symbiotic
relationship
with
end
users
and
vendors,
who
are
productizing
and
making
services
and
managing
services
is
new.
I
think
it's,
I
think,
early
days
of
open
source,
there
were
a
lot
of
individuals,
education.edus
and
academics
contributing
to
open
source.
But
you
know,
then
we
saw
this
sort
of
phase
of
the
corporatization
of
open
source.
A
I
think
to
me-
and
I
my
hope
is-
that
we're
in
a
new
phase
of
open
source
development
and
co-collaboration
and
co-creation
of
these
projects
like
kubernetes
and
driving,
where
it's
going
so
that
we
get
this
evolution
and
ease
of
consumption
because
we're
actually
not
just
listening
and
asking
for
feedback.
It's
not
feedback
anymore.
It's
the
feed.
You
know
the
it's,
it's
actually
in
the
trough.
Now
what
we're
eating
and
we're
all
eating
the
same
dog
food,
and
hopefully
it
tastes
better,
but
that's
my
opinion,
humble
as
it
may
not
be.
C
C
Are
you
absolutely
sure
that
this
is
the
thing
because,
like
I've,
I've
had
I've
seen
in
my
career,
I've
seen
technologies
come
and
go
and
be
completely
retired
and
irrelevant,
and
they
say
again.
Docker
is
a
prime
example
for
this
like
right,
it
was
all
the
rage,
and
now
it's
gradually
kind
of
being
at
least
the
runtime
is
gradually
being
phased
out,
and
so
you
know.
D
Yeah,
I
think,
but
you
know
like
the
bill
versus
my
question,
is,
is
interesting
because,
like
for
instance
envoy
and
other
things
that
we've
mentioned
here
are
built
on
top
of
other
technologies.
So
the
question
is:
is
your?
Is
your
firm
building
something
of
value
both
to
your
firm
and
to
the
wider
ecosystem?
And
can
you
identify
what
those
are
and
release
them
to
enable
you
know
better
competition
in
industry
as
opposed
to
kind
of
the
old
version
of
kind
of
chinese
walls?
D
And
things
like
this
that
that
create
false
scarcity?
And
things
like
that,
so
I
think
you
know,
I
think
open
source
is
becoming
understood
more
and
more
as
an
actual
strategic
way
of
interacting
with
a
market,
as
opposed
to
like
a
source
of
free,
labor
or
free
code,
or
something
like
that
and
that
that
becomes
interesting.
And
you
know,
then
you
can
make
arguments
that
say
things
like
okay.
D
So,
if
you're
interested
in
doing
something
where
you're
contributing
you're
either
creating
something
unique
for
your
your
own
organization
or
you're,
contributing
something
unique
to
the
ecosystem,
then
maybe
it
actually
makes
a
lot
of
sense
to
ask
someone
else
to
deal
with
the
operating
parts
of
your
system
that
don't
have
anything
to
do
with
creating
that
new
value
that
are
just
the
baseline
kind
of
everything
below
here
is
just
standard
stuff
that
needs
to
get
operated.
Be
nice
for
me
not
to
have
to
spend
a
lot
of
time.
D
And
it's
you
know
again
again,
you
know
from
for
me
from
my
perspective,
from
kind
of
a
worldly
ish
perspective,
that's
not
an
ethical
or
a
moral
statement
right.
That
is
a
business
statement
and
it
just
says
actually,
if
you,
if,
if
the
product
is
capable
of
operating
at
a
commodity
scale,
also
the
other
thing
that
it
needs
is
that
scale
so,
for
instance
like
if
you
have
a
company
that
only
has
like
5
000
servers
in
it.
D
It's
you
don't
get
the
same
advantages
that,
for
instance,
amazon
gets
for
being
able
to
operate
10
000
servers
per
operator
because
you
don't
have
10
000
servers
right,
so
you
have
to
have
a
certain
level
of
scale
to
even
take
economic
advantage
of
commodity
products
that,
like
as
the
seller
right.
So
I
think
it's
important
yeah
go
ahead.
Aaron,
sorry,
okay,.
B
B
B
There
are
asterisks
and
exceptions
to
everything,
but
you
know
once
you
get
to
a
certain
point,
almost
always
that
that
makes
sense,
because
it's
you
know
not
just
buying
you're,
buying
that
method,
you're
buying
all
the
research
you're
buying
all
their
maintenance,
and
all
that
goes
into
the
price
of
software
that
we
buy
and
I
think
the
the
open
source
lends
itself
towards.
This
was
something
else
I
was
thinking
about.
B
The
what
I
really
like
about
the
open
source
method
is
the
way
it
lets
us
explore
a
lot
of
different
options,
right,
there's
sort
of
that
back
and
forth,
and
that
we're
doing
the
name
we're
doing
the
same
thing
over
again.
It's
because
we
can
explore
10
different
things
at
once
from
an
see
which
one
might
be
better
say.
Oh,
it
looks
like
you
know.
Kubernetes
is
the
way
to
go.
We
might
find
out.
Oh
there's
this
limitation,
that
it
has
that
won't.
B
Let
us
whatever
I
don't
know
what
the
weird
next
abstraction
is
that
we're
not
gonna
be
able
to
do
right,
whatever
that
is,
and
then
maybe
we
have
to
go
back
to
the
drawing
board
and
figure
out.
How
do
we
do
this
again?
That
allows
us
to
break
through
that
that
very
right,
like
where
natural
evolution
requires
an
advantage
all
the
time
like
always
moving
up,
so
you
can
get
stuck
on
plateaus
when
we're
talking
about
software
and
like
designed
evolution
like
we
can
step
backwards
in
order
to
make
a
further
gain.
D
The
other
thing
I
say
really
quickly
is
that
one
of
the
other
things
that
I
think
tends
towards
this
commodity
scale
based
problem
becoming
more
prevalent
in
organizations,
is
because
organizations
are
reaching
a
threshold
of
complexity
that
makes
it
necessary
right.
So
I
think
you
go
to
a
modern
bank
these
days,
if
you,
if
you
roll
scroll
back
in
time
to
where,
where
where
google
starts,
with
with
borg
right,
you
get
the
complexity
of
google
at
that
point
and
you
look
at
the
complexity
of
an
average
bank.
D
That
made
google
need
to
have
something
like
borg
to
operate
anymore,
right
right,
and
so
that's
what
you're
seeing
is
it's
not
like.
You
know
it's
not
that
the
demand
for
things
like
this
is
artificial
or
if
this
isn't
just
resume
driven
development
type
stuff
anymore.
Some
of
these
problems
are
problems
that
are
newly
introduced
into
organizations,
because
they've
arrived
at
a
certain
level
complexity,
and
the
question
is
whether
or
not
they
can
either
internally
adapt
fast
enough
or
if
they
need
to
ask
for
help
operating
something
that
is
incredibly
complex
in
a
way
yeah.
A
You
may
not
want
to
build
it
yourself.
You
know
we
just
did
an
okd
workshop
all
weekend
last
saturday
where
everybody
walked
through
building,
ok,
d4
and
it
wasn't
fun,
you
know,
but
people
did
it
with
their
home
labs
in
five
different
flavors.
You
know
so
you
know
these
things,
you
know,
but
everybody
was
learning
together
right.
So
I
think
one
in
the
build
versus
by
consideration.
A
Sometimes
the
conversation
about
the
importance
of
open
source,
or
at
least
open
code
and
access
to
that
to
learn
from
it,
I
think,
needs
to
be
emphasized
a
little
bit
heavier
because
you
can
you
can
log
into
eks
or
wherever,
but
you
may
never
get
to
see
the
tweaks
and
things
that
they
did
and
you
don't
learn
from
it.
It's
not
that
I
want
to
force
amazon
to
open
source
everything
they
do
under
fargate,
and
you
know
whatever
it
is
right.
A
It's
just
that
that
if
we
want
to
create
the
co-collaboration
out
there
in
the
universe,
that's
going
to
drive
all
of
this
innovation
forward,
we
need
access
to
that
source
code,
which
is,
I
think,
one
of
the
the
key
value
points
of
open
source,
so
anyways
that
that's
my
podium
and
I'm
getting
on
it.
I
I'm
looking
at
the
time
here.
I
would
like
to
give
aaron
the
last
word.
So
where
do
you
think
we're
going
from
here?
A
B
Great,
this
is
gonna,
be
awesome.
This
is
where
I
explain
it
and
then
sasha
says
no.
You
got
it
wrong
after
I
get
off,
so
this
is
for
for
red
hat.
Our
managed
openshift
black
belt
folks
are
part
of
the
sort
of
extremely
technical
group
of
folks
that
help
with
implementation
inside
of
the
sales
org
right.
So,
on
the
one
hand
you
might
have
like
developer
advocates
that
reach
out
directly
to
broad
community.
B
We
get
to
do
some
of
that
inside
of
specific,
like
really
big
customers,
where
they
have
developers
the
size
of
the
entire
rest
of
the
community
right
like
they
might
have
2
000
developers
that
are
available
I'll,
try
to
figure
this
stuff
out,
so
we
get
a
little
bit
more
target
and
help
do
enablement
for
like
those
groups.
So
I
might
go
into
a
large
customer,
deliver
a
talk
like
this
or
talk
about
kubernetes
in
the
future
of
where
it's
going
or
help
them
with
some
of
the
technical
implementation
details
of
like
hey.
B
How
do
we
get
this
working
on?
Openshift
we've
been
trying
to
do
this
and
it's
not
working.
Can
you
point
me
in
the
right
direction,
so
very
much
sort
of
a
targeted,
very
similar
developer
advocate
type
roles,
but
a
little
bit
more
targeted
at
some
of
those
big
customers
that
sometimes
don't
get
out
of
their
own
way
and
end
up
creating
their
own,
very
big
gravity
of
culture
that
draws
all
their
own
developers
internal.
So
we
kind
of
get
to
jump
in
there
and
help
change
that
landscape.
A
B
A
And-
and
I
think
you
make
the
point
by
by
going
deep,
diving
in
with
some
of
these
end
users
and
customers
and
having
the
the
source
code
to
show
them
how
these
things
work.
This
is
where
this
co-collaboration
comes
out
and
and
it,
and
that
I
think
we're
seeing
more
and
more
of
this
more
of
it
in
the
open.
More
of
it
in
you
know,
gigs
that
you
guys
do
one-on-one
with
companies,
but
more
of
this
is
happening
out
in
the
open,
and
I
think
that's
the
evolution.
A
That's
happening
right
now
in
open
source,
and
you
know-
obviously,
it's
being
you
know,
fed
by
end
users
by
the
foundations
by
the
vendors
by
the
partners
and
the
cloud
hosting
providers.
So
it's
really
this
amazing
ecosystem
and
keeping
it
open
and
transparent
and
accessible
is
key
for
everybody's
success,
so
kudos
to
you
aaron,
because
that
was
one
of
the
best
presentations
on
this
topic.
A
A
The
very
so
yeah
because
I
would
love
to
see
the
reaction
to
like
a
whole
kubecon
audience
to
vanilla,
because
those
those
are
the
ones
that
I
think
a
lot
of
the
folks
in
the
room.
There
have
a
mythical
belief
that
vanilla
kubernetes
is
what
they
want
versus
the
reality
of
what,
when
they
go
back
home
to
their
organizations,
what
they're
able
to
do
so,
yeah
and
and
and
again
kudos
to
cystic
and
everybody
else.
Who
does
it
that
this
is
not
saying
you
shouldn't?
Do
it?
A
It's
just
saying
you
better
be
prepared
when
you
do
do
it
so
absolutely
yeah!
So
hopefully
we'll
get
you
all
back
on
again
soon
and
keep
talking
through
some
of
these
topics
and
jabe
and
sasha.
Thank
you
for
joining
us
today
and
chris
short
kudos
to
you
for
making
this
happen
and
broadcasting
out
to
the
universe
and
I'll
post
the
video.
And
if
you
go
back
to
your
resources,
link,
throw
that
to
the
last
page
and
we
will
share
the
slides
and
any
other
resources
too.