►
Description
When you begin your Cloud Native journey, you’ll quickly find that your current CI/CD pipeline is not going to make the grade. Kubernetes is finally moving us away from a monolithic approach to software development towards a service-based approach. This means each microservice will have its own life cycle and be independently deployable. This is the game changer. While you can force your current CI/CD pipeline to support microservices, this isn’t an optimal approach. With a cloud native environment comes new complexities. Just as a start, your configuration management shifts from check-in and build where linking is resolved, to a container build and run-time APIs. Join Tracy Ragan, CEO of DeployHub and CDF Board Member for a review of what a K8s pipeline look like, and how your current pipeline is disrupted. Meet Nathan Martin of Sagecore Technologies who will provide us a real world case study on managing microservice configuration with DeployHub (Ortelius.io open source) and routing with Istio Service Mesh in a modern pipeline.
Takeaways:
For most organizations, microservices will have their own repository and workflows. CD tools will need to support workflow templates.
Configuration management will be lost as large monolithic builds are replaced or non-existence. Link decision making is done at runtime – not by a build manager.
Service Mesh becomes core to deploying and routing microservices.
Meet Nathan Martin of Sagecore Technologies who will provide us a real world case study on managing microservice configuration with DeployHub and routing with Istio in a modern pipeline.
Join Tracy Ragan, CEO of DeployHub and CDF Board Member for a review of what a K8s pipeline look like, and how your current pipeline is disrupted.
Presenters:
Nathan Martin, CEO @Sagecore Technologies
Tracy Ragan, CEO @DeployHub
A
You,
okay,
let's
go
ahead
and
get
started.
I'd
like
to
thank
everybody
for
joining
us
today.
Welcome
to
today's
webinar
pivoting,
your
pipeline
for
micro
services,
I'm
Julius
Rosenthal
I'll
be
moderating
today's
webinar.
We
would
like
to
thank
our
presenters
today,
Nathan
Martin
CEO
at
Sage,
core
technologies
and
Tracy
Reagan
CEO
at
deploy
hub
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen.
A
This
is
an
official
webinar
of
the
CNC
F
and,
as
such
is
subject
to
the
CNC
F
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
Please
note
that
the
recording
and
slides
will
be
available
later
today
on
the
CNC
F
webinar
page.
With
that
I'll
hand
it
over
to
Nathan
and
Tracy
to
kick
off
today's
presentation.
A
B
You
so
much
and
I
want
to
thank
the
CNC
F
for
hosting
this
webinar
and
having
us
present.
This
is
a
this
is
a
fun
topic
for
me.
I
have
been
doing
I,
guess
what
you'd
call
the
software
delivery
lifecycle
for
pretty
much
most
of
my
career
and
I'm
part
of
the
CD
foundation,
I'm
on
the
CD
Foundation
Board,
which
is
a
sister
organization
to
the
CNC
f.
If
you
don't
know
about
it,
go,
go!
Learn
about
the
CD
Foundation,
we're
doing
some
interesting
things
there
around
continuous
delivery.
B
I'm
I
was
also
on
the
founding
board
of
the
Eclipse
Foundation
I'm,
a
DevOps
Institute
ambassador
and
I
love
to
talk
about
micro
services,
I'm,
just
gonna
Nathan's,
going
to
take
a
second,
the
second
half
of
this
presentation,
because
he's
going
to
dig
down
into
some
stuff
that
we're
doing
he's
doing
around
sto
but
I
want
to
say
he's
one
of
those
customers
that
you
love
to
geek
out
with.
So
thank
you
Nate
for
agreeing
to
be
on
this,
showing
what
you're
doing
at
Sage
core
absolutely.
C
B
Just
to
get
started
here,
what
we're
gonna
cover,
you
know
how
they
tell
you
just
to
you
know,
tell
your
audience
what
you're
going
to
tell
them.
You
tell
them,
and
then
you
tell
them
what
you
told
them
we're
gonna.
Do
it
that
way,
because
there's
a
lot
of
information
and
this
stuff
can
be
really
confusing,
so
we're
going
to
cover
a
cloud
native
journey
in
what
is
now
called
a
CD
pipeline.
B
Kubernetes
and
micro-services
is
really
moving
us
away
from
this
monolithic
style
of
software
development
to
a
service
based
approach,
and
that
really
will
require
that
you
pivot
your
pipeline.
There
are
going
to
be
some
problem
areas
that
we're
going
to
cover,
as
so
that
you
can
at
least
start
thinking
about
it.
We're
also
going
to
take
a
look
at
a
use
case
where
sto
is
brought
into
the
the
broader
picture.
B
To
do
some,
some
some
routing
and
it
may
not
seem
you
know
intuitive-
that
sta
would
be
part
of
your
CI
CD
pipeline,
but
because
this
do
does
the
routing
it
does
become
part
of
your
pipeline.
So
that's
what
I
mean
well,
there's
a
lot
to
learn
about
how
the
pipeline
is
pivoting
and
I'm,
hoping
that
this
presentation
will
get
you
thinking
about
what
you
need
to
do
for
the
future.
B
So
you
have
a
micro
service
will
be
related
to
repository
and
that
repository
is
going
to
be
related
to
a
workflow,
which
means
you're
going
to
need
lots
of
workflow
workflows,
running
and
we're
going
to
need
to
talk
about
templates
configuration
management
is
going
to
be
lost
and
we're
going
to
talk
a
little
bit
about
that
and
it's
lost
mainly
because
we
don't
do
builds
anymore
and
then
the
way
we
deploy
software
is
going
to
be
different
and
service.
Mesh
comes
into
that
picture.
B
Service
mesh
has
the
potential
of
finally
getting
rid
of
a
waterfall
approach
where
you
don't
necessarily
have
dev
environments,
test
environments
and
production
environments.
Now
I
know
that
sounds
crazy,
but
it's
true
and
I
know
that
most
of
you,
even
if
you're
working
in
kubernetes,
you
probably
have
clusters
mini
clusters.
We
have
I've
had
some
customers,
we
talked
to
one
of
them
recently
said
they
had
over
70
clusters.
So
we
know
that
you
have
a
lot
of
clusters
now,
but
servers
mesh
has
the
ability
to
help.
B
You
reduce
the
number,
the
number
of
clusters
you
have
to
manage.
So
let's
just
go
quickly
over
what
functions
are
and
I
know.
This
is
Sen
sub
CNC
F
group.
So
you
should
really
know
what
functions
are,
but
I
mean
micro
services.
Micro
services
are
functions.
You
have
to
think
functions
when
you
think
micro
services,
so
the
key
to
really
understanding
how
micro
services
can
be
leveraged
is
to
really
think
about
them
in
terms
of
functions
and
micro
services
are
immutable.
B
B
So
what
you
need
to
think
about
in
terms
of
what
your,
what
your
journey,
especially
on
the
CD
fraud,
is
that
you're,
taking
your
application
and
you're
taking
a
hammer
to
it
and
you're
breaking
it
into
lots
of
little
pieces
like
lots
of
little
pieces.
Potentially
Netflix
has
somewhere
in
the
ballpark
of
forty
five
hundred
micro-services
that
they're
managing.
So
it's
like
taking
a
wineglass
and
taking
a
hammer
to
it,
and
now
you
have
a
pile
of
glass
that
you
call
your
application.
B
The
application
is
still
there,
it's
just
lost,
but
it's
still
there
and
we
still
need
to
represent
it
and
it's
still
what
your
end.
Users
are
executing
right:
they're,
not
running
a
micro
service,
they're
running
a
version
of
your
application,
so
with
micro
services.
Your
overall
landscape
begins
to
change.
B
When
you
shift
to
have
modern
architecture,
you
have
to
think
about
how
you're
going
to
manage
individual
micro
services
that
are
deployed
independently.
Now,
while
we
talk
a
lot
about
managing
the
the
kubernetes
environment
and
I,
know
a
lot
of
money,
investment
and
time
has
gone
into
managing
at
that
level.
What
we're
really
talking
about
today
is
the
CD
pipeline,
as
it
relates
to
managing
the
applications
that
you're
building
in
your
micro
services
environment,
what's
running
on
those
clusters,
not
necessarily
how
to
orchestrate
or
manage
those
clusters,
but
what's
running
on
them,
and
how
are?
B
How
are
your
customers
executing
what
you're
putting
out
there
and
why
is
the
CD
pipeline
disrupted?
What
is
it
that
about
micro
services
that
changes
the
way
we
actually
manage
a
CD
processed?
Isn't
there
still
a
build
test
and
a
release
micro
services,
because
they're
deployed
independently
it
kind
of
changes
everything
we
do?
It
really
disrupts
our
basic
understanding
about
how
a
CD
process
operates
and
your
dev
test
and
prod
environments
are
morphing
seriously
morphing
and
Nate's
going
to
talk
a
lot
about
how
they're
morphing
and
how
STO
allows
them
to
morph.
B
So,
let's
just
think,
listen
we
have
to
in
order
to
understand
the
problem.
Sometimes
it's
easier
to
look
at
our
history
and
if
we
look
at
how
builds
are
put
together
in
the
monolithic
world,
what
we,
what
we
do
today
and
monolithic
is,
we
have
a
build
Meister
who
pretty
much
focuses
entire
day
on
making
sure
that
your
CD
pipeline,
when
you
do
a
check
in
that
your
your
code
compiles
and
what
that
means
is
they
make
decisions
about?
What
code
needs
to
be
checked
out
for
that
compiled?
B
What
versions
of
the
code
they
also
check?
They
also
determine
what
versions
of
libraries
may
be
used.
They
may
use
something
like
an
artifact,
turi
or
or
maven
to
try
to
look
at
transient
dependencies,
but
at
the
point
is
they
make
some
really
important
decisions
about
pulling
together
what
your
binary
looks
like
now,
when
we
did
the
linking
there,
we
did
it
really
early
right.
It's
a
first
step
on
our
CD
pipeline
in
a
micro
service
environment.
B
We
do
it
last,
so
we
go
from
linking
a
dev
at
the
very
first
part
of
our
CD
pipeline
to
managing
that
linkage
through
api's
and
in
a
runtime
environment,
and
that
runtime
environment
can
be
very
different.
You
can
have
many
clusters
that
your
your
your
doing,
the
linking
at
every
cluster
that
you
deploy
to
and
every
cluster
you
deploy
to,
because
I
could
have
a
different
configuration
of
micro
services.
B
So
our
bills
were
shipped.
They
you'll
still
have
a
CI
process,
but
your
your
compile,
if
you
do
compile,
will
be
small
if
you're,
using
something
like
golang
you
may
compile,
but
if
you're
using
Python
you're
not,
but
you
are
creating
a
buy,
a
build
image
and
you're
registering
a
build
image
and
that's
what
our
new
build
will
look
like.
B
Workflows,
I
think,
will
cause
most
people
moving
into
this
new
area.
The
biggest
problem
in
terms
of
how
your
pipeline
needs
to
shift
to
support
this
new
model.
We
have
to
think
in
terms
of
having
a
single
micro
service
that
is
independently
deployed,
so
it
needs
its
own
workflow,
while
most
of
you
are
probably
using.
You
have
some
very
nice
CI,
CD
pipelines,
you're,
probably
going
to
have
to
look
at
restructuring
them
in
some
way,
because
it
what
you
need
is
to
be
able
to
have
a
templated
design.
B
You
know
I
just
learned
about
Jenkins
X,
not
too
long
ago,
I
started
putting
my
head
into
it
and,
while
the
a
containerized
pipeline
solve
some
problems,
just
for
your
pipeline
in
terms
of
plugins
and
encapsulating
those,
so
you
don't
a
new
plugin
doesn't
break
everybody
else.
That
level
of
that
that
change
in
thinking
about
putting
of
containerize
in
your
pipelines
means
that
you
could
actually
template
based
on
those
containers,
so
think
about.
B
Now,
in
terms
of
the
the
you
know,
that's
the
three
core,
or
let's
say
the
two
for
today,
the
two
core
pieces
of
a
CI
pipeline.
A
CD
pipeline
is
build
and
release,
and
those
are
the
two
pieces
that
are
going
to
be
impacted.
The
most
when
you
have
a
when
you
have
workflows
running
through
separate
Micra
services
running
through
these
separate
workflows
and
you're,
pushing
them
out
independently.
B
You
really
begin
to
understand
the
loss
of
the
application
version
and
view
this
is
a
configuration
management
issue
that
was
resolved
when
you
did
the
build
in
monolithic,
and
you
made
those
decisions,
you
created
a
build
number,
you
had
an
application
version
number
that
you
were
running
off
of
all
of
that
goes
away.
So,
while
you
have
all
of
these
workflows
running
you're
going
to
need
to
start
aggregating
them
back
down
to
what
it
is
that
they're
pushing
out
and
keep
in
mind
that
microservices
in
a
really
proper
implementation
are
reusable,
which
means
one
applicant.
B
So
I
love
to
call
these
images
Death
Star's,
because
that's
what
they
very
much
look
like
and
I
saw
somebody
reference
that
on
a
Google
post
somewhere
along
the
line
a
couple
of
years
ago
and
I've
used
it
again.
Netflix
alone
has
about
4500
micro
services.
You
know,
thank
goodness,
they
have
micro
services,
because
I
know
we
all
want
to
watch
the
fifth
season
of
the
last
Kingdom
as
soon
as
it
comes
out.
B
If
you
haven't
watched
one
through
four,
you
better
start
because
it's
really
good,
but
thank
goodness
that
they
can
support
the
kind
of
usage
and
they
can
support
that
kind
of
usage,
because
they
are
built
around
a
micro
service
environment
allowing
these
things
to
spin
up
and
spin
down
on
as
they
need
to.
But
that
doesn't
mean
it
comes
without
some
issues
and
configuration
management
is
one
of
those
issues.
B
So
you,
if
you
take
it
away
somebody's
going
to
haunt
you
Frankenstein
clusters
or
just
kind
of
grow
and
get
bigger
and
bigger,
but
you
really
don't
have
a
good
understanding,
there's
observability
tools
that
are
working
to
help
us
find
these
these
this
kind
of
data
based
on
the
running
of
it
in
a
cluster.
But
we
have
to
think
about
how
we
solved
that
problem
in
the
in
the
monolithic
we
did
it
at
the
build
and
we
had
a
lot
of
control
about
what
went
into
a
particular
binary.
B
B
The
other
thing
you
need
to
you're
going
to
see-
and
this
is
a
this-
is
an
amazing
topic.
If
you're
moving
into
micro
services
and
I
highly
recommend,
you
read
about
it
and
learn
as
much
as
you
can,
and
that
is
adding
a
domain
driven
design
into
this
entire
process,
which
means
that
instead
of
having
a
kitchen
drawer
full
of
micro
services
that
you
just
throw
in
there
and
it's
this
junk
drawer,
everybody
has
a
kitchen
drunk
junk
drawer.
You
know
where's
the
where's,
the
reading
glasses,
you
dig
through
it.
B
That
is
not
what
you
want
to
do
with
micro
services.
Every
every
micro
service
needs
to
have
its
own
drawer,
so
you
know
where
to
go,
find
one
if
you're
looking
for
it.
If
you,
if
you're,
writing
a
really
good
security
services,
single
sign-on,
you
want
to
make
and
you're
sitting
on
the
eighth
floor,
you
want
to
make
sure
that
the
teams
on
the
fourth
floor
know
where
that
is
a
domain
driven
design
helps
you
do
that.
B
You
know
database
access,
routines,
centralized
logging
security
routines,
so
you
log
on
there
are
ways
that
you
can
start
seeing
patterns
even
by
decomposing
one
application
when
you
get
to
the
second
one.
Those
patterns
really
start
showing
themselves
and
that's
how
you
begin:
building
a
domain
driven
design
and
that
domain
driven
design
needs
to
be
part
of
what
you're
doing
in
terms
of
understanding
where
the
pieces
and
parts
come
from,
what
the
versions
are
and
and
where
do
we
go?
B
If
we
need
to
understand
if
this
value
this
domain
has
still
has
value,
so
we're
going
to
go
through
a
few
things,
that's
that's
kind
of
changing
I
think
helm
is
certainly
become
everybody's
favorite
for
creating
your
new
can
Tanner's
and
applying
those
containers
to
the
the
cluster.
So
if
you
haven't
looked
at
ohm,
you
should
be
taking
a
close
look
at
him
because
it
probably
will
become
one
of
the
core
pieces
of
your
CD
pipeline.
B
B
Sdo
is
what
we're
really
going
to
focus
on
today
and
sto
is
makes
for
an
interesting
part
of
the
CD
pipeline,
because
it
really
is
going
to
change
the
way
we
think
about
doing
releases
and
that's
why
it's
important
remember
the
two
made
two
main
functions
of
your
CD
pipeline.
Build
and
release
I
mean
there's
other
things
in
there.
B
Security
scanning
and
testing
and
I
mean
there's,
there's
certainly
other
parts
of
the
ecosystem,
but
why
we
did
this
in
the
first
place
was
to
be
able
to
compile
on
a
check-in
and
get
it
out
to
the
customers
as
quickly
as
possible.
Those
two
key
components
are
morphing
and
sto
is
one
of
the
reasons
why
so,
let's
just
think
about
what
that
CD
pipeline
might
look
like
in
the
future.
Your
your
build
is
going
to
switch
from
building
binaries
to
creating
container
images.
B
If
we
go
over
this
you're
going
to
have
container
images
instead
of
compiles
your
bottom
reports
going
to
have
in
your
different
ports
going
to
have
to
come
from
some
other
place
and
that's
tools
like
boy
Burnett,
ortelius,
that's
doing
configuration
management,
helm
is
going
to
be
the
piece
that
pushes
your
container
out
to
your
cluster.
It's
it
does
it
so
easily.
You
don't
need
a
big
heavy
ara
tool
to
do
that,
to
be
quite
honest
and
and
when
it
comes
to
where
it's
going
and
how
it's
being
routed,
sto
becomes
that
piece.
B
B
Configuration
management,
however,
is
going
to
become
more
critical
because
we
lose
the
bomb
reports
and
the
different
parts
and
the
impact
analysis
when
we
threw
away
the
build.
The
CD
pipeline
needs
to
be
able
to
support
literally
hundreds
of
workflows,
so
looking
at
tools
that
provide
a
good
templating
service
for
the
workflows
or
even
once
that
aren't
going
to
be
event-driven.
B
B
So
if
you
think
about
it,
I'm
just
this
is
my
last
slide
and
I'm
going
to
pass
it
over
to
Nate
he's
really
going
to
dive
down
into
how
he
implemented
is
do
sto
is
a
it
can
perform
user
routing
and
right
now
we
are
working
with
Sage
core
to
beta
test
this
out.
But
what
has
the
ability
to
do
is
to
be
the
central
point
to
pass
off
a
change
in
a
micro
service.
So
let's
say
we
push
email
service
and
v1
dot.
Seven
out
to
the
to
the
cluster
St
oak.
B
Has
the
potential
is
saying:
hey,
you're
a
developer.
When
you
execute
this
application,
you
need
to
execute
the
new
version
of
the
application
which
uses
this
new
version
of
the
email
service.
Now
that's
different
from
installing
it
into
a
development
cluster
and
then
saying:
let's
execute
the
the
new
micro
service
and
the
dev
cluster.
It
means
that
it's
going
to
be
using
all
of
the
other
stuff
from
the
production
level
and
when
it
comes
to
a
release,
it's
just
routing
again
now,
when
I
first
realized
that
this
was
possible.
B
I
spoke
to
some
people
and
they
looked
at
me
like
I
was
green
seriously
like
you're
insane,
and
then
we
did
a
recently.
We
did
a
meet-up
with
a
company
out
of
Santa
Fe
called
decart
labs
and
their
big
spinnaker
user,
and
he
he
had
a
pretty
detailed
presentation
around
spinnaker
and
then
towards
the
end
of
the
end
of
the
session.
He
said
now:
I'm
gonna
tell
you
guys
something
and
you're
gonna
think
I'm
crazy,
but
we
have
gotten
rid
of
all
of
our
dev
test
environments,
and
now
we
just
have
a
dev
test
cluster.
B
We
don't
we
don't
track.
We
have
a
dev
test
cluster
and
then
we
have
a
production
cluster.
We
put
everything
everything
we
do
for
dev
and
test,
isn't
a
single
cluster,
and
they
did
that
because
they
had
such
a
bad
cluster
sprawl
problem.
They
needed
to
figure
out
a
better
way
to
do
it
and
when
they
put
their
heads
together,
some
really
sharp
guys
from
Los
Alamos.
B
C
C
What
I
mean
by
that
is
traditionally
you
know
the
last
eight
years,
saij
core
technologies
has
been
custom,
developing
enterprise
software
to
essentially
manage
track
and
and
report
on
data
for
various
organizations.
Right
now
we
started
developing
tetra
core
to
help
us
solve
the
problem
of
scalability
within
that
sector,
and
ultimately,
we
decided
to
move
to
a
managed,
PK
or
a
managed
kubernetes
platform.
C
You
know,
if
you
deploy
a
micro
service
that
you
need
to
change,
you
have
to
be
able
to
version
that
appropriately
we'll
dive
more
into
that
our
request,
routing
being
able
to
actually
route
to
a
specific
micro
service
for
a
particular
context.
I'm
gonna
use
context
a
lot
in
in
my
slides
only
because
in
the
dynamic
Enterprise
realm,
everything
is
context.
There's
nothing
really
set
in
stone.
C
So
hopefully
I
don't
confuse
people
with
this,
so
our
host
based
routing
is
really
a
good
example
of
the
domain
driven
design
that
Traci
got
into
you
earlier
so
in
this
example,
we're
routing
all
traffic
from
my
app
comm,
which
is
default
to
production,
and
then
we
also
have
prod
mayakam,
which
is
our
direct
production.
Now
both
of
them
are
going
to
route
to
the
same
spot.
However,
in
the
future,
I
could
choose
to
split
those
if
I
wanted
to
in
this
yam.
C
C
So
what
we
realized
here
was
that
you
know
well:
yes,
we
can
do
some
host
based
routing
within
that
could
raise
ingress
objects
and
whatnot.
However,
there
were
some
limitations
when
we
actually
use
that
in
production,
we
also
really
needed
a
much
more
dynamic
lifecycle
to
actually
test
each
service
to
test
the
routing
on
different
domains.
C
Given
that
our
solutions
really
there's
not
a
lockdown
in
domains,
so
we
actually
have
to
be
very,
very,
very
structured
with
our
domain
driven
design,
and
we
also
need
to
actually
automate
our
CD
pipeline
so
that
when
we
roll
out
or
when
we
push
a
new
image,
that
it's
very
easy
for
us
to
actually
put
it
into
the
right
spot
to
deploy
it
in
our
cluster
and
route.
It
accordingly
without
tons
of
tons
of
heartache
right
and
work,
so
we'll
dive
into
how
we
do
that
next.
C
So
one
of
the
things
that
we
do
for
the
routing
of
different
destinations,
so
different
micro
service
versions,
I
should
say-
is
by
setting
up
the
sto
destination
rules.
So
this
really
for
for
us,
has
been
able
to
make
a
host
driven
deployments,
much
simpler
and
much
quicker
than
the
kubernetes
ingress.
So
what
really
makes
us
different?
You
know
obviously
I
can
update
my
kubernetes
ingress
object.
You'll,
see
that
your
routing
will
update
you
know
accordingly
and
everything's.
Fine.
C
The
problem
is,
is
usually
in
a
especially
in
a
managed
scenario
like
GK
or
AWS
you're,
going
to
have
a
lag
time
right,
while
they're
setting
up
all
the
abstractions
to
their
routing
rules
there.
All
that
stuff
it
takes.
You
know
on
GK
you're
talking
a
couple
minutes
right.
That
can
be
a
problem
when
you're
talking
a
massive
organization,
for
example
that
we
might
be
serving
you
know.
C
A
couple
minutes
can
be
the
difference
between
you
know:
I
almost
want
to
say
life-or-death,
you
know,
I
mean
we're
talking,
Big
Data,
you
know
anything
can
happen
when
you're
processing
huge
amounts
of
data,
so
you
have
to
have
that
ability
to
update
things
instantly,
be
able
to
rectify
things
instantly,
whether
it's
in
your
routing
on
the
host
level,
on
the
path,
level
etc
and
for
us
sto
really
solve
this
problem.
Nicely
we've,
you
know,
looked
into
some
of
the
other
other
service
meshes
and
I
won't
talk
to
the
validity
of
them.
C
C
So
another
problem
that
we
really
had,
especially
in
our
case,
was
that
our
request
routing
is
not
just
static,
so
obviously
you
know
we're
using
a
whole
different
combination
of
hosts
and
and
path
based,
routing,
cookie,
routing
etc.
But
you
know
we
really
needed
that
that
core
fundamental
architecture
to
be
able
to
actually
define
these
things
once
across
multiple
clusters,
and
then
all
of
those
routes
persist
right.
That
way,
it's
it's
more
of
an
issue
of
versioning
than
it
is
of
you.
B
C
Am
I
actually
routing
to
the
right
application
or
microservice
I
should
say
within
my
application.
So
this
you
know
the
you
can
hit
a
limit
quite
quickly
on
the
kubernetes
ingress
routing
and
that's
really
the
biggest
limit
that
I
think
we
saw
it's
great
for
your
top
level
network
design,
very,
very
top
level,
but
I
think
there's
a
there's.
There's
always
a
limit
I
think
it's
up
to
like
13
rolls
in
gke,
but
I
won't
speak
to
that.
C
So
I'll
walk
through
a
couple
examples
of
these
routings.
This
is
meant
to
be
a
broad
scope,
gamal
example.
So,
obviously
there's
going
to
be
some
things,
you'll
have
to
look
into
documentation
or
self.
These
aren't
necessarily
full
examples,
but
they
do
highlight
the
core
components
of
you
know
how
the
routings
being
defined.
So
in
this
example,
you
can
see
here
that
we've
defined
our
hosts
beta,
I
accom
very
similar
to
the
one
that
we
defined
for
production.
C
However,
in
this
one
we're
now
routing
to
the
destination
of
beta,
which
is,
is
still
my
app,
but
it's
another
version
right,
so
this
might
be.
You
know
for
testing
your
beta
right.
Obviously,
let's
move
on
here
so
in
your
your
CD
production,
your
CD
process
right,
you
we've
talked
about
having
the
different
labels
to
track
your
various
releases
right.
Obviously,
none
of
these
things
when
you
release
something
they
don't
overwrite
an
old
version.
However,
there
is
a
human
need
for
labeling
a
deployment
or
a
version
in
a
sense
of
which
version
in
human
terms.
C
That
you
built
it's
an
a
unique
version
right,
so
we
do
here.
Is
we
label
the
deployments
based
off
of
the
the
ISTE
of
subsets,
so
you'll
notice
here
that
in
these
animals,
I've
got
two
versions?
One
is
my
app
version
2.1,
the
other
is
my
app
version
1.
So
on
the
very
writes
my
deployment
for
production
is
version
1
and
it's
almost
identical
to
alpha
or
alpha
to
production.
C
You
get
the
point
except
for
the
different
version
label,
and
so
what
this
will
do
if
we
move
onto
the
next
slide,
this
will
correlate
to
the
something
called
a
destination
Rome,
so
destination
rule
in,
in
my
mind,
really
when
I
was
learning
these
stuff.
You
know
it
kind
of
abstract
that
that
problem
that
then
we
get
with
moving
from
monolithic
thinking
is
that
you
know
we're
still
working
on
a
version.
You
know
you
don't
want
to
have
to
increment
by.
You
know
a
version.
Every
time
you
build
a
new
image.
B
C
What
we
do
here
is
in
our
dist
destination
rule.
We
basically
define
a
subset
that
will
correlate
to
the
version
label
that
was
in
the
previous
slide.
So
the
previous
slide
was
your
deployments
right.
These
destination
rules
label
a
human
friendly
name
to
those
version
labels
so
you'll
see
I,
put
a
production
label
version,
1
I've
got
a
beta
label
for
version
2.1
and
an
alpha
for
version
2.2.
C
Now,
let's
move
on
to
the
next
slide.
Ok,
so
now
what
we
can
do
is
actually
define
virtual
services
to
route
to
those
appropriate
subsets.
So,
instead
of
saying
that
this,
this,
let's
just
take
my
opcom,
for
example,
instead
of
trying
to
route
it
every
time
to
version
2.3
and
then
I
update,
you
know,
release
a
new
version,
then
I
have
to
go
and
update
every
single
virtual
service,
2
3
or
using
this
method.
It
would
be
simply
defining
that
this.
C
This
host
mayakam
is
going
to
go
to
the
subset
called
production
and
then
in
our
destination
rules
we
then
define
what
production
means
in
sto
terms
right.
So
now
that
that
changes
our
pipeline
a
little
bit
to
for
deployment.
Let's
go
to
the
next
slide,
please.
So
in
this
case,
obviously
we're
showing
beta
is
going
to
the
beta
subset.
So
this
is
another
host
based
routing
example,
and
what
we'll?
What
we'll
do
here?
Let's
show
the
next
slide
please.
C
So
what
we'll
do
here
is
now
actually
update
the
destination
rule
to
change
what
version
right
we'll
go
to
an
actual
subset.
So
in
this
case,
you'll
notice
that
version
1
is
no
longer
the
production
version
anymore.
Now,
we've
elevated
version
2.1,
that's
now
the
most
stable
version,
everything's
ready.
We
update
our
UML
file,
push
this
out
and
then
now
every
single
production
routing
will
go
to
version
2.1.
C
C
Sorry,
so
the
the
biggest
challenge
that
we
really
had
with
migrating
from
monolithic.
You
know
the
mentality
right
is
really
being
able
to
see
what's
happening.
You
know
when
you
had
a
server.
You
know
you
could
very
easily
go
and
look
or
even
design
the
logs
to
essentially
spit
out
exactly
what
you
need
to
know
about
that
function
within
your
application.
However,
now
our
functions
everything's
been
exploded
and
now
we're
actually
talking
about
real
micro
services,
all
with
their
own
complexities
in
different
environments
that
they
may
be
running
right.
C
B
So
the
way
for
for
helping
with
this
routing,
what
ortelius,
which
is
an
open
source
project,
does
is
helps
with
what
what
Nate
just
described
it
helps
with
them
the
mapping
of
the
the
services
over
to
the
clusters.
Basically,
so
it's
it's
doing
the
configuration
management
needed
to
update
all
of
that,
those
that
variable
data
that
Nate
was
pointing
out
to
the
tracks
the
routing
and
replaces
what
basically,
your
deployment.
C
Awesome
well
so,
as
far
as
this
realization
goes-
and
this
has
actually
even
more
more
pertinent
when
you
have
a
managed
configuration-
would
be
to
see
how
everything
is
actually
performing,
so
you
know
which
services
are
actually
in
this
match.
How
are
they
connected?
How
are
they
performing?
Are
they
healthy?
Can
I
operate
on
that
or
how
can
I
operate
on
them
right
and
being
able
to
see
that
in
an
easy
way?
C
That's
going
to
be
better
in
this
context,
so
you
can
see
here
that
we
have
a
list
of
our
micro
services
and
you
can
see
that
they're
healthy.
You
can
see
the
various
labels
that
are
attached
to
them.
A
lot
of
this
stuff
really
would
be
managed
by
ortelius
right
I
would
imagine
as
far
as
the
labels
and
whatnot
goes.
So
that's.
B
C
Tool
that
would
really
help
with
this,
so
we've
got
our
rich
micro
services
in
the
mesh.
Now
on
the
next
slide
here
we
can
see
how
they're
performing
in
the
sense
of
both
health,
both
the
namespace,
which
is
actually
a
very,
very,
very
big
deal
in
Inis,
do
be
very
aware
of
your
namespaces
and
how
they
relate.
So
this
helps
with
that
and
the
next.
C
How
are
they
connected?
So
this
actually
solves
problems.
For
me
all
the
time
you'd
be
surprised,
you
know.
Sometimes
you
may
do
a
wild-card
host
or
something
that
you
know
you
might
have
done
it
twice
on
two
different
gateways
and
sto
or
something.
What
will
happen
is
is
then
you'll
be
able
to
see
exactly
where
the
request
is
coming
in
what
micro
service
is
routing
to
it
and
a
lot
of
times,
even
if
there's
no
possible
destination,
for
this
request
to
go
to
and
Kelly
does
a
very
great
UI
for
that.
C
B
It's
fine,
so
Thank
You,
Nate,
very
much
for
going
through
that
I
think
you
gave
a
really
great
example
of
how
you're
using
sto
to
manage
that
routing.
This
is
just
a
kind
of
a
word
from
from
your
sponsor.
We
do
have
art
Ilyas
out
there,
that's
helping
with
the
configuration
management
to
be
able
to
create
those
that
those
destination
rules
that
Nate
covered.
If
you're
interested,
we
would
love
to
have
you
join
the
project
and
start
talking
about
what
that
configuration
management
looks
like
and
how
to
make
those
connections.
B
Ortelius
was
the
first
map
maker.
So
that's
what
our
Tillis
is
doing
is
we're
building
maps,
and
we
see
that
when,
as
Nate
pointed
out,
trying
to
adjust
culturally
from
a
micro
service
to
a
monolithic
can
be
really
challenging
this.
This
particular
tool
is
helping
solve
that
problem.
So
visit
us
on
the
art,
ileus
github
site,
and
there
is
our
contact
information
for
anybody.
You
want
well
I'll
leave
that
up.
I'll
leave
this
screen
up
here.
So
if
you
want
to
reach
out
to
Nate,
ask
any
questions
about
how
he
set
up
those
destination
rules.
B
A
B
C
C
So
question
is:
if
people
are
able
to
consolidate
dev,
slash
test
and
production
clusters,
how
do
they
segregate
data
I
love?
This
question:
I'm
gonna,
try
not
to
go
too
deep,
but
essentially
it
depends
on
your
design.
So
if
you
have
a
single
cluster
and
you're
a
I'll
say
a
SAS
model
that
me
or
let's
say,
you're
you're
testing
or
your
your.
C
Your
data
isn't
actually
sitting
in
the
same
micro
service
as
your
production
microservice.
That
would
hold
your
data,
whether
that's
a
you
know,
hosted
SQL
or
whatever.
That
is
separating
the
data
out,
but
keeping
the
routing
within
a
single
cluster.
That's
the
simplest
answer.
I
can
provide
there
without
going
too
deep.
Do
you
want
more
on
that?
Send
me
an
email,
I
hope,
that's
enough,
and.
C
B
Take
this
one:
the
question
is:
are
there
cases
where
Kali
and
Hort
Ilyas
are
both
used
in
the
same
cluster,
so
yeah
ortelius
does
not
run
it
all
in
a
cluster.
It
is
again
sitting
outside
of
the
cluster
and
it's
looking
at
what's
being
pushed
across
all
clusters,
so
you
could
look
at
art,
Ilyas
and
say:
I
know
what
version
of
my
application
is
running
in
any
cluster
with
Kali.
B
You
would
be
running
it
at
the
cluster
level
and
you
would
be
looking
using
it
to
visualize
the
routing
and
the
transactions,
so
you
would
be
running
key
ally
in
multiple
clusters
and
ortelius
would
be
pushing
the
destination
rules
before
it
ever
gets
to
the
cluster.
So
it's
doing
the
configuration
management
and
Kali
is
watching
what's
actually
occurring.
B
C
C
B
And
there's
this
question
I,
you
know
I,
don't
think
I
can
answer
it.
I
know
that
everybody
has
a
different
journey
when
they're
going
through
the
migration
over
to
a
micro
services
and
kubernetes
environment
from
what
I
everybody
that
I
have
spoken
to.
They
they
end
up,
saying
I
wish
I
had
to
started
using
SDO
or
some
kind
of
service
mesh
sooner
I
think
it's
a
very
important
part
of
the
journey
Nate.
What
is
your?
What
are
your
thoughts?
You.
C
Know
I
would
say
that
when
you
have
more,
especially
on
the
managed
kubernetes
level,
if
you
have
more
than
I'd
say
three
to
five
host
based
routing
configuration
that
you're
using
on
a
traditional
ingress,
you're
going
to
want
to
consider
sto
pretty
quickly.
That's
that's
really,
probably
the
best
indicator
on
a
broad
level
that
I
can
provide.
B
Yet
the
question
is
doors
or
Tilly's.
Have
a
dashboard,
I
understand
per
cluster
view?
Kelly
can
be
used,
but
is
there
a
higher
level
uiview?
Yes,
that
sort
Ilyas
has
a
dashboard
and
that
dashboard
is
going
to
allow
again
it
has
a
domain
structure,
so
that
allows
you
to
publish
micro-services
and
when
you
publish
a
micro
service,
you
publish
it
with
all
of
its
deployment
data
like
chart.
It
needs
to
be
used.
B
What
the
SHA
number
is,
what
the
get
commit
is
to
make
that
particular
micro
service,
a
unique
version,
as
Nate
pointed
out
as
he
was
talking,
you
need
to
understand
what
version
of
a
particular
micro
service
that
you're
referring
to
so
it
does
that
versioning
and
then
what
it
does
is
allows
application
teams
to
consume
those,
and
then
we
track
through
the
CD
process.
We
track
the
versions
of
the
applications
and
their
configurations
think
about
it
as
a
newbomb
report
or
a
new
different
port
or
your
impact
analysis.
B
So
then
Keala
is
sitting
there
on
the
cluster
and
actually
watching.
What's
at
what's
occurring,
there
is
probably
some
good
integration
that
ortelius
and
Keely
could
have
between
the
two,
especially
when
it
comes
to
things
like
deprecating,
because
deprecation
seems
to
be
a
problem
for
a
lot
of
micro
service
environments.
It's
good
to
know
who's
using
a
micro
service.
It's
good
to
know
what
teams
are
using
it
and
what
version
I
think
we
could
probably
be
pulling
some
of
that
information
back,
but
we're
really
just
really
pulling
it
back
from
Misty
Oh.