►
From YouTube: Kubernetes and the platform of the future
Description
In this fireside chat, Steve Watt of Red Hat interviews Clayton Coleman (Chief Engineer for OpenShift) and Brandon Philips (previously CTO of CoreOS, acquired by Red Hat) on their long term view on platforms and where we’ll be taking Kubernetes and OpenShift in the future. Clayton and Brandon have led development for most of the major technologies that power the Linux Container ecosystem today (Kubernetes, Open Container Initiative, etcd and more). Hear questions from our Summit attendees and learn about the past, the present and the future.
Learn more: https://agenda.summit.redhat.com/
A
The
chief
engineer
for
OpenShift.
Many
of
you
folks
know
if
you
are
around
the
kubernetes
community,
that
these
are
two
of
them
most
significant
contributors
in
the
kubernetes
ecosystem,
and
so,
but
just
before
we
jump
in
I
just
want
to
sort
of
give
us
an
opportunity
to
calibrate
with
you.
So
you
get
the
most
out
of
the
session,
so
I
just
had
a
question.
A
How
many
folks
in
this
room
would
sort
of
categorize
themselves
as
sis
admins,
okay
and
how
about
software
engineers,
okay,
and
how
about
Enterprise,
architects
and
other
okay
and
then
one
last
one?
How
many
of
you
would
say
you
have
an
advanced
familiarity
or
an
advanced
capability
with
kubernetes,
okay,
intermediate
basic
okay,
all
right,
that's
good!
All
right!
So,
let's
start
off
with
Brandon.
Can
you
tell
us
a
little
bit
about
yourself
and
your
journey
with
kubernetes
and
its
ecosystem?
Sure
and
then
we'll
go
on
to
Clayton
sure.
B
So
I'm
Brandon,
Phillips
I
was
CTO
and
co-founder
of
core
OS,
which
was
recently
acquired
by
Red
Hat,
and
the
journey
that
I
had
with
kubernetes
really
begins
with
where
we
started
with
core
OS
and
our
thought
process
there.
So
I
had
started
my
career
at
SUSE,
Linux
and
as
soon
as
that,
we
we
thought
that
we
were
building
a
product.
B
But
there
is
packaging
up
the
software
or
what
happens
when
you
roll
out
a
version
of
the
software
in
the
roll
back,
integrating
CI
CD
into
the
whole
thing,
and
so
it
kind
of
inspired
me
and
my
co-founder
Alex
to
try
to
figure
out.
How
do
we
fix
some
of
those
problems?
And
so
containerization
was
really
what
we
saw
as
the
thing
that
would
help
fix
some
of
these
issues
around
how
you
roll
out
and
deploy
software,
so
that
we
wanted
to
shorten
that
time
from.
B
We
have
an
idea
of
how
we
want
the
infrastructure
to
go,
and
then
you
spent
like
three
months:
writing
like
a
bunch
of
scripts
to
like
do
Jenkins
and
put
it
up
into
a
s3
bucket
and
download
it
and
so
shorten
that
time
to
as
short
as
possible,
and
so
containerization
and
kubernetes
kind
of
fell
out
of
that
that
five
year
journey
from
starting
core
OS
to
docker,
existing
to
Google,
open
source
and
kubernetes
and
kind
of
been
involved
in
the
ecosystem.
Ever
since,
okay,.
C
We
wanted
the
technology
to
help
people
the
same
way,
and
so,
as
always,
Brandon
was
always
one
of
the
easy
people
to
feel
like
I
know,
Brandon
will
agree
with
almost
anything
I'm
saying,
and
so
now
that
Brandon
has
joined,
Red,
Hat,
I'm,
arguing
with
him
all
the
time
so
I
started
at
IBM
worked
on
websphere
and
social
software
at
IBM.
For
ten
years,
I
built
large
enterprise
applications.
I
ran
those
for
you
know.
C
Tens
of
thousands
of
users
of
some
of
the
largest
companies
in
the
world
and
I
left
IBM
and
I
went
to
Red
Hat
to
work
on
open
shift,
and
that
was
the
pre
openshift
one
O's.
You
know
we
want
to
make
it
easier
to
build
and
deploy
software
and
to
me
this
was
my
getting
exposed
to
open
source
and
the
ability
to
just
take
things
and
put
them
together
and
we
were
doing
a
ton
of
you
know
web.
You
know
direct
web
facing
running
services.
C
You
know
a
few
years
after
Heroku
launched,
so
it
was
pretty
early
in
the
paths.
The
paths
for
everybody
space
and
over
that
journey
I
was
always
a
little.
You
know:
I
enjoyed
openshift
100
and
OpenShift.
Oh,
but
I
was
always
looking
for
something
more
and
so,
as
when
docker
came
out,
it
was
very
clear
that
there
was
something
it
so
kind
of
a
gross
abstraction
right.
C
C
We
had
a
conversation
with
Google,
pretty
early
on
where
we
had
this
discussion
about.
Well,
you
know
we're
working
on
this
thing
that
we're
not
sure
we're
gonna,
you
know
go
out
with,
but
you
know
here's
what
we're
gonna
do.
That's
really
interesting,
but
then
you
know
they
didn't
call
us
back
like
it
was
kind
of
a
awkward
router
state
and
about
four
or
five
months
later
we
were
starting
to
kind
of
get
to
that
point.
We
were
like
okay,
we're
ready
to
go
to
meso
s--.
C
You
know,
just
as
like
it's
the
best
of
the
options
we
have
talked
to
some
people.
I
can
Google
called
us
up
and
said:
hey
we're
gonna
open-source
this
next
week.
Do
you
guys
want
in
and
we
were
like?
Well,
you
know
what
could
possibly
go
wrong
so
when
they
open
sourced
it,
I
got
commit
access,
I
think
the
first
day
that
they
open
source
kubernetes-
and
you
know
it
was
a
great
experience
for
me
personally,
working
with
some
of
the
really
talented
people
on
the
project.
Brendan
who's
was
talking.
C
That
was
a
really
unique
opportunity
for
me
personally
and
I've
really
enjoyed
being
a
part
of
this,
because
you
know
I
feel
like
we
can
take
some
of
the
lessons
that
we
learned
and
say
you
know,
is
there
at
the
right
time
enough
people
got
onto
this
idea?
Was
a
new
technology,
a
new
way
of
thinking,
and
we
could
do
things
right
this
time,
so
I've
really
enjoyed
that
part
of
this
journey.
Yeah.
C
B
So
when
we
we
went
through
Y
Combinator,
which
is
a
startup
accelerator
and
our
pitch
during
demo
day
five
years
ago,
a
little
over
five
years
ago
on
stage
was
Google's
infrastructure
for
everyone
and
of
course
we
made
it
a
hashtag,
hashtag,
iffy
and
so
jiffy
and
so
yeah
for
five
years,
even
before
kubernetes
had
come
out.
That
was
what
our
mission
was
was
to
try
to
bring
this
Google
I
can
just
rush
everyone
and
speaking
of
kubernetes
being
introduced.
We
got
lucky
in
some
ways
too,
because
Google
when
they,
when
they
built
kubernetes.
C
C
Made
it
it
was
decision,
you
know
it's
funny,
so
I'll
take
a
slight
digression.
It's
interesting,
so
I
spent
a
lot
of
time
in
that
period,
where
I
was
looking
at
new
technologies
and
I
was
like
what
is
it
that
makes
something
about
this
compelling
like.
What's
the
idea
out
of
this,
that
makes
easy
and
at
cities
just
a
key-value
store,
that's
it,
but
it
is
a
reasonably
fast,
simple,
extremely
efficient
at
what
it
does
key
value
store.
C
You
know
Cassandra
at
scale
and
used
Postgres
master-slave
replication
I've
talked
with
the
people
on
the
Red
Hat
high-availability
side,
and
it's
not
that
any
of
those
things
don't
work,
it's
that
they
have
evolved
and
they've
built
up
complexity,
because
there
are
abstractions
that
were
really
missing
or
tools
that
we
just
didn't
have
common
language
to
talk
about
some
of
these
problems
before
I
think
sed
was
actually
one
of
those
really
compelling.
It
was
the
seed
of
an
idea
that,
even
though
it's
not
perfect,
you
know,
there's
still
challenges
with
it.
C
It's
simple
enough
that
it
moves
the
discussion
of
X
phase
like
kubernetes
and
I.
Think
that
was,
you
know
that
was
one
of
the
best
choices.
I
think
they
made
in
the
early
days
of
kubernetes
was
let's
just
pick
something
that
will
be
AJ,
always
simply
yeah
simple
it
just
you
know
when
we
people
always
ask
us,
should
I
run
three
at
CVS
or
five
at
CVS
or
7.x
is
really
no
just
run
three
just
run,
you'll
be
fine
and
more
or
less.
It's
just
been
that
way.
Well,.
A
Speaking
of
you
know,
sort
of
running
it
CD
simply
write
that
one
of
the
next
sort
of
evolutions
we
took
in
kubernetes
as
towards
this
operator
framework,
and
one
of
the
first
implementations
of
that
was
a
CD.
He
tell
us
a
little
bit
about
what
how
you
arrived
at.
That
idea
that
this
operator
approaches
you
know
Bible
and
approach.
We
should
follow
incriminating.
Yes,.
B
So,
if
you're
not
familiar,
operators
are
these
this
concept
that
core
was
introduced
about
two
years
ago,
where
what
we
want
to
do
is
imagine
a
public
cloud,
but
public
clouds,
don't
let
you
introduce
new
services.
So
what's
interesting
about
cloud
is
that
you
can
make
an
API
call
and
then
they
give
you
a
new
copy
of
the
service,
so
I'm,
making
an
API
call
get
a
new
Postgres
database
I
make
an
API
call
I
get
a
second
Postgres
database.
B
So
kubernetes
had
this
custom
resource
thing
that
one
of
the
engineers
from
Google
Brendan
Burns,
had
introduced
really
early
on,
but
nobody
had
really
gotten
a
practical
application
built
against
it,
and
so
what
we
started
thinking
about
we're
like
well,
how
do
we
make
kubernetes
more
like
a
public
cloud?
We
we
wanted
to
start
to
introduce
higher
level
services.
Kubernetes
is
great
about
abstracting
compute
network
with
storage,
the
pods
get
an
IP
address
the
pods.
Let
you
run
a
process.
B
B
The
the
story
that
I
like
to
tell
the
most
is
Ticketmaster
is
a
tectonic
customer,
and
so
they
wanted
to
enable
all
their
teams
to
deploy
application
monitoring.
So
infrastructure
monitoring
is
like
what
a
lot
of
sis
admins
care
about
can
like
again,
compute
network
and
storage
is
the
CPU
spiking.
Am
I
saturating
the
link
between
the
servers?
B
Full
monitoring
stack
that
I
can
just
plug
into
and
configure
using
kubernetes
api
calls,
and
so
this
is
pretty
cool.
You
go
out
with
hypothesis,
and
then
you
actually
see
the
hypothesis
work
and
really
it's
just
like
anytime.
You
make
something
in
API
call
away
usage,
always
spikes,
but
the
trick
is
to
make
that
API
call
typed
money.
But
that's.
C
Like
that
that
idea,
kubernetes
has
the
idea
of
controllers
and
the
controller
patterns
yeah
a
lot
of
what
I
worked
on
Web
Apps.
You
know
someone
would
do
something
on
a
web
page
and
we
update
a
transaction
in
the
database
and
that'd
be
done.
But
when
you
have
multiple
participating
things
in
a
system,
you've
got
to
go
and
you
know
make
the
change
in
the
database.
C
Then
you
might
have
to
go
talk
to
an
external
system
and
then
keep
it
up
to
date
and
then
I
might
get
rolled
back
and
you
deal
with
all
this
complexity.
One
of
the
interesting
ideas
in
kubernetes.
That
was
a
kind
of
learned
thing
from
Google
internally
that
wasn't,
they
hadn't
quite
pushed
it
all
the
way.
But
it
was
part
of
the
paper
that
they
put
about
kubernetes,
and
it
was
something
we
talked
about.
A
lot
in
the
very
early
days
was
the
benefit
of
a
controllers.
C
Anything
you
do
all
the
time
fails
right
away
when
it
doesn't
work,
which
is
a
really
simple
idea,
but
it
takes
a
while
to
get
over
that
which
is
well.
If
I-
and
you
know,
system
ends
in
the
room
would
know
this
one.
If
you've
never
restored
your
backup,
you
don't
have
a
backup
system.
You
have
a
very
expensive
tape.
Drive
array
right
is
that
if
you
haven't
tried
to
restore
something,
refer
is
not
gonna
work,
you
don't
know
you
don't
know
this
gonna
work
and
the
same
thing
applies
for
controllers.
C
If
you
have
something
that
goes
and
mints
out,
50
pods.
Well,
there's
a
bug
in
it.
You
find
that
out
pretty
quick
because
it
doesn't
mint
50
pause
and
it's
50,000,
pods
and
so
going
through
that
model
of
anything
that
you
do
all
the
time
that
you
keep
doing
over
and
over
I.
Think
operators
really
benefit
from
that,
because
that's
actually
the
big
insight
is
you
put
an
API
on
it
and
you
tie
that
to
something
that's
just
checking
it's
stupid.
It
can
start
stupid
and
be
inefficient
and
do
that
checking
all
the
time.
C
But
you
know
what
computers
are
pretty
cheap
right
now,
and
human
time
is
really
expensive
right.
Everyone
in
this
room
who's
a
developer
or
assisted
men.
If
we
had
more
automation
to
help
us,
we
could
do
more
things
and
I
think
that's
the
you
know
make
the
machines.
Do
the
stupid,
repetitive
stuff.
We
said
it
humans
and
that
ties
into
you
know
a
lot
of
learnings
with
operators
and
kubernetes
and
the
things
that
Google
talks
about
like
Google
for
everyone.
A
C
Let's
see
what
trends
so
interesting
thing
that
I
think
the
cloud
has
made
more
prevalent
is
the
idea
that,
if
things
are
all
services,
you
have
these
different
types
of
services
that
you
know
are
different
levels
of
abstraction.
One
thing
that
I've
kind
of
struggled
with
when
looking
at
cloud
provider
API
is
that,
if
you're
a
producing
a
service
for
an
audience,
whether
it's
a
big
audience
or
a
fairly
tight-knit
audience
like
Big
Data
or
some
use
case,
you're
gonna
focus
on.
You
know,
80%
of
the
use
cases
and
you're
trying
to
get
those
well.
C
Actually
helps
you
know,
you
pick
a
pattern
that
a
lot
of
people
use.
There's
many
people
can
find
that
common
point
of
you
know
documentation
and
working
through
the
use
case.
So
if
you're
running
elasticsearch
all
the
time
and
someone
hasn't
managed
elasticsearch
service,
you
get
familiar
with
it,
but
a
flipside
of
that
is
that
maybe
and
Paul
alluded
to
the
Cygnus
keynote.
C
But
maybe
25
years
ago,
one
company
would
be
like
the
beacon
of
all
of
the
innovation,
even
though
we're
kind
of
talking
about
Google
like
that,
it's
not
even
close
to
the
truth,
as
Google
participate
in
these
open
system
use.
But
the
idea
that
there's
this
huge
community
of
people
doing
all
of
these
entry
things
and
surprisingly-
and
the
microsoft
word
guys
I-
think
have
a
quote
which
is
you
know,
80%
of
the
80%
of
the
features
or
80%
of
users
use
20%
of
the
features,
but
it's
not
the
same
20%
and
I.
C
Think
that
applies
in
cloud.
I
think
it
applies.
Any
of
these
services
is
at
the
end
of
the
day.
We
want
to
have
be
it,
make
it
easier
and
easier
and
easier
and
easier
to
run
services.
The
operator
pattern
and
the
operator
approach
we
kind
of
it's
trying
to
dovetail
into
that
is.
It
has
to
be
easy
to
run
services
because
if
my
use
case
isn't
solved
by
you
and
can
can't
run
it
at
the
scale,
I
need
it
to
or
even
run
it
at
no
scale
at
all.
C
It's
not
very
useful,
so
I
end
up
picking
something
that
doesn't
quite
fit
my
use
case
and
that
causes
trickle
on
problems
down
the
road.
So
getting
to
the
point
where
you
have
the
really
high
scale
super
crazy
stuff,
and
then
you
have
all
the
one-off
things
that
just
work
and
you
don't
think
about
them,
but
they're
what
keep
the
business
ticking
over
or
where
they
keep
the
the
mail
getting
delivered.
C
That's
sort
of
that
sort
of
feature
making
it
really
easy
to
run
things
at
any
point
of
the
spectrum,
not
just
server
lists
on
one
extreme
microservices
in
the
middle
and
monoliths
on
the
end
right
people
say:
micro
services
are
containers,
fits
really
nicely.
I
really
want
to
see
that
spectrum
I
wanna,
see
you
know.
I
can
have
fad,
serverless
containers
that
talk
to
other
services
running
by
operators
and
connect
them
to
applications
running
in
the
cloud
that
are
using
cloud
services.
C
You
know
we
can't
break
the
speed
of
light
data
gravity
is
always
going
to
be
a
big,
a
big
problem
where
you're
gonna
have
your
data
in
one
spot
and
all
these
things
need
to
talk
to
it.
That's
fine,
but
we
want
to
make
it
as
easy
as
possible
to
build
and
run
those
applications
as
close
to
your
data
as
you
need,
or
as
far
away
as
they
need
to
be
for
security
or
for
isolation,
so
that
flexibility
of
use
case
all
the
way
from
serverless
on
down
I
think
is
something
that
underpins
everything.
C
B
What's
cool
that's
happening
right
now
is
getting
so
many
different
parts.
The
ecosystem
with
different
personas
agreeing
around
the
kubernetes
api
is
really
really
cool,
because
it
means
that
you
translate
that
diagram
that
you
drew
directly
into
API
objects
into
kubernetes
and
then
those
API
objects
can
be
backed.
The
networking
team
can
worry
about
making
sure
that
there's
a
network
policy
in
place
that
protects
the
application
from
the
environment
in
the
environment
from
the
application.
A
B
Or
something
where
we
all
agreed
on,
like
one
language,
have
we
really
been
able
to
say
like
any
language,
any
computer
infrastructure
or
whatever?
This
is
an
API
we
can
agree
upon,
and
this
is
I
think
is
a
unique
opportunity
moving
forward
the
next
few
years.
It
enables
teams
to
be
a
lot
friendlier
with
each
other.
You.
C
Know
what
this
got
me
thinking
of
is
there's
a
particular
meme
that
I
hate
when
people
say
it
like
you're,
not
Google
right,
it's
a
very
it's
a
very
like
hey
you're,
over
designing
business.
You
know.
Sometimes
we
over
design
things.
You
know
that's
what
we
do
or
software
engineers
we
like
building
things
and
seeing
what
we
can
make
happen
whenever
someone
says
you're,
not
Google,
I
like
to
say
no
you're,
not
you
have
far
more
interesting
problems
than
they
do,
because
at
the
heart
of
it
you
know
some
of
the
things
that
make
Google.
C
What
they
are
is
that
they
have
a
they
have
a
ton
of
software
engineers,
building
big
complex
systems
that
layer
on
top
of
each
other
there's
a
they
have
a
lot
of
tools
that
they
use
internally.
I.
Think
those
advantages
are
things
that
most
of
the
rest
of
the
organizations
out
there
don't
have
and
so
being
able
to
take
those
ideas
which
they
even
the
Google
technology.
Isn't
that
great
you
get
Tim
Hawking
up
on
the
stage
and
like
I
speak
for
Tim,
but
you
got
Tim
upon
here
like
he'll.
C
Go
on
for
hours
about
you
know
all
the
bad
decisions
they
made
in
previous
lives,
because
we,
you
know,
we
build
things,
we
learn
and
we
build
them
better.
I
really
want
to
see
the
conversation
changed
because
I
talk
to
people
all
the
time
who
they
build
applications
and
they
build
applications
that
are
just
as
complicated
or
just
as
interesting
for
banks
for
retail
shops,
for
you
know,
line
of
business
inside
a
company
for
IT
that
are
just
as
interesting
as
anything
that
Google
has
ever
built
and
they're
under
a
lot
more
constraints
and
challenges.
C
I
like
to
think
of
what
we
want
to
do
is
make
all
of
the
tools
available.
I,
don't
care
if
you
have
a
hundred
one
pod
applications,
because
I
bet
you
those
101
pod
applications
are
just
as
important
to
you
as
anything
is
to
any
engineer
at
Google.
That
part
of
the
problem
is,
give
you
all
the
tools,
so
you
can
do
your
job
easier.
Yeah.
You
may
not
need
to
scale
up
a
kubernetes
cluster
to
five
thousand
nodes
or
something
like
that.
C
Some
people
do
that's
fine,
but
if
I
have
a
hundred
applications
and
I,
don't
even
think
about
them,
because
I
was
able
to
simply
in
an
afternoon
pull
an
API
together
that
checks,
those
for
health
and
keeps
things
ticking
off,
so
I
can
go.
Do
something
more
important,
I,
really
like
that's
what
that
that
transition
from
taking
the
toil
out
of
developers
lives
by
giving
them
these
tools
that
yeah
they
might
be
like
hideously
overpowered
for
the
use
case.
A
One
of
the
things
you
sort
of
both
been
talking
about
a
little
bit
of
their
api's
and
their
abstractions
that
they
imply,
and
over
time
this
has
evolved.
Can
you
I
guess
I'll
start
with
you?
Brenneke
talk
a
little
bit
about
the
type
of
workloads,
kubernetes
has
or
applications
that
kubernetes
supported
the
past.
That
recently
have
been
enabled
and
where
you
think,
that's
sort
of
going
in
the
future.
Yeah.
B
B
A
C
I
echo
what
brand
says:
I'm
always
surprised
by
the
complexity
of
the
things
people
are
able
to
build.
It's
really
it,
and
this
kind
of
is
why
that
you're,
not
Google
scale,
always
annoys
me.
It's
Amadeus
did
some
amazing
things
before
one
Oh
kubernetes
even
came
out
and
again
it
gets
down
to
giving
people
tools
that
do
one
thing
and
do
it
well
and
urbanize
gets
dinged
a
lot
for
being
so
complex,
but
I
like
to
think
of
kubernetes
is
just
broad,
I'm
sure.
There's
a
lot
of
concepts
to
learn.
C
You
don't
not
forced
to
learn
all
of
them
all
at
once
that
I've
seen
such
complex
applications
that
has
kind
of
taken
me
aback.
Sometimes
they've
done.
You
know
really
interesting
things
with.
You
know:
front-end
load
balancers
that
talk
to
multiple
clusters.
You
know
way
before
anybody
in
the
community
actually
had
anything
running
as
Federation
code.
C
People
were
load,
balancing
applications
across
the
entire
world,
redeploying
applications
automatically,
and
they
were
doing
it
with
some
bash
some
bash
and
some
some
Ruby
code
and
some
Python
code
they're
just
gluing
these
things
together
and
that
flexibility
was
I
couldn't
have
predicted.
What
they
would
have
built,
but
they
saw
the
value
in
a
tool
and
they
saw
how
they
could
take
that
tool
and
use
it
for
zone
infinite.
C
It
actually
reinforced
to
me
how
much
more
of
a
job
we
need
to
do
in
the
coroners
ecosystem
of
showing
people
examples
of
things
that
are
possible
not
just
in
kubernetes
but
in
the
general
software
ecosystem.
Examples
of
what's
possible
that
really
help
you
understand
why
and
how
a
tool
should
be
used
like
distributed.
Databases
are
great
if
you
needed
to
distribute
a
database.
How
does
someone
make
that
choice?
C
I
think
that's
a
trend
that
we
can
do
a
lot
better
job
in
kubernetes
things
like
operators
and
Service,
Catalog,
and
documentation
and
code
camps
and
better
education
as
a
whole,
which
is
here's
why
this
tool
is
so
powerful.
Here's
how
you
should
use
it
and
there's
all
these
other
ways
have
at
it,
but
help
you
orient
yourself.
First
yeah.
A
C
Service
Catalog
has
been
interesting
so
for
those
in
the
audience
we
talked
about
this
last
year,
at
Summa
has
been
a
part
of
the
service
broker.
Api
was
something
that
was
part
of
Cloud
Foundry,
and
it
was
the
rough
idea
that,
if
you
have
a
platform
that
can
only
run
stateless
applications
or
excels,
it
routes
a
excels
at
running
stateless
applications.
Then
you
want
to
be
able
to
connect
those
applications.
Stateless
and
the
Heroku
did
something
similar
previous
to
this.
C
This
is
the
pattern
that
you
should
follow
in
the
real
world's
more
nuance,
but
it
helped
people
get
up
to
speed.
The
idea
of
the
open
service
broker.
Api
was
just
to
give
you
just
enough
credentials
to
connect,
and
that
was
something
that
a
lot
of
people
in
the
ecosystem
who
had
these
big
deployments
were
using.
So
it
made
a
lot
of
sense
for
us
to
say:
kubernetes
is
in
an
Iowa.
C
Think,
as
kubernetes
has
improved,
what
we
are
seeing
is
we
want
to
make
kubernetes
extensible
and
it's
not
kubernetes.
It's
just
the
idea
of
simple
declarative
composable
things
that
run
on
flexible
infrastructure
and
you
can
just
add
30
more
of
them
and
they
just
keep
taking
over
you'll
have
to
think
about
it.
C
The
biggest
problem
with
any
new
piece
of
software
is
it
has
somebody
has
to
keep
it
up-to-date.
If
you
can
attack
the
problem
of
keeping
it
up-to-date
and
keeping
it
running,
then
you
open
the
door
to
say
well,
I
can
do
10
of
those
and
then
a
hundred
of
those
and
then
a
thousand
of
those,
and
so
I
think
over
time.
We'll
see
that
operator,
the
operator
approach,
kind
of
fits
in
the
middle
you've
got
the
I'm
just
consuming.
C
This
somebody's
got
to
run
those,
but
maybe
those
are
DBAs
or
professional
service,
mins
or
a
cloud
provider
and
you've
got
big
I
build
it
all
myself
that
that
rich
middle
I
think
is
where
two
teams
working
together.
They
don't
need
a
service
broker
to
interact.
They
can
talk
to
each
other
over
the
network
and
they've
been
doing
that
for
years.
That's
not
a
novel,
so.
A
We've
got
about
10
minutes
left
before
we're
going
to
leave
five
minutes
for
questions
so
just
to
sort
of
switch
to
some
more
the
futuristic
aspects.
Right
so
ask
you
this
one
Brendan,
you
know
the
next
generation
of
open-source
software
is
being
designed
right
now.
What
do
you
think
its
relationship
is
going
to
be
to
kubernetes
in
the
kubernetes
ecosystem,
as
well
as
like
the
infrastructure
that
kubernetes
is
running
on?
Given
that
there's
quite
a
shift
to
public
cloud-
and
you
know
and
also
you
know,
the
advent
of
service
yeah
so.
B
I
think
we're
at
an
inflection
point
for
open-source
software
for
a
long
time.
Open-Source
software
you
had
two
options.
First,
is
that
single
single
machine
installs
we're
super
easy.
You
like
downloaded
an
RPM
or
some
bash
script,
and
you
ran
it
or
if
it
had
any
component
of
having
to
run
on
more
than
one
machine,
it
was
impossible
to
install
method.
So
you
ran
through
like
a
thousand
or.
B
Can
through
like
unlimited
amounts
of
documentation,
you
have
to
generate
like
config
files
that
matched
exactly
or
the
system
wouldn't
work,
which
is
pretty
unrealistic
for
how
systems
have
to
work
today,
whether
it's
load,
balancers
or
databases
or
caches.
You
inevitably
have
to
have
more
than
one
copy
in
any
production
setup
and
so
I
think
the
opportunity
with
containers
and
kubernetes
is
that
these
open
source
systems
that
always
felt
too
complex
to
run
yourself
in
a
realistic
production
manner
and
therefore
just
kind
of
defaulted
to
being.
Oh
I'll
just
ask
a
cloud
service.
B
We
can
actually
bring
it
back
to
the
source
and
we
can
say
well.
Open
source
services
can
be
deployed
on
this
open
source
platform,
which
is
kubernetes,
I.
Think
that's
a
pretty
important
innovation,
because
for
a
long
time
we
struggled
we
struggle
with
Oh,
should
I
deploy
two
OpenStack,
but
then
Otis
sac
doesn't
work
against
the
public
cloud
or
my
laptop,
but
really
anywhere,
except
for
the
one
open
second
stall
inside
the
inside
the
business
and
so
I.
B
C
I
would
echo
all
that
I
want
to
see
tools
that
make
and
I
think
this
is
a
you
know.
You
alluded
Steve
earlier
to
being
fast
follower
and
I.
Think
one
of
the
nice
things
about
a
fast
follower
is
open
source
is
about
people
seeing
someone
else's
idea
in
iterating
on
it.
So
a
Google
paper
about
Chevy
helped
inspire
EDD,
Chubby's
Google's
internal
lock,
service,
great
name,
pre
names.
B
C
When
you
know
people
in
the
community
work
together,
every
open
source
project
has
some
story
of
someone
trying
to
scratch
an
itch
or
to
solve
a
problem,
or
increasingly
today,
people
trying
to
build
things
that
empower
other
people
and
being
Jenn
with
the
things
they've
created
so
open
sourcing,
the
things
that
help
make
Twitter
successful
and
not
all
of
these
fit
every
use
case.
But
if
we
can
go
and
do
just
enough
to
to
to
push
that
a
little
bit
further,
we
all
become
better
at
being
fast
followers.
So
I'm
always
surprised.
C
As
back
to
the
complexity
I've
seen,
you
know
talk
to
people
where
there's
a
project
launched
six
months
ago
and
they're
running
something
super
complex
depending
on
in
production,
on
kubernetes
at
an
immense
scale.
I'm
always
like
I,
didn't
think
that
would
be
possible,
but
because
you
understand
it,
it
was
able
to
provide
value
to
you
and
you
were
able
to
do
it.
It
was
the
tools
building
on
each
other
and
I.
C
Do
think
we're
at
that
inflection
point
of
open
source
being
reinforcing
and
they'll
always
be
services
that
we
consume,
that
other
people
provide
it.
That's
how
we
get
better
at
doing
these
things
that
somebody
else
does
it
better
than
I
can
but
there's
increasingly
an
element
of
for
every
person
who
can
do
it
better,
there's
10
or
15
or
20
people
that
all
have
that
same
problem
and
they
might
use
the
the
guy
providing
it
as
a
service,
but
they
might
just
as
well
work
with
a
community
to
make
that
better.
C
On
top
of
open-source
and
we've
seen
that
I
mean
this
is
what
we
see
all
the
time
in
red
has,
and
it's
always
inspiring
to
say:
we've
got
a
target.
We've
got
that
focus
if
we
can
do
a
better
job
of
helping
take
some
of
those
services
and
make
them
really
rock-solid
in
all
the
different
dimensions.
Everybody
else
gets
to
build.
On
top
of
that,
and
then
everybody
benefits
yeah
I.
B
B
Forgot
we
were
being
recorded
so
yeah,
so
I
think
that's
that's
a
big
change,
yeah
huge
thanks
to
docker
for,
like
thinking
of
how
do
we
repackage
Linux
software
in
a
way
that
you
can
read,
read
me,
and
so,
though,
here's
the
thingy
and
then
you
can
run
the
thingy
on
your
laptop
and
it
works
more
or
less
the
same.
Nowhere,
no
matter
where
you
go.
C
That's
no
I've
gotten
as
I've
gotten
older
I,
take
a
perverse
pleasure
and
something
that's
so
ugly
that
it
just
works
and
it
works
all
the
time.
Downloading.
Giant
blobs
of
entire
file
systems
from
the
internet
is
a
terrible
idea
and
it's
amazing
that
it
works
every
day.
So
I
think
I
looked
early
on
in
kubernetes,
we
had
a
bug
where
we
were
always
pulling
a
particular
image
and
when
docker
released
their
stats
for
number
of
images
pulled
pretty
early.
C
Rid
they
were
like
hey,
you
guys
are
hitting
us
all.
We're
really
sorry
and
that's
sort
of
you
know.
Bash
is
one
of
those
things
as
I
loved
it.
Everybody
loves
to
hate
on
bash,
like
it's
the
glue
that
binds
together
everything
and
it's
terrible
and
it's
ugly,
and
it
makes
us
more
productive
I
want
to
be
that
terrible,
ugly
glue
that
makes
everything
more
productive,
yeah.
So.