►
Description
Tame your Microservices with Ortelius - Juan Peredo, Bolbeck llc
You recently successfully migrated your applications to run using microservices. Since then, you have had to modify and upgrade multiple microservices in order to ship new features and fix issues. Then, one day as you upgrade one of the services, a number of your applications start to fail. After rolling back the change, you realize that you no longer know your microservices dependencies - development slows down to a crawl while you try to sort this out. In this talk we will explore how to use Ortelius to proactively ensure you have a clear picture of your microservices based applications' architecture. We will walk through a small micro services application to understand how to visualize, track and manage the dependencies for each one of your services. By the end of this talk you will know how to deploy new services' versions with confidence !
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
The
interesting
thing,
though,
is
that
it's
really
hard
to
find
a
very
good
pizza
in
a
restaurant,
and
why
is
that?
Well,
if
you
think
about
it,
a
good
pizza
is
actually
a
combination
of
all
the
ingredients
that
come
into
that
pizza,
the
quality
of
those
ingredients.
How
they've
been
stored?
How
they've
been
managed
how
they're
being
put
together
to
work
as
a
whole
in
the
world
of
microservices?
A
Now,
if
we
further
take
a
special
look
at
this
audit
microservice,
we
can
see
that
is
actually
receiving
information
through
the
broker
about
any
changes
that
all
the
other
services
do
and
it
looks
pretty
straightforward:
a
broker
the
service
in
the
database,
but
at
the
end
of
the
day,
if
we
look
at
the
micro
level,
we
can
see
that
there's
a
lot
more
things
that
have
to
work
properly
for
this
service
to
function.
The
way
it's
expected,
we
have
to
have
some
secret
management.
We
have
to
be
able
to
package
it
and
deploy
it.
A
A
We
can
see
that
the
audit
service
that
is
sitting
here
in
the
middle
is
actually
been
called
by
multiple
applications,
not
only
that
those
applications
may
be
calling
different
versions
of
our
microservice.
So,
for
example,
the
promotions
app
is
called
in
version
1.0,
while
our
orders
app
is
called
version
1.2
and
our
invoicing
application
is
called
in
version.
2.
A
And
so
what?
Well?
What?
What
does
that
mean?
Well,
it
means
that
our
modern
applications
have
a
lot
of
moving
parts
to
the
point
where
it's
really
hard
to
keep
all
that
straight
in
your
head,
when
you
have
hundreds
of
microservices
keeping
track
of
all
those
individual
systems
is
more
than
a
single
person
can
do,
which
also
means
that,
when
something
goes
wrong
or
when
you're
trying
to
update
a
component,
sometimes
you
may
find
yourself
with
some
unpleasant
surprises.
A
What
this
means
at
the
end
of
the
day
is
that
we
need
to
change
the
way
we
think
about
software
management.
It's
no
longer
about
thinking
about
just
a
single
application
and
how
to
manage
it.
It
becomes
how
to
manage
multiple
applications
that
work
together
as
a
whole
and
that
need
to
be
managed
individually.
So
we
know
how
to
deploy
them
and
how
to
make
them
work
together.
A
If
we
want
to
upgrade
the
microservice,
we
need
to
know
which
applications
are
going
to
be
affected.
What's
going
to
be
our
blast
radius,
when
we
make
this
change
so
that
we
can
understand
what
applications
will
have
to
change
as
well
or
which
applications
are
using,
which
version
of
the
particular
microservice
or
even,
if
we're
working
with
just
one
application
which
environments
contain
which
version
of
a
particular
microservice,
so
it's
prod
the
same
as
dev
or
the
same
as
test
when
something
goes
wrong.
A
A
A
A
Additionally,
it
will
contain
other
components
like,
for
example,
our
database
domain,
which
contains
mult
all
the
databases
that
we're
using
in
the
environment.
All
it
also
contains
the
version
number
is
so
we
can
track
that
now.
These
groupings
over
here
are
something
I
created
for
our
purposes,
but
you
can
group
them
any
way
you
want
in
any
way
that
makes
it
sense
for
your
organization.
A
So
when
we're
deploying
an
application,
we
will
actually
be
pulling
individual
pieces
from
each
one
of
those
domains.
Think
about
it
as
building
lego.
Using
lego
blocks
so
each
one
of
these
is
a
lego
block
or
an
ingredient
that
we're
putting
into
our
application
or
if
you
enjoy
pizza,
there
are
the
ingredients
that
we
put
in
our
pizza
all
right.
So
that's
what
the
domain
catalog
enables
us
to
do,
abstract
the
way
we
see
our
our
components
so
that
we
can
reuse
them
and
track
them.
A
A
And
the
first
place
we're
going
to
go
here
in
our
menu
structure
is
going
to
be
the
domains
and
the
domains
is
what
allows
us
to
create
our
buckets
or
categories,
and
we
can
see
that
we
have
the
same
categories
that
we
had
created
in
our
slides.
So
we
have
our
master
data
domain
and
we
have
our
security
domain
where
we
had
our
audit
microservice.
A
A
A
A
A
A
So
here
we
see
that
our
audit
service
is
actually
a
container
and
that
we
are
expecting
to
deploy
to
kubernetes,
and
if
I
go
further
down
zoom
in
a
little
bit
so
that
we
can
take
a
better
look,
you
can
see
that
our
audit
service
has
actually
been
used
by
three
applications:
the
invoicing
application,
the
forecasting
application
and
our
application
version.
One.
A
A
A
A
A
We
can
also
see
how
long
each
one
of
those
deployments
and
because
what
I
was
playing
with
was
very
small.
There
is
no
actual
time,
but
if
this
was
a
real
application,
we
could
see
how
long
each
one
of
those
deployments
take
over
time,
and
we
could
see
if
there's
been
a
number
of
failures
in
our
deployment.
A
For
now.
It's
all
green
we've
never
failed
deploying,
and
finally,
we
can
see
that
we've
deployed
our
application
to
production
if
we
had
deployed
it
to
other
environments.
That
would
drop
that
would
show
up
over
there
and
we
can
also
once
again
zoom
in
to
see
the
make
up
our
application.
So
we
can
see
that
it's
been
deployed
to
our
application
product
environment,
which
is
running
on
a
production,
kubernetes
cluster,
and
we
can
see
the
individual.
A
A
But
there's
a
there's
an
additional
view
that
I
would
like
to
show
you
that
I
think
shows
a
lot
of
promise,
which
is
our
map
view
that
will
display
for
us
a
bird's-eye
view
of
what's
running
on
our
environments.
So
we
can
see
that
we
have
our
application
in
our
application
version
one,
and
if
I
click
on
one
of
them,
we
can
see
it
highlights
all
the
dependencies,
including
our
audit
service,.
A
A
Well,
that's
a
lot
of
information
that
I
need
to
keep
track
on
and
maintaining
or
tell
you
and
you're
right,
but
that's
where
ci
cd
comes
to
the
rescue,
because
ortelius
integrates
with
cidc
cicd,
which
means
that
all
the
creation
and
maintenance
of
the
data
required
by
ortelius,
like
creation
of
new
components
or
new
versions,
is
automatically
created
as
you're.
Deploying
your
application
to
the
different
environments
and
nortel
provides
both
an
internal
deployment
engine
as
well
as
integration
with
multiple
external
popular
ccd
solutions
like
jenkins
and
gitlab.
A
A
What
changed
to
our
application,
who
had
caused
the
error?
So,
for
example,
did
I
deploy
version
1.4
of
our
service
and
is
that
what's
causing
this
particular
error
that
we're
seeing
well
with
hortelius?
We
have
enough
information
to
try
to
determine
that,
but
at
the
end
of
the
day,
right
we
need
to
change
the
way
we
manage.
A
A
A
All
right!
Well,
if
anybody
has
additional
questions,
I
know
we've
been
answering
questions
on
the
chat
if
anybody
wanted
to
jump
in
and
share
their
video
and
ask
questions,
that'd
be
great,
if
not,
we've
seen
a
lot
of
a
lot
of
good
questions
on
the
chat
and-
and
that
shows
that
this
is
a
real
problem
that
we're
facing
once
we
move
to
a
microservices,
have
a
base
architecture.
A
The
second,
the
second
way
to
do
this
is
through
the
integration
with
the
ci
cd
tools
we
saw,
while
the
slide
showed
the
integration
that
we
have
and
there's
more
that
are
coming
and
the
third
one
is
using
services
discovery.
So
one
of
the
things
that
the
team
I
believe
is
working
on
is
integrating
with
service
mesh
so
that
you
can
interrogate
the
service
mesh
to
see
what
what
traffic
is
coming
through.
A
A
B
A
A
Potential
issues
that
you're
going
to
be
adding
to
your
system
because
you
made
a
change
to
a
particular
microservice.
It's
very
important
and
it's
very
it's
very
good
information
to
have,
and
it's
something
that
most
people
when
they
start
working
with
microservices.
They
don't
realize
how
interrelated
these
things
are.
At
the
end
of
the
day,
yes,
they're
they're
built
to
be
independent,
but
they're
they're,
part
of
a
whole
right
of
a
bigger
picture.
B
C
A
B
Okay,
so
that
would
say
I'm
going
to
update
I'm
adding
a
new
endpoint
or
I'm
adding
a
new
version
of
this
thing
with
a
new
endpoint
and
people
are
consuming
the
old
endpoint
and
if
they
switch
my
new
one.
These
are
the
people
that
may
be
affected.
So
that
means
I
would
need
to
test
their
application
interaction
with
my
microservice.
A
It
means
that
now
you
know
that
before
you
deploy
your
new
version
and,
more
importantly
before
you
remove
the
old
version,
you
have
to
talk
to
some
people
and
make
sure
that
they
understand
that
that
that
there's
going
to
be
consequences
to
the
new
release
right.
So
your
team-
let's
say
your
your
billing
team.
The
last
thing
you
want
to
do
is
stop
billing,
because
you
change
your
microservice
that
does
authentication
right
right.
B
A
A
Well,
it
comes
down
to
whether
you
want
to
react
to
somebody
failing
or
be
more
proactive
right.
So,
yes,
it's
very
you!
You
can
set
up
your
environment
so
that
you
can
react
right
away
when
something's
failing
or
you
can
make
it
so
that
you
can
proactively
tell
people
that
this
is
going
to
fail.
Unless
you
do
xyz
right.
B
B
I
guess,
if
I'm
the
consuming
service,
I
would
be
able
to
know
that
the
new
version
of
the
api
is
there
and
I
could
test
my
application
to
use
it
and
I
wouldn't
necessarily
have
to
contact
them
about
the
new
apple
new
api
version.
I
would
just
see
it
and
I'd
be
able
to
say
all
right,
I'm
going
to
upgrade
to
the
new
api
version.
C
A
B
B
A
I
think
it
is
I'm
not
a
hundred
percent
positive.
I
I
I
don't
know
if
there's
there's
one
available
right
now
that
you
can
access
directly.
I
know
that
there's
tools
like
jenkins
that
will
post
into
it,
so
I'm
assuming
if
it's
not
available
it,
can
be
readily
made
available,
but
I
don't
know
I
won't.
I
won't
guarantee
that
that's
there.