►
Description
The what, why, and how of modern infrastructure automation using GitOps.
A
Let's
just
take
a
look
at
what
has
set
the
stage
for
get
ops,
which
is
the
fact
that
the
modern
landscape
for
software
development
is
changing
and,
as
always,
software
development
is
very
dynamic,
as
new
technologies
and
practices
emerge.
The
world
changes
and
we
need
to
adapt
to
those
changes.
So
take
a
look
at
what
sets
the
stage
for
get-ups.
A
There
are
a
lot
of
challenges
with
doing
waterfall
and,
unfortunately,
many
teams
are
still
practicing
waterfall.
One
of
the
main
challenges
is
the
cycles
are
so
long.
It's
a
long
time
before
you
get
any
feedback.
You
could
even
be
writing
software
that
nobody
even
wants.
So
in
order
to
address
these
challenges,
the
software
industry
came
up
with
agile
software
development.
A
So
there's
a
lot
of
advantages,
but
the
problem
is:
is
when
software
development
teams
are
sending
code
over
the
proverbial
wall
to
operations,
teams
to
deploy
and
operate
it
and
they're,
making
smaller
changes,
which
means
they're,
making
more
and
they're
sending
over
more
then
the
environment
and
the
practices
and
the
technology
needs
to
change
in
order
to
adapt
to
those
those
the
more
code
and
the
smaller
changes.
So
this
is
where
DevOps
comes
into
play.
A
Devops
is
about
software
development
teams
and
operations,
teams
working
together
and
engineering
and
automating
their
practices
so
that
they
can
not
only
write
code
in
small
changes,
but
also
test
and
deploy
those
small
changes
very
very
rapidly.
This
is
an
amazing
step
forward
and
a
wonderful
software
practice,
but
now
in
the
modern
environment,
we're
facing
even
more
challenges
where
we
need
software
applications
to
work
at
amazingly
large
web
scale
and
deal
with
things
like
micro-services
containerization
service
mesh
and
this
modern
world
of
kubernetes
and
containers
human
cloud
native
software
development.
A
What
applications
need
to
do
is,
as
load
comes
on
the
application,
they
need
to
scale
up
the
infrastructure
that
it's
running
on
and
then,
when
there's
no
load,
it
needs
to
scale
down
and
do
this
all
dynamically
in
a
very,
very
complex
way
across
many
micro
services.
So
in
order
to
meet
the
operational
needs
in
order
to
address
these
modern
operational
challenges,
this
is
where
get
ops
comes
into
play.
As
I
mentioned,
I'll
talk
about
the
what
the
why
and
the
how
of
get
ops
so
to
start
out.
A
Let's
just
talk
about
what
is
get
ups
get
ups
is
an
operational
framework
and
it
takes
the
DevOps
best
practices
used
for
application
development.
These
are
things
like
version
control,
collaboration,
compliance,
see,
ICD,
and
it
applies
them
to
the
realm
of
infrastructure.
Automation
in
a
nutshell,
get-ups
has
three
main
components:
it
equals
infrastructures
code
plus
merge
requests
as
your
agent
of
change,
plus
CI
CD
automation.
So
what
I'll
do
is
quickly
look
at
each
of
these
components.
A
Infrastructures
code,
merge
request
as
a
change
agent
and
see
ICD
automation
and
talk
about
what
they
are
and
how
they
fit
in
to
get
ops
when
you
are
practicing
adapts
how
you
use
each
of
these
components
so
start
out.
A
major
component
of
get
ops
is
having
your
environments
stored
as
code
in
a
git
repository
now
here,
I
use
the
term
infrastructure
as
code,
but
this
may
not
be
relegated
simply
to
infrastructure,
sometimes
I
might
say
X's
code
or
even
just
your
environments
in
general,
because
this
could
be
in
structure
configuration
policy.
A
A
Often
this
code
can
be
declarative,
which
means
you
are
declaring
the
eventual
state
that
you
want
the
environments
to
be
in
and
then
your
automation
is
gonna
reconcile
whatever,
whatever
state
your
environments
are
in,
the
automation
is
going
to
shift
it
towards
a
source
of
truth,
but
some
folks
in
you
know
some
phases
of
get
ops
are
maybe
using
procedural
code
as
well,
but
as
we
move
forward,
the
very
very
mature
ones
are
usually
doing
some
type
of
declarative
code
describing
the
desired
state.
Of
course,
this
is
stored
in
git
version
control.
A
Now,
really
you
could
do
get-ups
using
any
version,
control,
material
or
SVN
or
any
number
of
version,
control
systems
and
you're
gonna
get
the
benefit
of
using
version
control,
but
when
you're
doing
get
ops,
it's
very
critical
to
be
using
git,
specifically
and,
more
importantly,
a
git
management
tool.
We'll
talk
about
that
in
just
a
moment.
A
A
There's
a
lot
of
learning
material,
there's
all
these
advantages
of
using
it,
and
so
that
now
becomes
the
user
interface
into
changing
your
infrastructure
and
managing
your
infrastructure
via
get
the
next
component
as
I
mentioned,
and
why
it's
important
to
use
git
is
that
merge
requests
become
the
agent
of
change
and
get
lab.
We
call
the
merge
requests
and
other
systems
like
github
or
bitbucket.
These
are
called
pull
requests
and
the
idea
is
this:
becomes
the
gating
mechanism
for
any
changes
that
are
going
to
go
alive.
A
This
involves
using
a
system
where
you
have
a
branch,
and
that
branch
represents
this
the
state
of
a
particular
environment.
So
this
could
be
your
dev
branch
or
your
staging
branch
or
your
production
branch.
And
let's
say
you
have
a
production
branch
that
that
branch
of
code
represents
what
you
want
deployed,
a
production
and
so
anytime
you
want
to
make
changes,
you
make
a
make
a
fork
or
make
a
feature
branch
or
a
patch
branch.
A
You
do
your
changes
there
and
then,
when
those
changes
get
proposed
to
be
merged
back
in
via
a
request
to
merge
or
merge
requests
that
then
becomes
the
gate.
This
is
where
you
can
do
code
review.
This
is
a
peer
code
review.
This
is
where
approvals
can
happen.
Security
reviews-
and
this
is
also
where
you
can
manage
compliance,
for
example
like
mandating.
Who
has
the
ability
to
actually
merge
that
code,
then
that
gates?
Who
can
you,
can
change?
Who
can
make
production
changes?
A
The
last
component
here,
which
I've
touched
on
a
bit
because
they
are
all
interrelated,
is
automated
reconciliation
using
continuous
integration
and
continuous
delivery
of
CI,
CD
and
I.
Call
this
a
a
reconciliation
loop,
because
the
idea
with
git
Ops
is
that
you
are
continually
looking
at
the
state
that
is
running
and
your
defined
state
and
if
those
are
out
of
sync,
you
want
your
automation
to
sure
those
up.
So
in
some
ways
of,
if
you
were
to
start
practicing
get
ops
potentially
you
could
run
your
CI
CD.
A
It
could
either
be
a
coal
or
a
push,
sometimes
is
what
we
would
call
agent
list.
This
is
how
get
lab
see.
Icd
works,
there's
a
lot
of
CI
tools
that
do
this.
If
you're
using
a
tool
like
spinnaker
4-cd,
will
talk
about
tooling
a
little
bit
more
towards
the
end
of
the
video.
But
the
idea
is
your
CI
CD
system
when
it
gets
changes
from
get
it
then
pushes
those
into
your
environment.
A
The
idea
here
is
that,
when
the
infrastructure
state
is
out
of
sync,
the
CSE,
the
updates
the
infrastructure
to
match
the
definition,
that's
an
git
and,
of
course,
all
changes
are
implemented
in
this
automated
fashion.
So,
when
you're
practicing
get
out,
you
don't
do
any
manual
changes
production.
This
is
a
fully
automated
CD.
A
This
is
what
the
flow
might
look
like
for
an
operations
engineer
that
is
practicing
get
ops.
They
might
have
start
with
an
issue.
Let's
say:
there's
a
bug
to
fix
or
a
new
feature
or
a
new
request
that
comes
in,
and
then
that
issue
they
can
make
sure
that
they
understand
everything,
that's
needed
and
collaborate
on
that,
and
then
they
want
to
create
the
merge
request,
which
starts
a
new
branch
away
from
the
main
branch.
A
In
this
case,
we've
called
it
feature,
but
you
could
call
that
that
side,
branch
of
patch
or
anything
that
you
had
a
new
proposal
and
you
commit
your
changes
to
the
new
branch
while
you're
committing
those
changes.
The
CI
automation
runs
automated
testing,
so
you
can
get
a
lot
of
code,
quality
and
security
and
bugs
out
of
the
way
just
via
that
automated
testing.
Next
up
is
concept
of
a
review
app.
Now
you
may
or
may
not
use
review
apps
with
review
apps.
Essentially
what
you
have
is
within
that
feature
branch.
A
You
then
spin
up
at
production
like
environment,
to
test
that
those
changes
out
in
a
running
production
like
environment.
This
is
essentially
like
having
a
staging
environment
for
every
single
branch
proposal.
This
is
nice
because,
unlike
having
a
singular
staging
environment,
where
many
people's
changes
that
you're
testing
could
conflict
with
each
other,
you
can
test
each
proposed
change
in
isolation
and
that's
a
nice
component,
so
whether
you're
using
a
shared
staging
environment
or
staging
environments
on
every
branch
which
we
call
review
apps.
A
Those
are
different
ways
to
handle
it
and
have
some
benefits
for
each
each
one.
Some
pros
and
cons
within
that
you
can
then
do
peer
review
and
discussion
on
the
merge
request,
a
collaboration,
and
if
you
have
the
review,
app
staging
environment,
you
can
even
review
the
changes
live.
That
can
be
a
great
part
of
the
collaboration
system,
and
then
you
want
a
git
management
system
that
allows
you
to
have
approvals
to
manage
your
compliance.
A
A
Finally,
when
the
merge
request
is
merged,
it
closes
out
the
issue
and
the
main
production
pipeline
runs
which
is
going
to
enact
those
changes
to
the
production
environment,
and
once
it's
running
you
then
even
monitor
that
environment
or
monitor
the
applications
running
in
the
environment.
So
this
flow
looks
very
very
similar
to
what
a
git
lab
flow
or
git
flow
would
look
like
for
software
developer,
just
practicing
devops
with
their
application
development.
The
only
difference
is
this
is
proposing
infrastructure
changes
for
an
Operations
engineer,
so
git
and
infrastructures
code
are
related
terms.
A
I
would
even
think
of
get-ups
as
encompassing
many
things
and
a
component
of
that
as
infrastructures
code,
as
I
just
talked
about
earlier
infrastructures,
code
plus
merge
requests,
plus
CI
CD
equals
get
ops.
Let's
talk
a
little
bit
more
about
how
these
terms
are
related
to
each
other
with
git
ops.
Of
course,
you
have
code,
it's
going
to
be
stored
and
good.
When
you're
using
infrastructures
code
it
may
or
may
not
even
be
under
version
control.
A
You
could
be
defining
your
environments
in
code
and
using
a
tool
that
allows
you
to
define
your
environments
via
code,
but
that
doesn't
Cecilia
mean
your
versioning
them.
It
could
be
living
in
a
flat
text.
File
somewhere
and
that's
still
infrastructure
is
code,
but
it's
not
good
apps.
Similarly,
using
merge
requests
as
your
agent
of
change
if
you're
not
version
controlling
or
maybe
even
if
you
are
version
controlling,
you
may
or
may
not
have
to
go
through
any
kind
of
review
or
approval,
or
you
know,
code,
quality
process
and
collaboration.
A
So
if,
with
infrastructures
code,
there's
no
mandate
to
use,
merge
requests,
but
doing
this
in
the
practice
of
get
ups,
get
you
all
these
benefits
and
then,
similarly,
with
git
ops,
infrastructure
updates
are
automated,
whereas
when
you're
doing
infrastructures
code
it
may
or
may
not
be
automated,
perhaps
you're
using
command
line
tool
to
run
and
update
your
infrastructure.
And
so
it's
not
necessarily
automated.
It
could
be
a
manual
process.
A
But
if
you
look
at
how
these
are
related,
essentially
get
ops
is
infrastructure,
as
code
done
right,
if
you're
practicing
a
feature
search
code
and
you
are
doing
all
of
the
best
practices,
then
that
starts
to
look
a
lot
like
get
ops.
So
now
that
we've
defined,
what
get
ops
is
let's
talk
about?
What
some
of
these
benefits
are?
Why?
Why
is
get
ups
important
and
what
value
is
it
going
to
bring
to
your
organization
or
what
value
does
it
bring
to
organizations
that
are
practicing
it?
A
So
I'll
talk
about
these
benefits
in
the
context
of
using
different
components.
So
the
first
is
the
benefits
of
storing
your
definitions
in
code.
So
when
you're
doing
infrastructures,
code
or
excess
code,
you
automatically
get
some,
it's
one
is
self-documenting
environments.
If
your
environments
are
configured
manually
via
a
GUI
based
tool,
then
you
need
to
have
your
document
to
the
documentation.
For
that
completely
separate.
This
means
if
someone
else
wants
to
come
along
and
understand
what's
happening.
A
Hopefully,
the
documentation
is
up-to-date
and
if
you're
trying
to
do
any
type
of
collaboration
or
even
if
you
just
want
to
remind
yourself
what
did
you
do
last
week
or
last
year,
sometimes
that
can
be
tricky
depending
on
how
good
your
documentation
was,
whereas
if
all
of
your
environments
and
your
infrastructure
are
defined
as
code
now
now
you
can
just
go
and
read
and
see
what's
happening
and
to
some
degree
itself,
it's
self
documenting.
This
doesn't
completely
alleviate
the
need
to
do
any
documentation
whatsoever.
A
Like
I've
mentioned,
you
know,
maybe
it's
next
week
you
completely
forgot
so
you're
being
kind
of
your
new
tape,
your
new
team
members
or
existing
team
members
and
your
future
self,
by
keeping
good
documentation
and
even
if
you're
doing,
infrastructures
code
that
documentation
might
be
like.
Let's
say
in
a
readme
within
the
same
repository,
so
there
are
even
some
benefits
there,
but
to
a
large
degree
you
get
these
self
document
environments.
You
also,
then,
as
I'm
already
looting,
to
get
shared
knowledge
among
your
teams.
A
Let's
say
you
have
a
team
in
Brazil
and
they
have
built
out
the
set
of
infrastructure
and
running
an
application,
and
things
are
going
really
really
well.
You
want
to
proliferate
those
best
practices
that
that
team
has
come
up
with
over
to
your
team
in
the
UK.
Well,
now
you
can
share
that
knowledge,
because
you
can
say
here
is
the
code
repository
defining
everything
that
we've
done?
Essentially,
this
is
the
value
of
open
source
when
you
share
your
code
with
the
world
and
anybody
can
see
what's
happening
or
in
this
case
inner
source.
A
The
same
way
you
can
inner
source
your
application
code,
you
can
inner
source,
your
operations
code
and
your
infrastructures
code,
and
that
way,
it's
easy
to
share
knowledge
between
teams,
even
once
this
gets
over
to
the
UK
changes
that
they
make
and
adapt
and
improvements
that
are
made
and
easily
be
shared
back
because
it's
all
defined
in
code.
Finally,
this
makes
it
much
much
easier
to
then
start
to
be
able
to
duplicate
your
environments.
A
Let's
say
that
the
UK
team
wanted
to
completely
just
take
the
environment
that
the
Brazil
team
came
up
with
and
just
to
play
it
as
is
or
enact
it
and
created,
as
is
well
that
can
be
done
when
you
have
infrastructures
code.
If
everything
is
defined
as
code
now,
you
can
just
state
that
definition
and
and
clone
it
as
many
times
as
you
need
this
might
be
to
set
up
a
similar
or
the
same
environment
in
different
regions
or
to
make
different
instances.
A
This
might
be
so
that
stage
and
prod
look
the
same
or
feel
the
same,
or
this
might
be
a
case
where
there's
a
problem
or
a
bug
in
your
environment
has
come
collapsed
and
you
need
to
recreate
it.
Well,
you
can
do
that
if
your
definition
is
stored
in
code.
The
next
set
of
benefits
come
when
it's
not
just
stored
as
a
code
definition,
but
you
have
it
under
version
control
to
be
able
to
rollback
and
roll
forward
within
history.
A
So
the
first
thing
a
benefit
you
can
get
out
of
this
is
you
can
begin
to
in
some
instances
couple
the
application
version
to
an
infrastructure
version
or
at
least
set
a
dependency
between
those
two.
They
don't
necessarily
need
to
be
tightly
coupled.
In
fact,
I'll
talk
later
on
about
how
it's
even
better,
if
these
things
are
loosely
coupled
or
completely
separate,
but
if
they're
both
version-
and
you
can
determine
that
this
version
of
the
application
needs
a
certain
version
of
the
infrastructure.
A
You
can
get
some
benefits
out
of
this,
for
example,
let's
say
you
have
an
application
and
in
the
first
version
you
got
it
out
quickly.
You
got
it
out
to
your
users,
your
testing,
but
there's
a
rather
large
memory
leak,
and
so
in
order
to
run
in
production,
it
needs
a
lot
of
memory
dedicated
to
this
application
to
be
running
well
in
the
next
iteration
cycle.
You
fix
the
memory
leak
and
you
know
maybe
some
other
bugs
and
you
get
that
out
there,
and
so
in
order
to
save
money.
A
You
now
cull
down
your
environment
and
you're
using
a
lot
less
memory.
Well,
now,
all
of
a
sudden,
you
figure
out
that
there
is
a
bug
in
the
code.
Something
is
not
working
right.
It's
not
the
right
user
experience.
I
need
to
roll
the
code
back
to
the
previous
version.
Well,
the
problem
with
that
is
that
that
previous
version
of
the
code
still
had
this
memory
leak.
A
It's
still
used
up
all
of
this
memory
and
if
you
deploy
that
into
this
environment,
that
has
just
this
very
small
amount
of
memory
is
designed
for
a
much
more
optimized
set
of
code.
The
application
is
just
going
to
fall
over
on
itself,
whereas
if
your
environment
is
also
defined
as
code
now,
you
can
roll
back
that
environment
to
the
previous
version
as
well
that
spins
up
the
additional
resources
needed
to
handle
that
particular
version.
It's
a
really
powerful
benefit.
Another
benefit
is
not
related
application
code
at
all.
A
But,
let's
just
say,
your
infrastructure
itself
is
misconfigured.
There
is
a
bug
or
a
problem
within
your
infrastructure
definition.
If
it's
in
version
control
now
it
makes
it
easy
to
roll
back.
The
last
known
good
configuration
when
you
detect
a
problem
instead
of
having
to
wait
until
you
have
done
all
of
your
forensics
and
troubleshooting
to
uncover.
What's
wrong,
you
can
roll
back
to
the
last
known
good
configuration,
have
things
up
and
running
quickly
and
then
do
your
forensics,
very
powerful
mechanism
and,
of
course,
when
you're
doing
this,
this
lowers
your
mean
time
to
recovery.
A
We
know
from
organizations
like
Dora
that
when
you
are
practicing
these
kinds
of
DevOps
best
practices
and
again
get
ops
is
like
doing
DevOps
for
infrastructure
that
there
are
positive
business
outcomes
that
come
from
practicing
DevOps.
So
businesses
tend
to
get
larger
market
share,
tend
to
grow
revenue,
faster,
etc.
Have
all
these
positive
business
outcomes
when
they're
practicing
good
DevOps
and
good
software
development.
A
So
we
know
that
there's
a
direct
correlation
between
positive
business
outcomes
and
lower
mean
time
to
recovery
so
having
your
infrastructure
definitions
under
version
control
and
being
able
to
roll
back
to
that
last
known.
Good
configuration
lowers
your
time
to
recovery
when,
when
things
are
wrong
and
you
need
to
sort
things
out.
A
The
the
next
bit
of
benefits
is
the
automation
benefits.
So
when
you
are
automating
CI
CD
you
BSES
CD,
you
get
some
benefits,
so
the
first
is
that
you
can
deploy
faster
more
often,
this
is
really
the
value.
If
you
have
application
code
that
is
being
shipped
and
iterated
on
very
quickly
and
is
able
to
be
deployed
very
very
quickly.
Well,
you
want
your
environments
themselves
to
be
able
to
be
iterated
on
very
very
quickly
and
that's
what
get
off
Spivs
you.
A
Finally-
and
this
is
what
I
find
to
be
the
the
benefit
that
I
hear
the
most
about
or
them
brings
even
the
most
value,
especially
the
large
organizations-
is
that
get
ops
allows
them
to
be
secure
and
compliant.
So
one
of
the
benefits
here
is
the
way
that
you
are
granting
permissions
to
your
environment.
Without
get-ups,
you
tend
to
have
a
lot
of
different
environments
and
everybody
who
needs
access
to
do
anything
at
all
to
those
environments
needs
direct
access
to
those
environments.
A
Similarly,
auditing
becomes
a
lot
easier
when
your
get
log
of
all
the
changes
that
were
made
becomes
that
that
log
of
what
the
changes
were
in
a
manually,
configured
environment
where
you
or
when
you
have
manually
configured
your
environments.
When
that's
what
you
have
to
have
to
contend
with,
then
you
tend
to
have
to
go
around
to
a
lot
of
different
places
and
potentially
different
tools
and
gather
a
lot
of
information
in
order
to
do
your
auditing.
A
Whereas
if
everything
is
stored
in
one
place,
you
have
a
git
repository,
and
these
are
the
changes
that
have
been
done
to
this
environment.
You
have
a
nice
clean
log
in
the
'get
history.
This
is
very,
very
powerful
that
that
can
speed
up
your
auditing
process
immensely
and,
of
course,
you
can
comply
with
any
type
of
change
process
rather
than
having
to
be
in
the
old
world
of
getting
into
a
meeting
with
people
to
discuss
the
change
process.
It's
very,
very
heavyweight,
that's
very,
very
slow.
Now
you
can
have
very
very
quick
changes.
A
Anybody
can
propose
a
change
quickly.
It
can
be
reviewed
very,
very
quickly
because
it's
in
code-
and
it
could
be
enacted
very
very
quickly
and
at
the
same
time,
you
can
have
all
that
speed
and
still
be
compliant
and
still
have
a
small
set
and
a
defined
set
of
people
who
are
able
to
make
those
changes
and
have
all
of
your
approvals
in
place
as
well.
So
this
is,
these
are
just
some
of
the
benefits
of
get
ups.
A
There
are
are
many,
but
these
are
some
of
the
big
ones
that
I
hear
about
often
so
with
that
we
talked
about
what
get-ups
is
why
it's
important.
Let's
talk
a
little
bit
about
how?
How
can
you
start
doing
good
apps?
What
does
a
good
ops
team
look
like
what
are
the
technologies
involved
and
and
what
are
some
of
the
challenges
that
you
might
face
when
you
start
to
go
and
adopt
it
ops
or
when
you
start
to
deepen
your
good
ops
practice
well
to
start
out
list?
A
Let's
look
at
team
structure
now
there
are
an
infinite
number
of
configurations
for
how
to
structure
your
teams
and
your
org
chart.
This
is
one
that
I've
seen
the
most
common,
so
there
are
a
lot
of
different
ways
to
do
this,
but
of
those
the
commonalities
that
seem
to
come
from
the
successful
teams.
This
is
a
representation
of
that
and
there's
usually
three
components
with
two
to
three
sets
of
teams.
A
So
you
would
have
your
development
teams
represented
by
these
these
vertical
slices
and
each
of
these
slices
can
represent,
let's
say,
a
feature
team
or
a
product
team
working
on
a
particular
product
or
in
this
case
a
micro
service.
So
each
of
these
teams
owns
a
single
micro
service
or
perhaps
a
set
of
services,
and
those
services
or
applications
are
delivered
to
production
on
a
platform.
A
So
the
deployment
platform
is
run
and
managed
by
the
platform
operations
team
and
the
operations
team
is
going
to
be
responsible
for
the
the
clusters,
and
in
this
case
it's
kubernetes,
you
can
do
get
ups
without
kubernetes.
You
can
do
get
ups.
You
can
do
all
of
these
things.
You
can
have
your
infrastructures
code.
You
can
use
merge
request
as
your
change
agent.
A
You
can
apply
your
changes
via
automation
and
you
can
do
that
all
without
doing
containerized
kubernetes
applications,
but
what
we've
seen
is
that
git
Ops
has
taken
off
the
most
within
the
cloud
Native
community
and
that
the
very,
very
mature
get
ops
practitioners
are
using
kubernetes.
So
in
this
case
the
platform
operations
teams
they're
the
ones
that
are
managing
the
clusters,
creating
spinning
up
managing
those
clusters
and
serving
that
platform
up
to
the
dev
teams.
A
There
also
is
an
optional
component
of
an
infrastructure
team,
so
at
some
point
there
needs
to
be
a
server
somewhere.
I
can't
just
be
Turtles
all
the
way
down.
It's
got
to
be
running
on
a
server
somewhere,
that's
either
a
server
in
your
on-premises
data
center
or
a
server
managed
by
you
know,
usually
a
hyper
cloud
AWS
or
Google
or
Azure,
etc.
And
then
you
have
so
you
may
have
an
infrastructure
team.
A
That's
either
managing
your
first
web
structure
or
they're,
managing
a
set
of
virtual
machines
and
configuration
and
were
within
a
cloud
provider
like
AWS,
and
so
it
could
be
within
your
organization
that
your
platform,
engineering
team
owns
not
only
the
clusters,
but
they
also
do
all
the
infrastructures
work
as
well.
I've
also
have
seen
organizations
where
they
have
a
dedicated
infrastructure
team
and
a
separate
platform
operations
team
that
just
manages
that
that
middle
layer
within
the
dev
service
teams,
what
I've
seen
is
a
best
practice
of
having
those
as
cross-functional
DevOps
teams.
These
are
siloed.
A
All
the
developers
are
here.
All
the
quality
people
are
here
all
the
operation,
the
people
who
operate
the
application
over
here,
but
those
people
actually
sit
together
and
work
together
or
virtually
sit
together
in
the
case
of
a
remote
work.
Those
those
folks
are
a
part
of
a
cross-functional
team,
and
the
idea
here
is
also
that
there's
not
a
complete
separation
of
concerns.
A
So
it's
not
like
you
have
developers
who
are
doing
100%
of
the
software
development
and
then
they
chuck
it
a
offense
to
let's
say
a
site,
reliability
engineer
to
operate
and
monitor
that
application.
When
it's
when
it's
running
the
split
here
is
kind
of
like
a
Pareto
principle
of
an
80/20,
so
the
developers
are
usually
80%
software
development,
but
they
understand
how
the
application
operates.
They
understand
how
to
monomyth
application.
They
can
own
the
pager
if
their
service
goes
down
they're
the
one
that
fixes
that
they
not
only
develop
it.
A
But
the
team
owns
the
running
of
that
service
as
well.
So
it's
80/20
development
operations
for
the
devs
and
the
srvs
would
be
like
20%.
They
understand
how
the
application
is
built.
They
know
that
they
know
the
software
development
part
of
it,
but
their
primary
concern
is
the
operation
of
that
service.
So
that's
the
cross-functional
DevOps
team.
You
have
the
platform
team,
they
own
the
clusters,
if
the
environments
go
down
or
if
the
cluster
goes
down,
that's
the
platform
operations
team
that
gets
Paige
there.
A
From
doing
this,
if
you're
on
a
small
team
or
a
single
developer,
you
might
just
be
a
single
developer
and
you're
just
doing
all
of
the
good
apps
yourself
and
the
person
who's
approving
is
yourself,
but
if
really,
if
you're,
on
a
team
of
two
or
more
using
git
Ops
gets
you
this
collaboration
benefits
and
even
as
your
teams
grow
you,
you
know,
there
might
just
be
two
or
three
of
you
and
you're
doing
everything
across
the
stack,
but
you
can
still
practice
get
ops.
So
it's
a
little
bit
about
the
team
structure.
A
Let's
now
take
a
look
at
some
of
the
technologies
that
are
involved,
what
are
the
tools
or
the
technologies
and
the
capabilities
that
you
need
in
order
to
do
to
get
ops.
So,
of
course
you
need
a
git
repository.
I've
talked
about
that,
but
in
addition
to
that
git
repository,
you
really
need
a
git
management
tool.
A
Next
up,
we've
have
already
mentioned
talking
about.
You
need
a
continuous
integration
tool.
This
will
allow
you
to
automate
any
of
your
testing
and
quality
checks,
builds
etc.
Do
all
of
that
in
an
automated
fashion,
with
continuous
integration,
then
core
and
critical
to
practicing
get
ops
is
the
continuous
delivery
tool.
So
this
is
not
only
automating
your
build
and
test,
but
automating
the
deployment
itself,
and
this
is
not
just
automating
the
deployment
of
the
application
code
but
automating
the
application
of
the
infrastructure
code
or
the
the
enacting
of
infrastructure
code.
A
So
when
you
are
deploying
or
creating
or
changing
your
infrastructure,
those
changes
happen
in
an
automated
fashion.
Those
are
delivered
continuously
via
continuous
delivery
and
there's
a
lot
of
different
tools
here.
They
could
be,
as
I
mentioned,
pull
based
tools
like
your
lab
and
spinnaker,
or
our
push
faced
tools.
There
could
be
a
pull
based
tool
like
we've
worked
flux,
which
has
an
agent
that
runs
within
the
kubernetes
cluster
is
known
as
a
kubernetes
operator.
A
Next
up,
if
you
are
doing
kubernetes
development
or
containerize
development,
you're
going
to
need
a
container
registry
in
order
to
store
your
containerized
applications
now.
Also
on
the
list
here
is
the
configuration
managers.
This
is
the
traditional
way
to
do
infrastructure
as
code
using
tools
like
chef
and
puppet
and
ansible
salt,
etc.
A
These
are
the
traditional
infrastructure
as
code
tools
that
really
started
when
DevOps
started
and
in
some
ways
when
you
start
container
izing
your
applications.
All
of
your
server
definition
is
within
your
docker
file
and
that
alleviates
some
or
all
of
the
need
for
any
type
of
configuration
manager.
A
So
in
some
cases
you
may
not
need
a
configuration
management
tool,
but
what
we
find
is
for
for
many
folks,
they're
still
using
a
tool
like
ansible
to
do
configuration
management,
even
if
it's
just
at
the
infrastructure
layer
where
they
are
dealing
with
servers
that
need
to
need
to
be
configured
or
virtual
machines,
etc.
The
nodes
for
the
cluster
sort
of
speak.
A
In
addition
to
this,
you
not
only
need
to
have
your
configuration,
but
your
provisioning
as
well.
What's
actually
going
to
go
out
and
enact
those
changes,
particularly
within
a
cloud
environment.
Well,
we
see
folks
is
when
they're
completely
on-premises.
They
might
only
use
configuration
management,
but
once
they
start
moving
to
the
cloud,
then
tools
like
terraform
and
plumie-
and
you
know
AWS
CloudFormation-
become
very,
very
critical
and
folks
are
adopting
care
form
when
they're
moving
to
the
cloud,
because
this
is
not
just
about
provisioning.
A
The
virtual
machines
themselves
and
saying
ok
I
need
this
type
of
virtual
machine
with
this
size,
etc,
but
also
the
network
firewall
any
type
of
configuration
or
any
type
of
provision
provisioning
for
the
environment.
Anything
that
you
need
to
that
environment
I
need
to
spin
up
this
environment.
Please
give
it
to
me
cloud
provider.
You
need
to
have
a
provisioning
tool,
bloom
et
cetera
and,
of
course,
we've
talked
a
lot
about
kubernetes
Cooper
Day
is
not
required
to
do
get
ups.
A
With
that
look,
having
looked
at
the
technology
and
the
tools,
let's
talk
a
little
bit
as
we
go
to
wrap
it
up.
What
some
of
the
challenges
you
might
face
as
you
go
to
adopt
get-ups
within
your
context,
so
the
the
first
challenge
whenever
you're
you
are
looking
to
change
anything
within
your
organization.
The
first
challenge
is
always
cultural.
There
are
hearts
and
minds
and
practices
that
need
to
change
along
with
the
technology.
People
everywhere
are
always
used
to
doing
that.
A
Then
they
start
to
buy
into
it
more
because
it's
it's,
it's
proven
the
point
where,
as
before,
they
didn't
know
if
it
was
going
to
work
or
not
so
the
idea
here
is
that
operations
engineers
in
order
to
do
get
ops
are
going
to
need
to
adopt
a
developer,
centric
view
of
their
work
and
operations.
Engineers
may
not
want
to
do
that.
Many
many
do
many
are
you
know,
operations
people
are
learning
software
development
and
thinking
about
their
jobs
and
an
engineering
way
and
automation
is
all
very
exciting
to
them.
A
But
some
folks
are
not
very
excited
about
that
and
they've
been
doing
this
for
a
long
time,
and
so
one
of
the
challenges
you
may
just
the
face
is
that
get
ops
really
is
a
developer.
Centric
workflow
and
if
your
developer
get
ops,
is
an
amazing
way
to
run
your
infrastructure
because
it
leverages
everything
you're
already
doing
and
everything
you
already
know.
If
you
are
an
Operations
engineer,
this
may
be
completely
new
to
you,
and
so
it
requires
learning
some
new
skills
and
some
new
practices.
A
Next
is
that
the
next
barrier
that
you
may
face
is
that
you
need
a
sophisticated
level
of
deployment
automation
I
mentioned
this
earlier.
This
is
about
not
just
automating
through
CI,
but
also
very
sophisticated
CD
and
your
organization
or
your
team.
Just
may
not,
may
not
be
there
and
that's
okay,
you
don't
have
to
be
all
the
way
doing.
100%
get
apps
for
everything
to
to
get
some
of
the
benefits
from
doing
some
good
ops
right,
so
you
can
even
just
start
out
by
using
infrastructures
code.
A
Finally,
not
not
everything
should
be
good
apps,
not
all
operations
belong,
and
yet
these
are
a
few
that
I
can
think
of
that
may
or
may
not
work
the
best.
If
they're
defined
as
code,
you
can
think
of
something
like
a
observe,
observe,
observe
ability,
tools,
your
logging,
your
tracing,
your
monitoring,
there's
a
lot
to
be
done,
and
they
are.
A
There
are
very
sophisticated
tools
for
that
and
if
you
try
to
distill
that
all
down
and
to
get
and
require
a
merge
request
for
every
single
change,
it's
a
pretty
heavyweight
process
for
every
single
change
that
we
need
to
be
made.
I,
don't
think
for
observability
tools,
we're
going
to
see
them
moving,
lock,
stock
and
barrel
and
to
get
anytime
soon
that
doesn't
see
that
make
sense.
A
Another
example
of
this
might
be
feature
flags,
for
example,
if
you
are
doing
progressive
delivery
and
you
are
feature
flagging,
your
applications
so
that
it's
serving
different
code
to
different
users
at
different
times
under
different
circumstances.
This
is
a
wonderful
software
development
practice
that
lets
you
deploy
under
less
risk
and
it
lets
you
test
changes,
but
it
doesn't
really
make
sense
to
define
that
all
I
get
or
for
every
change
to
flipping
a
feature
flag
on
or
off,
requiring
a
merge
request
that
again
kills
heavyweight.
A
Apparently,
some
type
of
you
know
operations
practice
like
incident
management,
although
certainly
large
components
of
managing
incidents
when
your
infrastructure
is
down
or
degraded
when
there's
a
problem,
and
you
need
to
bring
things
back
up
some
components
of
that
having
things
that
are
written
down
and
text
base
or
code
base
format
that
can
be
versioned
and
shared,
there's
certainly
going
to
be
some
benefits
there,
but
there's
a
large
component
of
incident
management.
A
large
part
of
that
toolset
that
really
just
doesn't
belong
and
get-and
is
a
is
a
parallel
practice.
A
Alongside
of
git
ops,
that
isn't
necessarily
you're
not
going
to
get
ups
and
put
all
of
your
incident
management
into
a
git
repository.
So
those
are
just
a
few
there's,
probably
more.
If
you
can
think
of
more,
you
can
comment
on
the
video
or
reach
out
to
us
on
Twitter,
but
these
are
just
some
of
the
challenges
so
with
that
I
want
to
thank
you
for
hanging
out
for
the
video
we
talked
about.
A
What
get
ops
is
why
get
ops
is
important
and
how
you
can
start
adopting
it
if
this
has
been
helpful
or
you
learn
something
new
I'd
love
to
hear
from
you
like
I
said,
please
leave
a
comment
on
the
video
or
reach
out
to
get
lab
or
myself
the
William,
chia,
Twitter
and
we'd
love
to
just
continue
conversation.
Good
Ops
is
continually
evolving,
we're
learning
more
and
things
are
changing
and
as
those
change
we
would
love,
we
at
get
Lahab
would
love
to
collaborate
with
you
and
co-create
with
you,
this
new
fun,
exciting
future.