►
Description
OpenShift Commons: DevOps: The Triumph of the Commons - Andrew Clay Schafer (Red Hat)
Keynote LATAM OpenShift Commons Gathering
A
So
we're
going
to
replay
that
keynote
today
and
andrew
is
going
to
join
us
afterwards
for
some
live
q
a
and
we're
going
to
have
a
conversation
about
the
topic.
So,
if
you're
interested
in
this
we'll
put
the
the
link
to
this
landing
page
in
the
chat
everywhere,
you
might
be
up
whether
it's
on
facebook,
openshift,
youtube
channel
or
on
the
twitch
channel,
and
you
can
click
through
here
and
watch
all
of
the
talks
that
were
done
here,
especially
the
ones
in
spanish.
A
Some
great
customer
panels,
people
talking
about
how
they
did
things
down
in
adopting
digital
transformation
in
latin
america
and
some
great
spanish
versions
of
the
what's
new
and
open
shift
4.5.
So
I
encourage
you
to
to
take
a
look
and
jump
over
there
after
this
and
and
watch
some
of
these
talks
as
well,
and
it's
all
available
there's
this
minor
gatekeeping.
Now
you
have
to
log
in
because
it
was
an
event,
and
eventually
all
of
this
will
be
up
on
on
youtube
as
well.
A
So
without
any
further
ado,
I'm
going
to
ask
them
the
the
engineer,
chris
short
today
to
cue
up
the
the
video
and
I'm
going
to
stop
sharing
for
a
minute
and
watch
along
with
you.
You
can
chat
in
the
in
the
sidebars
wherever
you
are,
and
we'll
just
rock
and
roll
and
then
have
a
conversation
with
andrew
and
learn
a
little
bit
more
about
his
thinking
around
this
topic
of
devops
and
the
triumph
of
commons.
B
So
this
is
a
bit
about
devops.
It's
going
to
be.
I
talk
about
myself.
I
talk
about
my
role
in
in
devops
my
role
at
red
hat
and
then
kind
of
end
with
a
bit
of
comments
about
platforms
and
commons
and
kind
of
this
process
of
how
those
things
fit
together
in
a
in
a
devops
context
in
a
devops
narrative.
B
So,
as
I
said
a
little
bit
about
myself
first,
my
name
is
andrew
clay.
Schaefer
I've
been
involved
in
a
bunch
of
open
source
infrastructure
projects
over
the
last
going
on
over
a
decade.
Now-
and
you
know,
people
know
me
from
some
of
these
communities
and
doing
work
in
these
communities,
but
I
feel,
like
most
people
know
me
from
from
devops
and
devops
days,
and
I've
been
organizing
devops
days
since
the
beginning.
I'll
tell
you
a
little
bit
about
that.
I've
also
been
part
of
some
of
these
other
communities.
B
Like
velocity
conference,
I
think,
played
a
very
big
role
in
in
the
the
conversation
that
we
call
devops
and
the
the
writings
and
the
books
like
this
web
operations
book
that
I
contributed
to
is
stood
the
test
of
time.
In
my
opinion,
when
you
look
at
the
the
big
picture
here
about
devops
and
and
the
rest
of
the
stuff,
that
kind
of
make
more
sense
by
the
end
of
this
talk,
so
I'm
I'm
a
red
hat.
I've
been
at
red
hat
for
just
almost
a
year.
B
Now,
I'm
going
to
tell
you
a
little
bit
about
my
team
in
a
minute,
but
first
very
important.
This
is
my
twitter
handle
that's
going
to
come
back
a
few
times,
but
this
is
also
important.
This
is
my
personal
logo,
because
you
know
you
need
things
like
that.
I
also
want
you
to
realize
that
I
come
in
various
configurations
of
hair
and
beard
and
I
might
see
you
some
other
time
with
a
different
configuration.
So
don't
be
afraid
it's
the
same
same
person.
B
So
I'm
not
going
to
go
into
like
every
bit
of
everything.
All
of
us
did,
but
that's
just
a
little
bit
of
our
background
and
I've
been
working
on
and
associated
with
devops
globally,
since
since
2009
really
2000,
you
know,
since
it
was
a
word
and
I'm
going
to
tell
a
little
bit
of
that
story
and
then
we'll
kind
of
come
back
to
this
notion
of
devops
and
commons
and
openshift,
and
all
that
by
the
end,
so
buckle
up.
B
So
I
I
said
I
wouldn't
I
would
speak
english,
but
I
I
try
to
make
some
attempts
to
translate
a
little
bit
of
it
just
to
to
make
sense
of
it.
But
I
feel
like
these
are
the
most
important
devops
concepts.
People
can
learn
very
critical,
especially
the
last
one.
So
I
be,
I
believe
people
need
to
learn
how
to
read
very
important,
learn
how
to
write,
learn
how
to
speak
right.
B
So
you
know
this
is
a
theme,
hopefully
will
be
clear
by
the
end
that
you
know
in
some
sense,
devops
is
at
least
the
way
I
think
it
should
be.
Practices
is
about
this
communication
and
essentially
this
negotiation,
which
will
hopefully
be
more
clear
by
the
end
and
then
last
but
not
least,
but
also
critical.
B
B
You
know
a
bunch
of
a
bunch
of
interesting
work
getting
done
on
the
internet
so
with
that
being
said,
I
want
you
to
realize
that
the
good
devops
they
copy,
but
great
devops,
they
steal
and
I'm
going
to
steal
a
few
more
things
from
some
other
people
by
the
end
of
this
one
of
them
is
jade,
but
then
another
carnegie
mellon
phd,
that
is
his
friend
I'm
definitely
gonna,
take
imagine
so
this
is.
This
is
a
presentation
that
was
given.
B
These
are
slides,
taken
from
a
presentation
that
was
given
at
velocity
conference
in
2009,
and
this
was
10
deploys
per
day,
john
allspon
paul
hammond,
talking
about
the
the
devnops
cooperation
afflicker
and
at
the
time
this
was
considered
heresy
or
or
irresponsible
to
talk
about
10
deploys
per
day
in
in
2020
terms,
that's
passe.
In
fact
you
have.
B
You
know
organizations,
cloud
native
organizations
on
record
they're
deploying
every
second
of
the
day,
so
I
was
sitting
in
the
audience
and
I
was
watching
this
talk
and
I
started
tweeting
about
the
the
things
they
were
saying,
and
so
just
I'm
not
going
to
read
all
of
them.
But
I'll
read
this
one.
Just
don't
just
say
no,
you
aren't
respecting
other
people's
problems
and
I
hashtag
you
know
velocity
conference
devops
and
working
together,
and
that
was
the
kind.
B
B
But
there's
some
there's
some
history.
So
let's
talk
a
little
bit
about
what
surrounds
this
time.
So
this
is
I'll.
Just
read
this
as
well.
The
traditional
model
is
that
you
take
your
software
to
the
wall
that
separates
development
operations
and
throw
it
over
and
then
forget
about
it,
not
at
amazon.
You
build
it.
You
run
it.
This
brings
developers
into
contact
with
the
day-to-day
operation
of
their
software.
It
also
brings
them
into
day-to-day
contact
with
the
customer.
B
This
customer
feedback
loop
is
essential
for
improving
the
quality
of
the
service,
so
this
is
verner
vogels,
the
cto
of
amazon
in
a
in
a
pretty
famous
interview
from
2006..
So
this
is
three
years
before
devops
is
a
word,
but
this
sounds
a
lot
like
what
I
would
describe
as
a
devops
environment,
a
devops
approach
to
delivering
software
delivering
this
cloud,
and
in
fact
I
would
argue
this,
you
know.
Emergence
of
these
processes
at
places
like
amazon
is,
is
really
driven
by
that
that
innovation
to
deliver
those
things
at
scale.
B
B
B
So
imagine
the
the
tools
that
we
have
available
in
2020
and
you
should
be
able
to
get
that
curve
even
lower.
This
is
slide.
I
used
to
use
all
the
time
starting
right
around
2008
and
I
would
talk
about
you
know.
This
is
in
the
context
of
building
systems
with
with
the
tools
at
the
time
and
and
this
wall
of
confusion
between
developers
and
operators
and
how
you
could
use
the
automation
to
basically
be
an
interface
between
the
two
and
I'm
going
to
come
back
to
this
slide.
B
For
versions
of
this
slide
a
few
times
the
rest
of
the
talk,
but
the
this
is
2008
version.
You
have
a
wall
confusion.
The
only
real
communication
between
the
developers
and
operators
is
a
ticket
system
that
makes
these
people
unhappy
and
maybe
even
worse,
I
don't
know
if
you've
ever
worked
there,
but
this
is
how
it
ends
up
being
in
a
lot
of
places
and
2009.
As
I
mentioned,
this
is
a
book.
B
I
wrote
a
chapter
called
agile
operations,
it
was
written
in
2009,
but
I
still
think
that's
one
of
the
best
books
out
there
you'll
also
notice.
The
authors
on
the
title
are
john
also
and
jesse
robbins,
who
I
already
mentioned,
and
you
know
my
my
name's
inside
so
there's
this
kind
of
force
and
I'm
going
to
come
back
to
this
later
and
and
reframe
it
in
a
different
way.
B
B
So
this
is
me
and
patrick
meeting
perchance
in
an
airport,
taking
a
selfie
and
and
just
for
the
sake
of
having
a
funny
joke
about
it.
I'm
going
to
call
everything
2006
and
before
is
before
cloud
because
that's
the
year
ec2
was
launched
and
then
2009
is
after
devops.
So
who
knows
what
happens
in
the
three
years
in
between?
But
that's
what
we're
going
to
call
it.
So
what
is
devops?
Well,
I
I
don't
know
either,
but
I
think
it's
a
competitive
advantage.
B
I
know
it's
been
very
good
to
me
in
my
career
and
I
feel
like
the
results
that
we
can
get,
are
demonstrably
improved.
There's
actually
data
story,
but
to
me-
and
this
is
if
you've
ever,
if
you,
google,
my
name-
and
there
is
no
talent
shortage,
you
can
watch
a
talk
where
I
use
this
slide,
probably
15
times
to
to
talk
about
competitive
advantage
and
and
working
the
new
ways
of
working
as
a
competitive
advantage.
So
it's
definitely
a
competitive
advantage.
B
I
I
will
assure
you
that
at
the
time
this
is
what
it
felt
like
to
me
and
and
the
work
that
we
were
doing
to
do
this,
because
devops
is
not
always
easy
and
I'll
also
come
back
to
that.
So
this
is
legacy
andrew
in
2010
I
wrote
a
blog
post
which
still
exists
on
the
internet,
about
what
devops
means
to
me.
There's
a
group
of
us.
B
B
System
administration
is
evolving
to
look
more
and
more
like
software
development,
so
you're
talking
about
a
world
in
2010
where
you
know
ec2
is
established,
you
have
you
know
these
kind
of
tools
for
doing
things
with
apis
and
and
you
can
provision
systems,
configure
systems
monitor
systems
all
these
things
with
apis.
You
know
now
kubernetes,
and
you
know
some
of
the
stuff
you
can
do
with
operators
or
whatever
it's
even
more
and
more
software
development
or
more
like
software
development
to
administer
systems.
B
But
then
I
think
this
last
point
is
the
most
interesting
and
particularly
in
this
context
that
I'm
going
to
bring
up
over
and
over
about
a
commons.
It's
it's
a
it's,
this
global
community,
that's
evolving,
sharing,
sharing
the
solutions
right
and,
and
I'm
a
smart
person-
and
I
have
lots
more
friends,
but
the
fact
that
we
can
work
together
or
that
people
that
I
know
have
already
solved
problems
I'm
about
to
have
makes
us
all
go
faster,
makes
us
all
go
better
at
the
same
time.
B
This
is
right
after
the
very
very
first
devops
days
in
the
u.s.
There
was
this
blog
post
about
this.
It
kind
of
became
this
culture,
automation,
metrics
and
sharing
cams,
and
then
our
friend
jazz
added
lean
later,
and
I'm
going
to
talk
for
probably
the
next
15
minutes
or
so
like
what
these
mean
to
me
and
then,
like
I
said,
I'm
gonna
come
back
to
more
kind
of
commons
and
openshift,
focusing
so
for
the
next
10
15
minutes.
B
So
what
does
that
mean?
Was
that
what
does
that
mean?
I'm
supposed
to
do
right?
So
I
I
think
the
motive
for
me-
and
this
is
content-
I've
given
in
few
different
forms
a
few
different
times,
but
but
what
I'm
attempting
to
do
when
I
have
these
kind
of
conversations
is
help
make
people
see
what
they
can
actually
do,
what
they
can
take
action
on
instead
of
just
saying
the
word
culture,
I
think
culture's
a
little
bit
ambiguous.
B
If
vomiting
rainbows
isn't
working,
you
aren't
vomiting
enough,
rainbows
very
important,
so
culture
automation,
lean
metrics
and
sharing
going
forwards,
we'll
get
to
culture.
This
is
a
famous
quote:
culture
eats
strategy
for
breakfast,
so
this
is
a
american
management
consultant,
very
famous
peter
drucker.
I
still
don't
know
what
that
means.
I
think
this
is
interesting.
This
is
in
a
bunch
of
the
books.
B
So
if
you
read
like
the
devops
handbook
or
accelerate
there's
this
western
topology
of
culture
and
I'm
going
to
copy
this
format
for
the
for
the
others
as
well,
but
I
think
this
gives
us
a
nice
framing
to
think
about.
What's
better
and
what's
worse
right,
so
it's
not
just
about
culture,
it's
about
a
spectrum
of
possible
cultures
and
being
able
to
think
about
where
you're
at
and-
and
hopefully
we
can
agree
that
pathological
is
not
as
good
as
generative
right.
B
B
I
think
we
can
all
agree.
Hopefully
you
know
this
is
again.
This
is
in
these
books.
You
can
go
read
on
its
own
that
it's
better
to
work
in
a
culture
where
people
share
the
responsibility
they
share
the
inquiry.
They
actually
want
to
implement
novelty
right.
That's
that's
the
interesting
thing
when
you
get
to
the
bottom
line
in
in
all
these
organizations
where
they
say
they
want
innovation,
they
say
they
want
to
be.
You
know
able
to
create
these
new
things.
B
B
So
there's
lots
of
you
know
this
could
be
its
own
hour-long
talk
just
on
culture,
but
there's
there's
sort
of
these
high
level
things
that
we
talk
about,
and
one
of
the
things
that
I
always
talk
about
is.
If
you
show
me
how
your
org
chart
is
set
up,
and
you
show
me
how
your
funding
model
works,
then
I
can
predict
where
most
of
your
problems
are
going
to
be
so
thinking
about
how
everyone's
set
up
to
get
you
know
compensated,
think
you're
promoted.
B
All
of
these
things
are
really
what
determine
a
lot
of
these
behaviors.
So
you
can
be
just
deliberate
about
designing
your
organization,
as
you
are
about
your
technology,
so
moving
on
automation
and
I
also
add
architecture
and
I'm
not
going
to
go
deep
into
what
I
mean
by
architecture
today,
but
I
have
tons
of
other
thoughts
and
content
about
what
architecture
is
and
you'll
see
more
of
that,
hopefully
later
from
from
red
hat,
so
automate
all
the
things
this
used
to
be
me,
I
would
say
this:
you
know
I
had
puppet.
B
B
No,
that's,
not
automation.
That's
the
manual
process,
there's
there's
a
man
and
he
does
the
thing
and
then
it
makes
all
the
tools
do
things
so
it
starts
with
the
manual
process.
What
you
need
to
have
automation
is
this:
you
need
robots
to
do
everything
and
that's
still
not
a
good
architecture,
and
you
know
this
is
a.
This
is
an
object
lesson
and
it's
sort
of
meant
to
be
as
a
joke,
but
also
it's.
B
I
think
it's
true
is,
if
you
just
take
what
you
have
and
put
it
in
a
container
is
not
going
to
solve
all
your
problems.
So
if
you
just
take
this
automated
robot
architecture,
bad
architecture,
imperfect
architecture
and
just
decide,
okay,
we're
going
to
scale
by
putting
a
lot
of
these
things
in
my
favorite
container
scheduler,
then
you're
going
to
learn
this
lesson
the
hard
way
I'll
I'll
quote
a
famous
video
game
which
I
believe
made
it
to
most
of
the
world.
So
hopefully
this
actually
makes
sense
to
you.
B
So,
just
to
kind
of
copy
that
same
format.
What
I,
what
I
came
up
with
is
is
this
spectrum
of
you
know
the
kind
of
like
the
manual
maximizing
toil
way
to
do
this
work,
the
automation
to
the
platform,
so
in
the
in
the
bad
side,
you
know,
there's
there's
a
lot
of
toil,
there's
a
lot
of
human
work.
When
things
fail,
they
fail
catastrophically.
Everyone's
really
focused
on
trying
to
stop
the
incidents
we
keep
having
incidents
and
outages
as
you
get
a
bit
better.
B
You
know
you
put
effort
into
automation,
you
get
focus
on
disaster
recovery
and
reducing
the
mean
time
to
recovery
in
the
in
the
highest
performing
cloud
native
there's
a
platform.
You
know
we're
going
to
come
back
to
that
in.
In
the
end,
when
we
talk
about
the
recommending,
that's
you
know
got
a
directed
architecture,
it's
self-healing
and
at
certain
scale,
is
operating
with
continuous
partial
failure
and
and
there's
no
service
disruption
right.
So
you,
when
you
hear
about
things
like
chaos,
engineering
and
you're,
more
of
the
kind
of
high
performing
cloud
native
you.
B
You
know
that
you
can
have
these
failures.
Constantly
partial
failures,
with
no
service
disruption
to
the
to
the
customer.
Now
I'm
going
to
give
you
a
little
homework.
I
thought
you
didn't
know
you're
going
to
get
homework.
I
I
think
is
one
of
the
most
elegant
framings
of
a
of
a
thing,
and
I
got
even
new
language
I'm
going
to
introduce
by
the
end.
That
makes
it
even
more
interesting
to
me,
especially
this
notion
of
service
level
objectives,
but
I'm
going
to
ask
you
to
read
the
sre
book.
B
You
can
read
it
for
free
if
you,
google
srebook,
but
this
is
sort
of
google's
discussion
of
devops
and
these
three
chapters.
You
know,
there's
a
lot
of
practices
they're
specific
to
google,
but
a
lot
of
it
will
translate
straight
across
to
managing
you
know.
Whatever
your
favorite
container
platform
is
open
shift,
but
this
kind
of
notion
of
embracing
risk
service
level
objectives
and
eliminating
toil
is
just
solid
gold
like
gold
nuggets.
Everyone
should
read
that
this
is
devops
implemented.
Google,
it
really
checks
all
these
boxes.
B
Remember,
good
devops
copy
great
devops
deal
so
go
steal
that
now,
when
you
read
the
book
and
or
if
you're
familiar
with
kubernetes,
then
then
hopefully
you've
heard
a
board
and
if
you
haven't,
maybe
you
want
to
go,
read
this
paper.
So
this
is
a
quote
taken
from
the
the
google
borg
paper,
which
has
been
out
about
four
or
five
years
ago,
and
and
also
just
for
for
a
fun
fact.
I
remember
a
time
say:
2009.
B
If
you
said
the
word
borg
in
the
room
full
of
people
that
worked
at
google,
then
they
would.
They
would
stop
talking
to
you,
and
that
was
the
end
of
the
conversation
because
it
was
considered
a
secret.
Now
now
it's
very
different
and
you
know
they've
released
kubernetes
as
open
source
product,
but
at
the
time
this
was
their
secret
weapon.
B
So
this
is
from
the
sre
book
again,
I
love
the
sre
book.
This
is
the
service
reliability
hierarchy
sometimes
referred
to
as
dickerson's
hierarchy
and
and
you'll
notice.
That
monitoring
is,
is
the
foundational
of
the
pyramid.
It's
the
it's
the
it's
the
bottom
right!
You
can't!
You
can't
do
anything
if
you
didn't
measure
it,
you
don't
know
anything
you're
flying
blind.
If
your
systems,
don't
don't
tell
you
what
they're
doing
so,
this
is
again
straight
from
the
sre
book.
B
Without
monitoring,
you
have
no
way
to
tell
where
the
service
is
even
working,
absent
and
thoughtfully,
designed
wiring
infrastructure
you're
flying
blind.
Maybe
everyone
who
tries
to
use
the
website
gets
an
error.
Maybe
not,
but
you
want
to
be
aware
of
problems
before
your
users
and-
and
I
will
wager
again-
I
like
making
bets
that
a
lot
of
these
deployments
in
quote
unquote.
Production
are
relatively
unmonitored
unmonitored
by
the
kind
of
sre
standards
or
what
I
would
consider
the
high
performing
cloud
native
standards.
B
So
that
brings
us
to
service
level
objectives.
When
you
have
a
service
level
indicator
that
you
get
from
your
monitoring,
you
can
start
to
have
service
level
objectives.
This
is
going
to
come
back,
but
basically
a
service
level
objective
is:
is
a
three-way
contract
between
developers,
operators
in
the
business
that
is
negotiated
so
that
reliability
gets
a
class
consideration.
If
you
don't
meet
your
slo
budget
from
the
development
side,
then
you
repurpose
the
the
development
resources
towards
reliability,
and
I
ask
people
this
question
all
the
time.
What
are
your
objectives
and
a
lot
of
times?
B
I?
I
don't
think
people
have
good
answers
right.
So
it's
like
you
have
you
have
work
to
do
you
have
a
backlog,
you
have
you
have
things
that
you're
trying
to
do,
but
if
you
really
press
people
on
their
objectives,
it's
often
it's
often
an
organizational
struggle
to
to
clarify
them,
and
if
you
don't
know
what
they
are
or
even,
if
you
do
do,
you
know
why
they
are
right.
So
this
is
this.
Is
I'm
going
to
bring
y
back
in
in
another
slide
in
a
few
minutes?
B
But
why
are
you
even
trying
to
do
things?
What
is
it
what's
the
organization
that
you
work
for
do
and
then,
if
you
got
to
why,
how
do
you
know
you're
meeting
them?
So
if
you
don't
have
good
monitoring,
you
don't
have
good
metrics,
you
don't
have
measurements,
you
don't
have
a
way
to
analyze
that
and
think
about
it.
You
never
know
so
going
back
to
the
spectrum
on
one
side
you
have
things
that
are
unmonitored.
You
know
there's
very
little
info.
B
B
The
monitoring
is
built
in
as
part
of
the
architecture
and
development
process,
and
that
gives
you
much
more
insight.
Much
more
actionable
and
and
really
is
the
foundation
of
true
sli's
they'll
come
to
sharing
so
global
community
practice
already
mentioned
that
and
then
there's
this
notion
of
whoops
a
little
too
fast.
So
there's
this
wall
of
confusion
between
devin
ops,
which
I
already
told
you
once
but
now
there's
like
a
party
on
each
side
and-
and
this
is
a
common
pattern-
I
see
all
the
time.
B
You
know
people
get
excited
and
if
you
got
to
raise
congratulations,
but
I
don't
think
this
solves
the
problem
and
particularly
it
doesn't
solve
the
problem
of
creating
a
shared
understanding
or
a
commons
which
we're
going
to
I'm
going
to
come
back
to
that
again
a
few
times
so
the
this
is
not
you
know
the
worst
thing
you
can
do
you
can.
You
can
basically
make
progress
this
way,
but
this
is
not
the
best
thing
you
can
do
either.
B
So
I'm
going
to
talk
a
little
bit
about
why.
So
this
is
I'm
stealing
from
another
friend.
This
is
simon,
wardley's
stuff,
and
he
separates
the.
Why
of
purpose
from
the?
Why
of
movement
and
the?
Why
of
purpose
just
to
make
it
simple,
if
you
think
about
a
game
like
chess,
the
wire
purpose
is
to
win
right.
So
you
have
an
organization,
you
have
a
mission,
there's
some
game.
Your
organization
is
trying
to
win,
you
know
economic
or
what
have
you
and
then
there's
the?
B
Why
of
movement,
which
is
more
about
understanding
you
know
and
going
back
to
the
chess.
You
know
it's
one
thing
to
say
the
the
purpose
of
the
game,
the.
Why
of
the
game
is
to
win,
but
then
what
piece
should
you
move
and
and
why
should
you
move
it
has
much
more
depth
and
and
all
these
other
kind
of
factors
about
it
and
that's
what
separates
the
the
best
players
in
the
world
from
you
know
the
the
not
as
great
players,
so
understanding
that
you
want
to
win.
Everyone
wants
to
win
everyone
has
that
why?
B
But
why
of
movement
and
understanding
like
real
strategy
and
depth,
is
where
you
you
kind
of
get
the
greatest
advantage.
So
this
is
just
an
imaginary
arc
chart
and
there's
all
these
people
and
I'm
going
to
argue
each
one
of
them
has
a
different.
Why
so
you
have
you
know
all
these
different
levels
and
each
one
of
them
has
a
family
and
each
one
of
them
has
hobbies
each
one
of
them.
You
know
there's
some
combination
of
the
incentives
that
they
get
paid
for
and
then
other
things
that
they're
they're
valued
right.
B
So
you
know
as
a
as
a
developer,
I
like
to
create
code.
I
like
to
express
ideas
as
a
sysadmin,
I
like
to
keep
things
in
a
certain
way
and
every
one
of
us
has
sort
of
this
notion
of
what
the
the.
Why
is
for
our
own
personal
thing
and
then
the
why,
for
our
our
skills
for
our
particular
job,
but
the
more
we
can
connect
that.
Why
share
that?
B
Why,
with
the
with
the,
why
of
purpose
for
the
whole
organization,
the
better
off
we're
going
to
be,
and
then
we
want
to
connect
each
of
our
different?
What's
what
we
actually
do
with
our
y's,
to
that
big
y
and
and
then,
if
you
think
about
these
as
communities,
each
of
these
has
a
communal
nature
right,
so
that
developers
have
some
notion
of
what
the
best
way
to
do
things
there
are.
The
operators
have
a
different
idea
of
what
the
best
thing
to
do
things
are.
B
You
know
the
business
has
their
own
ideas,
and
so
each
one
of
them
have
what
I'll
call
a
different.
Why
of
movement?
They
have
a
different
view
of
the
chess
board.
They
have
a
different
understanding
of
what
the
pieces
are
for
and
they're
thinking
about.
All
those
things
in
a
way
where,
if
they're
optimizing
for
for
themselves
for
their
own
understanding,
it
might
be
best
for
them,
but
it's
not
going
to
necessarily
be
best
for
the
project
for
the
for
the
company
and
so
the
game.
B
B
Now
when
it
when
I
made
this
slide,
I
didn't
have
this
language
that
I'm
going
to
introduce
by
the
end
of
this
around
recommending.
But
you
know
remember
this
word
recommending
you
know
this
is
the
openshift
commons,
and
so
commons
is
the
thing
we're
going
to
say
over
and
over,
but
the
the
notion
of
recommending
is
really
that
what
this
process
is
about.
You're
connecting
these
these
groups,
together
with
their
own
selfish
interests,
they
each
have
their
own
selfish
interests
and
you're,
trying
to
connect
them
together
for
the
collective
interest.
B
I
feel
like
people
cultivate
the
information
and
share
it
in
a
way
that
helps
their
their
colleagues,
make
the
best
possible
decisions,
and
then
this
is
also
in
I
mean
from
a
red
hat
kind
of
perspective
and
from
the
open
shift
commons
perspective.
I
think
it's
interesting
the
thing
about
the
global
community
and
how
we
can
both
contribute
to
and
take
advantage
of,
the
the
global
communities
of
practice
so
moving
on.
B
Last
but
not
least,
we'll
add
in
lean,
and
if
you
really
study
lean,
if
you
really
study
lean,
manufacturing
and
kind
of
the
lich
or
going
back,
you
know
50
years
now,
it
really
has
a
lot
of
these
factors.
You
know
all
these
kind
of
notions
of
sharing,
but
the
thing
that
I
think
the
ads
that's
interesting
here
is
this
notion
of
kaizen
or
continuous
improvement.
So
what
we're
doing
today,
we
can
always
do
better
tomorrow
and
that
we
shouldn't
we
shouldn't
be
complacent.
B
You
know,
so
all
these
other
things
are
great
on
their
own
and
we
want
to
improve
them,
but
we
always
we
always
want
to
improve.
There's,
no
there's
no
done
so
just
to
keep
with
the
same
motif,
we'll
keep
the
three
columns,
and
this
one
will
be
simple.
We'll,
hopefully,
can
agree
that
complacent
is
not
as
great
as
inspired
so
in
the
middle
you're
motivated,
but
I
feel
like
the
highest
performing
team
is
actually
inspired
by
their
mission.
B
Also,
I
think
that
calms
with
lean
sounds
a
lot
better
than
cam,
so
I'll
make
a
shrub.
So
this
is
this
kind
of
pentagram
or
like
five
five
things
of
devops
that
I've
been
talking
about.
Other
people
have
been
talking
about.
This
is
the
same
same
basic
ideas
of
the
spectrum,
but
I
put
them
all
on
one,
so
you
can
kind
of
see
them
all
one.
B
The
easy
thing:
if
the
right
thing
is
hard
thing,
then
people
won't
do
it.
You
need
feedback
loops
in
a
way
that
makes
you
like
we.
We
have
a
hard
time,
reasoning
about
things
that
are
separated
in
time,
so
the
faster
we
can
get
the
information
back
to
the
people
who
can
actually
make
changes
the
better
make
the
actors
accountable
if
there's
a
a
long
loop
in
time,
but
also
there's,
there's
no
real,
there's
no
real
consequence
for
the
people
who
take
the
action.
Then
that's
not
going
to
matter
leverage
the
community.
B
That's
the
community
inside
your
organization
also
they
can
be
outside
and
then
connect
everything
to
y.
So
this
is
kind
of
devops
in
a
in
a
box.
You
know
super
super
compact.
We've
been
saying
all
this
stuff
for
10
years,
though
right.
So
this
is
not
a
new
conversation
been
saying
the
same
stuff
over
and
over
people
kind
of
listen,
but
also
it's
hard,
but
there's
also
data
right.
So
we
have
the
data
the
data
is
in
and
this
data
shows
that
there
are
teams
are
performing
higher.
This
is
the
state
of
devops
report.
B
It's
unclear
exactly
how
this
will
evolve
and
there's
some
other
stuff
that
will
probably
come
out
of
google
and-
and
I
know,
there's
other
research
going
on,
but
the
the
last
six
seven
years
of
the
state
of
devos
reports,
starting
with
puppet
and
then
and
then
dora
show
that
there
there
is
this
meaningful
difference
and
it
is
evolving
and
and
it's
evolving
in
a
way
where
the
the
high
performers
are
are
even
separating
faster
and
faster
from
from
the
low
report.
Performers.
B
Also,
the
the
the
data
shows
that
the
faster
is
also
safer.
So
you
get
a
lot
of
excuses
in
organizations,
especially
when
they
have
governance,
risk
and
compliance
concerns
that,
oh,
if
we,
if
we
go
faster,
it
will
somehow
be
unsafe
and
we'll
compromise
all
these
things.
The
data
shows
that's
not
necessarily
true,
and
that
faster
tends
to
be
safer,
that
you
you're
both
having
less
incidents
and
that
you
recover
from
your
incidents
faster.
Your
failure,
rate's,
lower
and
you're
recovering
faster.
B
So
this
is
this:
is
this
kind
of
notion
of
software
and
and
software's
eating
the
world
right?
So
people
say
that
it's
a
cliche,
but
I
personally
see
this
and
I
believe,
every
aspect
of
human
performance
and
experience
that
can
be
optimized
with
software
will
be
like
we
feel
this
and
we
we
have
this
experience
in
our
in
our
individual
lives.
You
know
we
have
the
cell
phones
in
our
pockets.
B
We
have
data
that
connects
us
to
everything
that
anyone
knows
about
anything
on
the
internet
and
all
these
kind
of
things
with
with
transportation
and
food
and
the
rest
of
it,
and
and
that's
that's
everywhere
in
the
world.
Now
that
that's
not
just
you
know
in
some
ways,
I'd
say
that
the
the
us
is
behind
in
ways
compared
to
other
places,
but
the
I
I
don't
know
where
you
live,
but
I
I'm
pretty
sure
that
if
you're
watching
this,
you
have
the
internet
right.
B
So
there's
there's
a
lot
of
these
things
that
are
happening
right
before
our
eyes
and
we're
experiencing
in
our
lives.
So
software
is
people
is
made
by
people
for
people.
It's
not
a
thing
without
people,
and
this
is
my
andrews
definition
of
devops,
so
devops,
going
back
to
this
theme.
Software's
in
the
world
is
optimizing
human
performance
and
experience
operating
software
with
software
and
with
humans.
B
So
there's
this
language
I'm
about
to
introduce
as
we
go
into
this
kind
of
notion
of
the
commons
around
and
and
how
humans
sort
of
work
together
is
key
to
it.
So,
just
to
reiterate,
devops
is
simple,
but
it's
not
always
easy,
and
at
least
for
me,
it
often
felt
like
this.
Even
when
people
were
talking
about
how
fun
and
awesome
it
was
so
the
thing
that
makes
devops
hard
and
we
talked
a
bit
about
communities
and
connecting
communities
of
practice
and
wise
a
minute
ago.
B
B
So
coming
back
to
this
notion
of
the
wall
of
confusion
and
what
what
this
actually
represents
in
my
mind-
and
this
is
language
I'm
getting
now-
I
didn't-
I
didn't
have
this
10
years
ago
and-
and
you
know
I'll
thank
jade
for
some
of
this,
but
jabe
has
this
work
in
his
phd.
So
a
lot
of
what
I'm
about
to
show
is
really
to
jay's
phd
and
one
of
his
colleagues
at
carnegie
mellon's
phd
dementia.
B
So
there's
this
notion
of
two
economies
and
I'm
going
to
introduce
the
third
economy
in
a
minute,
but
it's
basically
differentiation
and
scale,
and
just
to
simplify
that
and
have
the
conversation.
The
scale
economy
is
really
focused
on
winning.
This
game
of
operational
excellence
and
kind
of
removing
variation
and
getting
efficiency,
while
the
the
differentiation
economy
is
trying
to
accelerate
the
change
and
the
creation
of
value,
and
so
these
are
really
two
different
games,
they're
being
played
and
they
have
two
different
rules
and
two
different
payoffs.
B
So
a
lot
of
what
we'll
we'll
see
here,
you
know
we
can
kind
of
go
through
each
of
these
again.
This
could
be
its
own.
You
know
hour-long
discussion
about
what
what
these
rules
are
and
how
they're
different,
but
just
to
kind
of
keep
it
simple
and
keep
moving
on
one
side:
you're
trying
to
re,
remove
inefficiencies
and
drive
down
costs
on
the
other
side,
you're
trying
to
create
new
things
and
create
new
value,
and
so
this
wall
of
confusion.
B
This
this
this
difference
or
this
kind
of
conflict
between
developers
and
operators,
is
really
that
they
don't
understand
the
other
game
right.
They
don't
have
the
the
language;
they
don't
have
the
the
incentive
they're
not
playing
that
game,
they're
playing
a
different
game,
so
they
don't
understand
the
game
and
in
some
organizations,
particularly
as
organizations
get
larger,
they
don't
understand
that
the
game
can
only
be
one
either.
Game
can
really
only
be
one
together,
so
it's
like.
If
you
got
everything
efficient
but
you're,
not
creating
value,
then
you
didn't
really
win
either,
or
vice
versa.
B
So
this
notion
of
a
third
economy.
This
is
really
from
jabe's
phd
work
as
well,
and-
and
I'm
going
to
give
you
some
examples
of
what
it
means,
not
just
the
academic
setting.
So
there's
this
notion
of
a
third
economy
in
between
and
I'll
tell
you
a
little
bit
about
that.
So
what's
this
third
economy,
this
is
this.
This
thing
that
connects
the
scale
economy
to
the
differentiation
economy.
B
It
acts
as
a
as
a
clutch
as
a
transfer
between
the
two
that
gives
you
a
way
to
keep
promises
about
efficiency
to
the
scale
economy,
while
enabling
differentiation
in
the
differentiation
economy
so
moving
on
the
scope
economy,
acts
to
connect
the
scale
and
differentiation,
and
how
does
this
scope
economy
come
to
be
well?
What
happens
in
organizations
and-
and
you
know
I
I'll
argue-
that
every
devops
project
ever
that
was
successful,
went
through
this
process.
B
That
would
probably
be
better
managed
as
part
of
this
platform,
and
so
this
this
process
of
of
building
a
common
shared
platform
is
language
that
we'll
call
recombinant
and
I'm
going
to
steal
this
from
the
magic.
So
I
told
you
the
great
dev
of
steel,
so
this
is.
This
is
language
from
dimension.
This
is
from
his
phd
work.
Platforms
may
be
understood
more
conceptually
as
guiding
principles
that
redefine
two
sides
of
a
binary
relationship
that
reveal
the
mass
middle
as
an
opportunity
for
intervention
platforms
can
help
us
recommend
resource
management
through
new
approaches
to
negotiation.
B
So
this
is
the
meiji's
language
he
uses
the
word
platform
over
and
over
in
his
dissertation.
He
is
not
talking
about
technology
at
all.
In
fact,
if
you
go
look
at
his
dissertation,
which
I've
stolen
from
here,
then
you'll
see
that
the
model
that
he's
describing
in
some
of
his
research
is
is
really
like.
It's
it's
built
on
these
narratives
from
kind
of
nigerian
villagers,
building
a
or
kind
of
building
a
platform.
That's
what
that's
the
language
he
uses
so
that
they
don't
over,
exploit
these
shared
resources
right.
B
Like
it
deserves
to
be
its
own,
probably
two
hour
talk
on
on
recommending,
but
this
notion
of
the
platform
owners
that
are
steward
stewarding
and
exploiting
common
commoners.
So
it's
basically
like
some
tension
between
the
stewarding
commoners
are
the
ones
who
are
are
more
protective,
essentially
of
the
of
the
common
resource,
while
the
exploiting
commoners
they
they
are
using
the
resource,
maybe
a
little
more
than
the
stewarding
or
like
their
concern
for
the
collective
might
be
slightly
less.
You
could
say
anyway
this.
B
In
the
most
successful
organizations
was
really
about
bringing
together
those
different
personas
from
developers
and
operators
and
and
making
those
clear
dilemmas,
those
those
clear
conflicts
between
their
eat,
their
selfish
interests
on
both
sides
and
resolving
them
in
in
favor
of
the
collective
interest,
so
that
everyone
can
kind
of
win
for
themselves.
So
the
scope
economy
frames
a
negotiation
between
the
selfish
and
collective
interest
to
manage
shared
resources,
so
this
is.
This
is
devops
like
in
a
core
thing,
so
commons
these
are
shared
resource,
managed
for
individual
and
collective
benefit.
B
This
is
the
open,
openshift
commons,
so
hopefully
that's
somewhat
familiar
to
you
and-
and
it's
also
used
as
the
practice
this
this
social
practice
of
self-governing
shared
resources
by
a
community
through
the
institution
of
the
creator.
So
both
of
these
are
used
as
commons
and-
and
I
think
that
this
is
an
interesting-
you
know,
example
of
the
community
that
you're
participating
in.
We
also
have
good
examples
from
industry.
So
I'm
going
to
read
this
one
remove
friction
between
remove
friction
from
product
development,
high
trust,
low
process,
no
handoff
between
teams.
B
Don't
do
your
own
undifferentiated
heavy
lifting
use,
simple
patterns
automated
by
tooling
self-service
cloud
makes
impossible
things
instant.
This
is
not
from
my
presentation.
This
is
actually
another
thing
I
stole
from
my
good
friend
adrian
colcroft
when
he
was
at
netflix.
So
this
is
a
from
an
old
talk
he
gave
he
could
find
online
called
netflix
lessons
learned
he.
B
He
has
some
other
points,
but
I
pulled
these
ones
out
just
to
make
this
point
that
this
is
essentially
them
describing
how
they
built
this
shared
platform
and
kept
these
promises
between
the
differentiation
and
the
operational
considerations,
and
I'm
going
to
argue
every
single
one
of
these
cloud
native
companies
built
a
shared
platform
essentially
with
this
recommending
process.
So
they
did
this
because
they
had
to
there
wasn't
a
there.
Wasn't
a
kubernetes,
there
wasn't
openshift,
they
could
take
advantage
of
sre
built
framework
modules
to
implement
canonical
solutions
for
the
concern
production
area.
B
As
a
result,
development
teams
can
focus
on
the
business
logic
because
the
framework
already
takes
care
of
correct
infrastructure
use.
This
is
another
copy
straight
out
of
the
sre
book
and
I
believe
this
is
google
self-described
narrative
for
commenting
the
google
platform
in
the
sre
book.
The
borg
is
a
scope
economy
construct
this
shared
resource
management.
Kubernetes
is
a
scope
economy
construct
as
well.
B
B
I
also
will
argue
that
slo,
you
know
now
that
I
have
this
language
and
slo
is,
is
a
recommending
negotiation
between
developers
and
operators
to
manage
a
a
shared
collective
interest
in
favor
of
their
selfish
interests,
and
so
these
three
economic
rules
that
we
have.
We
have
you
win
differentiation
by
creating
novelty,
you
win
the
scope
economy
by
creating
more
and
more
sharing,
and
you
win
the
scale
economy
by
creating
more
efficiency,
so
the
perfect
world
is
you
have
this
platform
in
the
middle
that
keeps
promises
to
both
sides?
B
You
have
enabling
constraints
with
self-service
access
that
keeps
promises
to
the
reliable,
compute,
networking,
storage,
primitives
and
the
scale
economy,
while
enabling
value
creation
in
the
differentiation
economy.
So
this
is
platform
as
an
interface
that
allows
this
recommending
process
or
facilitates.
You
still
have
to
do
the
work
as
humans
for
your
specific
organization
to
get
to
you
know
understanding
of
what
needs
to
be
available.
What
needs
to
be
self-service?
B
What
promises
can
you
keep
to
both
sides,
but
this
process
of
recommending
bringing
everyone
together
focusing
on
building
that
platform
together
is
what
allows
you
to
get
to
the
point
where
you're
you're
able
to
win
both
games.
So
the
developers
have
the
the
novelty
and
innovation
and
the
operators
have
the
efficiency
so
coming
to
the
end
and
we'll
call
it
a
day.
B
I
want
you
to
kind
of
have
these
these
things
as
I
go
and
I'll
give
you
a
call
to
actions
so
realize
and
think
about
is
that
the
new
behaviors
are
more
important
than
the
new
words
right.
So
a
lot
of
times
you
see
people
who
collect
all
the
buzzwords,
but
they
don't
really
change
their
behavior.
So,
let's
change
our
behaviors.
The
principles
are
more
important
than
the
practices
are
more
important
than
the
tools
you
know.
B
Obviously,
we
like
certain
tools,
we
like
certain
practices,
but
if
you
understand
the
principles
and
the
practices
and
the
tools
will
take
care
of
themselves,
your
mindset
is
more
important.
Your
skill
set
is
more
important.
Your
tool
set
adapting
is
more
important
than
adopting
so
think
about
what
you're
trying
to
do.
Connect
to
a
y
connect
to
a
larger
y
in
your
organization
and,
like
I
said
more
and
more,
why
is
more
important
than
what
what
you
do
is
not
as
critical
as
why
you
do
it.
B
If
you
understand
why,
then,
what
will
follow
if
you
only
understand
what
you're
kind
of
you're
kind
of
trapped
right?
So,
if
you
think
about
in
a
technical
sense,
you
know
technical
debt
sends
code.
If
you
only,
if
you
only
understand
what,
then
you
can
only
reproduce
what
it
is
right,
that's
why
you
lift
and
shift
if
you
understand
why
you
have
so
much
more
flexibility
to
reimagine
the
mission,
the
architecture,
all
the
technology.
B
B
B
So
this
is,
this:
is
red
hat?
I'm
I'm
glad
you
took
this
time,
hopefully
kept
you
interested
and
got
you
some
new
thinking.
I
know.
Sometimes
I
probably
talk
fast
and-
and
I
have
funny
language,
but
if
you,
if
you
want
to
reach
out
to
me
on
twitter
or
linkedin,
I'm
happy
to
continue
the
conversation
and
explain
anything
that
did
didn't
make
sense.
B
So
I
feel,
like
red
hat,
has
a
very
special
place
and
very
special
mission
right
now
to
connect
communities
and
bring
the
best
practices
and
the
best
projects
together
to
to
you
know,
build
the
future.
So
with
that
I'll.
Thank
you
for
your
time
and
I
look
forward
to
hopefully,
one
day
being
in
the
same
room
with
you
and
maybe
speaking,
a
little
bit
more
spanish,
gracias,
adios.
A
The
with
the
blue
jeans,
and
so
if
andrew,
if
you
want
to
turn
on
your
video,
that
would
be
great
and
we'll
continue
the
conversation
with
the
blue
jeans,
and
so,
if
andrew,
if
you
want
to
turn
on
your
video,
that
would
be
great
and
well
all
right
and
we're
back
here
and
we
can.
You
can
stop
sharing
your
screen
chris
and
and
we'll
try
and
get
everything
synced
up
here
and
we're
all
watching
your
twitter
feed.
A
A
B
It
is
like
open
up
to
this
other
stuff,
like
the
the
other
other
like
framings
of
commons,
and
you
know,
ostrom's
work
on
the
like.
I
mean
she
won
a
nobel
prize
for
for
being
able
to
kind
of
like
frame
some
of
the
stuff
in
a
different
way,
and
and
so
that
that
was
interesting
to
me
and
then
I
kind
of
like,
like
I
think,
one
of
my
jobs
right
now
is
like
take
the
things
that
that
jab
has
like
academic
framing
for
and
translate
them
into
speech.
B
So
if
you
look
at
dimensions,
work
deeper,
then
in
some
sense
like
I
don't
think
it's
fair
to
say.
Oh,
it's
not
a
real
commons
like
there's
like
not
a
commons
definition,
it's
a
spectrum
of
commons
and
and
and
then
there's
there's
all
these
different
roles
and
every
role
has
a
different
relationship
to
the
shared
resource
in
terms
of
the
things
they
can
contribute
and
the
things
they
can
consume
and
the
things
like
there's,
no
there's
no
like
it's
strict
definition
of
commons
and
that's
one
of
the
things
that
makes
it
interesting.
A
A
It's
like
this
multi-dimensional
chess
game
that
we're
playing
too,
but
there's
also
another
thing
that's
happening
beyond.
I
think
even
devops
is
and
you're
seeing
the
cross-community
collaboration
across
all
these
multiple
communities
and
trying
to
create
a
collective
under
things
like
this,
the
ncf
or
whatever,
where
we
all
are
engaged
and
have
a
common
language
and
theoretically,
a
common
governance
model
to
work
together
and
sync
up
all
the
the
features
and
functions
and
all
of
the
projects
that
are
interdependent.
A
That
becomes
you
know
mind-boggling
and
then
there's
a
changing
thing
too
that
we're
just
starting
to
see.
You
know
I
someone
said
it
at
the
cncf
keynote,
this
virtuous
end
user
cycle,
where
the
end
where
in
the
past
it
would
have
been
like
red
hat,
contributing
to
a
project
on
behalf
of
a
customer.
A
You
know
companies
like
amadeus
or
surpr
or
other
folks
that
are
right
in
there
with
us,
contributing
in
the
upstream
and
so
defining
the
roles
and
personas
has
is
changing
a
lot
as
well
and
having
the
common
language
is
really
and
the
guidance
around
how
to
how
these
things
work
together
for
the
benefit
of
all
is
really
changing.
So
it's
it's
a
conversation
we
have
to
just
keep.
Having
and.
A
Yeah,
so
I
think
that
the
goal
for
the
openshift
commons
was
and
was
to
change
the
community
model,
so
community
models
for
open
source,
we're
always
like
focused
razor
sharp
on
getting
people
to
contribute
to
your
project
right.
So,
like
I'm
working
on
linker
d
or
cd
and
I'm
as
a
community
development
person,
I
want
people
to
come
and
work
there,
but
really
for
openshift
commons.
B
B
So
there's
like
the
the
larger
collective
that
is,
you
know
the
cncs
and
all
the
these
projects
and
the
contribution-
and
you
know,
there's
vendors
and
then
and
then
there's
what
actually
has
to
happen
for
an
organization
to
take
advantage
of
that
platform
or
or
what
or
what
that
platform
enables
you
to
build.
You
know
which
is
essentially
your
own
platform,
and
so
this
is
the
thing
I
like
about
the
recommending
language
is.
B
Is
it
puts
a
little
bit
more
or
I
hope
it
does
responsibility
onto
the
personas
in
an
organization
to
recognize
their
participation
and
the
co-creation
of
that
outcome?
And
then
you
know,
even
if
you
get
into
the
into
like
the
the
middle
of
it,
there's
no
one
vendor,
especially
when,
when
people
are
doing
things
in
their
own
data
center
right
like
they
can
actually
provide
all
these
pieces
right
now,
yep
right.
So
so
you
need
like
what
are
you
going
to
do
for
your
databases?
What
are
you
going
to
do
for
your
cache?
B
Your
queue,
your
you
know
all
these
things
that
you
need
to
make
the
developers
productive,
but
also
keep
promises
to
the
to
the
operations
and
the
efficiency,
all
those
things
kind
of
come
together
in
that
in
that
central
commons,
where
everyone
has
their
own
selfish
interests
about.
You
know
I
want
to
be
able
to
use
these
databases.
I
want
to
be
able
to
do
this
thing.
This
way,
self-service
whatever,
but
also
on
the
other
side.
I
don't.
I
don't
want
to
be.
B
You
know
on
on
a
page
or
at
3am,
and
I
want
to
be
able
to
keep
like
some
understanding
of
what
we're
actually
responsible
for,
and
I
think
that
kubernetes
as
a
framing
is
like
doing
a
very,
very
interesting
job
of
evolving.
Not
only
those
conversations
but
those
possibilities
inside
of
a
bunch
of
organizations.
A
Yeah,
no,
I
think
it's
it's
and
it's
an
interesting
time
to
be
in
open
source.
It's
also
an
inter
a
very
interesting
time
to
be
inside
of
tech,
for
lots
of
reasons
and
james
just
popped
in
so
I'm
just
mute
on
mute
and
I
know
chris
short
who's.
Our
our
producers
is
in
the
background
and
I'm
just
we're
running
well
over
our
allotted
time,
but
I
don't
know:
if
that's
a
problem,
is
it
chris?
We
have
no
sound
from
you
and
you're
smiling.
A
B
A
Like
is
he
gonna
show
up
for
this
conversation?
If
he's
got
that
many
meetings
going
on
meetings
about
meetings
and
nothing
gets
done
so,
but
I
also
think
if
jay,
if
you
can
unmute
yourself
and
join
in,
I'm,
not
sure
if
you're
having
let
me,
let
me
see
if
I
can
get
it
to
work
and
there's
a
beautiful
child.
Hey.
A
I
think
some
of
the
sound
is
is
kind
of
a
little
bit
wonky,
but
I
can
hear
myself.
I
can
hear
little
idea,
and
I
also
think
that
one
of
the
one
of
the
things
that's
really
interesting
about
this
time-
that
we're
in
right
now
is
the
implications
for
leveraging
recommending
outside
of
tech
and,
if
you're,
if.
A
Yeah
we're
in
hyperspace
mode-
I
don't
know,
maybe
in
star
trek
or
somewhere
there's
a
you
know,
a
super
multi-dimensional
chess
game,
but
it
feels
feels
a
lot
like
that.
These
days
is
that
we
have
and
being
able
to
frame
it
and
and
if
we
think
about
like
demages
cards,
which
always
reminds
me
of
cards
against
humanity.
B
A
B
One
of
the
things
you
just
said
remind
me
of
a
total
like
non-sequitur
aside,
but
I
think
it's
interesting
one
of
my
friends
who's
doing
like
this
kind
of
quantum
stuff
and
and
he
has
to
work
at
google
right
now.
But
he
made
this
quantum
chess
game
and
he's
he's
trying
to
get
us
to
like,
like
do
like
a
fun
kind
of,
like
sponsored
quantum
chess
event
around
some
quantum.
So.
A
Quantum
chess,
a
wonderful
speaker,
holly,
I
think,
holly
cummins-
is
her
names
on
quantum
that
who's
an
ibm
like
their.
You
know
one
of
their.
Their
leads
for
that
and
I'm
gonna
have
her
on
stage,
probably
at
the
the
day,
zero
commons
at
kubecon,
north
america
or
in
the
fall
or
someplace
soon,
and
we
could
get
her
to
come
in
as
that
as
that
role
over
there.
So.
A
B
How
it
all
played
he
he
wanted
to
attach
it
to
what
is
already
a
quantum
conference
like
they'll,
be
they're
going
to
do
this
virtual.
So
it's
so
those
that's
another
commons,
essentially
right.
So
it's
like
coming
together
to
like
you,
know,
talk
about
and
share
a
certain
research,
but
then
also
have
this
like
fun
little
distraction.
Basically,.
A
Yeah,
no,
it's
interesting
the
whole
the
whole
goal
for
commons
and
the
commons
gatherings
and
the
briefings
is
really
to
to
create
spaces
for
people
to
have
these
conversations
and
to
to
share
these
ideas.
So
you
know-
and
it's
not
really
to
be
a
propaganda
machine
for
any
one
project
or
any
one
product
or
philosophy
it's
and
and
these
thurs
these
thursdays
we're
not
on
thursday
we're
on
fridays,
these
transformation
fridays
conversations
probably
are
my
my
favorite
conversations
and
talks
for
the
whole
week.
A
A
Underneath
it,
let
me
just
tell
you
they
were
not
thrilled,
but
they
they
had
some
help
and
I
think
I
think
we
got
most
of
them,
but
I'm
not
sure
how
they
translate.
I'm
gonna
have
to
go
back
the
puking
panda
slide.
I
have
to
go
back
and
see
if
it
looked
to
me
like
they
didn't
quite
say,
puke
or
something
along
that
lines,
but
they
got.
A
Yeah
and
all
of
that
content,
and
if
you're
listening
to
this
and
you're
looking
for
spanish
language
content,
we
we
have
a
whole
playlist
that
I'll
add
to
the
end
of
the
video
here
for
the
from
the
latam
group
and
if
you're,
looking
for
more
transformation,
friday
stuff,
we
have
a
whole
playlist
of
that
and
the
calendar
full
chock
full
of
really
great
speakers
coming
up.
Michael
ducey
is
on
next
week
and
he's
he
just
did
some
awesome.
Talking
about.
A
And
so
there's
there's
a
lot
of
good
folks
coming
on
and
the
more
we
can
get
this
language
out
there
and
have
the
conversations
with
us
with
a
common
language
to
talk
about
the
more
effective
I
think
we'll
all
be
doing
being
to
make
these
changes
happen
in
the
world
of
tech
and
the
world
out
loud
at
large.
So
thank
you
again
for
taking
the
time
and
much
appreciated,
and
will
I
love
your
background.
I
know
it's
virtual.
A
What
city
is
that
behind
you
supposedly,
I
believe
it's
new
york
that
looks
like
a
new
york,
one
yeah
you
can
see.
This
is
my
kitchen,
so
I
haven't
set
up
a
green
screen
or
anything
else,
but
I'm
getting
there.
So
thanks
again
and
we'll
have
you
on
soon
and
I'm
going
to
hit
you
up
for
a
talk
for
the
kubecon
north
america,
one
as
well,
so
stay
tuned
and
we'll
go
further
with
this.