►
Description
Why do all companies represent DevOps with a sideways figure-8 digram?
Talk from DevOps Day LA 2020.
Recorded by Francis Potter
A
Hi
there
I'm
Francis
Potter
solution,
architect
with
gitlab
and
I'm
here
today
to
talk
to
you
about
future
of
DevOps
and
the
importance
of
right-to-left
thinking.
This
is
a
talk
that
I
gave
a
DevOps
de
la
in
March
of
2020,
and
the
video
of
that
wasn't
so
good,
so
I
decided
to
just
record
more
or
less
the
same
thing
at
my
desk.
I
hope
you
enjoy
it.
I
started
thinking
about
this
with
the
question
a
very
simple
question:
what
does
DevOps
look
like
visually?
If
you
could
see
it?
A
What
does
it
look
like
so
I
went
to
everybody's
favorite,
resource
Google
and
I
typed
in
DevOps
and
click
the
Images
tab,
and
what
I
saw
was
a
sea
of
sideways
figure,
eight
diagrams,
every
single
one
of
them
on
their
side,
almost
exactly
the
same
design
with
these
arrows,
pointing
left
to
right
across
the
front
and
then
right
to
left
down
the
back.
I
decided
to
investigate
a
little
bit
further
and
I
discovered
that
these
diagrams
have
a
lot
of
very
similar
words
on
them,
but
not
exactly
the
same
words.
A
They,
some
of
them
have
more
phases
than
others,
but
essentially
they
have
to
do
with
planning
coding,
testing
packaging
deploying
releasing
and
monitoring
your
application
and
that's
sort
of
that
cycle
in
DevOps.
The
ones
at
the
bottom
actually
have
tools
associated
with
them.
I
think
it's
really
funny
that
this
one
in
the
bottom,
at
the
middle,
doesn't
have
any
planning
tools,
but
the
one
on
the
left
is
actually
from
gitlab.
A
application,
performance
monitoring
and
a
lot
of
times.
The
group
that
looks
at
the
monitoring
reports
is
a
completely
different
group
from
the
one
that's
doing
product
planning
and
quite
frequently,
applications
aren't
really
instrumented
for
the
kind
of
monitoring
that's
useful
for
product
planning
in
the
current
environment.
Devops
is
more
important
than
ever
for
several
reasons
that
I'd
like
to
touch
on
before
we
start
to
address
this
question.
The
first
is
that
all
companies
are
software
companies,
whether
you're
in
transportation,
healthcare,
entertainment,
it
doesn't
matter.
Every
company
has
software
development
teams
working
at
them.
A
A
That's
doing
the
planning
and
they're
probably
separate
from
the
coders
and
the
people
running
the
DevOps
pipelines
and
they
might
be
separate
from
the
people
doing
the
deployment.
How
are
you
supposed
to
be
fast?
Are
you
supposed
to
be
secure,
there's,
so
many
different
teams
in
communication
between
them
is
really
tricky
and
really
difficult.
Finally,
there
is
a
confusing
array
of
different
technologies,
ideas
and
and
movements
in
the
world
of
DevOps
that
can
leave
us
completely
confound
it
even
in
the
modern
world
and
make
it
almost
impossible
to
think
about
the
future.
A
So
those
are
some
of
the
challenges
that
we
face.
So
who
are
the
winners
going
to
be?
Who
are
the
companies
that
are
going
to
really
really
when,
in
the
long
run
over
the
next
five
to
ten
years,
playing
the
DevOps
and
software
development
game?
Well,
I
think
the
winners
have
a
few
specific
characteristics.
First
off
winners
measure
everything
they
become
data-driven
organizations
no
longer
our
product
features
roadmaps,
even
bug
fixes
dependent
on
the
hunch
of
an
individual
product
manager,
or
even
a
committee
rather
they're,
based
on
data.
A
A
A
It's
no
longer
just
monitor
to
plan.
It's
a
whole
aspect.
How
you
think
about
your
software
development
life
cycles,
I'm,
assuming
that
we
have
get.
We
have
good
software
development
practices.
We
have
code
review
processes,
we
have
I'm,
assuming
we
have
continuous
integration
and
continuous
deployment.
Those
are
all
solved
problems,
but
the
tricky
part
is:
how
are
you
doing
that
data
collection
and
how
are
using
that
to
drive
iteration,
so
I
drew
a
new
diagram
that
reflects
that
reality.
A
Now
this
diagram
of
the
future
of
DevOps
is
really
dealing
with
one
module
or
one
feature
of
your
application.
Remember
your
system
is
a
many-headed
Beast,
meaning
that
you
actually
have
a
lot
of
different
features
or
a
lot
of
different
modules
or
components
or
whatever
you
call
them,
and
each
one
of
those
should
have
this
cycle
built
into
it
step.
A
One
is
to
build
the
minimal
version
of
a
feature
or
the
minimal
improvement
to
a
feature
in
every
iteration
and
I
mean
not
broken
just
minimal
it
to
be
documented
it
to
be
tested
it
to
be
working,
but
it
can
be
very,
very,
very,
very
small.
We've
really
forced
ourselves
to
do
this,
a
git
lab,
and
it
is
not
easy
if
you
think
that
you
can
just
snap
your
fingers
and
have
the
smallest
version
of
a
feature,
your
features
probably
10
times
as
big
as
it
actually
needs
to
be.
A
So
once
you've
built
a
minimal
version
of
that
feature,
instrumented
for
data
collection
be
thinking
about
data
collection
from
the
very
beginning,
and
that's
not
just
monitoring
data
like
how
many
people
clicked
on
it.
That's
just
where
the
beginning
is.
It's
also
how
many
people
rolled
over
it?
How
long
did
they
take
before
they
clicked
on
it?
Can
you
experiment
with
the
control
being
in
four
different
places
on
the
screen
and
gather
data
on
which
one
gets
clicked
on
the
most
or
the
quickest?
A
Furthermore,
can
you
gather
human
feedback
like
ask
questions
and
surveys
and
and
poll
users
who
are
using
this
feature
as
to
how
much
they
like
it?
What
else
they
would
like
to
see
how
often
they
might
use
it?
How
much
money
or
speed
it's
going
to
mean
to
them?
And
can
you
gather
that
human
feedback
once
you've
instrumented
that
feature
for
data
collection?
A
The
third
stage
is
to
control
deployment,
don't
roll
this
feature
out
to
absolutely
everybody
and
absolutely
every
version
of
your
application,
absolutely
every
server
but
use
canary
deployments
and
feature
flags
to
control
who
actually
sees
this.
So
if
there's
something
wrong
with
it,
it's
really
easy
to
switch
back
and
get
rid
of
it
shut
it
off.
Maybe
I
have
to
do
is
hit
a
checkbox.
Maybe
all
you
have
to
do
is
is
update
one
server
really
quickly.
You
want
to
be
able
to
control
that
deployment.
A
You
also
want
to
be
able
to
mix
and
match,
because
you've
got
many
headed
beast.
You've
got
lots
of
different
feature
teams,
each
working
on
different
modules.
Maybe
some
users
get
the
new
feature
over
here,
and
some
of
you
just
get
a
new
feature
over
here
and
some
get
both
in
some
get
none
and
you
can
see
how
those
interact
and
you
can
analyze
that
data.
A
The
fourth
step
is
to
plan
your
next
iteration,
based
on
real-time
data,
that
data
that
you're
collecting
from
your
data
collection
from
that
small
group
of
users
should
be
made
available
immediately
to
the
team
responsible
for
that
feature,
whether
it's
product
management,
UX
design
or
the
developers
whoever's
responsible
for
that
feature,
that's
not
monitoring
data
that
goes
to
some
ops
team
somewhere
else.
That's
data.
That's
made
available
immediately,
so
that
that
team
can
immediately
start
working
on
the
next
iteration.
A
The
next
minimal
change
to
that
feature,
and
from
there
iterate
iterate
iterate
on
the
tightest
cycles
you
possibly
can
the
shorter
your
cycle
times
are
the
more
data
you
can
gather
and
the
more
data
you
can
gather
the
better.
Your
feature
will
be
when,
as
it
actually
grows,
and
furthermore,
you'll
have
that
feature
in
market,
even
though
it's
just
a
minimal,
tiny
version
of
that
feature.
The
end
result
is
that
your
organization
becomes
a
winner
and
becomes
the
most
competitive
organization
in
the
market,
with
your
software
at
the
core
and
driving
the
future
of
DevOps.