►
From YouTube: Know Your Blast Radius
Description
Presented by Munirat Sulaimon & Temitope Bimbo Babatola and Hosted by Atul Tiwari
So you feel like you’re flying blind sometimes? That is because you may not have the data to show you how a single microservice update will impact a specific cluster, and the applications. In this presentation, you will see how Ortelius manages your impact analysis and blast radius of all microservices.
A
A
Okay,
hoteliers,
open
source
orderless
is
a
micro
service
management
platform
that
version
still
tracks
micro
services,
their
blast,
radios
and
inventory
across
clusters,
providing
proactive
view
of
your
microservice
architecture
as
it
changes
over
time.
Autelius
is
an
incubating
project
under
the
governance
of
cd
foundation,
and
our
mission
is
to
simplify
the
adoptation
of
microservices
through
a
world-class
microsoft
management
platform
driven
by
supportive
and
diverse
global
open
source
community.
A
Okay,
I
am
atul
tiwari.
I
am
the
newest
member
of
autelius
open
source,
and
I
and
I'm
in
the
in
my
final
year
of
graduation
and
open
and
ortalius,
is
the
very
first
open
source
community
that
have
joined
so
our
presentators
bhimi
and
muni,
bimi
and
muni
both
are
from
nigeria.
They
came
to
ortelius
through
the
chico
africa
program,
which
is
a
boot
camp
for
specially
designed
for
women
by
autist,
open
source.
B
Hi
everyone-
this
is
bimi,
I'm
a
data
scientist
and
I'm
a
part
of
the
authorized
open
source
community
and
natalia
is
actually
my
very
first
open
source
community.
This
is
the
first
time
I'm
doing
working
as
an
open
source
contributor
and
I've
been
enjoying
myself
today
we're
going
to
be
talking
about
knowing
a
microservice
blast
radius.
B
So
I'll
be
talking
about
this
with
money.
I
will
take
in
the
introductory
part
of
it
just
explaining
what
it
blast
radius
is
and
why
you
should
understand
ambassadors
and
then
muni
will
take
us
through
how
ortega's
helps
you
to
manage
your
blast
switches
and
then
I'm
just
going
to
stick
it
from
there.
B
They
are
not
very
confident
when
they
are
pushing
updates
and
making
updates
to
their
services,
because
they
are
unsure
of
all
the
applications
that
will
be
affected
and
because
of
this
problem,
usually
feature
microservices
are
not
fully
enjoyed
so
because
they
are
not
sure
how
how
scalable
these
microservices
they
end
up,
not
using
them.
I
just
dumped
them
after
the
very
first
use
and
I'll
tell
you.
This
is
an
example
of
what
a
blaster
just
looks
like.
B
So
this
is
a
microservice
and
you
need
to
cut
service
version,
one
two
through
150,
easy
micro
service
and
the
ipsta
store
labor
day
leave
if
you
start
start
labor,
day
sale
and
if
you
start
july
for
still
the
blast
studios.
Those
are
the
applications
that
can
be
affected
by
this
card
service
object.
So
there's
an
example
of
a
blast
radius.
This
form
just
locating
from
ortelius
blast,
reduce
map
and
okay.
So
the
problem
definition.
When
you
don't
understand
what
your
blast
rejoice
actually
means.
B
Is
you
because
microservices
is
basically
trying
to
move
away
from
monolithic
process
practices
to
handling
to
doing
microservice
architecture?
But
if
you
do
not
understand
your
blast
radius,
you
end
up
going
back
to
multiple
processes
by
tracking
your
microservices
individually.
So
you
start
updating
your
applications
one
by
one
by
one,
and
that
is
not
what
they're
trying
to
do
here
with
microservices.
B
So
when
you
do
not
know
your
blast
radios,
you
cannot
consistently
predict
the
success
of
a
microservice
release
and
out
of
necessity,
teams
begin
to
request
their
own
clusters
and
name
spaces
to
isolate
the
applications
and
control
what
is
updated.
So
you
find
that
maybe
you
have
different
teams
in
the
same
environment.
Everybody
starts
saying:
okay,
well,
my
down
service
by
ourself
and
things
like
that,
and
you
go
away
from
the
original
plan
of
the
micro
service
architecture.
B
Just
because
you
do
not
understand,
I
don't
know
your
blasts
radius,
properly
and
yeah
this
this
whole
thing
is
basically
summed
up
to
two
problems,
so
there
are
two
problems:
when
you're
gonna
assign
your
blast
radius
completely,
there's
a
micro
service,
pro
learning,
micro
service,
drips
and
I'll
go
to
the
next
slide.
Now
so,
okay
for
micro
service,
plug
spoil
a
lack
of
visibility
into
the
usage
of
a
single
micro
service
across
all
of
your
clusters
is
a
dangerous
condition.
B
When
you
do
not
know
your
micro
service
blast
radios,
you
want
to
avoid
an
adverse
impact
to
end
users,
so
you
are
left
with
some
under
undesirable
options.
One
option
is
to
run
back
to
monolithic
practices,
even
in
cloud
native
environment,
maybe
using
kubernetes
namespaces
to
style
your
applications
configuration
what
this
basically
means
is
when
you're
in
microservice
floor.
Imagine
you
have
three
clusters
and
all
the
three
clusters
use
the
same
services.
B
What
you
end
up
doing,
because
you
don't
know
your
blasphemous
is
like
repeating
the
same
services
all
over
again
three
different
places.
So
you
end
up
having
imagine
you
have
four
services
under
three
applications.
You
end
up
having
four
services
because
you're
duplicating
services
in
all
the
different
clusters.
I
know
that's
a
little
bit
confusing,
but
I'm
going.
I
have
a
picture
in
the
next
line
to
show
you
exactly
what
that
looks
like
and
micro
service
drips.
B
Usually,
of
course
when
is
microservices
sprawl,
because
then
you
update
a
service
in
a
an
application,
and
then
you
forget
to
update
updates
in
another
application,
and
then
you
see
that
your
services
are
no
longer
in
sync.
One
is
behind
and
one
is
way
ahead
in
version.
So
let
me
go
to
network
and
show
you
what
this
looks
like.
So
this
is
an
image,
and
in
this
image
we
have
three.
We
imagine
three
clusters,
three
namespaces
12
pods
and
one
environment,
so
the
pods
are
the
services.
So
this
is
the
first
cluster.
B
So,
instead
of
just
one
thing:
managing
the
three
services
before
services
for
us
we're
repeating
our
service
in
every
cluster
and
that
becomes
problematic
because,
instead
of
managing
four
pods,
we
end
up
minding
12
points
and
microservice
drip
drips
now
happens.
When
okay,
we
tried
to
update
the
shipping
port
here
from
version
3
to
version
4.,
so
we
updated
it
in
candy
store
cluster
and
the
toy
store
cluster.
But
we
forgot
to
update
this
new
clothing
store
cluster,
and
this
happens.
B
This
now
causes
a
drip
because
now
candy
store
and
toys
are
now
ahead
of
clothing
stock
cluster.
I
mean,
after
that,
the
shipping
service
drifts
at
the
clothing
store
cluster
and
those
are
the
major
problems
that
non
understanding.
What
your
blast
radiance
looks
like
would
cost,
so
I
wasn't
okay,
so
that
is
all
for
me.
I've
been
helped.
B
C
C
First,
explain
the
shared
service,
oriented
architecture,
so
here
it
says
to
minimize
the
number
of
resources
required
and
reduce
the
micro
service
pro
and
drift.
We
need
to
understand
what
teams
are
using,
which
services
so
basically
ateliers
get
tracks
dm
applications
that
are
using
your
microservice.
C
Therefore,
you
don't
have
to
update
every
application
when
the
microservice
changes.
These
architecture
reduces
the
microservice
pro
and
the
drift.
So
you
don't
you
don't
get
to
have
a
sprawl
or
a
drift
if
you
are
using
this
architecture.
That
is
moving
away
from
the
monolithic
approach
where
you
have
to
update
each
application
individually.
C
So
a
shared
service
reduces
the
complexity
of
microservice
by
eliminating
the
confusion
caused
by
the
dirt.
Like
I
previously
explained.
Most
importantly,
a
shared
service
architecture
ensures
that
critical
updates
of
the
shared
services
are
being
consumed.
By
all
terms,
a
single
releases
fixes
a
problem
for
autism.
So
if
all
the
application
used
by
a
microservice
is
connected
to
it
onesie
once
the
service
is
updated,
the
applications
are
automatically
automatically
pick
up
the
updates
and
work
with
it.
Therefore,
you
won't
have
any
cost
of
drift
or
sprawl
next
slide.
C
C
So
this
diagram
shows
how
the
drift
and
pro
problem
is
eliminated.
Previously
we
saw
that
each
cluster
adds
separate
services
in
it
and
some
of
the
one
of
the
cluster
was
not
properly
updated
to
the
new
version,
but
here
in
the
shared
architecture
service
using
the
architectural
service.
Rather,
this
is
an
example
of
an
online
store
company
cluster.
What
is
a
candy
store?
There's
a
clothing
store
and
it's
a
toy
store.
Yet
the
three
namespaces
are
connected
to
a
central
namespace
in
this
game
space.
C
Now
they
have
different
services,
they
have
the
shipping
and
version
for
port,
they
have
a
payment
and
the
card
service,
so
it
shows
that
there
was
previously
a
version
for
shipping
which
was
version
3
and
there's
a
new
release
for
shipping,
which
is
now
the
version
4.
so
automatically,
and
the
candy
store
toy
store
and
cloning
store
updates,
and
it
picks
up
the
update
from
the
shared
services.
C
So
there's
no
sprawl
or
drift
here.
The
problem
has
been
eliminated
by
using
this
service
architecture
next
slide,
so
that
is
ultimately
util
solutions
to
knowing
your
blast
radius.
So
this
them
diagram
shows
that
we
have
different
services
and
different
services
could
have
different
versions
and
looking
at
the
front-end
version,
front-end
service,
we
have
a
version,
one
underscore
two
on
score:
eight,
we
have
another
one
of
version,
one
underscore
two
on
scroll
nine,
so
either
of
these
versions
can
be
used
just
so
you
can
have
several
versions
for
your.
C
You
can
have
several
versions
of
these
services,
so
you
just
have
to
select
which
version
you're
currently
using
and
it
automatically
updates
all
the
application
that
uses
the
services.
Also
same
thing
applies
to
card
services,
where
the
white
has
two
versions
here,
but
this
diagram
currently
shows
that
it
is
using
version.
C
One
underscore
two
on
the
score
two
on
the
score:
one,
four
nine
so
either
of
the
version
will
be
selected
and
it'll
be
used
by
the
application.
So
the
application
we
are
looking
at
here
is
the
ipsta
store
july
4th
sales.
So,
under
the
it's
a
store,
the
license
application.
We
have
all
of
these
components
which
are
managed
by
artelios.
C
C
C
C
C
So
here
it
shows
that
if
this
card
service
is
updated
at
any
point,
all
of
this
application
will
also
be
updated.
It
should
be
updated
in
all
of
these
applications,
thereby
you
don't
have
to
go
into
im
individual
applications
to
update
this
service,
since
it
is
connected
centrally
to
the
service.
So
all
you
need
to
do
here
is
update
the
service
upload
it
to
deploy
to
arterios
and
each
of
the
application
uses
the
service.
C
C
We
could
have
several
applications.
There
are
several
versions
for
each
application.
Like
yeah,
we
have
ipsta
store
july
for
sale.
That
is
the
base
version,
and
then
we
have
ipsta
store
july
4th
sale.
We
have
another
version,
we
have
version
one
underscore
two
on
the
score
nine,
so
it
was
initially
deployed
to
cicd
test
cluster
to
pipeline
to
test
and
the
service
the
services
in
the
application,
and
then
it
was
deployed
to
ipsta
stock
cluster.
C
C
Also,
audio
shows
the
difference
in
an
application.
If
a
service
is
updated
in
an
application,
you
can
easily
track
the
service
that
was
updated.
So
here
it
shows
that
we
previously
have
ipso
store
cluster.
Then
we
had
ipso
store
july
4th
sale.
So
the
difference
between
the
ipsu
store,
cluster
and
ipsu
store
july
for
sale
is
the
card
service.
C
C
C
So
we
could
have
several
services
that
are
shared
by
different
applications
yeah.
It
shows
that
most
of
the
services
yeah
are
used
by
the
both
applications,
except
for
load,
test
cases
down
here
and
load
generator.
Then
all
of
that
all
of
that
application,
most
of
them.
Okay,
I
think
ad
services
is
used
by
just
web
store
label,
so
all
other
services
are
being
shared
by
both
application,
both
web
store
july
and
the
web
store.
C
Then
it
finally
gets
deployed
to
the
application
and
also
the
blast
radius
report
shows
dm
for
each
of
this
is
like
the
blm
report
is
showing
generally,
which
application
is
using
what
service
yeah,
but
the
blast
radios
report
is
per
services,
so
we
are
looking
at
card
service
yeah.
These
three
applications
are
using
the
cache
service,
the
ipso
store
library,
if
the
store
july
4th
sale
and
the
ips
store
labor
day,
sale,
yeah
so,
and
also
there's
different
reports.
C
C
Then
once
autelius
gets
the
new
update,
it
schedules
either
on
demand
or
cicd
triggers
the
deployment.
So
sometimes
you
have
to
schedule
the
deployment
out
to
the
applications
or,
yes,
it
might
be
on
demand
or
after
the
test
on
the
ci
cicdm
pipeline.
It
just
automatically
deploys
to
the
applications,
depending
on
which
one
was
selected.
A
B
Hi
I'll
be
answering
that
question.
Let
me
just
take
us
back
to
slide
where
explain
using
an
image
makes
it
really
easy
easy
to
understand
using
this
image.
So
we
have
three
clusters
in
one
environment:
three
clusters,
candy,
store,
cluster
clothing,
store,
cluster
and
toy
support
stuff.
They
all
belong
in
one
environment
and
they
all
use
the
same
service,
the
exact
same
services.
They
all
use
them.
B
If
you
look
through,
they
all
have
the
same
services,
but
because
we
have
a
service,
for
we
don't
know
our
black
students
here
we
are
repeating
the
services
all
over
and
all
over
again,
and
we
should
not
have
to
do
this
so
using
the
hoteliers,
shared
service
architecture,
we
can
just
have
all
the
services
in
one
big
box
here
and
all
the
clusters
are
connected
to
it.
So
it's
full,
of
course,
when
we
separate
our
services
into
different
different
clusters.
A
B
Okay,
I'm
taking
that
question
too.
So
from
what
money
told
us
earlier,
there
was
the
bomb
reports
that,
like
that
was
very,
very
straightforward.
So
these
bomb
reports
it's
at
the
beginning,
maybe
at
onboarding
with
the
clients
hoteliers,
goes
through
and
asks
for
all
the
applications
and
all
the
services
that
the
client
uses
so
hoteliers
already
because,
like
it's
like
a
bomb
report
showing
all
the
applications
in
the
pink
boxes
and
then
which
services
they
use,
which
ones
they
don't
use
and
so
on
and
so
forth.
B
So
just
already
document
all
this
and
then
updated
in
the
back-end
relational
relational
database,
so
hoteliers
keeps
it
locked
down
just
as
onboarding,
they
ask
you
the
important
questions.
What
applications
do
you
have?
What
services
do
you
use
for
these
applications
and
that's
how
we
keep
track
of
the
blast
radius.