►
From YouTube: Keynote: Cloud Native CD: Spinnaker and the Culture Behind the Tech - Dianne Marsh, Netflix
Description
Keynote: Cloud Native CD: Spinnaker and the Culture Behind the Tech - Dianne Marsh, Director of Engineering, Netflix
Created at Netflix, Spinnaker is an open source, multi-cloud continuous delivery and infrastructure management platform for releasing software changes with high velocity and confidence. Spinnaker’s open source community includes Netflix, Google, Microsoft, Oracle, Target, Kenzan, Schibsted, and many others.
In this keynote, you’ll learn how various aspects of Netflix culture, and open source have shaped Spinnaker and how Spinnaker, in turn, has influenced the engineering culture at Netflix. We’ll discuss how lessons learned from an earlier open source product, Asgard, influenced us and drove a Cloud Native first approach.
About Dianne Marsh
Director of Engineering, Netflix
Engineering Tools, Developer Productivity, Continuous Delivery, Women in Tech
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
What
I'm
going
to
talk
about
is
how
culture
impacts
the
tech
and
then
also
how
the
tech
can
turn
that
around
and
also
impact
the
culture
we're
going
to
start
with
talking
about
how
culture
impacts,
the
tech
I
think
it's
really
important
for
us
to
understand
when
we
build
tools
that
were
basically
reflecting
the
culture
in
those
tools.
If
we're
not
reflecting
the
culture
in
those
tools,
we
might
be
challenging
the
culture
with
our
tools.
A
Likewise,
when
you
adopt
a
tool
understanding,
if
that
culture
is
which-
which
one
of
those
things
is
going
to
happen,
when
you
bring
that
tool
into
your
organization,
is
it
going
to
challenge
the
culture?
Is
it
going
to
reinforce?
The
culture
is
also
a
consideration,
so
I'm
going
to
talk
about
Netflix
culture
a
little
bit
and
then
I'm
going
to
bring
in
a
discussion
about
a
tool
at
Netflix,
so
that
we
can
reinforce
that
that
conversation,
so
Netflix
is
really
about
freedom
and
responsibility
and
we're
talking
a
little
bit
more
detail
with
the
speeds.
A
A
These
pieces
of
freedom
responsibility
are
the
part
that
I
want
you
to
think
about
as
I
talk
about
an
open-source
tool
that
we
have
called
spinnaker.
How
many
of
you
use
spinnaker
today
so
spinnaker
I'm,
not
here
to
encourage
you
to
use
spinnaker,
although
I
think
it
might
be
fun
if
you
thought
that
it
was
useful
when
I'm
really
here
to
do
is
to
talk
about
it
as
a
case
study
and
talk
about
how
our
culture
is
being
reflected
in
that
tool.
A
But
first
I
wanted
to
talk
about.
The
genesis
of
spinnaker
is
a
continuous
delivery
platform,
an
infrastructure
management
platform.
Before
spinnaker
there
was
a
tool
at
Netflix,
called
Asgard.
How
many
of
you
used
Asgard
for
cloud
delivery.
Yeah
several
of
you
Asgard
was
really
built
to
simplify
the
delivery
of
our
services
to
the
Amazon
Cloud.
We
opened
it
up
and
put
it
in
open
source
and
a
lot
of
people
enjoyed
it.
A
What
they
did
was
used
it
in
their
own
environments
and
for
their
own,
but
they
ran
into
some
of
our
cultural
considerations
when
they
did
such
as
the
fact
that
we
didn't
need
permission
to
be
able
to
do
deployments.
They
also
found
that
it
only
supported
one
cloud
provider
and
there
were
a
lot
of
other
limitations
about
Asgard.
That
made
us
think
that
we
wanted
a
continuous
delivery
platform
beyond
just
a
deployment
tool,
so
we
were
working
on
a
spinnaker
inside
of
Netflix.
At
the
same
time,
there
was
another
project
which
you
hadn't
heard
about.
A
Probably
it
was
an
interim
project
called
Asgard.
This
isn't
13
I'm,
sorry
I
called
edge
Center.
This
is
being
done
by
another
team
at
Netflix,
the
edge
API
team,
and
they
were
building
this
for
their
own
purposes,
because
they
couldn't
wait
for
the
centralized
team
us
to
finish
the
product
that
we'd
been
working
on.
They
had
very
immediate
needs
and
they
needed
to
do
fast
deployments
and
they
needed
to
have
those
done
in
a
safe
and
reliable
repeatable
way.
A
So
they
built
this
tool
called
edge.
Center
and
a
lot
of
people
were
really
enjoying
using
it,
and
then
other
people
were
coming
to
them.
Saying
gosh
we're
not--we're,
not
in
the
edge
API
teams,
but
we'd
really
like
to
use
your
tool,
and
that
was
inserting
some
pressure
on
that
team,
because
they're
not
a
centralized
team.
They
don't
typically
support,
centralized
tools.
You
might
wonder
what
was
engineering
tools
during
during
during
this
time
and
we
were
continuing
to
work
on
the
centralized
product,
but
we
were
chasing
the
features
that
were
showing
up
an
edge
Center.
A
If
we
wanted
a
centralized
tool,
it
was
going
to
serve
all
of
Netflix.
We
needed
to
have
those
features
represented
in
the
tool
that
we
were
building,
but
remember
they
were
solving
a
problem
for
a
very
distinct
purpose,
and
so
they
were
able
to
run
very
very
fast
and
we
were
basically
solving
the
problem
for
the
rusty
organization,
so
we
were
running
a
lot
slower,
maybe
walking,
and
so
this
presented
a
challenge.
How
are
we
ever
going
to
catch
up
to
them?
A
These
two
teams
met
a
lot
and
every
month
they
meet
they'd
say
oh
gosh,
not
yet
we're
not
ready.
Yet
we're
not
ready.
Yet
on
the
spinnaker
side
and
the
edge
center
side
would
say,
your
product
isn't
ready
for
us
to
adopt
yet
I'm
telling
you
all
this,
because
I
think
that
the
answer
to
this
problem
basically
demonstrates
two
of
our
cultural
values
that
Netflix
courage
and
selflessness.
A
The
answer
this
problem
was
the
Andy
Glover,
who
leads
the
delivery.
Engineering
team
at
Netflix
went
to
Sangeeta
and
Arianne,
who
leads
the
edge
Center
the
edge
API
team
at
Netflix
and
said
it
was
a
lot
of
courage,
said
I
can't
possibly
keep
up
with
you.
Can
we
is
there
any
way
we
can
join
forces
and
make
this
because
I
am
NOT
going
to
be
able
to
get
edges
needs
built
into
my
tool
fast
enough
for
you
and
for
the
rest
of
the
company
and
singita
who's
very
selfless
said.
A
A
Center
they'll
bring
the
context
from
the
edge
teams
into
the
product
as
well,
and
so
this
is
what
they
did
and
they
work
together
as
a
team,
and
they
are
able
to
realize
spinnaker
I,
probably
just
embarrassed
those
two
people
in
on
stage
and
I
did
not
warn
them.
That
I
was
going
to
do
that,
but
I
think
it's
really
important
to
call
out
cultural
values
and
make
sure
that
people
feel
appreciated
when
they
do
something
I
think
is
really
quite
unique.
A
A
It
was
designed
to
be
a
pluggable
architecture.
Some
of
the
challenges
I
said
that
we
met
was
spent
with
Asgard
was
that
people
would
fork
it
because
they
had
extra
needs
on
top
of
what
Asgard
could
do.
It
was
never
gonna
work
for
everybody,
and
so
they
would
fork
the
tool
in
the
community
and
go
off
on
their
own
on
their
own
path,
and
we
would
never
get
the
benefit
of
that
innovation.
A
Likewise,
people
would
fork
it
for
other
clouds,
so
spinnaker
was
designed
initially
to
be
a
multi
cloud
from
the
very
beginning
to
be
a
multi
cloud
tool.
We
worked
with
other
companies
in
order
to
realize
the
multi
cloud
solution
and
this
actually
changed
at
the
architecture,
because
you're
thinking
about
what
the
cloud
is
not
just
what
your
implementation
of
the
cloud
is
so
in
2014
spinnaker
was
an
internal
tool.
A
When
we
finally
released
it,
we
talked
about
the
fact
that
we've
been
working
with
Google
and
AM
and
Microsoft.
We
were
supporting
Amazon's
needs
with
our
implementation,
but
Google
was
supporting
their
own
end
points
of
cloud
provider,
Microsoft
was
providing
its
cloud
provider
and
pivotal
was
providing
one
as
well.
A
So
when
you,
what
you
see
today,
is
a
tool
that
can
support
many
calm
providers
and
that
doesn't
have
to
be
forked
in
order
for
all
of
us
to
realize
that
innovation,
the
community's
vibrant
and
strong
and
I'm
really
excited
about
having
all
of
them
working
together.
What's
not
on
this
list
is
actually
the
Oracle
is
also
working
on
a
bare-metal
solution,
so
it
continues
to
grow.
A
A
A
We
also
support
setting
persistent
properties,
we're
deploying
immutable
objects
into
our
ecosystem,
and
we
need
to
be
able
to
make
changes
to
those
immutable
objects.
That's
kind
of
funny,
isn't
it
we
need
to
adjust
those
immutable
objects,
maybe
to
turn
bugging
and
such
and
so
persistent
properties
give
us
an
ability
to
be
able
to
do
that,
and
so
we've
often
called
these
fast
properties
we're
starting
to
call
them
persistent
properties.
A
Now,
because
we
want
to
emphasize
the
fact
that
these
can
roll
out
just
like
deployments,
roll
out
across
your
infrastructure
and
they
could
be
rolled
back
as
well
and
one
place
where
I
want
to
stop
and
talk
about
culture
with
both
the
deployments
and
and
persistent
properties.
Is
that
one
of
the
expectations
we
have
at
Netflix?
Is
that
we'll
be
able
to
have
an
active
active
environment?
A
We
don't
want
your
stranger
things
streaming
to
be
interrupted
by
the
fact
that
an
engineer
may
be
pushed
out
an
arrant
deployment
or
changed
a
property
that
they
shouldn't
have
in
the
whole
system
goes
down
so
one
of
the
ways
we
can
respond
to
problems
in
our
ecosystem,
which
a
lot
of
times
are
us
shooting
ourselves
in
the
foot,
is
to
failover
to
another
region.
While
we
have
enough
time
to
figure
out
what
we
did
wrong
in
this
region.
A
What
that
means,
though,
is
that
in
a
multi
region,
environment,
the
deployment
system
that
Netflix
has
what
we
don't
want.
Our
engineers
to
do
is
to
push
globally
to
all
regions
at
the
same
time,
because
then,
what
have
you
just
done?
You've
completely
defeated
the
purpose
of
having
an
active
active
environment,
and
so
we
need
to
set
that
expectation
within
our
culture
and
then
with
also
with
our
tools.
A
A
We
also
want
to
give
the
developers
the
ability
to
manage
their
instance
health.
What
needs
to
happen
to
this
in
what
needs
to
happen
to
this
service,
do
I
need
to
rebake
it
and
redeploy
it,
because
something
was
deprecated.
I
want
to
be
able
to
give
you
a
dashboard,
an
opportunity
to
see
this
at
the
place
where
you're
spending
your
time.
A
A
Key
to
understanding
the
way
that
this
tool
works
and
the
way
that
Netflix
works
is
to
understand
that
we
want
to
provide
guardrails,
not
gates.
I,
don't
want
to
stop
you
from
doing
something.
I
want
to
give
you
context
about
why
we
think
it
might
be
a
bad
idea.
I
want
to
make
sure
that
you
have
all
the
context
to
make
that
decision,
but
I
don't
want
to
prevent
you
from
doing
it.
A
We
do
this
for
a
couple
reasons,
one,
because
the
developers
are
making
the
decision
about
what
to
deploy
I
said
before
they
understand
their
service
better
than
anyone
else.
If
there's
an
emergency
I
do
not
want
to
get
in
their
way.
The
last
thing
I
want
to
do
is
put
up
a
gate
that
basically
people
have
to
jump
over
and
trip
and
fall
and
make
things
worse
right,
and
our
tools
really
reflect
that
developers
have
a
lot
of
responsibility.
A
They
decide
when
to
deploy
they're
on
call
for
that
service
they're,
the
ones
who
are
going
to
be
woken
up
in
the
middle
of
the
night
if
they
made
a
mistake
and
they
have
to
fix
it.
So
we
give
them
context
about
execution
windows
as
well,
and
this
is,
if
all
of
you
are
watching
stranger
things.
We
have
a
pretty
good
understanding
about
what
those
timeframes
will
be
and
that's
reflected
at
the
bottom
of
the
screen,
where
you
see
this
very
cyclical
graph,
very
repeatable
pattern
about
what
traffic
looks
like
to
our
service.
A
We
provide
this
information
so
that
developers
can
create
their
deployments
and
time-based
deployments
to
reflect
times
that
aren't
busy
that
they're
able
to
deploy
windows
that
they're
able
to
deploy
into,
but
they
might
have
a
service
that
doesn't
they
don't
really
think
will
be
affected
by
that?
And
it's
okay
for
them
to
deploy
outside
of
that
window
if
it
so
they
don't
have
to
use
execution
windows
engineers
manage
the
lifecycle
of
their
services,
but
we
also
want
to
give
them
context
about
what
which
services
are
absolutely
critical
to
the
services
to
service.
A
Overall,
and
this
is
this
traffic
guards
page-
is
a
solution
to
the
problem
of
making
sure
that
systems
don't
go
to
zero,
that
you
don't
accidentally
delete
a
duplicate,
some
service
that
you
didn't
expect.
You
engineers
decide
their
own
deployment
strategy.
There
are
many
different
deployment
strategies
built
into
spinnaker,
but
we
also
give
a
in
the
continuous
delivery
pipeline.
We
give
the
ability
to
be
able
to
add
a
manual
judgment
now.
Does
that
sound
counter
to
continuous
deployment?
Maybe
it
does,
but
what
I
think
this?
Does
it's
optional,
I
think
what
it
does
is.
A
It
gives
the
opportunity
for
our
developers
to
build
confidence
in
our
tooling
that
they
know
that
when
this,
when
they
push
that
button,
they
can
decide,
do
I
want
a
manual
stage.
Do
I
want
that
last
that
last
screen
before
I
check
out
at
a
retail
store.
That
says,
don't
worry,
we're
gonna,
let
you
look
at
this
one
more
time
before
it
processes
your
credit
card
right
and
that's
kind
of
the
equivalent
here.
It
also
gives
them
the
ability
to
build
confidence
in
their
own
service.
Am
I
ready
to
go
without
a
manual
deployment
stage?
A
We
want
to
provide
smart
defaults
based
on
the
criticality
of
a
service.
We've
started
identifying
our
services
as
critical
to
streaming
critical
to
the
business
different
expectations
around
that
service,
the
core
services
that
that
will
provide
you
with
the
ability
to
be
able
to
stream
a
movie
all
have
great
fall
backs
in
the
event
that
the
service
is
not
available.
That
tells
you
what
you've
been
watching
on
a
different
device
or
the
service
isn't
available.
That
tells
you
some
recommendations
about
shows
that
you
might
like.
A
What
are
we
going
to
go
in
the
future?
With
this,
as
I
said,
I
think
we're
gonna
extend
back
a
little
bit
more
into
the
continuous
integration
space
kind
of
blur.
That
distinction
a
bit
declarative,
continuous
delivery,
gives
us
the
ability
to
be
a
little
bit
more
abstract
about
what
we're
deploying
where
we're
deploying
to
gives
the
developer
more
focus
on
the
domain
and
the
problem
that
they're
trying
to
solve
we're.
A
Taking
on
some
of
that
responsibility
by
them,
giving
us
some
configuration
information
rather
than
what
specific
instance
type
do
they
want
to
deliver
to
deploy
to
or
what
specific
parameters
they
want
to
use
over
here.
So
we're
gonna
see
a
lot
of
space.
A
lot
of
movement
in
that
area
as
well
spend
a
few
minutes
here
talking
about
how
tech
impacts
the
culture.
A
How
some
of
this
was
a
surprise
to
me
an
increased
interest
in
delegation
of
that
responsibility
to
us
was
kind
of
a
surprise
to
me
when
I
joined
Netflix
about
four
and
a
half
years
ago,
the
the
sense
the
engineering
culture
was
really
all
about.
Let
us
configure
all
the
things
we
want
to
see
all
the
details.
We
want
to
look
at
that
every
detail
that
might
be
available
in
the
Amazon
console
and
by
the
way
we
might
want
to
go
to
that
sometime
so
give
us
that
access
right.
A
2017
give
us
smart
defaults
now
this
might
be
a
change
in
the
way
in
the
the
people
that
we're
hiring
might
be
more
domain
experts.
Maybe
it
might
be
a
reflection
of
the
fact
that
people
trust
our
tools
more
I,
don't
know
what
I'm
telling
you
is
that
people
really
do
want
to
focus
more
on
the
problems
that
they're
coming
to
solve,
rather
than
every
single
person,
understanding
the
details
of
a
build
and
deployment.
Something
for
you
to
consider
as
you
build
your
as
you
build
your
own
tools.
A
What
are
you
making
your
users
now
we
built
some
understanding
about
what
the
best
practices
are
across
all
of
these
providers.
We
really
understand
what
a
cloud
deployment
looks
like
not
just
an
AWS
deployment
or
a
Google
deployment
or
a
sure
deployment.
We
really
get
to
build
those
abstractions
and
really
understand
what
the
what
the
cloud
ecosystem
looks
like
and
build
those
into
the
tool
lots
of
community
contributions.
I,
don't
think
this
is
always
realized
in
open-source
projects,
but
this
community
has
been
really
responsive.
A
We've
used
inspiration
from
the
kubernetes
cloud
provider
that
Google
developed
we've
also
implemented
directly.
Their
role
based
access
control
solution
called
Fiat,
we're
deploying
a
lot
more
often,
we
have
about
8,000
orchestrations
a
day
that
includes
tearing
things
down
creating
services.
It
means
that
we're
also
doing
a
lot
of
deployments,
we're
also
holding
some
hackathons
and
I
think
this
is
critical
to
the
success
of
spinnaker
internally,
especially
because
we
want
our
other
internal
teams
to
be
able
to
understand
how
to
contribute
back
to
spinnaker.
A
It's
those
stages,
those
custom
stages
for
their
use
cases
are
what's
going
to
continue
to
grow
the
tool
and
we
don't
want
to
be
the
lynchpin,
the
the
the
bottleneck
and
that
in
that
problem,
we're
only
getting
started.
I
think
there's
a
lot
more.
We
can
do,
but
I
want
to
give
you
some
parting
thoughts.
I
want
you
to
think
back
to
what
I
talked
about
with
courage
and
selflessness.
A
Are
there
places
in
your
and
your
general
workday
that
you
can
exhibit
courage
and
that
you
can
exhibit
selflessness
and
you
can
actually
make
change
in
your
environment?
I
also
want
you
to
think
carefully
about
the
tools
that
you
choose.
Are
you
fighting
culture
or
are
you
at
reinforcing
it?
I
say
here,
don't
fight
culture.
I
just
actually
mean
be
more
aware
of
the
fact
that
you
are.
Thank
you
very
much.