►
Description
Supercharge Cloud Migration with Progressive Delivery - Rosemary Wang, Hashicorp
You’re ready to send some canary traffic to a newly refactored application in a new cloud provider while the former application resides in your current datacenter or cloud. However, you encounter a problem: you haven’t aggregated application metrics from both environments, and you’ll have to manually review a dashboard to determine whether or not to increase the percentage of canary traffic. Is there an automated way to do this? In this talk, Rosemary combines canary analysis with the powers of service mesh observability and traffic management to supercharge migrations in multiple environments with progressive delivery. She’ll demonstrate that setting up tools such as HashiCorp Consul, Prometheus, and Spinnaker can help scale the migration and support of refactored applications across multiple clouds or platforms while reducing their production risk.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
So
the
story
starts
with
cloud
migration.
I've
done
a
lot
of
cloud
migration,
just
because
everybody
told
me
hey.
We
have
to
move
to
public
cloud
for
some
reason
or
another,
whether
it
be
data
center
or
another
cloud,
and
it
involves
three
steps.
The
first
is
refactor
the
application
to
cloud.
We
usually
choose
a
low
impact,
high
value
application
as
a
first
refactoring
step
and
then
eventually
re-platform
other
applications
over
time.
A
The
second
step
is
to
deploy
and
test
the
new
application
in
the
cloud
deploying
and
testing
the
new
application
in
the
cloud.
It
involves
a
certain
amount
of
time
spent
debugging
trying
to
triage
any
issues.
Sometimes
it's
repackaging
the
application
into
a
container
and
re-platforming
it
entirely.
A
A
The
reason
why
it's
more
complicated
is
that
involves
me
sitting
and
examining
a
dashboard.
The
dashboard
usually
contains
some
application,
metrics,
sometimes
of
errors
and
latency.
It's
important
to
recognize
that
this
dashboard
was
created
by
either
myself
or
someone
else,
and
I
didn't
necessarily
know
whether
or
not
the
application
metrics
were
accurate.
A
After
about
a
week,
I'd
re-analyze
all
the
information
and
see
if
I
could
increase
the
traffic
a
little
bit
more
as
it
turns
out
you
know.
Sometimes
I
couldn't
sometimes
errors
only
popped
up
whenever
I
increased
it
to
about
90
to
cloud,
in
which
case
I
would
then
roll
back
and
find
things
new
things
to
fix
and
then
try
to
repeat
the
process
again.
This
entire
process
took
months
and
it
seems
like
it
could
take
a
lot
shorter
amount
of
time,
except
you
do
want
to
allow
the
percent
of
traffic
to
bake
a
bit
right.
A
You
need
some
user
requests
coming
into
the
applications
so
that
you
get
a
larger
sample
size
and
you
actually
know
whether
or
not
the
application
in
cloud
is
working.
Well,
who's.
This
person,
who
sat
and
stared
at
dashboards
and
tried
to
figure
out
whether
or
not
I
could
increase
canary
deployments
well.
My
name
is
rosemary
wong.
I'm
a
developer
advocate
at
hashicorp.
A
So
when
I
thought
about
trying
to
automate
this
workflow,
I
had
a
wish
list
of
things.
The
first
is
that
I
wanted
to
automate
the
increase
of
traffic
and
the
analysis.
It's
not
to
say
all
analysis
should
be
automated,
but
I
did
want
to
make
sure
that
I
had
didn't
have
to
sit
there
and
stare
at
a
dashboard
all
the
time.
A
The
second
thing
I
wanted
was
one
source
of
truth
to
control.
If
I
have
a
data
center
or
a
first
cloud
and
then
a
new
cloud,
I
do
want
to
have
one
source
of
truth:
to
control
both
environments,
I
need
to
be
able
to
say:
okay,
here's
the
dns
of
this
application
and
let
me
actually
control
the
traffic
to
both
environments.
A
The
third
thing
I
wanted
was
to
aggregate
and
standardize
the
metrics
depending
on
the
older
environment.
I
might
not
have
the
same
kind
of
metrics
that
I
want
in
the
new
environment,
if
I'm,
let's
say
re-clapping
platforming
from
virtual
machines
to
containers,
I
might
use
some
of
the
container
metrics
libraries
out
there
that
actually
give
me
some
of
the
information
out
of
the
box.
A
The
last
thing
I
wanted
was
to
be
able
to
tag
and
identify
applications
on
each
cloud.
This
is
important
from
an
audit
standpoint
and
also
is
important
for
me
to
know
which
application
I
was
parsing,
a
certain
percent
of
traffic
to
so
the
solution
to
this
to
me
seemed
to
involve
two
different
segments.
The
first
is
trying
to
find
some
infrastructure
layer
between
multiple
environments
that
abstracts
away
that
control,
and
that
way
I
get
this
one
view
across
all
of
the
environments.
A
I
have
the
second
solution
that
I
needed
was
some
kind
of
delivery,
automation
to
control
and
also
fix
the
infrastructure
layer,
so
I
needed
some
delivery
automation
that
would
analyze
the
metrics
based
on
that
infrastructure
layer
and
then
make
the
changes
and
control
the
percent
of
traffic
as
it
turns
out.
You
can
do
this
as
long
as
you
supercharge
it
with
a
couple
of
tools
out
there.
You
could
write
your
own,
but
it's
pretty
difficult.
So
what
are
the
tools
that
we
have
today
that
allows
us
to
supercharge
our
cloud
migration?
A
The
first
is
the
service
mesh
service
mesh
is
an
infrastructure
layer
to
manage
service
to
service
communication.
It's
a
buzzword,
but
it's
actually
very
useful.
It
provides
really
fine-grained
control
over
service
to
service
communication,
which
is
really
powerful
in
an
environment
like
this,
where
you
want
to
be
able
to
parse
the
certain
percentage
of
traffic
to
one
environment
or
the
other,
and
understand
how
much
traffic
you're
sending
to
each
a
service
mesh
works
in
with
a
few
different
components.
The
first
is
a
control
plane.
This
control
plane
is
exactly
what
it
sounds.
A
A
So
the
proxies
pass
communication
to
each
other,
while
console
tells
the
proxies
where
this
traffic
should
go.
The
proxies
exist
in
front
of
a
user
interface
or
application,
so
the
proxies
basically
process
anything
between
applications.
In
this
case
I
have,
let's
say,
a
ui
application.
That
is
a
thin
client,
can't
be
moved
to
the
cloud
immediately,
so
I'm
going
to
keep
in
the
data
center,
but
it
references
a
backend
application
upstream
called
my
application,
the
proxies
funnel
all
the
requests
between
ui
and
my
application.
A
I
want
to
migrate
my
application
to
cloud.
The
eventual
path
is
that
ui
and
data
center
will
access
my
application
in
cloud
with
the
proxies
in
the
console
cluster
for
cloud
communicating
across
the
data
center.
I
can
actually
apply
this
infrastructure
layer
and
control
the
service
to
service
communication.
A
So
the
next
solution
that
you
could
apply
is
progressive
delivery.
Now
progressive
delivery
is
a
practice.
It's
not
necessarily
a
solution
per
se,
but
what
it's
going
to
offer
is
control
on
how
and
when
changes
are
delivered.
Progressive
delivery
includes
practices
like
canary
feature
flagging
and
a
b
testing,
all
of
which
can
be
implemented
and
executed
by
a
service
mesh.
A
So
in
this
case,
combining
service
mesh
and
progressive
delivery
offers
a
couple
benefits.
It's
agnostic
to
the
data
center
cloud,
vms
or
containers
in
this
case
today,
I'm
showing
a
deployment
across
vms
and
containers.
It
standardizes
the
metrics
right
because
the
metrics
are
coming
from
the
proxies.
Since
the
proxy's
process
requests
it's
able
to
provide
standardized,
metrics
and
they're
fairly
uniform
across
environments.
It
also
offers
one
layer
of
control.
A
But
it
has
a
downside.
You
have
to
retrofit
the
service
mesh
into
older
environments.
So
if
you're
doing
a
cloud
migration,
it's
okay
to
go
in
and
maybe
add
the
service
mesh
into
a
newer
environment.
But
in
an
older
environment
you
have
to
take
the
time
and
effort
to
retrofit
the
service
mesh
into
the
applications,
and
this
may
or
may
not
be
completely
possible.
A
I
will
say
it
is
worth
the
effort,
especially
if
you
do
this
over
five
or
six
years.
Most
cloud
migrations
are
running
kind
of
in
this
hybrid
mode
or
multiple
environments
for
a
couple
of
years,
and
if
you
plan
on
doing
that-
and
you
have
many
applications
that
have
to
be
migrated,
you
might
consider
retrofitting
the
service
mesh
into
an
older
environment.
Just
so
you
have
the
single
level
of
control
and
you're
able
to
automate
and
standardize
the
process
of
cloud
migration
in
a
progress
and
progressively
deliver
new
applications
in
a
new
environment.
A
So
the
setup
that
I'm
going
to
show
today
involves
a
couple
components,
as
I
mentioned
before,
I
have
a
console
cluster
in
a
data
center
and
a
console
cluster
in
the
cloud
I'm
going
to
migrate,
my
application
to
the
cloud.
So
here
I'm
going
to
configure
console
to
funnel
traffic
between
data
and
cloud.
The
two
console
clusters
are
connected
through
something
called
federation.
A
They
are
aware
of
each
other.
They
actually
communicate
to
each
other
in
order
to
retrieve
the
services
in
each
cluster.
So,
for
example,
cloud
is
aware
of
ui
in
data
center,
because
the
proxies
exist
and
the
service
mesh
is
in
place.
I
can
scrape
these
metrics
using
prometheus,
prometheus
scrapes
metrics
from
envoy
proxy
and
collects
them
by
extension.
I
can
then
use
spinnaker
and
cayenne
to
canary
analysis
to
use
the
metrics
from
prometheus
and
analyze
them
to
do
my
canary
deployment.
A
I'm
only
going
to
show
one
metric
today,
you
can
configure
more
sophisticated
canary
analysis
in
caienta
if
you
want,
but
today
I'm
only
going
to
use
one
metric
when
spinnaker
analyzes
the
metrics
and
decides
that
it
the
canary,
is
successful.
It
will
configure
something
called
a
console
service.
Splitter.
A
console
service.
Splitter
is
a
configuration
entry
that
determines
what
percentage
of
traffic
goes
to
each
service.
So,
for
example,
in
the
first
stage,
I'll
have
spinnaker
deploy
90
percent
of
traffic
to
the
data
center
and
set
10
of
traffic
to
the
cloud.
A
The
console
service,
splitter
propagates
to
the
envoy
proxies
and
the
proxies
ultimately
control
where
the
traffic
will
go
for
this
demonstration.
I
wanted
to
expedite
the
process
a
bit
since
it
takes
some
time
to
run
a
canary
deployment.
Spinnaker
itself
is
using
a
canary
stage
of
analysis
stage
of
about
three
minutes
each
for
every
increment.
So
the
result
is
that
the
pipeline
takes
about
20
minutes
to
run
so
the
this
has
already
been
executed,
which
is
why
I'll
just
show
some
of
the
configuration
that's
relevant
for
a
canary
deployment
and
using
a
service
mesh.
A
The
first
is
that
I
actually
configure
a
console
using
spinnaker
in
spinnaker,
I'm
able
to
configure
console
and
say
I
want
a
service,
something
called
a
service
resolver.
This
tells
console
and
subsequently
the
proxies
in
the
service
mesh
to
resolve
anything
going
to
my
application
cloud
to
data
center
cloud
and
service
my
application.
A
Furthermore,
I
have
a
service
splitter.
The
service
splitter,
as
I
mentioned
before,
controls
the
percent
of
traffic
from
one
application
to
the
other
application.
In
this
case,
I
have
a
hundred
percent
going
to
my
application
and
zero
percent
going
to
my
application
cloud
in
the
first
stage.
The
reason
why
it's
important
and
why
I
don't
specify
specifically
my
application
data
center-
is
that
by
default,
the
application
that
is
accessing
my
application
will
default
to
its
specific
console
data
center.
A
So
in
the
case
of
the
data
center,
which
actually
has
two
views,
I
have
cloud
and
I
have
my
data
center
ui
will
resolve
to
my
application
and
because
ui
is
in
data
center.
It
by
default
goes
to
the
data
center.
My
application,
however,
when
I
examine
my
application
and
the
routing
configuration
it's
actually
saying,
a
hundred
percent
will
resolve
to
cloud
now.
That's
because
my
pipeline
has
finished.
A
I've
done
a
successful
county
deployment,
so
a
hundred
percent
has
now
been
sent
to
cloud
in
terms
of
the
actual
configuration
itself
within
spinnaker
to
do
the
canary.
The
canary
configuration
runs
for
about
three
minutes.
Analysis
runs
for
about
three
minutes.
I
did
this
to
expedite
the
demonstration
and
you
can
actually
set
a
couple
other
configurations
like
delay
and
interval.
A
I
configured
a
baseline
location,
called
data
center
and
canary
location
called
cloud.
This
gets
passed
to
my
metric
in
my
canary
configuration.
The
metric
will
use
the
location
to
determine
which
console
data
center.
It
should
be
accessing
the
metrics
from
when
I
examine
the
canary
config
called
canary.
A
The
metric
itself
includes
one
metric,
which
is
console,
which
is
console's
envoy.
Cluster
upstream
request
request
this
tracks
any
requests
to
an
upstream
application
and
records
its
response
code,
so
in
the
filter
template
for
spinnaker.
What
I'm
actually
looking
for
is
a
console
source
service.
This
is
a
tag
added
by
envoy
and
console
to
the
metric.
I
also
have
the
envoy
response
class
code
response
code
class,
I'm
looking
for
500
errors
in
this
case,
and
I
also
have
a
console
source
data
center.
This
source
data
center
is
where
I'm
pulling
that
data
center
location.
A
A
A
Eventually,
you
know
this
is
the
fifty
percent
point.
So
the
request,
fifty
percent
of
requests
are
going
to
cloud.
Fifty
percent
are
going
to
data
center
and
eventually
now
in
this
particular
setup,
I
have
run
a
hundred
percent
going
to
cloud.
I
don't
delete
data
center
in
this
particular
pipeline,
because
maybe
I
want
to
keep
data
center
around
for
a
little
while
in
case
there's
some
regression.
It's
up
to
you
ultimately
and
your
organization
to
decide
during
a
successful
canary
deployment,
whether
or
not
you'll
keep
the
older
application
for
a
little
bit
longer.
A
A
So
if
I
examine
this
within
console
recall
that
I
mentioned
before
it
will
set
a
resolver
and
console
as
well
as
an
initial
canary
deployment
of
10
to
cloud.
So
when
I
examine
ui
ui
goes
to
my
application
in
my
routing
you'll
actually
notice
that
90
goes
to
the
data
center
and
10
goes
to
cloud.
So
this
starts
my
canary
deployment
and
everything
that
goes
to
my
application
cloud
resolves
to
the
cloud
so
notice
that
spinnaker
flagged
the
canary
analysis
as
unsuccessful.
A
It
will
then
proceed
to
a
rollback
canary
stage.
This
rollback
canary
stage
cuts
all
the
traffic
back
to
data
center,
so
the
run
canary
intervals
actually
failed.
The
threshold,
and
the
result
is
that
it's
actually
going
to
tell
me
to
stop
and
it
automatically
rolls
back
the
canary
deployment.
So
the
rollback
canary
does
not
delete
the
canary
itself.
I
might
want
to
keep
the
canary
around
for
troubleshooting.
A
More
importantly,
if
I
have
someone
using
the
application,
a
customer
or
otherwise,
it
will
always
be
available
to
them,
because
it
is
routing
back
to
the
older
application
in
the
data
center.
So,
in
terms
of
a
cloud
migration
strategy,
the
idea
is
that
if
you
have
many
applications,
all
of
which
depend
on
each
other,
you
can
use
this
technique
to
control
traffic
between
all
of
them
and
you
don't
have
to
coordinate
across
100
different
applications
and
remember
which
pipelines
you
have
to
manually
approve
to
increase
the
traffic
anymore.
A
Instead,
you
allow
something
like
spinnaker
and
the
automated
canary
analysis
to
handle
the
analysis
portion
and
automatically
increment
it
for
you
and
no
matter
which
environment
you're
in
and
no
matter
which
target
your
environment
you're
in
your
pipelines.
Pretty
much
remain
the
same.
You
can
use
templating
in
order
to
configure
the
service
splitters,
let's
say
in
consular
or
any
kind
of
traffic
management
in
the
service
match.
A
If
you're
curious
to
learn
more,
I
have
a
list
of
resources
that
you
can
check
out.
There
is
a
blog
that
I
have
about
spinnaker
and
console
together.
So
if
you
want
to
know
more
of
the
configuration
in
detail
feel
free
to
check
that
out.
This
example
is
available
for
your
reference
as
well
on
github
and,
if
you're
interested
in
canary
configurations
for
spinnaker,
as
well
as
the
service
splitter
entry
that
I've
configured
for
console
I've
attached
some
references
here,
don't
worry
about
screenshotting
these
slides.
A
A
A
Hi
there
I
just
want
to
make
sure
I
think
the
audio's
on
I
see
it
going
green
thanks
for
tuning
in.
I
appreciate
everyone
staying
around
for
the
presentation,
if
you
have
any
questions,
feel
free
to
drop
it
in
the
q.
A
I'll
also
check
the
chat
as
well.
One
of
the
commonly
asked
questions
that
I
get
when
I
was
discussing
this
with
a
couple
folks
in
in
the
community
overall
is
like
do
you?
A
A
This
is
also
something
you
can
do
with
any
of
the
other
service
meshes
that
you
might
use
as
long
as
it
has
some
kind
of
kubernetes
resource,
and
you
can
leverage
that
if
you
do
want
to
do
something
to
the
service
mesh
api,
endpoint
or
use
cli,
for
example,
you
will
have
to
use
other
plugins
within
spinnaker
in
order
to
do
that,
and
that
was
something
that
I
ran
into.
I
did
actually
have
to
set
up
a
cli,
oh
a
cli
plug-in
at
one
point
just
so.
A
Otherwise,
the
other
question
I
get
quite
a
bit
is
whether
or
not
metrics
come
out
of
the
box
for
some
of
the
some
of
this
kind
of
topology,
and
the
answer
is,
it
depends
on
the
tool
you're
using
many
of
the
service
mesh
tooling
out.
There
adds
some
kind
of
metadata
and
tagging
so
keep
in
mind
that,
if
you're,
adding
some
metadata
and
tagging
that's
to
your
tool
of
choice,
your
service,
that's
just
likely
adding
their
own
tags
as
well.
A
In
this
case,
I
showed
tags
for,
let's
say:
console
source
service
console
destination
service.
Those
are
not
universal
across
all
tooling,
so
the
envoy
response
code
class,
for
example-
that
shows
the
five
that
is
more
universal
and
because
it
is
using
with
service
meshes
that
use
envoy.
So
there
are
some
caveats
to
some
of
the
configuration
here,
but
if
you
have
any
confusion
or
there's
some
complications,
you'll
you're
more
than
welcome
to
reach
out
to
me
there's
there
is
a
repository
this
is
associated
with.
A
A
I
do
know
that
there
is
a
couple
folks
in
the
community
who
have
done
that
and
are
able
to
do
that
with
us
with
a
service
mesh,
but
they
had
to
separately
either
create
their
own
kind
of
canary
analysis
workflow
in
their
pipelines,
or
they
had
to
use
some.
You
know
some
other
mechanism,
so
a
third-party
mechanism,
so
it
is
possible
to
do.
However,
you
have
to
figure
out
what
kind
of
investment
you
want
to
make.
Yes,
I
will
share
the
link.
A
As
for
the
list
of
resources,
the
demo
content
that
you
that
I
at
least
I
showed
for
this
one-
is
under
this
github
and
he
does
good
hub
here
and
there's
also
another
piece
if
you're
interested
in
the
exact
configurations,
or
at
least
a
deeper
explanation
of
the
kind
of
the
them
the
at
the
very
least
and
the
technicalities,
the
ins
and
outs,
there
is
actually
a
more
detailed
blog
that
describes
it.
The
blog
itself
doesn't
show
necessarily
the
cloud
migration
piece
to
it.
A
There's
some
complexities
to
having
two
different
service
meshes
in
two
different
instrument,
regions
or
two
different
data
centers.
So
this
blog
is
just
showing
the
canary
the
automated
canary
deployment
piece
of
it.
It
is
not
necessarily
showing
the
multi-cluster
component
of
that.
So,
if
you're
interested
in
the
multi-cluster
component,
the
code
base
has
the
two
separate
clusters
and
the
configurations
for
how
you
would
federate
between
the
two
clusters
with
that.
If
there
are
no
more
questions,
I
appreciate
any
those
who
are
still
in
chat
and
tuning
in,
I
think
I
am
going
to.