►
From YouTube: Where’s the Application? Understanding the Challenge of Your Microservice CD Pipeline - Tracy Ragan
Description
Where’s the Application? Understanding the Challenge of Your Microservice CD Pipeline - Tracy Ragan , DeployHub
As we take a hammer and smash up our monolithic applications into lots of little pieces, we also break the way we track and manage a software application. The software application no longer exists, yet we still need it. The loss of the application is partly responsible for the complexity in managing microservices. This session investigates the core benefits of continuous integration in a monolithic pipeline in terms of the packaging and configuration management of the software application. We will cover why the CI step is critical to the entire Continuous Delivery process, and what we lose as we move to microservices. We will explore the tracking of application versions overtime to remind us of the importance of BOM reports, 'diff' reports, and impact analysis. By looking at what we do well today, we will understand what we need to solve in a microservice based CD Pipeline.
A
So
understanding
those
challenges
will
be
critical
as
you
move
forward
and
really
start
thinking
about
how
you're
going
to
manage
microservices
through
a
cd
pipeline,
but
first
a
little
bit
about
me.
I'm
tracy
reagan.
I
am
the
ceo
of
deploy
hub.
I
am
also
a
board
member
of
the
cd
foundation.
I'm
a
microservice
evangelist.
I
ride
big
horses,
I
have
a
black
belt.
I
live
in
a
small
town
in
outside
of
santa
fe
new
mexico
and
love
it.
A
A
Consumers
are
hungry
for
data
you
and
I
are
driving
this.
We
want
data
and
we
want
it
now.
We
want
our
medical
records
when
we
want
it.
We
want
to
be
able
to
log
in
and
get
our
banking
information.
We
want
to
be
able
to
vote
online,
wouldn't
that
be
nice.
We
want
data
and
we
want
it
now.
We
want
smarter
applications.
We
want
faster
applications.
We
want
applications
that
are,
that
are
fault
tolerant.
A
We
don't
want
to
log
into
something
and
see
it
down,
so
consumers
are
driving
the
demand
for
what
I
like
to
call
business
agility
and
that
new
demand
requires
a
newer,
faster
and
modern
approach
to
architecture.
That
is,
that
is,
that
is
high,
performing
fault,
tolerant
and
can
auto
scale.
These
are
three
critical
pieces
of
what
we
call
modern
architecture
and
they're,
absolutely
important
for
creating
high
performance,
computing,
machine
learning
and
artificial
intelligence,
and
that's
where
kubernetes
is-
and
you
know,
I'm
sure
all
of
you
have
heard
of
kubernetes.
A
But
if
you
haven't
you're,
probably
asking
kubernetes
what
kubernetes
is
a
is
really
the
foundation
of
modern
applications,
and
that
is
because
modern
applications
are
more
and
more
being
built.
Around
containers
and
kubernetes
is
a
container
orchestration
solution
and,
as
we
move
from
a
containerized
applica
monolithic
application
to
decomposing
that
kubernetes
becomes
more
important.
A
Kubernetes
is
an
open
source
product
managed
by
the
linux
foundation.
The
cncf-
and
it's
also
greek
for
the
word
for
helmsman
or
a
of
a
ship
or
a
pilot,
so
shifting
to
modern
architecture,
is
essential,
and
this
is
really
what
you
need
to
take
home.
You
must
shift
to
this
architecture.
There
is
not
an
option
for
keeping
a
traditional
kind
of
monolithic
practice
for
future
applications.
A
It
is
a
complete
robot
block
to
21st
century
software,
you're
not
going
to
get
the
kind
of
massive
pattern
matching
and
massive
data
science
that's
needed
for
what
we're
going
to
write
in
the
future
you're
not
going
to
have
a
monolithic
solution
and
autonomous
cars,
for
example.
Everything
that
we're
looking
at
in
the
future
is
going
to
require
this
new
modern
fault,
tolerant,
auto
scaling,
type
of
environment
and
microservices
will
be
a
core
piece
of
that,
so
microservices
are
really
taking
over.
A
A
That
may
include
some
of
the
new
modern
architecture
software
as
well,
but
it's
a
big
market
and
there's
reasons
for
it.
It's
not
only
important
for
your
modern
architecture
and
building
these
21st
century
solutions,
but
it
also
saves
a
lot
of
money,
so
the
bean
counters
love
it
there's
a
substantial
operational
savings
from
the
use
of
microservice
over
a
physical
or
even
cloud-based
environments
and
there's
an
increase
in
computing
power
at
the
same
time.
A
So
in
other
words,
kubernetes
has
gone
mainstream
when
you
start
seeing
cartoons
and
dilbert
cartoons
about
kubernetes.
You
understand
that
it
has
truly
gone
mainstream
and
I
really
love
this
one.
You
know
I
love
it
when
he
says
I
need
to
know
why
moving
our
app
to
the
cloud
didn't
automatically
solve
all
of
our
problems.
A
A
So
what
are
we
really
looking
at
we're
really
looking
at
a
shift
from
monolithic
applications
to
microservice
based
applications,
we're
looking
at
decomposing
our
monolith
to
small
functions
or
in
essence
taking
our
static
application
or
static
monolithic
application,
and
I
call
it
static
because
we
do
a
link
step.
We
create
a
jar
file
to
a
to
breaking
it
out
to
each
of
those
class
files
being
its
individual
function
and
living
in
its
individual
container
and
being
able
to
be
shared
across
multiple
teams.
A
Now.
What
we're
really
talking
about
is
moving
from
a
monolithic
to
what
I
like
to
call
a
death
star
and
if
you
look
at
amazon
and
netflix,
these
these
points
are
all
individual
functions.
Individual
services
and
the
complexity
is
pretty
epic.
We're
talking
about
four
thousand
five
thousand
microservices
in
these
cases,
they're
they're.
These
companies
are
the
on
the
bleeding
edge
and
have
taught
us
how
important
it
is
and
what
can
be
done
to
support
thousands
and
thousands
of
customers
in
this
type
of
environment.
A
But
we
do
lose
the
ver,
the
the
application,
that
is
the
biggest
problem.
The
concept
of
an
application
version
goes
away
and
over
the
course
of
all
of
our
experience,
the
application
version
has
always
been
sort
of
our
north
star.
Everything
we
do
is
based
on
an
application
version
and
remember
I'm
going
to
say
this
more
than
once,
microservices
are
shared
across
teams
and
they're
deployed
independently,
so
you're.
Thinking
of
now
an
application
is
a
function.
An
application
is
a
microservice,
but
the
application
version
as
a
whole.
A
A
So
when
you
don't
manage
it
and
when,
when
you
start
running
into
problems,
this
is
the
kinds
of
problems
you'll
find
alexandra
noonan.
I
have
quoted
her
many
times.
This
came
from
an
article
I
have
st
times
she
said
what
happened
is
we
would
release
an
update
to
a
library
and
then
one
service
would
use
the
new
service
and
all
of
a
sudden,
all
these
other
services
were
using
an
older
version
that
we
had
to
try
to
keep
track
of
which
service
was
using?
A
What
version
of
the
library
what
she's
talking
about
is
the
the
the
struggle
of
being
able
to
keep
track
of
what
the
application
is
consuming
and
how
that
application
changes
over
time
as
a
new
version
of
a
microservice
is
updated
to
the
cluster,
so
we
have
to
evolve
the
pipeline
to
be
able
to
track
version
and
deploy
these
microservices
and
here's
four
points
that
we're
going
to
talk
about.
First
of
all,
continuous
integration
becomes
really
a
continuous
build
of
a
container
image.
A
That's
going
to
shift
probably
the
most
continuous
delivery
must
progress
through
production.
We
absolutely
must
be
able
to
track
production
updates
through
the
cd
pipeline
right
now,
when
I
talk
to
people
most
people
are
just
doing
continuous
integration
and
if
they
are
doing
continuous
delivery,
they
get
it
to
test
and
very
few
are
making
it
all
the
way
to
production.
We
can't
achieve
devops
at
scale.
If
we
don't
push
it
to
production,
we
need
some
sort
of
automated
configuration
management
to
track
service
to
application
relationships.
A
That's
what's
going
to
give
us
the
confidence
to
deploy
new
microservices
out
to
a
cluster
and
know
that
we're
not
going
to
impact
anything
now.
I
know
microservices
should
be
fully
backward
compatible
and
there's
a
lot
of
work
being
done
to
make
sure
that
that
happens,
but
it
doesn't
always
happen
and
then
understanding
what
version
of
a
microservices
is
running
in
a
particular
cluster
isn't
also
important,
because
that's
the
feedback
that's
required,
that
we
need
to
push
back
into
the
cd
pipeline.
A
So,
let's
look
at
what
we
do
now
and
just
you
know,
level
set
continuous
integration,
continuous
delivery,
continuous
deployment
at
this
first
level.
This
is
probably
the
most
important
piece
of
the
cd
pipeline
today
and
where
most
companies
have
achieved
some
success
and
that
is
in
the
ci
process.
Continuous
integration
is
the
the
point
of
ci
was
to
make
sure
that
we're
checking
code
in
on
a
regular
basis
and
making
sure
that
we
can
pull
it
check
it
out
and
run
a
build
in
less
than
10
minutes.
A
We've
heard
jez
humble
ask
us
many
times:
can
you
do
a
10
minute
or
less
build
in
a
microservice
world?
We
may
not
have
to
ask
that
question
anymore.
Microservices
are
small,
so
in
a
ci
cd
pipeline.
What
we
basically
do
is
continuous
integration,
which
can
also
be
referred
to
as
a
continuous,
build
and
that's
where
most
companies
are
at
now.
A
You
are
talking
about
this
step
where
you're
pushing
to
each
environment
so
that
a
continuous
test
can
run
okay.
So,
let's
just
look
at
what
we
are
doing
in
ci,
because
that's
going
to
change
a
lot
today,
what
we
do
is
we
use
it
to
integrate
code
by
merging
and
pulling
these
based
on
the
label
we
scan
for
transitive
dependencies.
We
compile
and
link
everything
statically
in
a
big
war
file
or
a
binary
of
some
sort
which
creates
the
application
version
right.
That's
where
we
create
the
application
version.
Sometimes
we
have
its
own
numbering
schema.
A
Sometimes
we
use
the
build
number
at
that
point
in
time
we
have
other
work
products.
Sometimes
we
have
a
bill
of
material
report,
often
called
a
bomb
report
and
from
that
bomb
report
we
can
compare
two
bomb
reports
and
get
a
difference
report
and
in
some
more
mature
ci
practices,
there's
the
ability
to
run
impact
analysis,
but
it
what
we're
really
talking
about
is
the
creation
of
a
release
candidate.
A
A
So
that
means
the
ci
step
is
different.
What
we're
doing
with
the
ci
step
is
not
worrying
about
doing
an
integration
and
trying
to
do
a
10-minute
build.
What
we're
doing
is
we're
creating
a
microservice
that
we're
going
to
put
in
a
docker
container,
so
we
start
kind
of
this
in
a
similar
way.
We
pull
code
out
of
github,
we
might
even
scan
for
dependencies,
let's
say
you're
using
python,
you
might
use
it
to
find
python
libraries,
you
pull
all
that
and
you
put
it
in
your
docker
image.
A
That
image
then
is
checked
into
a
registry
in
a
very
similar
way
and
and
deployed
into
your
cluster.
Now
we
repeat
that
often
we
repeat
it
constantly
for
each
microservice:
we
don't
we
don't
do
one
big
binary,
we're
doing
small
ones
and
we're
doing
it
with
a
high
level
of
frequency
so
think
about
it.
As
you
know,
microservice
is
sort
of
constantly
your
ci
workflow
constantly
flowing
and
any
particular
point
in
your
your
death
star.
A
A
So
think
about
the
things
that
we
lose
when
we
don't
have
an
application
version,
we
lose
the
schema.
We
lose
the
ability
to
talk
about
it.
This
impacts
testing,
it
impacts,
bug
tracking
and
it
even
impacts
our
value
stream.
So
having
the
ability
to
track
an
application
version
is
a
critical
piece
of
the
new
cd
pipeline.
A
We
still
need
bill
of
material
reporting.
We
still
need
to
understand
what
version
of
our
application
our
logical
application
is
using,
which
versions
of
the
microservices
that
it's
consuming
and
remember
when
you
are
using
microservices,
if
you're
doing
it
correctly,
they're
highly
reusable,
so
your
application
team
may
be
consuming
a
microservice
that
you
didn't
write,
which
means
that
somebody
else
might
the
other
teams
might
push
it
out.
A
So
the
concept
of
microservice
configuration
management,
you
know,
helps
you
puts
the
app
put
the
application
back
together.
This
is
a
missing
piece
and
in
being
able
to
confidently
manage
literally
hundreds
of
microservices
moving
across
that
very,
very
fluid
continuous
delivery
pipeline
that
is
running
at
at
scale.
A
A
There's
other
tools
like
container
build
and
registry
tools
like
harbor,
quay
and
helm.
Some
of
these
are
part
of
the
cncf,
and
then
there
are
other
new
tools
like
ortillius
that
are
managing
the
configuration
management.
So
some
of
these
tools
will
be
on.
These
are
the
new
types
of
tools
that
you'll
be
seeing
in
the
future,
as
you
start
tweaking
your
cd
pipeline
to
meet
the
needs
of
a
microservices
platform.
A
So
if
we
think
about
what
it
will
look
like
and
again,
there
are
many
many
steps
that
we
could
be
adding
to
this
picture,
but
I'm
trying
to
keep
it
as
simple
as
possible
for
today
for
today's
presentation,
but
we
start
very
similar
to
what
we
have
would
have
done
in
the
past.
We
get
a
jira
change
request
or
we
get
a
github
issue
or
something
that
says
we
have
a
problem.
A
We
do.
We
manage
our
code
and
we
get
a
code
complete
status
and
in
something
like
github,
that's
where
it
stops
being
the
same
and
where
it
starts
changing.
Instead
of
doing
this,
full
binary
build
like
we
used
to
do
in
ci.
Instead
we're
going
to
pull
the
code,
create
a
new
image
and
register
it,
and
I
like
to
think
about
that
as
a
new
release
candidate.
A
Some
people
will
argue
that
there's
the
release
candidate
comes
at
the
code
level,
but
when
I'm
thinking
about
doing
continuous
deployment,
I'm
waiting
for
that
that
binary
that
new
microservice
to
be
registered
and
in
a
in
a
in
a
container
registry,
because
then
I
know
where
I
can
find
it
and
where
it
needs
to
be
pulled
from,
and
I
can
track
it
now.
Tracking
is
the
important
part.
So,
tools
like
artelias
help
establish
the
logical
application
versions.
A
A
A
domain
driven
design
is
important
for
managing
microservices
and
you'll
start
under
seeing
the
need
for
cataloging
microservices
sort
of
the
ability
to
organize
them
so
that
they
can
be
re-shared
across
teams
and
then
at
the
tools
like
this,
provide
your
your
bomb
report.
They
track
what
application
version
is
using
which
microservice
versions
and
they
track
that
across
the
clusters,
it's
different
from
having
a
registry
in
a
single
cluster.
A
This
is
tracking
across
the
clusters
now
tracking
across
across
the
clusters
is
important
because
remember,
every
microservice
version
that
is
new,
creates
a
new
application
version,
so
you
could
have
multiple
application
versions
running
in
different
clusters,
which
you
will
in
the
same
way
as
you
do
in
a
monolithic,
waterfall,
dev,
test,
prod
scenario.
It's
just
that
it's
going
to
happen
more
frequently
and
it's
going
to
be
harder
to
track.
A
A
And
I'd
like
to
thank
you
for
hearing
me
out
today
and
I
would
love
to
chat
if
you
have
different
opinions,
I
would
love
to
hear
those
opinions.
I
speak
to
people
all
day
long
and
ask
them
these
kinds
of
questions
to
hear
what
they're
up
to
and
what
I'm
hearing
is
that
about.
40
microservices
is
where
they
start
running
into
problems.
I'd
like
to
hear
where
you're
at
in
your
journey
and
where
those
problems
might
be
showing
up.