►
From YouTube: Observability vs. Visibility - what is the difference?
Description
In this session hosted by Karamjot Singh, Sacha Wharton gives an overview of the Observability trend and explains how Ortelius provides a proactive approach to 'visibility'.
A
Welcome
everyone
to
arterious
microservice
visionaries2021,
it's
a
pleasure
to
have
you
all
guys
with
us,
and
today
we
are
going
to
discuss
a
very
hot
topic
in
the
field
of
microservices.
That
is
observability
and
visibility.
So,
as
you
know,
like
microservices
have
spam
the
whole
software
engineering
and
it
has-
although
it
also
created
lots
of
challenge,
new
challenges
and
how
we
monitor
our
applications.
A
B
It's
awesome
to
be
doing
this
talk
with
you
right,
so
let
me
get
started
yeah,
okay,
so
just
to
introduce
ortillius,
open
source
project,
the
microservices
management
platform,
that
versions
and
tracks
microservices
the
blast,
radius
and
inventory
across
clusters,
providing
a
proactive
view
of
your
micro
service
architecture
as
it
changes
over
time.
The
turlius
is
an
incubating
project
under
the
governance
of
the
ced
foundation,
also
known
as
lennox
foundation.
B
Our
mission
is
to
simplify
the
adoption
of
microservices
through
a
world-class
microservice
management
platform,
driven
by
driven
by
a
support
and
supportive
and
diverse
global
open
source
community
right.
Okay.
So
it's
like
like
ram
introduced,
we're
going
to
be
talking
about
observability
and
visibility
and
arc
or
tillius
creates
visibility
across
all
clusters.
B
B
So
monitoring
and
observability
are
quite
a
hot
topic
at
the
moment,
and
I
find
that,
whilst
doing
this
research,
there
was
a
lot
of
a
lot
of
conflicting
uses
of
the
words
and
they
were
used
interchangeably,
but
basically
what
it
boils
down
to.
However,
you
use
it
doesn't
really
matter
in
the
end
it
kind
of
boils
down
to.
I
found
that
monitoring
is
a
reactive
process
that
tells
you
when
known
problems
have
occurred.
B
It
gives
you
a
systematic
overview
of
of
time,
tracking,
the
known
and
unknowns
in
the
system
it
uses
instrumentation
to
show
you
performance
points
of
failure.
It
is
also
a
it's
also,
very
reactive,
it's
basically
after
the
fact
alerting.
The
problem
has
already
occurred,
but
in
today's
systems
they've
become
increasingly
complex,
distributed
and
and
dynamic.
So
this
kind
of
this
has
changed
the
way
we've
always
traditionally
done.
B
Monitoring
it's
always
been
in
place
after
the
fact
the
application
gets
deployed,
then
monitoring
gets
slapped
onto
there,
but
this
is
it
with
this
change
into
microservices
and
distributed
services.
It
requires
us
to
go
now
to
sort
of
the
next
level,
which
is
observability,
and
this
allows
us
to
proactively.
B
This
is
actually
proactive,
making
systems
applications
monitorable,
and
this
is
moving
towards
an
active
identification
and
making
visible
of
unknown
issues,
and
this
information
relies
on
logs
and
traces
and
metrics.
So
now
we
really
have
to
move
into
this
environment
where
we
actually
need
to
unearth
what
we
need
to
monitor
before
we
kind
of
knew
what
we
needed
to
monitor.
That
was
reactive.
B
Now
we
need
to
actually
design
our
monitoring
systems,
or
our
observability
system
or
visualization
was
also
another
word
that
was
thrown
in
there
to
be
proactive
and
they
need
to
be
started
from
the
beginning
of
them,
and
the
application
is
developed
right
from
the
beginning.
They
need
to
be
part
of
the
design
and
the
plan
they
can't
just
be
slapped
on
at
the
end.
B
Obviously,
there's
configuration
management
to
to
to
look
at
and
also
various
different
environments.
It's
not
just
one
singular
environment,
there's
multiple
environments,
multiple
configurations
and
these
micro
services
are
spread
out.
They
could
be
global,
they
could
be
regional,
it
all
depends
on
how
your
system
is
being
set
up
and
what
you
have
to
manage.
B
So
there
needs
to
be
some
sort
of
proactive
visualization
and
which
autilius
does
and
gives
us
this
logical
mapping
of
microservice
relationships
and
application
dependencies
across
all
clusters,
not
only
just
with
a
single
cluster.
It
also
gives
us
the
insight
into
the
into
the
now
and
on
the
other
side
of
it.
It
also
allows
us
to
understand
the
future
of
our.
B
Applications
so
ortillas
core
object,
consists
of
domain
and
applications,
components,
environments
and
endpoints,
and
I
find
that
australia's
answers.
These
are
just
some
of
the
questions
that
I
was
thinking
of.
What
is
autelius
answer
like?
How
does
this?
What
questions
does
it
answer
across
these
distributed
services
and
I've?
I
came
up
with
these
three
questions.
I'm
sure
there's
a
whole
lot
more,
but
I
just
met
I
jot
it
down.
B
B
So
karam
wrote
an
excellent
blog,
which
helped
me
understand
and
get
a
really
good
foundation
about
observability,
and
I
had
to
quote
his
blog
post
in
this
presentation
because
it
was
just
so
brilliant
and
it
just
explains
what
what
otilius
uses
to
show
these
these
visualizations,
because
that's
what
they
really
are.
They
are
proactive,
visualizations
that
almost
almost
work
almost
in
near
real
time
and
they
can
re
and
they
really
help.
You
understand
your
application,
like
I
said
like
now
and
in
the
future
and
for
example,
there's
they
use
it's.
B
The
use
of
the
container
show
it's
the
application
baseline
package
and
change
software
bill
of
materials.
It's
the
revision,
history
and
the
difference
map,
so
you
can
actually
use
octillius
to
show
that
what
what
what
was
changed
and
what
has
and
and
what
is
it
now
you
can
track
the
deployment
logs.
It
combines
this
data
to
give
you
a
complete
overview
of
your
application
and
how
it
interacts
and
how
it
has
relationships
with
other
micro
services
that
are
running
in
your
environments.
B
This,
for
example,
is
a
blast
radius
report
and
at
the
bottom
is
a
difference
report.
You
can
see
the
different
versioning
and
at
the
numbers
that
that
show
yeah
these
numbers.
They
show
what
what
the
version
was
and
what
it
is
now.
The
bullet
materials
report
shows
you
everything
that
makes
up
this
this
cluster.
A
B
Yeah,
so
that's
a
that's
a
good
question
so
beforehand
it
was
much
easier
to
to
monitor
a
monolithic
application,
and
that's
that's
why
I
say
ethics
monitoring
was
put
on
at
the
end
because
it
was
kind
of
you
know.
Everything
was
self-contained
into
one.
You
know
one
environment
or
yeah.
It
was
the
application
wasn't
that
distributed.
It
was
always
sort
of
sort
of
put
on
an
island
and
isolate
it,
and
that
was
it
was
it
wasn't.
B
It
was
quite
easy,
then,
just
you,
you
were
fine
with
using
monitoring
to
give
you
a
to
give
you
feedback
on
how
your
system
was
performing
and,
like
I
said
it
was
very
reactive
because,
for
example,
if
you
would,
you
would
know
like
you
would
know,
on
a
high
level
like
if
you
needed
more
memory
or
your
cpu
or
what
was
an
acceptable
rate
set
for
your
cpu.
But
I
don't
think
it
was
good
enough
for
for
developers
you.
Actually
there
was
just
so
many
things
that
actually
could
that
needed
to
be
monitored.
B
So
we
had
to
do
then
we
had,
and-
and
this
was
never
going
to
work,
this
reactive
type
of
monitoring
was
never
going
to
work
as
we
started,
moving
towards
a
more
virtualized
environment,
and
now
we're
really
now
we're
not
only
virtualizing
on
a
you
know
like
a
from
the
on
a
virtual
machine
level
on
the
operating
system.
Now
we've
cut
that
out
and
we've
gone
straight
down
to
the
raw
to
the
binary
and
that
can
be
spread
out
and
run
anyway.
B
So
what
the
user
would,
how
the
user's
query
would
actually
move
through
a
system
how
it
where
what
points
it
touched
on-
and
this
allowed
us
to
really
understand
how
users
interacted
with
our
applications-
and
this
means
we
could
make
proactive
decisions
and
I
think,
even
in
a
sense,
experiments
and
prototype
understanding
like
what
happens
if
we
had
a
for
example,
maybe
we
were
a
product
company?
What
happens
if
we
decided
to
have
a
massive
sale
and
we
had
like
double
the
amount
of
users
hitting
outside
now
with
it
with
the
visualization
from
austilius?
B
We
understand
exactly
all
these
points
are
going
to
be
hit,
so
we
would
have
we
could.
We
could
be
proactive
in
making
sure
that
this
system
was
ready
to
handle
more
users,
and
we
could
really
dive
deep
into
these
these
application
components
and
make
sure
that
they
were
able
to
handle
this
type
of
traffic,
and
that
would
mean
changing
whatever
we
needed
to
change
to
handle
this
so
yeah.
I
hope
that
answers
the
question.
A
So,
like
the
evolution,
I
will
be
like
obvious
with
the
monolith
application.
We
had
a
single
point
of
failure,
but
like
with
microservices
we
have
like,
we
can
have
lots
of
points
of
failure
and
it's
difficult
to
track.
So
we
have
to
rely
on
you,
this
particular
three
pillars:
logs
metrics
and
traces,
to
like
help
us
help
us
out
and
find
the
bottleneck
in
our
system.
B
B
You
know
it's
not
like
back
in
the
day
when
you
had
to
trawl
through
logs
and
terrible
having
to
try
and
read
tiny
little
bits
of
text
or
trying
to
figure
out
some
sort
of
a
nasty
script
to
try
and
highlight
what
you
wanted
to
see,
and
anyway,
there
was
just
so
much
data
that
distributed
among
systems.
It
wasn't
centralized
so
well
now
that
we
have
ortilis,
we
can
really
understand
the
history
and
and
actually
pull
out
what
we
want
to
see
in
these.
A
So,
like
autonomous,
provides
us
the
tools,
one
is
the
application.
Will
work
and
the
business
side
of
the
people
can
see
all
that
all
of
your
micro
services
together
a
single
application
or
a
product
as
well
as
for
the
from
the
developers
or
the
technical
side
of
you.
They
can.
The
teams
can
deep
dive
into
the
smart
into
the
services
and
get
more
details
about
the
deployment
and
all
so
what
is
basically
a
single
source
of
truth,
which
integrates
with
all
four
existing
tools
that
we
have.
B
I
always
have
a
little
bit
of
fun
with
the
lord
of
the
rings
and
for
the
one
ring
to
rule
them
all
because,
like
we're
going
to
have
beer
and
donuts-
and
I
was
actually
thinking
of
a
dino
and
the
donut
for
me-
would
symbolize
all
the
services
you
know
that
are
that
are
packed
in
all
around
on
the
donut
and
in
the
middle
is
ortilius
actually
could
be
the
jam.
If
you
want
to
call
it.
B
Be
able
to
aggregate
all
that
different
bits
of
informed
pieces
of
information
from
all
around
it
and
be
a
central
source
for
the
developers
to
be
able
to
actually
see
the
impact
that
they
are
having
on
a
system
and
when
they
change
things,
what
they
are
changing
and
when
they
change
it.
What
does
it
affect?
A
B
I
think
open
telemetry
is
the
future,
because
it's
api
driven.
I
was
also
having
a
discussion
the
other
day,
actually
with
sergio
and
yeah,
and
I
was
talking
about
another
product
which
uses
a
lot
of
agents
and
like
this,
this
kind
of
takes
that
away.
There's
no
more
agents
create
for
me,
an
overhead.
B
You
know
a
management
overhead,
whereas
if
you're
using
an
ap
api
based
type
of
tool,
this
allows
you
to
to
actually
streamline
what
you
the
kind
of
information
you
want
want
out
of
that
and
to
standardize
on
something
like
this.
It's
just
brilliant
because
it
allows
you
to
pretty
much
design
and
get
creative.
B
The
way
you
want
to
see
the
data
and
you
can
choose
what
you
pull
in
and
and
leave
out,
and
I
think
it
gives
an
immense
amount
of
flexibility
in
terms
of
visualizing
the
state
and
how
you
want
to
visualize
it
yeah
you
can.
I
think
I
think
your.
I
think
I
think
the
creativity
is
endless
and
I
definitely
think
something
like
open
telemetry
is
a
is
a
it's
definitely.
The
future
yeah
api.
Definitely
api
driven
types
of
things
like
that
that
service.
B
A
B
B
You
could
follow
me
and
ask
me
if
you'd
like
to
on
linkedin,
I
don't
mind
helping
out.
They
could
also
look
for
you
on
linkedin
and
yeah.
We
are,
we
are.
We
are
looking
for
people
who
really
just
want
to
come
in
and
and
join
and
learn
and
and
create
a
really
great
community.
It's
a
great
community
of
people
to
be
in
and
to
and
to
enjoy,
taking
something
like
this
together
with
people
from
all
over
the
world
is
a
real
privilege
and
yeah.
B
We
like
we
would
really
welcome
anybody
who
would
like
to
come
and
join,
and
please
go
and
check
us
out,
go
and
have
a
look
at
what
austilius
is.
You
can
go
to
ortillius.io2,
oh
there,
it
is
actually
said
io
and
go
and
have
a
look
what
ateliers
can
do
and
how
you
can
get
involved.
Thank
you
very
much.