►
Description
Red Hat’s senior leadership is having to execute at an ever-increasing pace. That means that today's technology decisions have to balance short-term risk with long-term gains. This unique series provides host Chris Short inviting thoughtful and candid discussions with each guest.
An hour with the one and only Clayton Coleman, OpenShift and Container Architect, One of the Top Contributor Kubernetes
A
What
is
the
future
of
cloud?
What
is
the
future
of
compute,
so
you're
kind
of
the
architect
in
charge
of
looking
forward,
and
you
know,
you're
a
huge
kubernetes
contributor?
Obviously,
but
what
is
the
future
of
compute?
Look
like
that?
Doesn't
sound
like
a
hard
problem
to
solve,
or
anything
at
all
like
that.
Well,.
B
I
mean-
I
don't
know
if
you
have
ads
on
this
chris,
but
we're
going
to
draw
this
out
as
long
as
possible
so
that
we
can
get
a
bigger
and
bigger
audience,
as
the
word
goes
out
that
we're
going
to
we're
going
to
drop
some
knowledge
about
the
future
of
computing.
In
all
seriousness,
it's
funny.
I
worked
on
openshift
for
eight
plus
years
now
just
about,
and
you
know
that
whole
time
you
know
the
mission
has
evolved
right.
It's
making
developers
happy
giving
operations
teams
something
right.
B
It's
kind
of
a
everybody
loves
running
applications.
You
got
operations,
teams
that
are
in
the
weeds
and
we
went
from
you
know
manually
copying
things
on.
You
know
floppy
disks
and
moving
them
to
servers
to
you
know
crazy
network
file
system
hacks
back
to
ssh.
You
know
distributing
apps
like
you
know.
I
remember
early
days
of
ruby
and
you
know
ruby
on
rails.
It
was
you
know,
capistrano
was
the
hottest
thing
and
it
was
using
ftp
sites
to
upload
your
website,
and
you
know
we
keep
getting
all
these
better
and
better
tools.
B
B
Right
so,
like
five
years
in
six
years
in
you
know,
kubernetes
is
successful,
containers
or
something
that's
kind
of
you
know
and
not
everybody
uses
containers
today
you
might
not
know
you're
using
it.
If
you're
in
a
big
company
you
very
well
might
be,
you
might
still
be
using
vms,
you
might
be
using
you
know,
serverless,
you
might
be,
you
know
still
stuck
in
the
in
the
the
old
world
of
you.
Don't
even
have
like
great
deployment
experience
or
you
might
be
right
on
that
cutting
edge.
B
A
lot
of
what
I've
been
thinking
about
is
okay.
What
can
we
take
from?
What's
been
successful
kind
of
look
at
all
the
problems?
People
have,
you
know
stitching
this
stuff
together.
What
are
the
kinds
of
abstractions
that
can
move
the
move?
The
discussion
forward
so
like
kubernetes
is
a
great
example,
because
there's
a
lot
of
interesting
concepts
in
kubernetes
about
what
I
call
like
application
infrastructure.
That's
programmable
right,
so
you
know
you've
got
services.
A
service
you
know
doesn't
have
a
you
know
a
whiz-bang
list
of
features.
You
know
10
miles
long.
B
You
got
to
go
to
service
mesh
or
you
know,
go
to
one
of
the
the
api
management
tools
for
that,
but
it's
just
enough
that
most
people
can
depend
on
it.
When
you
have
that
in
place,
you
can
start
building
stuff
on
top
of
it.
Even
even
service
mesh
actually
relies
on
service
services
right,
obviously
from
the
name.
So
you
keep
building
up
this
level
of
technology
and
abstractions.
Are
there
other
abstractions
that
we're
not
thinking
about?
And
you
know
this
is
one
that
I've
been
spending
a
lot
of
time.
B
B
Thinking
about
that,
I
think,
is
going
to
be
a
really
big
part
is
what
are
the
parts
of
the
kubernetes
abstraction
that
you
can
kind
of
lift
up
and
use
together,
because,
like
right,
we
took
machines
and
we
put
them
into
a
cluster
right,
and
then
we
came
up
with
abstractions
that
didn't
care
about
machines.
So
what
are
the
abstractions
that
take
clusters
and
make
us
not
worry
about
clusters
and
it's
probably
going
to
be
different
abstractions?
What
parts
of
it
are
the
same?
B
A
B
It's
a
lot
of
manual
stuff,
there's
a
lot
of
work
on
inner
connectivity
between
clusters
and
services,
everybody
kind
of
has
their
own
way
of
gluing
the
stuff
together.
You
know,
red
hat
has
a
couple
projects.
You
know
all
the
way
from
the
lowest
levels
working
in
the
community
with
submariner
all
the
way
up
to
the
scupper
project
which
kind
of
lets
you
have
a
virtual
application
network.
You
know
from
the
and
you
can
go
even
lower.
You
can
set
up
your
clusters
so
that
everything
can
talk
to
everything
else.
B
I
think
it'd
be
really
awesome,
and
I
think
this
is
something
that's
a
big
focus
for
us
is.
Can
we
make
that
easier
in
the
community?
Yes
and
with
standard
standard
patterns
right
so
that
you
know
most
people
most
of
the
time,
don't
think
about
it?
That
opens
up
new
doors
for
new
types
of
delivery.
Experiences
right
like
if
you
stop
kind
of
carrying
what
cluster
you're
running
on,
maybe
local
development
to
staging
to
production.
A
B
Exactly
and
you
know,
we've
we've
learned
a
lot
about
how,
when
you
have
a
lot
of
automation
at
play,
what
are
good
security
boundaries
and
one
thing
that
I
think
a
lot
of
organizations
a
lot
of
people
using
kubernetes
today
struggle
with
is
they
have
a
lot
of
those
abstractions
they're
building
themselves
right.
So
that's
that's!
B
Just
duplication,
everybody
using
the
same
get
up
solution
for
ci
cd,
awesome,
yeah,
everybody
that
wants
to
integrate
into
that
cic
solution
have
to
coming
up
to
come
up
with
new
abstractions
and
new
extension
points
slightly
less
awesome,
so
there's
ways
that
we
can.
I
think
I
just
call
it.
You
know
putting
putting
the
community
to
work
by
looking
for
places
where
we're
all
doing
similar
stuff
and
what
are
the
bits
that
we
can
kind
of
supercharge
by
taking
stuff
that
already
works.
Well,
and
you
know
this
is
the
hardest
part
about
kubernetes.
B
I
think
we're
at
a
point
where
we
want
to
find
out
ways
to
extend
quote-unquote
application,
infrastructure
or
flexible
applications
that
are
a
little
bit
less
tied
to
the
cluster
right
and
that's
gonna,
be
you're.
Gonna
have
some
people
that
you're
gonna
have
to
pay
a
little
bit
of
cost
to
change
your
apps.
Ideally,
you
know
this
is
like
a.
How
do
you
move
forward
right?
We
didn't
all
start
using
containers
in
day,
one
no
built
bridge
technologies.
You
know
sometimes
containers
were
part
of
these
new
systems.
B
You
adopted
that
you
didn't
even
know.
Containers
were
under
there
right
the
early
versions
of
platform
as
a
service
used
virtual
machines
or
containers,
and
sometimes
you
couldn't
tell
which
one
was,
which
you
know
serverless
functions
depending
on
who
you're
running
in
sometimes
they
run
in
containers.
Sometimes
they
run
in
micro
vms.
Sometimes
they
run
big
fat
vms,
and
you
know
this
this.
This
mindset
is
I'd
still
think
we
want
to
be
less
focused
on
the.
How
and
look
for
places
where
you
know
open
communities.
B
Do
this
really
well
like
kubernetes
has
been
hugely
successful
as
an
open
community.
There's.
No,
you
know:
there's
no
czar
of
kubernetes,
there's
a
bunch
of
really
passionate
people
who
try
to
make
the
world
better.
It's
pretty
decentralized,
sometimes
that
that
means
it's
really
hard
to
to
yank
it
around
and
to
solve
some
pretty
thorny
common
problems
yeah.
But
you
know
that
that
still
gives
us
room
to
say,
but
it's
okay,
because
we're
willing
to
give
up
on
a
little
bit
of
you
know
10-year
roadmap
style,
stuff.
A
B
Or
looking
for
places
where
people
actually
need
solutions
or
need
the
flexibility
to
build
their
own
solutions,
so
that's
another
characteristic.
I
think
we
need
to
think
about
going
forward
is
how
do
we
make
open
source's?
Perfect
strength
has
always
been.
How
do
I
take
what
you've
done
and
build
something
else
with
it?
Sometimes
that's
code
when
it's
frameworks
or
libraries
and
sometimes
that's
components
right
when
you're
you
know
pulled
together
a
helm
chart
that
has
700
components
in
it.
B
You
don't
know
how
any
of
that
works,
and
you
know
sometimes
you
pull
in
operators
or
you
know,
you've
got
a
team,
that's
using
services
from
a
cloud
provider
they
want
to.
They
want
they're
telling
you
know,
you've
got
to
use
the
database
service
from
a
particular
cloud
provider
right.
What
are
the
things
that
we're
missing?
That
makes
some
of
that
easier
that
help
glue
together
these
bits.
You
know,
there's
a
lot
of
great
technologies
out
there
in
the
ecosystem
that
kind
of
glue
together
bits
of
quote-unquote
cloud-native
applications.
B
I
actually
think
kubernetes
and
the
concepts
around
kubernetes
is
a
place
where
we
could
do
that.
You
know
what
multi-tenancy
within
a
single
cluster
is
hard.
You
know
we
said
before
you
know:
if
you've
got
all
these
different
environments,
can
we
use
some
of
the
same
abstractions
that
we
use
name
spaces
and
clusters,
but
kind
of
lift
them
up
a
level
bring
them
up
and
then
plug
in
a
broader
set
of
of
integrations?
B
So
these
are,
you
know,
there's
a
lot
of
stuff
going
on
in
the
community
a
lot
of
great
investment
in
a
bunch
of
different
areas.
One
of
the
things
I'm
looking
at
is
everybody's
trying
to
solve
a
lot
of
these
problems.
How
can
I
personally
work
with
teams,
individuals,
companies,
partners,
clouds,
competitors
to
say
you
know
we're
all
struggling
to
solve
this
problem?
B
If
this
problem
and
this
problem
in
this
problem
could
be
overlaid,
could
we
all
work
together
on
that?
So
that's!
That's!
That's
a
little
bit
of
what
you
know
my
day
to
day
has
been
for
for
a
lot
of
the
last.
You
know,
six
months
to
a
year
is
starting
to
think
bigger
than
bigger
than
the
the
current
state
of
the
ecosystem.
Where
can
we
create
some
alignment
points
and
bring
people
together
around
projects
that
really
accelerate?
You
know
the
broad:
how
do
you
deploy
applications
anywhere
and
use
all
computing
to
go?
B
A
Do
we
want
to
care
about
which
cluster
is
running,
which
workload
kind
of
thing
right
like
it
is
that
pets
versus
cattle
mentality?
If
all
of
your
clusters
are
bespoke,
you
know
artisanal
clusters,
you've
kind
of
defeated.
The
purpose
of
using
kubernetes
right,
like
the
idea,
is
to
make
them
very
much
replaceable,
which
has
driven
us
to
this.
Where
we're
at
with
all
these
multiple
clusters,
hanging
out
everywhere
and
and
people.
B
Need
the
capability
right
like
yeah,
you
never
want
to
say
no,
you
can't
use
something
like
a
service
mesh
or
you
can't
use
a
particular
network
plug-in
right,
because
the
moment
you
start
saying
well,
I'm
going
to
stack
this
really
tall,
narrow
path
up
of
all
of
this.
All
these
things
have
to
line
up
perfectly.
You
start
to
get
a
little
bit
wobbly,
so
you're
going
to
broaden
that
foundation
and
actually,
I
think,
we're
kind
of
in
the
broaden,
the
foundation
phase
of
absolute
containers
and
applications.
B
B
I
think
we're
looking
for
places
where
we
can
kind
of
break
down
a
few
of
those
walls
stack
those
pieces
and
get
to
that
next
level.
There's
a
great
you
know,
you
know
sometimes
like
we
talk
about
like
the
unix
way
right,
so
this
gets
trotted
out.
A
lot
you
say,
like
the
unix
way,
is
lots
of
small
composable
tools.
I
think
composable
is
important,
but
the
better
one
is
orthogonal.
B
You
have
a
bunch
of
tools
that
you
can
use
independently
or
together
to
solve
different
problems,
and
the
areas
between
them
are
actually
pretty
carefully
chosen
right
so
like
in
in
unix.
You
have
the
command
line
and
you
can
pipe
standard
in
standard
out
and
you
can
chain
together,
but
I
don't
know
about
you,
I
I
do
tons
of
short
chains
and
tons
of
long
changes,
and
sometimes
I
say
you
know
what
I
want
you
to
take
that
chain
and
turn
it
into
a
program.
B
So
I
moved
to
bash
or
python,
and
I
start
digging
in
those
those
tools
all
work
together.
They
have
good
orthogonality
cube,
tries
to
have
this
right.
What
are
the
concepts
in
cube
like
your
services
and
pods?
You've
got
where
you're
running
and
how
you
reach
it
they're
pretty
separate,
they
don't
depend
on
each
other
closely.
It
was
a
it's
a
testament
to
a
lot
of
the
original
folks
in
the
cabrillo's
ecosystem
from
google's
and
others
who
recognized
that.
B
That's
a
really
key
property
of
a
of
a
powerful
system,
and
so
I'm
you
know
a
lot
of
what
I'd
like
to
look
for
is
places
we
can
pick
for
more
orthogonality
like.
Why
do
I
have
to
deploy
everything
in
containers?
I
don't.
Can
I
bring
together
some
of
my
systems
and
you
know
the
terraform
project
you
know.
Is
you
know,
terraform
and
ansible
together?
There's
a
lot
of
a
lot
of
people
in
those
ecosystems
who
use
a
config
management
approach,
deploying
cloud
resources
and
linking
them
together.
B
Cube
actually
has
a
lot
of
similarities
to
that.
But
cube
adds
that
level
of
reactivity
right
and
I'd
say
that's
the
difference.
You
have
config
management
and
then
you,
you
start
running
it
multiple
times
and
you
have
a
loop
and
then
you're
in
a
world
where,
once
you
have
a
loop,
you
start
thinking
about
how
you
can
be
more
efficient
and
what
you
can
react
to
and
reactivity
is
the
is
the
second
step.
B
So
kubernetes
is
a
natural
evolution
at
its
core
model
of
that
loop,
but
it
doesn't
really
have
to
be
tied
to
running
linux
processes
or
windows
processes
right
and
so
there's
a
lot.
I
think,
there's
some
opportunities
to
say
well
like
what
are
the
other
config
loops
that
people
are
doing
today
that
if
you
looked
at
I'd,
be
like
well,
this
just
didn't
fit
kubernetes.
B
Well,
maybe
what
if
we
took
kubernetes
and
took
away
the
machines?
Does
it
fit?
You
know
what
if
there
was
a
more
of
a
control
plane
for
applications
right,
it
had
the
powerful
concepts
from
kubernetes
and
worked
well
with
kubernetes,
but
was
a
little
bit
less
focused
like
containers,
are
kind
of
the
the
goldilocks
right,
they're,
the
not
too
hot,
not
too
cold,
not
too
bright,
not
too
small,
not
too
opinionated,
not
too
flexible.
B
A
Yeah,
it's
I'm
sorry,
go
ahead,
yeah,
please!
So
I
always
looked
at
like
terraform
and
ansible
and
that
whole
suite
of
configuration
management
tools
as
like
the
way
like
the
toolbox
to
glue
or
hammer
or
whatever
put
all
the
things
together
right
like
and
make
sure
that
either
the
the
infrastructure
was
deployed
correctly
or
the
application
was
deployed
on
top
of
it
correctly
and
kubernetes,
like
you
kind
of
s
stamp
all
that
down
into
you
know,
often
one
you
know,
series
of
files
for
lack
of
a
better
term
and
oftentimes.
It
can
be
one
file.
A
If
your
app
is,
you
know
simple
enough,
and
you
know
just
needs
like
a
little
bit
of
connectivity
and
off.
It
goes
kind
of
thing,
so
you
know
having
that
natural
evolution
of
like
all
of
a
sudden
I've
gone
from.
Oh,
I
need
14
bits
of
terraform
or
you
know
three
or
four
different
things
from
ansible
galaxy
kind
of
plugged,
together
with
some
of
my
custom
bits
of
ansible
to
now,
where
it's
more
universally
understandable
in
kubernetes
yaml.
B
B
B
They
don't
always
necessarily
expose
every
capability
right.
They,
you
have
to
go,
write
a
mapping
between
the
cloud
provider,
api
or
a
sas
provider.
Api
sas
providers-
actually
not
a
lot
of
them,
have
they
don't
necessarily
all
have
terraform
plugins,
because
somebody
has
to
go:
do
the
work
of
taking
an
api
and
many
times
a
fairly
declarative
api
object,
and
you
know
stitching
that
in
coming
up
with
a
new
abstraction
for
right.
So
you
take
the
api
that
the
the
provider
gives
the
original
observation.
B
B
You
know,
and-
and
you
know
it's
funny
when
kubernetes
bash
got
us
a
very
long
way
for
builds
and
at
some
point
it
becomes
time
that
you,
you
start
standardizing
and
formalizing
the
stuff
that
you're
doing
in
bash
into
something
a
little
bit
more
rigorous.
That's
a
really
important
step
for
most
projects,
it's
very
important
for
open
ecosystems,
because
for
most
things
in
an
open
ecosystems
thrive,
a
lot
of
people
have
to
find
them
valuable
and
they
need
to
solve
a
problem.
B
That
adds
that
reactivity
loop,
but
we
can
also
help
simplify
the
process
of
adding
new
things
into
kubernetes
right
like.
Why
is
it?
You
know
if
I
want
to
adapt
someone's
sas
api
to
cube,
so
that
I
can
do
a
really
quick
and
dirty
application,
and
do
that?
Can
we
get
to
a
point
where
we
can
make
that
easier
than
using
terraform
or
ansible
directly,
because
after
all,
both
the
terrible
and
terraform
enanciable
ecosystems
have
really
great
plugins
for
kubernetes
that
work
dynamically.
B
I'm
really
proud
of
the
work
that's
been
done
in
both
those
communities
to
to
deal
with
the
abstraction
and
to
pass
it
through
without
really
having
to
modify
it.
The
kubernetes
kind
of
provides
that
create,
update,
delete,
reconcile
loop,
not
perfectly,
but
well
enough,
that
if
you
can
extend
that
your
terraform
script
can
still
drive
it.
So
for
me,
I
think,
there's
a
huge
opportunity
here
in
the
ecosystem
to
take
those
ideas
of
plugging
all
of
it
together.
B
If
you
looked
at,
I
guarantee
you,
you
looked
at
a
100
cloud
native
application,
terraform
files.
You
find
a
lot
of
common
problems
that
are
solved
perfectly
well
today
that
we
can
improve
on
and
bring
those
closer
to
running
applications
in
a
way
that
starts
to
to
streamline
and
simplify
a
lot
of
that
sprawl
in
in
the
application
ecosystem,
and
that
gives
us
new.
B
You
know
the
more
you
bring
together
the
more
you
concentrate,
the
more
opportunities
there
are
for
right,
vendors
and
community
members
to
say
you
know
what,
if
I've
got
a
bunch
of
functions
and
I've
got
access
to
programs
some
of
these
other
interfaces,
I
don't
have
to
worry
about
some
of
the
details
of
authorization
like
if
we
can
standardize
some
of
that
bit.
That
opens
up
doors
for
people
to
build
really
powerful
integrations.
B
That
might
let
you,
for
instance,
do
really
trivial
function,
deploy
flows
where
the
community
works
together
to
say
you
know
we're
tired
of
solving
this
problem
for
five
different
ecosystems,
writers,
yeah
yeah.
Can
we
all
do
development
of
serverless
functions
in
a
similar
way?
Can
we
can
we
coalesce
on
apis
right?
There's
a
huge
divergence
of
what
the
apis
for
functions
are.
Some
of
them
are
efficient.
Some
aren't.
A
Well,
I
think
that's
a
wonderful
point.
You
bring
up
about
the
kubernetes
like
ecosystem
and
of
itself
right
like
before.
It
forms
a
sig,
a
working
group
or
anything
else.
Right
like
there
is
a
process
that,
like
the
decision,
tree
kind
of,
has
to
go
through
and
say
all
right.
Are
we
going
to
focus
on
this
holistically
as
a
project
or
ecosystem
or
community?
A
That's
where
folks,
like
us,
red
hat,
and
you
know
other
various
vendors
come
in
and
we
say:
okay,
fine
kubernetes
has
this
great
wonderful
thing,
but
it's
not
just
kubernetes
that
you
need
right,
like
it's
kubernetes
and
nowadays
and
like
I
wanted
to
kind
of
touch
on
like
it's.
You
know,
folks
are
starting
to
often
like
realize
that
they
need
a
little
bit
more
than
cube
all
right
like
it's
just
the
beginning,
not
necessarily.
B
The
end
everyone
has
way
more
than
cube
right.
Do
you
know
where
it
all
comes
from?
Do
you
know
that
it
works
together,
and
some
of
these
are
problems
that
you
know
that
open
ecosystems,
you
know
always
have
linux-
has
been
going
through
this
and
we
have
bunches
of
linux
distributions.
We
have
lots
of
cube
distributions
a
lot
of
things
in
linux
that
standardize
over
time
and
there's
a
lot
of
things
that
don't
like
packaging
doesn't
stop
ecosystems
from
being
valuable,
but
I
also
think
there's
places
where
there's
opportunities.
B
You
know
those
there
are
opportunities
in
those
ecosystems
to
to
build
consensus
and
to
to
align.
I
mean
the
best
part
about
kubernetes
is
to
go,
extend
kubernetes,
you
don't
have
to
talk
to
a
sig.
You
don't
have
to
get
anybody
to
agree
with
you
now,
maybe
if
you're,
if
you're
going
to
you,
know,
take
the
whole
code
base
and
change
large
chunks
of
it,
you
might
want
to
think
about
the
long-term
support
ability
of
that,
but
there's
plenty
of
organizations
out
there
that
do
that.
B
For
things
all
the
way
from
you
know,
like
red
hat
works
with
ecosystems
all
the
time,
sometimes
people
want
the
latest
and
greatest.
Sometimes
people
want
stability
for
10
years
huge
spectrum
there,
but
the
key
goal
is
make
sure
the
communities
and
ecosystems
themselves
are
sustainable
and
growing.
The
more
you
can
stay
focused
on
that,
the
better
so
like
yeah
I'd
say
like
our
stability
is
hard.
B
Yes,
but
if
you
stay
stable
forever,
that's
also
a
trap.
So
because
again
it's
how
do
you
bring
change
in?
So
a
lot
of
the
thought
around
you
know.
Where
does
kubernetes
go
from
here?
You
know.
Service
v2
is
a
great
example
of
maybe
not
something
we
could
have
done
very
early
on
or
shouldn't
have
done
very
early
on
in
cube,
but
as
a
community
as
an
ecosystem.
You
got
you
know
tens
of
vendors
and
projects,
and
you
know
a
large
number
of
motivated
organizations
that
are
building
and
deploying
around.
B
You
want
to
centralize
as
much
as
you
can
you
want
to
solve
the
pragmatic
problems
you
have,
but
then
you
don't
want
to
get
fall
into
stasis
right.
You
never
want
to
be
the
kind
of
project,
that's
too
afraid
to
change
so
like
how
could
kubernetes
change?
What
are
ways
that
kubernetes
can
can
change.
So
I
do
think
one
is
the
you
know
aggressively
thinking
about
how
kubernetes
patterns
and
model
is
applicable
to
a
wide
set
of
problems
outside
of
a
single
cluster.
That's
one
other
ways
are
how
you
start
to.
B
You
know,
standardize
and
solve
application
problems,
that's
necessary
for
that
first
thing:
if
you
don't
have
a
consistent
way
to
talk
across
clusters
or
consistent
ways.
Let's
say
you
know:
what
are
the
things
that
we've
built
in
the
ecosystem
that
don't
standardize
well
service
v2
is
a
great
example
of
that.
We've
done
a
lot
of
work
with
persistent
volumes
and
the
storage
subsystem
in
cube.
B
I
feel
like
the
most
successful
communities
ping
pong
between
those
two
creating
open
opportunities
for
people
to
redefine
whole
classes
of
problem
and
then,
as
people
consolidate
those
bring
those
back
and
and
move
forward.
You
know
outside
of
you
know
even
kubernetes.
This
is
a
huge
problem
for
developer
tools.
Yeah,
like
you.
B
And
it's
it's
awesome
too,
because
you
know
in
the
in
the
last
six
years
the
number
of
people
who've
built
simple
and
useful
platform
as
a
service
type
tools
right
very
opinionated.
In
the
vein
of
heroku
and
the
early
days
of
the
various
paths
efforts,
you
can
still
have
opinionated
flows,
a
lot
of
organizations
build
opinionated
flows.
B
When
I
look
at
the
developer
and
application
life
cycle
or
ecosystem,
there's
a
lot
of
diversity
and
similarity
that
nobody's
really
attacked
yet,
and
so
that's
another
one-
and
we
were
kind
of
alluding
to
this
earlier-
is,
I
think,
the
goal
of
kubernetes
as
a
concrete
piece
of
software
is
pretty
well
accomplished.
It's
got
to
keep
evolving.
B
C
B
B
What
are
the
things
that
we
can
put
into
source
code
so
like
infrastructure,
as
code
has
been,
you
know
kind
of
a
hot
topic
around
this
there's,
probably
lots
of
other
descriptions
of
the
world
that
don't
really
fit
into
our
source
code
workflows
today
that
could
be
fit
in
whether
that's
process
or
pipeline
we've
gone
through
many
iterations
of
those.
You
know
everybody's
got
a
file,
they
stick
in
their
git
repo
or
10
files
or
50
files.
B
A
I
mean
my
dream
ultimately,
is
that
I
can
create
a
quote
pipeline
file
of
some
sort
that
says
it
soup
to
nuts
right
like
if
it's
bare
metal,
pointing
at
a
server
here
in
the
house,
or
you
know
pointing
at
some.
You
know
api
in
the
cloud
somewhere.
It's
going
to
cover
not
just
the
infrastructure
setup,
but
also
the
application
pipeline
development
setup
and
it's
gonna
have
the
hooks
and
everything
already
glued
together
right.
B
And
secrets
are
a
great
problem,
which
is
not
all
secrets
are
necessary
everywhere.
If
you
can
standardize,
you
know,
secrets
are
effectively
a
boundary
between
two
systems.
Where
you
know
the
best
solution
we've
come
up
with,
is
well
I'll.
Just
hide
some
data
over
here
and
hope
that
everything
goes
well.
You
know
the
one
of
the
things
that
I
think
you
know
in
the
kubernetes
ecosystem,
in
the
broader
application
and
nobody's
really
tackled,
is
within
a
cloud
there's
a
lot
of
really
interesting
opportunities
to
force
standardization
yeah
of
on
a
particular
identity
technology.
B
A
B
All
right
and
and
ser
service
mesh
took
one
of
those
steps
within
cube
right
service
mesh
kind
of
said:
can
we
tie
identity
and
interconnection
closer
to
the
application?
Yes,
I
think
we're
just
at
the
beginning
of
kind
of
those
is
you
know,
thinking
about
moving
to
multi-cluster
worlds
tying
in
cloud.
B
You
know
if
you're
running
an
application,
that's
tying
into
the
cloud
you
may
actually
want
and
again
like
this
depends
on
who
you
are
you
know
everybody
wants
something
a
little
bit
different
as
we
standardize
more
on
authorization
and
identity
interfaces,
as
we
standardize
more
on
application
infrastructure.
Abstractions
like
whether
it's
service,
mesh
or
injecting
secrets
into
your
workload.
B
Can
we
actually
build
out
some
of
those
open
source
glue
projects,
and
there
have
been
a
few
in
the
community
that,
for
various
reasons
haven't
always,
you
know,
exploded
into
wild
adoption,
and
can
we
smooth
those
paths
just
kind
of
standardize,
those
like
for
us
identity,
a
great
one,
single
sign-on,
tying
cloud
to
everything
else.
You
know.
So
what?
If
you'd
like
to
have
some
flexibility
in
how
your
im
implementation
works,
but
you
want
many
of
the
same
guarantees
that
you
could
get
from
a
cloud
provider
yeah.
B
I
think
there's
a
lot
of
opportunity
in
open
source
projects
out
there
to
work
closer
together
and
to
help
standardize
on
those
like
concentrate.
Some
of
this,
like
if
you've
made
a
bet
on
kubernetes
or
if
you
have
a
particular
serverless
implementation,
why
is
it
so
darn
hard
to
get
data
from
one
to
the
other,
looking
at
ways
that
we
can
both
make
that
open
right?
So
not
everything's
gonna,
run
in
one
cloud
or
on
premise
or
on
your
laptop?
B
A
Oh
yeah,
no,
I
mean
my
my
last
few
ops
jobs
before
I
joined
red
hat
were
very
much
right,
like
okay,
I've
logged
into
the
quote
network,
or
you
know
domain
and
oh
now
I
have
to
log
into
my
cloud
providers
and
there
was
various
steps
involved
in
doing
that
right
and
octa
and
everything
else.
It
all
came
back
to
our
single
sign-on.
But,
yes,
it
was,
you
know
all
glued
together
through
a
service,
and
it
was
a
pain
right.
So,
like
you
know,
it
is
what
it
is.
B
I'd
like
I
think
you
know
something
that
red
hat
as
an
open
source
company
who's
very
interested
in
making
developers
and
operations
teams
lives
easier,
is
to
be
able
to
stay
focused
on
those
kinds
of
abstractions
and
just
over
time,
help
help
the
communities
help
bring
individual
projects
together.
Keep
a
little
bit
of
relentless
pressure
right.
Open
source
is
a
little
bit
like
the
ocean
right.
We
all
use
it.
Yeah,
there's
not
a
single
person,
I
know
of
who
doesn't
use
some
open
source
in
every
bit
of
their
day-to-day
interactions.
B
B
How
can
we
slowly
move
in
the
direction,
and
the
great
thing
is,
is
that
most
people's
incentives
are
lying
towards
this
right
like
this
is
what
yeah
you
know
if
you're,
if
you're,
if
you're
a
developer
and
you
can,
you
can
hack
on
something
that
you
put
on
a
on
github
or
on
you
know
some
other
site
that
that
brags
about
how
much
you
improve
your
dev
workflow,
someone
will
go.
Do
that.
B
A
B
Someone
has
a
solution
if
you
spend
enough
time
looking
at
what
people
are
trying
to
build-
and
this
is
always
the
hard
part
is
it
takes
me-
you
know
one
unit
of
effort
to
hack
together
a
bash
script
or
a
you
know,
a
single.
You
know
a
single
chunk
of
code
that
solves
my
problem
right.
It
is
10x
or
100x
or
1000x
harder
to
take
that
and
find
and
make
it
generally
useful
right.
That's
where
a
lot
of
open
source
kind
of
dies?
B
It's
something
that's
useful
for
me
right,
but
when
you
start
having
10
or
15
of
those
examples,
you
do
often
get
a
pretty
good
idea
of
what
so
you
know.
I
spend
a
lot
of
time
like
especially
in
this
discussion
about
multi-cluster.
I
spend
a
lot
of
time
you
know,
reading
and
looking
at
what
other
organizations
are
doing,
whether
they're
contributing
to
the
work,
the
multi-tenancy
working
group
in
cube
right,
there's
a
lot
of
prototypes,
a
lot
of
really
passionate
people.
We've,
probably
you
know,
probably
generated
150
ways
to
do
aspects
of
multi-tenancy.
B
C
B
And
they're
willing
to
share
it.
You
can
learn
a
lot
by
seeing
what
problems
people
are
struggling
with
yeah
and
when
you
have
a
lot
of
solutions
that
none
of
them
really
take
off.
You
really
can
look
at
that
combo
of
those
things
and
say
well,
what's
the
thing
they
all
have
in
common?
Why
hasn't
that
succeeded,
and
sometimes
it's
you're
not
changing
the
problem
domain
up
enough?
Sometimes
it's
sometimes
it's.
There
may
be
no
local
minima
and
you
know
you'd
say
like
okay.
B
Well,
if
we
have
10
of
these,
surely
there's
one
well,
there
is,
but
it's
10
times
the
work
and
it
doesn't
really
get
that
opportunity.
So
I
I
do
think,
there's
a
you
know,
I'm
sorry
in
the
future
of
computing,
we're
still
going
to
write
ugly
hacky
integrations
to
glue
stuff
together
and
that's
okay.
I've
learned
that
over
over
my
career
is
it's
okay
to
make
ugly
things
that
solve
your
problem
right.
The
goal
is
not
to
be
pretty.
B
The
goal
is
to
get
the
stuff
running
and
for
people
to
be
happy
on
the
other
end.
So
like
right,
that
helps
me
is
like
you
know.
I
spend
a
lot
of
time
looking
at
what
we're
doing
and
saying.
If
I
take
myself
outside
of
the
particular
problem
space
we're
in
what
does
someone
actually
want
and
a
lot
of
times,
you
know
where
we
go,
invest
at
red
hat.
B
You
know
where
people
who
are
in
the
community,
sometimes
it's
someone
will
have
a
great
idea
and
they'll
casually
mention
it,
and
someone
else
will
have
a
very
similar
idea.
I've
actually
found
more
and
more
that
if
you
spend
a
lot
of
time
listening,
you
actually
don't
have
to
do
as
much
thinking
as
you
would
expect,
because
most
of
the
good
ideas
are
out
there.
It's
actually
the
synthesis
of
it.
It's
actually
the
hard
part,
and
you
don't
need
a
ton
of
people
doing
that.
But,
like
it's
the,
how
do
you
pay
attention
to?
B
What's
going
on
in
the
community?
Look
for
areas
that
you
know
where
a
little
bit
of
consolidation
or
coordination
could
go,
make
those
bridges
and
that's
kind
of
how
like
in
my
day-to-day
I'm.
That's
really.
All
I'm
doing
is
trolling
github
and
talking
to
a
lot
of
people
and
then
trying
to
boil
that
back
down
into
well.
What
are
all
the
things
that
we
we're
all
thinking
right
that
will
help
us
move
forward.
A
So
we
do
have
a
question
in
chat.
Is
there
any
plans
in
the
future
for
automating
cluster
backup,
which
I
think
is
interesting,
because
we
talked
about
pets
versus
cattle
a
little
bit
earlier,
and
pvc
backups
and
integrating
it
into
the
cluster
of
the
ui
itself,
somewhat
similar?
What
valero
does
and
there's
a
lot
of
cluster
backup
solutions
out
there
and
there's
a
lot
of
ways
to
back
up
pvcs,
but
none
of
it
has
become
like
a
defective
standard
right.
This.
B
Is
so
I'll
say,
this
is
one
of
those
areas
that
we're
all
looking
for
a
local
minima
and
we
haven't
quite
found
it.
Yet
you
know
valero
is
a
great
project,
it
does
some
things
really
well
and
it
struggles
with
other
things.
I
think
one
of
the
so
there's
two
dimensions
of
this.
The
pv
abstraction
has
helped
us
think
about
the
problem
differently,
so
snapshots
and
right
yeah.
We
didn't,
we
don't
always
get
these
perfectly,
but
the
pv
is
a
thin
reference
to
something
underlying.
B
I
don't
know
that
we
would
have
thought
about
backing
up
every
single
hard
drive
in
an
organization
couldn't
do
it
yeah
every
six
hours,
so
there's
a
lot
of
places
where,
as
the
technology
for
backup
and
the
underlying
infrastructure
has
gotten
better,
we've
been
able
to
use
that.
I
know
there's
a
number
of
backup
people
in
the
ecosystem,
who
are
doing
very
similar,
smart
things
for
us,
ocs
and
seth.
I
think
there's
a
lot
of
room
for
that
in
an
on-premise
setting
in
the
cloud.
B
So
you
know
how
do
you
make
every
application
crash
safe?
Well,
first
off,
if
you
want
to
make
every
application
crash
safe,
you
build
a
container
platform
that
crashes
a
lot
and
you
teach
people
that
you
have
to
think
about
crashing.
So
that's,
like
you
know,
there's
a
little
bit
of
as
we've
gotten
better
over
the
years.
B
You
know
I
worked
on
applications
early
on
in
my
career,
where
the
thought
of
crashing
and
crash
safety
was
oh,
that
that's
interesting
but
yeah.
I
don't
worry
about
that.
Yeah
kubernetes
builds
into
its
very
premise,
things
crash
and
die,
and
we
don't
always
do
it
cleanly.
We
spend
a
lot
of
time
in
the
early
days
of
kubernetes,
like
you
know,
ringing
our
hands
about
whether
people
could
run
postgres
instances
on
cube.
B
If
we
didn't
get
the
shutdown
model
correct
and
the
answer
is
you
can
and
if
you
know
what
you're
doing
you're
fine
and
it's
still
possible
to
shoot
yourself
in
the
foot,
because
you
still
absolutely
so
crash
safety
is
really
hard.
I
don't
think
we'll
ever
get
all
applications
to
do
backup
exactly,
but
by
creating
these
abstractions.
That
kind
of
put
a
certain
mindset
in
place,
which
is
you
write
to
disk,
and
if
you
want
to
do
backup
the
only
way
you're
going
to
be
able
to
really
easily
back
up
the
snapshot.
B
B
You
know
an
append
only
log
with
some
read
semantics.
I
feel
I
see
the
ecosystem
kind
of
aligning
on
that.
One
of
the
things
that
I
think
would
be
a
great
opportunity
is,
while
we
might
not
ever
get
a
magic
backup
integration
that
does
all
applications
equally,
if
we
make
it
easier
to
do,
sql-like
abstractions
right,
not
to
not
too
generic.
You
know
give
me
a
an
http
connection.
Has
its
own
problems
works
for
web
services,
but
not
others
right,
and
it's
not
a
super
low
level
integration.
B
You
know
built
into
every
framework,
but
if
you
can,
you
can
find
those
right
points
of
abstraction
and,
you
could
say,
maybe
represent
a
type
of
database
and
again
like
it's,
not
just
generic
sql
differences
between
sql
databases
matter.
But
if
you
can
say
things
like,
I
need
a
postgres
compatible
database
that
most
of
the
time
you
know
I'm
dealing
with
a
database
or
a
set
of
tables
or
a
schema.
You
know
some
of
those
abstractions
don't
really
exist
today.
B
B
There
are
interesting
opportunities
there
that
we
haven't
really
explored
yet
still
pretty
early
that
I'd
like
to
see
you
know,
a
concept
of
a
database
opens
up.
A
bunch
of
new
topics
doesn't
mean
everybody's
going
to
use
it
today,
it's
easier
just
to
go,
you
know,
pull
in
the
credentials
and
stick
them
into
a
file
and
stick
a
secret
there
yeah
the
important
thing
about
every
abstraction
that
we
put
in
the
cube
is.
B
It
has
to
be
just
as
easy
as
the
stupid
thing
and
more
useful,
because
nobody
switches
from
the
easy
that
people
will
write
back
to
the
heat
death
of
the
universe,
but
and
people
will
copy
secrets
and
connection
strings,
and
you
know,
write
passwords
on
the
on
their
sticky
notes.
Yeah
yeah,
you
know
some
put
them
on
their
monitor
until
the
end
of
time.
What
we
have
to
do
is
actually
make
the
abstraction
useful
enough
and
cube.
Did
this
right
cube
made
the
service
abstraction
useful?
It
made
the
pod
abstraction
useful.
B
Almost
every
successful
software
project
has
some
abstraction
that
was
similar
to
what
you
were
doing
before
and
easier
ruby
on
rails.
If
you're
building
a
website
for
for
a
client,
ruby
on
rails
dramatically
swept
the
ecosystem,
because
its
center
of
gravity
was
so
much
lower
cube
did
that
for
the
container
ecosystem.
I
think
you
know
in
the
whole
backup
story
we're
looking
to
put
abstractions
in
place
that
kind
of
lower
the
friction
point.
So
you
know
if
you,
let's
I'm
just
going
to
hypothesize
for
a
second.
B
If
you
want
to
move
an
application
around
yeah,
you
got
to
move
the
data
around
right
and
sometimes
moving
lots
of
data
is
hard.
There's
physics,
sometimes
there's
physics
involved,
there's
there's
politics
involved
and
there's
money
involved,
all
of
which
are
very
difficult
politics.
You
know
politics,
money
and
physics,
I'm
not
sure
which
of
those
is
hardest.
A
B
But
you
know
what
are
some
advantages
that
if
we
could
standardize
some
of
the
data
side
across
multiple
clusters
is,
you
know,
there's
vendor
people
today
who
can
do
backups
of
pvs
on
a
whole
cluster
awesome.
We
might
want
to
introduce
abstractions
that
make
backing
up
applications
awesome
if
we
can
create
the
opportunity
for
more
people
to
use
these
abstractions
by
kind
of
getting
even
more
of
the
application
development
experience
to
be
cube-like,
but
maybe
not
cube-centric
right,
not
depending
on
a
cluster.
B
But
if
you
want
to
move
that
app
from
across
two
clusters,
you
either
need
to
know
that
that
data
is
sticky
and
ain't
going
anywhere,
in
which
case
maybe
the
app
doesn't
do
much
good.
You
might
need
to
tunnel
it.
You
might
need
to
copy
it.
You
know-
and
this
is
like
there's
some
super
painfully
easy
things
that
we
haven't
standardized
in
cube.
Yet,
but
almost
everybody
I
know
who's
running
in
a
big
on-premise
setup
has
two
clusters
or
two
data.
Centers
close
proximity
right,
active
passive
across
two
cube
clusters
is
insanely
difficult.
C
B
Today,
but
why
don't
we
like?
There's
nothing?
It's
just
it's
just
most
people
don't
have
enough
of
the
same
problems
that
everybody's
problem
lines
up.
The
thing
I'm
really
focused
on
is
like:
how
do
we
get
those
problems
to
line
up
so
for
the
backup
thing?
Can
we
get
persistent
volumes
and
backup
persist,
volumes
tied
to
apps
and
orchestration
across
clusters?
B
If
you
can
orchestrate
across
clusters,
that's
one
dimensional
problem.
It
also
gives
people
building
in
the
ecosystem
a
better
handle
on
applications
themselves,
because
today
applications
are
kind
of
tied
to
a
cube
cluster
right.
The
best
you
know
a
lot
of
the
trivial
ones
aren't
but
there's
assumptions
that
get
baked
in
if
we
can
make
those.
B
And
if
we
can
do
a
better
job
of
standardizing
some
of
those
assumptions,
it
makes
backups
easier
right.
You
know
everybody's
kind
of
talked
about
this
for
years
like
if
only
we
had
the
concept
of
an
application.
There's
no
such
thing
as
the
concept
of
an
application,
there's
the
environment
and
the
abstractions.
You
use
to
build
your
application.
B
Red
hat
is
not
necessarily
gonna
build
the
best
backup
solution,
but
the
ecosystem
motivated
vendors,
red
hat
users
all
have
most
of
the
partners.
Cloud
providers
all
have
many
of
the
pieces
that
we're
all
dependent
on
right
like
this.
This
call
right
now
is
dependent
on
so
many
layers
of
technology.
It's
probably
it's
terrific.
It's
dizzying
dizzy.
B
A
And
it's
funny
right
like
for
producing
and
making
this
channel.
We
say
we
have
moved
the
complexity
to
the
seat
of
the
producer
right
like
when
any
big
software
project,
you're
moving
complexity
somewhere
right
and
like
we've,
realized
that,
like
for
this
channel,
we
need
to
have
the
complexity
sit
with.
You
know
me
or
someone
like
me
and
for
a
kubernetes
like
federated
system,
that
complexity
has
to
live
with
something
and
is
it
the
scheduler?
Is
it
the
cubelet?
What
where's
where's
it
gonna
sit
and
where's
the
best
place,
for
it
is
the
hard
problem.
B
It's
not
a
knock
on
terraform,
it's
we're
just
not
doing
enough,
you
know
comprehensively
and
then
comprehensive
is
hard.
So
this
is
we
can.
We
are
on
a
path
to
try
and
you
know
bring
these
things
together
is
kubernetes
going
to
be
the
thing
that
we
all
use
for
the
next
30
years.
I
don't
know,
are
we
going
to
have
all
of
the
things
that
we're
using
now
plus
10x?
More
absolutely?
A
It-
and
I
think
kubernetes
has
done
a
lot
of
quote
democratization
and
a
lot
of
bringing
sometimes
opponents.
You
know
like
together.
Right,
like
you
know,
red
hat
and
microsoft
were
working
on
kubernetes,
we
weren't
always
best
of
friends.
You
know,
but
now
it's
all
good,
because
we
see
this
opportunity
to
work
together
right.
We
see
opportunities
across
the
industry
where
we
hadn't
before
kubernetes
came
along.
B
Was
these
little
islands
of
you
know,
walled
off
knowledge
and
you
went
from
company
to
company
and
you
had
to
relearn
everything
and
everything
yeah,
and
so
those
initial
communities
grew
by
you
know
controlling
it
all
controlling
the
whole
ecosystem,
but
now
we're
in
a
different
phase
right,
open
source
is
not
just
individual
contributors.
It's
people
trying
to
get
their
job
done.
It's
companies
who
exist
solely
to
offer
a
solution,
and
they
know
that
open
source
is
fundamental
to
their
story.
B
They
can't
avoid
having
something
open,
even
if
they
have
closed
elements
right
and
you
can't
succeed
in
open
source
day.
You
can't
succeed
at
programming
unless
you
can
figure
out
how
to
come
up
with
win-win
scenarios
and
like
this
is
the
open
source
was
kind
of
the
biggest
win-win
of
all,
which
I
take
stuff
and
you
can
use
it
huge
win-win.
B
The
next
hard
problem
was,
how
do
you
and
I
both
try
to
fight
to
get
value
out
of
what
we're
doing
you
know
the
startups
have
done
this
for
a
while
red
hat's
seen
this
you
know
come
and
go
all
the
cloud
providers
are
jumping
on
this.
We
love
open
source,
you
know,
and
the
reason
is,
is
because
everybody
who
works
with
those
companies
who's,
you
know,
come
up
in
the
last
30
or
40
years,
almost
certainly
uses
open
source
in
their
daily
lives.
B
So
it's
like
it's
changed
from
being
something
we're
not
fighting
to
get
open
source
accepted.
What
we're
trying
to
figure
out
is
how
all
of
us
work
together
in
a
win-win
fashion
versus
a
zero-sum
game.
Right,
like
I
win,
you
lose
that's
a
hard
problem,
but
that's
actually
the
important
problem
right
because
right,
I
can't
make
you
do
anything,
but
if
I
can
set
it
up
so
that
you
and
I
both
benefit
together,
we're
all
better.
A
B
And
understanding
what
someone's
looking
trying
to
achieve
you
know,
spending
spending.
Five
percent
of
your
brain
cycle
like
open
source,
is
about
spending
greater
than
zero
percent
of
your
brain
cycles,
figuring
out
how
what
you're
doing
as
a
person
is
useful
to
someone
else,
putting
yourself
in
their
shoes
and
trying
to
build
it,
and
I
think
that's
why
you
know
cuba
is
successful.
B
A
B
I
am
incredibly
privileged
to
have
been
working
on
openshift
in
the
kubernetes
community
in
the
container
ecosystem
and
the
linux
ecosystem
in
the
open
source
ecosystem
in
general.
I
want
to
thank
everybody
who
you
know,
contributes
uses
feeds
back,
thinks
about
other
people's
problems
and
takes
that
that
greater
than
zero
percent
thinking
about
how
you
can
help
move
all
of
this
forward,
because
none
of
this
would
be
possible
without
everyone
else.
A
Absolutely-
and
I
think
that's
the
best
way
for
us
to
end
this.
Thank
you
clayton
for
joining
us.
Thank
you.
Everyone
for
watching
please
tune
in
next
time,
which
is
a
couple
weeks
for
hank.
Hang
on
when
calendar
opens.
Nevermind
calendar
is
not
going
to
open
today,
okay,
fun!
Thank
you
calendar
for
being
so
helpful.
Joe
fitzgerald
is
the
next
person
coming
up
here
in
a
couple
weeks,
so
thank
you,
clayton!
Thank
you,
everyone
and
we'll
catch
you
next.