►
From YouTube: Commit Virtual 2020: GitOps Based Ops Modernization
Description
In this talk, Kubernetes GM Bob Wise covers how to evolve DevOps to GitOps, the why, the what and where we are heading. What are the motivators, effective strategies and deployment challenges.
Speaker: Bob Wise - General Manager, AWS
Get in touch with Sales: http://bit.ly/2IygR7z
A
B
But,
as
always,
I
think
it's
important
to
think
about
the
big.
Why?
Why
do
we
care
about
devops?
Why
do
we
care
about
git
ops?
Why
do
customers
care-
and
I
think
these
are
the
reasons
that
I
hear
from
customers
all
the
time
velocity
overall
velocity
of
building
systems,
building
software
delivering
value
is
critical
to
competitiveness,
and
this
isn't
just
true
nit.
This
has
become
true
across
all
industries,
and
we've
also
been
seeing
in
a
number
of
industries,
huge
velocity
gaps
between
the
high
performance
orgs
and
the
average
performance
org.
B
Now,
I
wouldn't
say
big
gaps
between
the
high
and
the
low,
that's
certainly
true,
but
even
between
the
high
and
the
average
here,
and
then
combined
with
that
is
a
natural
desire
to
be
more
efficient,
constrain
small
sprawl
use,
fewer
better
tools,
have
everybody
use
fewer,
better
things
and
the
teams?
This
is
an
hr
issue.
Teams
need
to
modernize
their
approach
because
it
helps
employees
be
happier
happy.
Employees
help
recruit
their
friends
and
a
good
work
environment's
good
for
everybody,
so
there's
considerable
pressure
to
evolve.
This
is
a
recent
pressure.
B
This
has
been
going
on
for
a
long
time,
and
this
has,
of
course
been
leading
to
a
lot
of
thinking,
some
of
it
more
recent
like
get
up.
Some
of
it
has
been
in
process
a
long
long
time.
I'm
talking
about
the
importance
of
how
do
you,
how
do
you
make
more
small
changes
as
opposed
to
fewer
big
changes,
and
this
is
of
course
the
discussion.
That's
been
going
on
for
years
and
years
about
waterfall
versus
incremental
kinds
of
approaches.
B
B
Whereas
if
you
can
make
progress
towards
a
more
high
velocity
approach
with
the
smaller
changes-
and
it
isn't
just
about
small
changes,
it's
about.
How
do
you
make
small
changes
and
use
automation,
get
the
help
from
the
robots
to
make
that
happen
so
get
ops
as
a
way
to
potentially
kind
of
help,
move
from
spiraling,
slower
and
slower
to
spiraling,
faster
and
faster.
B
But
that
said
fully
automated
deployments
are
really
really
hard.
So
I
don't
want
to
minimize
that
because
as
important
as
it
is
to
kind
of
leaping
that
chasm
from
let's
say
average
velocity
to
high
velocity,
it's
a
big
investment,
it's
a
big
change,
and
hopefully
some
of
the
things
I
say
here
today
can
help
on
that
journey.
B
So
why
is
that
so
hard
complication,
that's
big
complicated
systems
and
trying
to
coordinate
all
the
changes
between
those
systems
is
really
hard.
When
you
have
systems
that
have
lots
of
ordered
steps,
when
that
number
of
steps
gets
really
large,
it
gets
really
dependent
on
each
other
things
that
get
complicated
dependency
tracking.
B
There's
a
lot
of
the
success
of
immutable
style
approaches
and
containers
generally
are
based
on
improving
the
dependency
tracking
situation,
and
then
you
have
packaging
at
various
levels
of
the
system.
How
do
you
deal
with
versions,
different
versions
of
different
versions?
You
know
you
have.
Let's
say
you
have
lots
of
micro
services,
each
one
of
which
is
versioning
differently.
You
have
even
more
complication
there
and
then
what
do
you
do
when
things
go
wrong?
You
have
to
have
a
an
approach
for
rollbacks
when
continuous,
continuous,
isn't
when
a
particular
deployment
isn't
working.
B
So
so
these
are
all
these
are
all
the
the
complications
and
where
we've
been
moving
to
as
an
industry
to
approach
these
things
has
been
to
take
some
pretty
bold
steps.
A
shift
from
imperative
approaches
to
declarative
approaches
is
certainly
one
of
them.
Moving
from
kind
of
automated
mutation
to
immutability
is
another
big
one.
B
So,
to
be
a
little
bit
more
specific
right,
so
manual
processes,
automation.
This
has
been
going
on
for
a
while.
This
is
at
the
devops
level
really
what's
going
on
here,
but
in
a
git,
ops
and
containers
world
things
are
a
bit
more
prescriptive
and
there's
some
better
opportunities
here
to
improve.
So
I'm
replacing
package
managers
and
bash
scripts
and
so
forth,
with
containers
actually
depending
on
configuration
as
code
having
all
of
the
configuration
be
in
a
source
control
system
again
best
practice
in
the
devops
world.
B
B
B
It's
a
critical
devops
practice,
but
continuous
deployment
is
actually
quite
hard,
and
so,
as
we
move
from
a
world
where
the
dev
teams
are
going
really
fast
and
the
operations
teams
are
maybe
not
at
not
going
as
fast.
I
I
think
this.
This
shift
from
focusing
on
ci
to
focusing
on
cd
is
really
important.
B
Okay,
so
all
right
now
to
the
main
topic
here,
devops
is
devops-
is
transitioning
to
git
ops
for
a
lot
of
a
lot
of
folks,
especially
in
the
container
world.
Okay,
so
first
of
all
can't
really
say:
get
ops
without
tip
of
the
hat
to
the
weave
works.
Folks,
who
invented
this
term,
and
now,
let's
move
on
to
kind
of
what?
What
are
the
principles
of
get
up
so
systems
described
entirely
declaratively
the
desired
state
is
versioned
in
the
source
control
system
approved
changes
can
be
automatically
applied.
B
Note
here
that
the
shift
here
is
a
bit
towards
humans.
Do
their
work
up
front
and
the
robots
do
the
work
after
that,
and
then
the
use
of
systems
like
kubernetes
that
have
a
great
support
for
this
kind
of
model.
The
built-in
support
for
building
agents
and
watches
and
and
things
that
that
work
really
well
in
the
get
ops
world
so
just
to
emphasize
here,
declare
declaration,
versioning
automation
and
then
support
from
the
underlying
systems.
B
Okay,
so,
let's
think
into
each
one
of
these
a
little
bit
more
declarative
is
important,
because
it's
much
easier
to
reason
about
it
scale.
It
forces
simplification
in
a
disciplined
way.
There's
always
things
that
you
kind
of
want
to
think
about
imperatively,
but
ensuring
that
the
teams
are
required
to
think
through
a
declarative
approach
often
help
simplify
things,
a
really
important
point
here:
it's
it's
defined
intend.
So
this
is
the:
how
do
we?
How
do
we
in
this
new
world
manage
robots?
B
How
do
we
cross
the
human
robot
interface
and
the
the
approach
here
that's
been
working
is
to
define
intent
and
let
robots
do
the
work,
and
then
a
notion
of
constant
convergence
of
the
system
is
really
critical,
especially
in
these
large
distributed
systems.
A
declarative
approach
helps
make
a
clear
convergence
point
that
the
robots
are
always
working
towards
everything
in
source
control.
So
this
is,
I
think,
to
devops
practitioners.
This
would
be
non-controversial.
B
B
We
love
our
robots,
they
they
aren't
yet
our
our
overlords,
but
we
still
need
to
be.
We
still
need
to
be
nice
to
them.
I
would
say
this
is
probably
the
biggest
difference.
If
I
wanted
to
poke
at
that
that
difference
between
the
really
high
performance
org
and
the
average
org,
I
would
say
this-
is
it
most.
B
We
are
terrified
if
our
orgs
are
deploying
software
directly
to
production
and
not
using
automation.
So
I
think
this
is.
This
is
a
place
where
we're
we're
practicing
what
we
preach.
Again,
though,
this
is
really
hard.
This
is
a
big
investment,
but
the
payoff
that
you
get
for
making
this
investment
is
great,
all
right,
so
why
kubernetes
kubernetes
was
really
built
with,
as
as
a
robot.
B
It's
one
way
to
one
way
to
think
of
it
is,
is
a
robot
for
ops
teams,
and
it
supports,
has,
from
the
early
days
a
declarative
kind
of
approach.
The
notions
of
convergence
are
built
into
the
system.
This
is
why
the
controllers
and
operators
pattern
is
so
popular
immutability,
its
container
management
system.
It
has
support
for
things
like
deployments
which
helps
here.
B
B
B
So
the
the
idea
here
is,
you
should
have
this
desired
state
and
that's
really
that
immutable
thing
that's
checked
into
your
source.
Control
system,
like
you,
have
your
desired
state.
You
check
is
my
current
state,
the
the
matching
with
the
desired
state
and
then
take
some
action
to
either
correct
it,
or
it
can
be
the
case
that,
because
the
the
robots
are
still
not
not
that
sophisticated,
sometimes
they
still
need
human
help.
So
often
the
robots
can
fix
a
problem.
Oh
a
pod
died.
B
I'm
supposed
to
have
five
pods
here,
there's
only
four
pods.
Let
me
converge
the
state
back
to
five
pods,
for
example,
in
kubernetes
the
robots
can
do
some
of
the
work,
but
maybe
it
gets
too
complicated.
Oh,
I
ran
out
of
resources
to
get
back
to
five
pods
again,
so
how?
How
is
it
that
I?
When
do?
I
ask
humans
for
help?
B
So
a
big
piece
of
the
story
here
is
ensuring
that
it's
clear
in
your
systems
where,
where
the
robots
are
doing
the
work
and
where
they
need
to
ask
for
human
help,
okay,
so
digging
even
a
little
bit
deeper
here.
If
you
want
to
think
about
this
another
way,
I
think
this
was
again
when
I
started
first
started
trying
to
understand
the
implication
of
get
ops
operationally
the
notion
of
the
source
control
system
as
a
firewall
between
the
ci
world,
the
developer
world
and
the
git
ops
world
more,
the
ops
world.
B
B
I
would
suggest
you
think
about
it,
ci
as
a
kind
of
build
process
where
artifacts
by
the
way,
one
of
the
things
that's
missing
here
is
from
this
diagram
is
a
artifact
repository
like
a
container
registry,
for
example,
but
if
you'll
forgive
the
simplification,
the
the
main
point
is
here
that
in
the
ci
and
dev
world,
you
do
a
lot
of
things.
They're
they're
committed
into
the
source
control
system,
the
humans
review
it
and
then
the
robots
take
over.
B
So
you
get
a
single
source
of
truth.
All
operations
all
changes.
The
system
are
committed
by
pull
request,
and
then
you
get
into
this
checking
the
diffs
and
automatic
conversions.
This
has
another
really
positive
benefit,
especially
from
a
security
and
audit
perspective,
which
is
you
have
a
clear,
very
clear
kind
of
change,
control
path.
Here's
the
humans
that
looked
at
the
changes,
here's
who
approved
it,
here's
who
merged
it,
here's
the
desired
state
of
the
system
that
has
a
lot
of
positive
effects
outside
even
outside
the
operations
team.
B
B
Okay,
so
one
of
the
things
that
we
announced
last
week
at
kubecon
is
a
system.
We
call
ack
it's
in
developer
preview,
it's
open
source,
come
check
it
out,
try
it
give
us
your
feedback,
but
the
the
reason
I
mentioned
in
the
previous
slide.
The
all
dependencies
is
that
to
date
it
wasn't
entirely
clear
if
you're,
using
a
git
ops
approach
with
kubernetes
or
eks,
for
example
on
aws
how
to
think
about
application
dependencies
on
aws
services.
B
B
B
I
think
the
main
one
has
been
focus
on
operations
on
the
operation
side
and,
if
you're,
if
you're,
in
an
organization
that
like
aws
practices,
you
build
it,
you
run
it.
This
is
more
of
a
life
cycle
and
rolls
thing,
maybe
within
the
team,
if
you're
a
operation
that
uses
sres
or
perhaps
has
development
and
operations
in
separate
teams,
you
can
you
can
think
of
the
focus
here
as
being
on
the
operations
team,
as
opposed
to
the
operations
practice,
either
way
works
and
again.
B
You
can,
of
course,
use
container
orchestration
to
help
realize
ci
and
cd,
and
I
would
also
say
that
this
should
not
be
viewed
like
like
most
things.
These
kinds
of
transformations
are
really
hard.
As
I
said
earlier,
continuous
deployment
is
really
difficult
and
it's
important
to
take
an
incremental
approach
to
this,
as
it
is
anything
else,
and
you
can
incrementally
evolve
the
entire
organization,
not
just
not
just
new
projects.
B
Modernization
as
a
critical
prelude
to
any
kind
of
microservices
re-architecture
is
critical,
so
my
recommendation
here
would
be
make
sure
that
you
can
do
continuous
deployment
on
your
monoliths
before
you
start
before.
You
start
re-architecting
those
into
microservices,
and
you
know
beyond
the
topic
of
this
talk
you
know
continuous.
The
observability
is
as
important
as
continuous
deployment.