►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Deploy, Release, CI/CD, Oh My! DevOps for the Rest of Us - Jeremy Meiss, CircleCI
While it seems that every week new terms appear to describe DevOps tools, segments, ideas, practices, etc., are they really new? And with so many entering the DevOps community, plenty of these terms form a word salad that is tough to sort out. CI/CD, Progressive Delivery, AIOps, GitOps, TreeOps (not real, yet?) - are they all the same, or are they just reimagining last week’s buzz words? In this talk we will break down a few of these terms, what they mean, how they’re used, and why they may matter for you and your teams and set a baseline for interacting with the DevOps community.
A
All
right
well,
I
think
we're
about
ready
to
get
started
so
we're
gonna,
so
I'll
go
and
get
started.
So
yeah
we're
gonna
talk
about
deploy,
release,
ci
cd,
oh
my
or,
as
I
call
it
kind
of
devops
for
the
rest
of
us.
You
know
it
seems
every
week
that
there
are
a
lot
of
different
new
terms.
That
kind
of
appear.
You
know
to
describe
the
different
devops
tools
and
segments.
You
know
the
ideas,
the
practices
et
cetera,
but
I
think
the
question
for
me
often
is
is
like.
A
Are
any
of
these
really
new?
You
know
you
have
ci
cd.
You
got
progressive
delivery,
ai
ops,
git,
ops,
tree
ops,
okay,
it's
not
really
a
real
one,
but
I
mean
maybe
next
week,
and
I
will
absolutely
confess
that,
as
I
was
building
this
talk
and
started
doing
this
about
a
year
ago,
I
did
in
fact
register
devtreeops.com
and
treeops.cloud
and
put
a
coming
soon-ish
website
on
it.
So
yeah
I
have
over
two.
You
know
this
kind
of
illustrates.
A
A
You
know
the
twitter's
timeline.jurordog.me,
which
I
don't
keep
up
to
date
as
much
as
I
should,
but
you
can
find
me
there
so
with
all
these
different
terms
that
are
out
there,
you
know,
are
they
all
the
same
or
are
they
just
kind
of?
You
know
reimagining
the
buzzwords
from
last
week,
and
sometimes
like
feels
like
companies
they
like
to
kind
of
chop
up
a
lot
of
these
buzzwords,
throw
them
all
together
and
voila.
They
have
a
new,
you
know
devops
term
or
a
devops
solid,
that's
born.
A
So,
as
we
think
about
you
know
the
devops
life
cycle,
there's
kind
of
the
hope
of
how
we
implement
this.
This
kind
of
this
thing
and
then
there's
really
the
reality.
John
alsball
called
this.
The
you
know
work
as
imagined
versus
work
is
done
in
this
in
this
tweet
that
he
sent
over
six
years
ago
now,
and
it
really
illustrates
all
of
my
coding.
A
My
attempts
at
coding
really
is,
I
feel,
like
I'm,
going
to
get
through
the
finish
line,
and
next
thing
I
know,
I'm
you
know
middle
of
the
I'm
drowning
in
the
middle
of
my
own
inability
to
do
so,
and
this
image
really
illustrates.
I
think,
where
we
get.
You
know
when
we
think
about
the
devops
life
cycle.
You
know
how
we
try
and
put
things
together
within
our
teams.
You
know
so
there's
the
hope
of
how
we're
gonna
you
know.
A
A
So
we'll
start
with
aiops
so
gartner
they
coined
the
term
which
is
short
for
artificial
intelligence
for
it
operations
and
since
they
coined
the
term,
they
get
to
define
it
which
defined
it.
As
you
know,
combining
big
data
machine
learning
to
automate
it
ops
processes,
including
event,
correlation
anomaly,
detection
and
causality
determination,
sounds
like
the
architect
from
the
matrix
kind
of
walking
through
everything
there.
But
another
way
to
put
this
wikipedia
had
that
kind
of
goes
more.
A
It's
you
know
an
industry
category
for
machine
learning,
analytics
technology
that
enhances
it
operations
analytics.
So
these
tasks
that
they're
talking
about
they
are.
You
know,
automation,
performance,
monitoring,
event
correlation
among
others,
and
there
are
two
main
aspects
of
what
an
ai
ops
platform
kind
of
looks
like.
So
you
have
the
machine
learning
piece
and
you
have
the
big
data
piece
in
order
to
collect
data
from
you
know
that
big
data
platform,
so
that
you
can
observe
it
and
then
engage
with
it.
A
You
kind
of
have
to
shift
away
from
segregated
I.t
data
towards
kind
of
this
whole,
more
holistic,
machine
learning
and
analytic
strategy.
The
goal
there
is,
then,
you
know
to
make
sure
you
receive
continuous
insights,
so
you
can
continuously
fix
and
improve
via
automation,
so
to
kind
of
simplify
things
into
one
grouping
of
images.
A
It's
relatively
simple
right,
it's
kind
of
simplified
makes
a
little
bit
more
sense.
You
know
it's
really
is
it's
an
ai
ops
platform
that
helps
aggregate
make
sense
of
all
the
different
data
sources
within
your
your
platform,
within
your
code,
with
everything
that
you're
doing
identifying
all
the
links
and
all
the
interrelationships
between
those
kind
of
different
silos
within
your
platform
and
then
helps
to
kind
of
predict
events
hopefully
prescribe
solutions
that
are
going
to
work
and
then
act
based
on
kind
of
that
real
time.
A
Data
streams
that
are
coming
in
get
ops
so
get
ops.
Is
it's
relatively
new?
There
isn't
even
a
wikipedia
page
for
it,
and
I
did
just
check
just
so
we're
clear
before
doing
this
again.
It
has
just
started
appearing
kind
of
in
the
last
few
years,
but
it
is
newer
than
than
aiops
there's,
not
even
a
page
for
if
you
type
in
get
space
ops
on
wikipedia
you
know,
if
you
type
in
git
ops,
it
does
appear
as
kind
of
a
subset
of
the
larger
devops.
A
But
even
then
it's
like
a
sentence,
so
there's
not
really
been
a
whole
lot
of
of
effort
put
into
defining
this
at
least
on
wikipedia-
and
you
know
I've
been
doing
this
talk
now
for
almost
a
year
and
nobody
has
kind
of
stepped
up
to
kind
of
jump
in
and
and
fill
that
void.
So
I
feel
like
this
is
probably
a
very
serious
oversight
by
the
devops
word
solid
gods
and
one
of
them
should
rectify
it,
which
I'm
sure
at
some
point.
One
of
them
will
figure
out
who's.
Gonna.
A
A
You
know
what
it
does.
Is
it
kind
of
it
attempts
to
take
this.
You
know
like
the
existing,
continuous
delivery
and
infrastructures
code,
principles
which
are
non-tool
specific
and
then
repackage
them
down
into
like
tool-specific
things,
and
so
you
know
that
causes
a
lot
of
different
controversy,
because
you
know
devops
tends
to
be
it's
about.
It's
not
about
the
tooling.
It's
about
the
processes.
It's
about
the
culture,
it's
about
the
pro
the
things
that
you're
going
to
put
in
place.
A
The
tooling
comes
afterwards,
but
by
trying
to
create
something
here,
it
definitely
creates
a
lot
of
controversy.
Whenever
somebody
mentions
you
know
asks
on
twitter
about
get
ops,
that's
the
you
know
becomes
the
topic
for
the
week.
So,
but
it
is,
you
know
it
is
out
there.
There
are
some
companies
that
are,
you
know,
attempting
to
do
a
lot
of
different
things
with
it,
but
yeah.
So
that's
that's
good
ops,
now,
devsecops,
so
phil
richards
in
a
in
a
post
on
threat
post
described,
described
it
like
this.
A
A
I
think
a
key
piece
here
is
like
each
delivery
team
is
empowered
to
factor
in
the
security
into
their
software
delivery
process
and
that
security
you
know,
and
testing
security
practices
and
testing
are
performed
earlier
in
the
development
life
cycle,
and
that's
that's
kind
of
where
this
term
shift
left,
you
know,
can
definitely
be
used.
That
phrase
has
become
pretty
common.
A
It's
a
security
team,
so
we'll
do
that
last
well!
The
idea
is,
it
needs
to
be
a
part
of
everything
that
we
do
so
that's
kind
of
that's
where
devsecops
kind
of
fits.
You
know
there
are
many
tools
out
there,
which
kind
of
the
desires
to
give
developers
the
resources
the
power
to
kind
of
implement
security,
as
you
know
that
important
part
of
the
life
cycle,
and
not
just
kind
of
as
that,
like
I
said,
is
that
after
thought
that
we
throw
over
the
wall
now
progressive
delivery.
A
So
there
are
two
kind
of
things
which
make
up
the
methodology
around
progressive
delivery.
One
is
kind
of
this
release
progression
and
that
refers
to
kind
of
taking
the
number
of
users
that
get
exposed
to
and
really
impacted
by
new
features
at
a
pace.
That's
appropriate
for
the
business.
So
starting
out
you
can
re,
perform
release
progressions
in
a
number
of
different
ways.
A
You
know
you
could
do
like
a
targeted
rollout,
so
it's
only
going
to
go
to
certain
people,
maybe
that
you've
identified
with
that
use
your
app
a
certain
way
or
there'll
be
like
canary
launches
ring
deployments,
as
it
keeps
getting
broader
and
broader
percentage
roll
out.
So
on
so
there's
you
define
it
as
what
works
best
for
your
business,
but
you
slowly
roll
it
out
to
minimize
impact
and
you
kind
of
think
of
like
a
release
progression
as
kind
of
like
a
progressive
deployment
or
progressive
release.
A
The
second
piece
is
kind
of
the
comes
down
to
like
progressive
delegation,
and
this
is
like
the
idea
here
is
you're
progressively
delegating
the
control
of
a
feature
to
the
owner.
Who
is
most
responsible
for
its?
You
know
the
outcome
or
the
success.
So
when
you
think
about
this,
when
you
initially
developing
the
tool
or
the
process,
whatever
you're,
whatever
you're
doing,
you
know
the
engineers
they're
controlling
that
feature,
they're
getting
it
done
because
they're
the
ones
that
they're
responsible
for
building
and
testing
it.
A
But
once
that's
been
tested-
and
it's
done,
then
it
makes
more
sense
for
like
the
product
manager
to
step
in
and
own
that,
because
then
they
now
control
the
process
of
launching
that
feature
and
then
the
you
know
letting
engineers
get
back
to
doing
the
engineering.
And
it's
it's
this
idea
of
progressively
pushing
the
delegation
of
the
people
that
are
most
responsible
for
its
outcome
now,
when
we
think
about
release
and
deploy
or
release
and
deployment
over
the
years.
I've
seen
a
lot
of
it.
A
That's
going
to
include
all
of
the
like
technical
activities
that
are
needed
to
make
us
a
software
system
or
feature
available
to
to
be
used.
So
if
you
think
about
like
a
docker
container,
that's
running
in
a
pod
on
kubernetes
cluster,
so
we're
just
gonna
use
some
buzzwords
here
and
throw
them
out
there.
A
A
It's
running
smoothly,
you're,
taking
all
the
kind
of
the
technical
checks
and
balances
and
placing
them
there
without
any
of
the
risk
that
can
be
involved
by
actually
starting
to
serve
production
data
to
it,
you
can
kind
of
think
about,
like
deploying
a
piece
of
software
is
or
really
should
be,
a
very
mundane
and
risk-free
activity
and
deployments
are
tend
to
be.
You
know,
they're
related
to
the
overall
kind
of
continuous
delivery
process,
but
they're
going
to
be
more
automated.
You
want
them
to
be
more
automated
getting
them.
A
You
know
ready
to
be
released
now
when
we
think
about
release
that's
going
to
come
after
the
deployment
that
includes
all
the
activities
that
are
needed
to
move
part
of
or
all
of
the
production
traffic
to
the
new
version.
So
you
know
this
is
where
all
the
risk
can
happen
is
where
all
the
things
can
go
wrong
is
when
it's
actually
starting
to
be
released
to
the
public
or
at
least
to
production
or
to
production
traffic.
A
Release
cycles
is
really
kind
of
just
this
overall
process
of
deploying
software
to
an
environment
and
then
ensuring
that
all
of
the
deployments
in
that
release
are
functioning
performing.
As
expected,
you
know
one
could
you
could
review,
you
could
view
release
processes
in
management
as
kind
of
being
related
to
continuous
delivery
concept,
but
their
individual
processes
themselves
now
continuous
integration,
continuous
deployment
depend
continuous,
yeah,
cicd,
that's
gonna,
that's
rooted
in
agile
methodologies.
A
It
really
embodies
kind
of
the
culture
of
a
team
or
a
company's
commitment
to
automation,
and
you
know
devops
principles,
agile
methodologies,
you
know
generally,
that's
contains
a
set
of
operating
principles.
You
think
about,
like
the
agile
manifesto
anything
that
has
a
manifesto.
It's
got
to
be
good
right.
It's
based
on
12
of
these
kind
of
methodologies,
operating
principles
and
then
like
a
collecting
collection
of
practices,
which
the
idea
was
to
enable
dev
teams
to
release
quality
code
more
frequently
and
reliably.
A
A
Hopefully
there's
a
laugh,
there's
only
a
couple
chuckles,
let's
have
a
big
I've,
never
actually
heard
of
what
scrumbonne
was
until
somebody
mentioned
in
a
recent
talk-
and
I
was
like
oh
okay-
I
never
guess
I
didn't
guess
the
teams
I
worked
on.
Never
did
that
right.
So
you
know
what
it
is
great
back
to
this,
but
it's
brought
about
like
a
variety
of
different
agile
software
development
practices.
A
A
That
came
with
this
idea
of
you
know
extreme
programming,
which
was
built
on
the
booch
method
and
that
advocated
itself
for
releasing
multiple
times
per
day.
It
really
kind
of
changed
the
game.
I
don't
know
if
anyone
here
remembers
this
book.
I
remember
I
had
it
on
my
desk.
When
I
worked
at
sprint,
it
was.
There
was
a
lot
of
really
great
stuff
there.
A
So
this
cut
we
started
to
see
coming
out
of
this.
Was
you
know,
shorter
release
cycles,
extensive
code
reviews,
or
you
know,
we
call
pair
programming,
now
unit
testing
acceptance
testing.
All
of
these
started
to
come
out
of
extreme
programming
and
they're
now
pretty
pretty
standard
because
of
it
from
here.
A
We
started
to
get
kind
of
a
lot
more
and
more
kind
of
methodologies
that
kind
of
built
on
this,
but
the
one
goal
was
still
in
mind
was
trying
to
make
it
easier
to
write,
clearer,
higher
quality
code,
get
it
out
to
the
users,
and
while
we
recognize
that
you
know
all
this
needed
to
happen,
we
really
didn't
have
the
tools
at
the
time
to
really
make
it
happen
on
the
scale
of
that
we
needed
at
least
not
easily.
Now
cruise
control
is
that
one.
Anyone
remember
that
there's
there's
only
a
couple
that
that
recommend.
A
Remember
that
one
for
sure
it
was
an
open
source
tool
was
the
first
one
that
made
continuous
integration
easier.
When
we
look
back
now,
it
really
did.
I
mean
easy's
a
very
interesting
term
back
then
it
was
the
first
of
its
kind
yeah,
and
so
you
know
compared
to
what
we
see
today.
It
was
really
primitive
and
pre
store
prehistoric,
but
it
was
a
game
changer
20
people
20
years
ago,
and
I
still
see
some
evidence
online
of
people
kind
of
still
using
it
in
some
form
or
fashion
today.
A
Sadly,
but
it
was
revolutionary
when
it
was
released,
you
know
for
the
first
time
there
was
this
system
that
could
be
installed
and
stood
up
by
yourselves
or
by
it.
You
know,
by
a
team
to
automate
the
management
of
builds
in,
allowing
you
know,
developers
to
you
know,
release
way
more
often,
and
it
even
would
integrate
with
your
ide.
So,
depending
on
the
ide
you
had,
you
would
have
to
have
a
specific
variant
of
cruise
control.
So
if
your
id
excuse
your
ide
was
eclipse,
then
you
had
a
java
specific
variant.
A
A
A
You
can
you
can
use
that,
and
you
know
it
is
it's
relatively
stable,
relatively
secure
still
is
pretty
popular,
but
the
downside
for
things
like
this
that
have
been
you
know,
become
hosted
solutions
that
kind
of
stand
up
and
to
kind
of
take
a
mind
of
their
of
their
own.
Is
that
you
know
the
way
that
we're
building
software
the
way
we're
deploying
it
the
way
we're
using
it
is
changing,
and
so
you
know,
jenkins
is
really
kind
of
starting
to
show
its
age
as
others
like
it
there's.
A
You
know
travis,
ci
and
and
few
others
are
kind
of
still
on
that
old
concept
of
host
it
yourself,
but
there
are
cheaper,
more
available
options
that
are
in
the
cloud
to
do
this.
That,
actually,
you
know,
like
I
said,
move
back
to
the
way
that
we
do
stuff
now
circle.
Ci
is
one
of
those
cloud
services.
There
are
others
they're
built
so
that
you
don't
have
to
really
babysit
your
ci
process
service
or
your
infrastructure,
letting
you
kind
of
get
back
to
the
business
of
writing
software.
A
You
know
if
your
business
is
not
meant
to
like.
If
you,
if
you're,
not
developing
a
ci
cd
platform,
then
you
probably
shouldn't
have
a
ci
cd
team
inside
your
company.
They
could
probably
be
better
used
integrating
back
into
your
you
know,
building
your
core
product
and
using
a
cloud
service
that
would
help
speed
up
what
you're
trying
to
do
in
all
of
these.
They
all
kind
of
have
the
support
lots
of
different
languages,
sometimes
all
of
them
that
are
out
there
different
build
environments.
A
A
Ultimately,
for
you
now
many
years
ago,
thankfully,
microsoft
visual
source
safe,
how
who
all
used
microsoft,
visual
source
safe,
who
all
regrets
having
to
use
microsoft,
visual
source,
safe,
okay,
at
least
one
of
us
in
here
I'll,
be
the
second
one.
It
was
great
for
what
it
was
when
it
came
out.
It
was
great
it
was
allowed.
For
you
know
the
attempt
was
kind
of
keep
you
from
over
working
on
code
that
someone
else
was
doing
the
idea.
You
checked
that
out.
A
It
operated
a
little
bit
differently
than
what
we
have
come
to
use
with
with
git,
but
that
was
the
idea
was
to.
You
know
make
sure
that
you
weren't
working
on
code
that
someone
else
was
working
on
in
theory,
that
was
good,
but
it
usually
did
dissolve
into
going
on
a
hunt
for
the
developer
that
decided
to
check
out
the
entire
directory,
instead
of
just
that
one
file
only
to
find
out
that
they
had
gone
on
vacation
and
you
had
to
get
it
to
take
care
of
it.
A
A
You
know
it
is
the
practice
of
merging
all
the
developers
working
working
copies
to
a
shared
code
repository,
which
means
that
your
your
merging
code
changes
often
so
the
team
itself
is
more
informed
about
what
each
other's
code
base
looks
like
the
potential
future
conflicts
it
might
arise
and
since
code-based
changes
are
being
merged,
often
it's
important
to
you
know
run
those
automated
tests
that
are
validating
that.
Those
changes
in
the
builds
are
are
quality
code
that
aren't
going
to
cause
any
issues.
A
If
you
think
about,
like
you,
know
the
ability
to
get
to
faster
fixes
ability
to
not
push
code
that
is
going
to
break
your
customers
way
of
working.
It
really
helps
you
kind
of
get
to
the
speed
that
you
know,
since
you
know
you're
once
you're,
writing
your
code,
it's
quality
and
it's
getting
deployed
and
you're
able
to
push
it
upstream.
A
Let
the
automation
take
over
where
it
needs
to
be
validate
the
builds
and
what
now
continuous
deployment
is
really
just
basically
automation,
the
goals
of
cd
and
producing
you
know
software
releases.
Are
it's
generally
going
to
be
like
automation,
efficiency,
reliability,
reproducibility,
verification
of
quality?
You
know
through
continuous
testing,
which
everybody
should
be
doing.
A
You
know
the
overall
chain
of
process
here
generally
gets
called
a
pipeline,
and
that
helps
us
with
you
know:
releasing
our
software
faster
by
automatically
getting
the
source
code,
changes
running
them
through
the
building,
testing,
packaging
and
other
related
operations
to
produce
that
release.
In
most
cases,
it
also
means
you're,
delivering
smarter
you're.
A
This
question
is
ci
cd,
a
tool,
and
so
in
the
spirit
of
every
answer
to
every
devops
question,
it
depends
much
has
changed
in
the
way
that
we
do.
You
know
the
developers
ship
and
build
code
so
in
when
you're
implementing
ci
cd
you're
really
implementing
the
practices
and
principles
which
aren't
really
about
the
tooling.
A
It
is
important
that
you
and
your
teams,
you
know,
sit
down
and
understand.
You
know
how
you're
going
to
be
implementing
these
processes
in
principles,
because,
like
cicd,
aims
to
break
down
those
walls
between
dev
and
ops
and
get
everyone
on
the
same
page
working
together,
you
don't
have
to
implement
ci
cd
all
at
once.
Instead,
you
can
kind
of
think
about
that
very
process
of
being
something
very
iterative
itself:
the
systems
and
tech
that
are
currently
in
place
for
your.
A
So
the
fundamental
tenet
of
ci
cd
is
quite
simple,
commit
and
integrate
your
code
often
daily
at
a
minimum,
and
such
a
small
change
in
your
software
development
process
can
can
really
yield
some
bigger
yield.
Big.
So
and
when
we
talk
about
speed
obligatory,
you
have
to
put
the
top
gun
one
up
there
about
ci
cd
gives
you
speed.
Getting
amazing
speeds
as
a
business
become
a
high
performing
team.
So
when
you
think
about
high
performing
teams,
it's
important
to
have
one
important
to
be
a
part
of
one.
A
Much
like
these,
who
I'm
assuming
are
product
managers,
I'm
sure
that's
that's
kind
of
what
they
at
their
on
sites,
that's
kind
of
how
they
practice
product
managing
over
the
last
three
years
or
more.
We
have
been
publishing
research
that
we've
been
done
been
doing
around
what
it
means
to
be
a
high
performing
team.
We
reviewed
over
300
million
workflows
over
that
time.
Over
40
000
organizations,
almost
300
000
projects
we've
been
able
to
kind
of
identify
specific
ci
cd
benchmarks.
A
So
these
when
it
looks
like
what
a
high
performing
team
is,
this
is
where
you're
merging
you
know
on
any
pull
request.
Your
throughput
is
just
as
at
the
speed
of
your
business.
The
duration
of
time
is,
you
know,
of
your
builds
10
minutes
or
less
mean
time
to
recovery
less
than
an
hour.
Success
rate
should
be
90
on
your
on
your
default
branch
on
your.
A
If
you
want
to
get
kind
of
the
full
report
around
around
the
data,
we
call
it's
the
state
of
software
delivery
report.
You
can
either
go
to
circle.ci
ssd2022
or
you
can
scan
this
qr
code.
You
don't
have
to
sign
up
for
anything.
You
don't
have
to
give
us
your
email,
you
just
click
the
button
that
says
download
so
yeah.
So
that's
that
definitely
you
know
we're
here.
A
A
A
Yes,
so
it's
all
any
any
jobs
that
are
run
on
our
platform
is
part
of
that
data
set
it's
all
anonymized,
but
it
is
the
largest
grouping
of
data
of
any
of
the
reports
out
there
and
it's
dealing
with
like
the
state
of
devops
reports.
The
dora
reports
are
amazing,
they've
been
extremely
influential
to
kind
of
where
we
are
as
an
industry.
A
They
are
still
surveys
and
dr
forsgren
has
done
a
great
job
of
in
her
team
of
refining
the
questions
and
you
know
making
sure
that
to
hopefully
remove
some
of
that
bias,
but
it's
still
relying
on
you
know
what
your
memory
is
of
what
you
did
last
week,
and
so
what
we've
done
is
we've
taken
that
and
looked
it
for
ourselves.
Look
at
the
data
and
see
how
long
builds
are
running,
see
what
the
mean
time
to
recovery
is
all
of
that
and
then
we've
gone
and
looked
at
okay.
A
So
how
does
that
match
up
to
that
report
and
what
they've
identified
as
high
performing
teams
50
of
the
people
on
our
platform
fall
into
that?
So
it's
a
it's
a
good
measure
where
we're
going
okay.
This
is
definitely
validated
by
you
know,
not
only
industry
ways
of
looking
at
it,
but
the
actual
data
itself.
A
A
Breaking
that
also
points
to
you
probably
don't
have
a
lot
of
good
testing
and
so
we're
able
to
look
at
that
data
and
understand
when
you
mash
it
all
up
what
that
looks
like
now,
a
hyper,
and
I
do
a
talk
on
like
the
metrics
report
and
on
high
performing
teams,
but
so
I'd
love
to
talk
to
you
more
about
that.
But
the
short
answer
is
that
you
have
to
start
with
the
baselines
for
your
business
because
not
like
when
you
think
about
the
throughput.
I
mean
you
think
about
duration.
A
Well,
that
should
be
10
minutes
or
less
that's
great,
but
if
you're
building
a
very
monolithic
application,
that's
in
c
or
in
java-
or
you
know
some
of
these
big
like
compiled
languages,
that
could
take
long
and
you
don't
have
a
lot
of
room
for
for
movement
now.
You
can
split
jobs
up,
you
can
do
concern
jobs.
You
can
there's
things
you
can
do,
but
the
reality
is
that
you
may
not
be
able
to
get
to
that
10.
A
But
if
you
set
the
baseline
and
then
start
making
sure
that
you
you
take
the
different
steps
to
streamline,
you
can
get
closer
to
that
and
that's
where
you
can
say:
okay,
well,
we've
done
that's
our
benchmark
was
here.
This
was
our
baseline,
we're
getting
closer
and
closer,
and
you
can
you
can
set
that
so
every
business
you're,
not
the
netflix.