►
From YouTube: RED HAT OSG ASC Nueva VersioĢn
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Time,
I'm
going
to
pretend
I'm
looking
out
at
your
smiling
faces
and
hearing
your
laughter,
but
I
hope
everyone's
in
a
in
a
safe
place,
watching
this
and
in
a
good
in
a
good
space
to
learn
a
few
things
and
maybe
think
a
few,
a
few
new
thoughts.
So
this
is
a
a
bit
about
devops.
It's
going
to
be
a
talk
about
myself.
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.
B
I've
also
been
part
of
some
of
these
other
communities,
like
velocity
conference.
A
Like
this
web
operations
book
that
I
contributed
to
is
stood
the
test
of
time.
In
my.
B
Opinion
when
you
look
at
the
the
big
picture
here
about
devops
and
and
the
rest
of
the
stuff
would
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.
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.
B
So
this
is
my
team
at
red
hat
right
now
and-
and
these
are
people
that
I
really
have
a
lot
of
fun
with-
and
I
learned
a
lot
from
and
maybe
you've
learned
some
things
from
them
as
well.
Maybe
you've
heard
of
some
of
these
books
that
they
were
contributors
to
so
the
the
co-authors
of
the
devops
handbook
and
the
phoenix
project
are
my
team
and
then
I'm
going
to
talk
a
little
bit
about
some
of
the
stuff
jabe
does
and
jabez.
B
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
gonna
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
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'd
be.
I
believe
people
need
to
learn
how
to
read
very
important,
learn
how
to
write,
learn
how
to
speak
right.
So
you
know
this
is
a
theme,
hopefully
will
be
clear
by
the
end.
B
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.
You
should
make
sure
that
twitter
knows
your
opinion
about
this
presentation.
B
B
So
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
jay,
but
then
another
carnegie
mellon
phd,
that
is
his
friend,
I'm
definitely
gonna,
take
advantage.
B
So
this
is
this
is
a
presentation
that
was
given.
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
gonna
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
then
I
hashtag,
you
know
velocity
conference
devops
and
working
together,
and
that
was
the
kind.
B
This
is
the
first
tweet
that
was
used
using
devops
in
this
context
in
in
this
kind
of
modern
framing
of
what
was
happening
and
there's
a
bunch
of
these
other
tweets,
you
can
read
them
I'll,
give
the
slides
to
my
colleagues
and
they
can
share
them.
You
can
read
them
later
or
you
can
search
twitter.
B
At
the
same
time,
I
was
already
working
conspiring
with
my
friend
patrick
to
do
what,
at
the
time
when
we
first
started
we're
going
to
call
agile
infrastructure
and
the
theme
of
this
talk,
then
he
decided
that
we
were
going
to
call
it
devops
days
and
that's
the
beginning
of
the
devops
days
and
the
hashtag
and
the
rest
of
the
story
and
what
we
now
kind
of
take
for
granted
as
this
global
movement
and
conversation
around
devops.
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
B
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,
but
there's
this
force
of
developers
and
operations
that
is
sort
of
putting
them
against
each
other,
so
one's
trying
to
create
stability
and
the
other
ones,
basically
trying
to
create
instability.
We
call
that
innovation,
but
they're
they're
really
trying
to
introduce
change
into
the
system.
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
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
We
wrote
kind
of
independent
versions
of
what
devops
means
to
us
at
the
time,
but
this
is
what
it
means
to
me,
and
I
think
this
is
still
pretty
true
and
and
we'll
kind
of
come
back
to
a
few
themes
of
this
before
the
end,
but
developers
and
operations
canon
should
work
together.
B
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
lost
my
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.
This
is
right
after
the
very
very
first
devops
days
in
the
u.s.
There
was
this
blog
post
about
this.
B
It
kind
of
became
this
culture,
automation,
metrics
and
sharing
cams,
and
then
our
friend
jazz
added
lean
later
and
I'm
gonna
talk
for
probably
the
next
15
minutes
or
so
like
what
these
mean
to
me
and
then,
like
I
said,
I'm
going
to
come
back
to
more
kind
of
commons
and
openshift,
focusing
so
for
the
next
10
15
minutes
we're
going
to
talk
about
what
devops
means
to
me
through
the
lens
of
these,
these
things,
so
culture,
automation,
lean,
metrics
and
sharing.
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-
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.
B
This
is
in
a
bunch
of
the
book,
so
if
you
read
like
the
devops
handbook
or
accelerate
there's
this
western
topology
of
culture
and
and
I'm
gonna
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
So
we
want
to
work
yeah
where
there's
high
cooperation,
where
people
are
trained
to
communicate
with
each
other,
where
the
messenger
in
in
a
pathological
culture.
Then
then,
when
someone
has
bad
news,
they
they
shoot
them.
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.
B
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.
They
want
the
novelty,
but
in
reality
their
culture
is
actually
crushing
the
the
novelty
they're,
crushing
the
innovation.
So
if
you
want
innovation,
you
can't
kill
it.
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.
All
these
things
are
really
what
determine
a
lot
of
these
behaviors.
B
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
things
this
used
to
be
me,
I
would
say
this.
You
know
I
had
puppet.
I
had
whatever
I
could
automate
things.
B
You
could
still
get
this
sort
of
thing
with
some
of
the
new
tools,
but
then
I
realized
that
the
architecture
matters.
So
this
is
a
question.
Is
that
automation?
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,
it's
sort
of
meant
to
be
as
a
joke,
but
also
it's.
B
The
thing
is
true
is
if
you
just
take
what
you
have
and
put
it
in
a
container,
it's
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.
B
So
hopefully
this
actually
makes
sense
to
you,
but
if
tetris
has
taught
me
anything,
they
say
airs
pile
up
and
accomplishments
disappear,
and
the
idea
here
is
that
if
you
just
lift
and
shift
the
architectures
that
you
have
into
the
containers,
then
you're
not
necessarily
going
to
get
a
benefit
of
the
of
the
new
architectures
and
and
the
new
automation.
B
So,
just
to
kind
of
copy
that
same
format.
What
I,
what
I
came
up
with
is
is
the
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
focused
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
a
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
about
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
that
are
specific
to
google,
but
a
lot
of
it
will
translate
straight
across
to
managing
you
know.
Whatever
your
favorite
container
platform
is
openshift,
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
secret.
Now
now
it's
very
different
and
you
know
they
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
sorry
book.
B
Without
monitoring
you
have
no
way
to
tell
where
the
service
is
even
working,
absent
and
thoughtfully,
designed
monitoring
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
first-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
I
ask
people
this
question
all
the
time.
B
What
are
your
objectives
and
a
lot
of
times?
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
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.
B
Is
I'm
going
to
bring
why
back
in
in
another
slide
in
a
few
minutes?
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.
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
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
opps,
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
So
what
we're
going
to
do
is
we're
going
to
fix
that
with
devops
and
and
it's
like
a
new
thing
with
a
new
title,
that's
sort
of
in
between,
and
I
I
think
this
is
an
anti-pattern.
You
know
people
get
excited
and
if
you
got
a
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
gonna.
I'm
gonna
come
back
to
that
again
a
few
times
so
the
this
is
not.
B
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.
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.
B
B
You
know
it's
one
thing
to
say
that
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
as
a
sys
admin
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
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,
when
I
made
this
slide,
I
didn't
have
this
language
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
So
with
that
we'll
go
back
to
the
spectrum,
so
in
an
organization
you
know
I'll
consider
these,
like
the
not
so
awesome
organizations,
there's
lots
of
silos
very
strong
secrets,
and
you
can't
find
any
information
as
you
get
a
little
bit
more
along,
there's
searchable
things,
people
put
things
in
a
wiki
might
be
hard
to
find,
but
at
least
it's
there
I
mean
maybe
there's
secrets
to
the
company
in
in
the
highest
performing
organizations.
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
a
I
mean
from
a
red
hat
kind
of
perspective
and
from
the
open
shift
commons
perspective.
I
think
it's
interesting
to
think
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
shrug.
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
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
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
devops
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
repo
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
rates
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
like
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
z
in
the
world
is
optimizing
human
performance
and
experience
operating
software
with
software
and
with
humans.
B
B
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
why
is
a
minute
ago,
is
that
there's
no
one
person
or
persona
that
can
do
it
by
themselves.
You
can't
just
make
these
changes
unilaterally.
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
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.
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.
B
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.
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
they
don't
have
the
the
language.
B
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
dun
done
this.
Is
this
this
thing
that
connects
the
scale
economy
to
the
differentiation
economy.
It
acts
as
a
as
a
clutch
as
a
transfer
between
the
two.
B
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
We
didn't
always
have
the
benefit
of
kubernetes
or
some
of
these
other
things,
but
you
you
have
these
things
that
are
innovations
and
depth
and
and
they,
but
they
be
more
valuable
as
a
shared
resource
is
part
of
a
platform
that
people
can
get
value
out
of
and
then
also
there's
things
that
are
probably
overly
constrained
trying
to
get
efficiency.
B
That
would
probably
be
better
managed
as
part
of
this
platform,
and
so
this
this
process
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
deal
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
You
could
say
anyway
this
this
is
like
fascinating
to
me
to
have
this
language,
and
it's
especially
interesting
when
I
think
back
through
all
of
the
devops
conversations
I
had
for
the
last
decade
to
have
this
language
and
realize
that
the
the
process
that
we
went
through
you
know
going
back
to
the
the
earliest
days
of
devops.
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
could
kind
of
win
for
themselves.
So
the
scope
economy
frames
a
negotiation
between
the
selfish
and
collective
interests
to
manage
shared
resources.
B
So
this
is.
This
is
devops
like
in
any
core
thing
so
commons.
These
are
shared
resource,
managed
for
individual
and
collective
benefit.
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
interesting-
you
know
example
of
the
community
that
you're
participating
in.
We
also
have
good
examples
from
industry.
B
So
I'm
going
to
read
this
one
remove
friction
between
remove
friction
from
product
development,
high
trust,
low
process,
no
handout
between
teams.
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
There's
there's
a
funny
joke.
You
could
make
that
kubernetes
ecosystem
is
a
commons
for
building
a
commons.
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?
B
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?
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.
B
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?
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.
A
B
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.
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
than
your
skill
set
is
more
important.
B
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?
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.
B
So
this
is
my
favorite
methodology
for
building
things,
building
things
that
matter
inspired
people
working
together.
You
know
a
lot
of
times.
People
want
to
have
a
a
magical
thing
that
they
think
will
solve
their
problems
if
they
follow
the
process,
I
not
that
you
shouldn't
have
a
good
process,
but
if
you
don't
have
inspired
people
working
together,
the
process
won't
matter.
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.