►
From YouTube: 2020-08-06 Istio Community Meeting
Description
A demo of Mesh Dynamics, and thoughts on the mesh ecosystem.
A
A
A
B
B
Yes,
yes,
okay,
cool
sounds
good,
so
let
me
quickly
set
up
the
problem
context
a
little
bit
here
so
with
I
mean
we
all
know
that
microservices
adoption
is
pretty
rapidly
growing
across
the
across
all
companies,
while
the
operational
aspects
of
microservices
are
are
being
addressed
pretty
well.
These
at
the
adoption,
has
actually
created
new
problems
for
developers.
So
one
of
the
the
two
areas
that
we
are
actively
looking
at
is
as
a
developer
changes
a
service,
let's
say
in
their
entire
microservices
application.
B
How
can
the
developer
test
her
change
quickly,
including
the
service
interactions
and
so
on?
So
there's
a
lot
of
friction
in
that
in
that
in
that
process,
that's
one
area
and
the
second
area
is
around
api
test
integration,
test
creation
and
what
used
to
be
sort
of
unit
tests
in
the
monolith
world
has
become
some
sort
of
integration
test,
the
component
level
at
the
service
level
and
even
at
the
app
level.
B
So
if
you
look
at
the
current
options
that
we
have,
as
we
talked
to
a
bunch
of
developers
working
on
these
microservices
applications,
there
are
three
options
that
we
seeing
primarily
the
predominant
one
is
using
dev
clusters
right.
So
if
I
make
a
change
to
one
service,
I
actually
push
that
service
to
a
dev
cluster,
along
with
other
services
that
I
depend
on,
or
the
entire
application
itself
into
a
dev
cluster
me
either
in
a
personal
name,
space
or
a
team
name
space
and
start
debugging
in
that
cluster.
B
B
This
this
request,
outgoing
requests,
are
automatically
redirected
by
the
proxy
in
this
on
the
desktop
in
the
in
the
in
our
mess
dynamics
product
to
the
mesh
dynamics
simulation
services,
if
you
will
the
mock
services-
and
these
mocks
are
actually
auto
created
from
their
traffic-
that
we
are
captured
from
the
continuous
integration
pipelines
that
way
the
catalog
service.
Things
is
search
and
recommended,
services
are
live,
but
they're
actually
faithfully
being
mocked
based
on
the
traffic
that
we
saw
right.
So
the
developer
doesn't
need
to
worry
with
our
search
and
recommender
are
alive.
B
There
are
for
that,
for
their
purpose.
They're
all
alive
and
kicking,
but
they're
able
to
use
their
ide
to
test
service
integrations
component
testing,
all
of
those
things
right
right
in
their
id
without
having
to
push
their
change
to
a
dev,
cluster
or
or
relying
on
a
name
space
and
so
on.
So
that
is
a
that's
a
that's
the
capability
that
we
enable
and
if
they
need
to
change
any
of
the
ingress
api
signatures
or
responses
or
the
egress
api
requests
and
responses.
B
We
enable
the
developer
to
edit
in
place
and
get
that
that
that
kind
of
a
behavior
also
testing
going
on
when
the
other
service
is
not
ready
yet
right.
So
that,
in
a
nutshell,
is
what
we
offer
and
we
are
heavily
leveraging
this
istio
capabilities
to
deploy
these
online
filters
and
and
create
those
filters
right.
If
you
look
at
it,
it's
there
is
a
one-time
setup
where
we
actually
create.
B
We
have
a
template
which,
which
uses
a
whole
bunch
of,
let
me
see
if
it
opens
up
yeah.
So
this
is
our
template,
lua
filter.
It
has
a
bunch
of
environment,
this
variable
name,
service,
name,
namespace
and
so
on,
and
someone
can
so
there's
a
filter
generator.
Once
we
take
the
services.yaml
from
istio,
we
just
substitute
the
service
names
creates
the
lower
filters
and
whenever
you
want
to
record
the
traffic,
you
just
keep
cutting
apply
the
lowerfilters.yaml
and
the
recording
is
going
on
right.
B
Basically,
and
you
can
stop
whenever
you
want
by
deleting
those
filters.
So
that
is
the
way
we
are
leveraging
these
to
your
capabilities,
to
actually
set
up
the
recording
and
preparing
enabling
developers
to
test
their
service
changes
locally.
So
let
me
stop
sharing
and
hand
it
off
to
rahul.
Meanwhile,
I'm
happy
to
take
any.
C
C
C
So
when
we
record
the
data,
we
are
actually
recording
traces,
not
just
individual
requests,
so
cell.
So,
for
example,
right
now
I
have
a
version
of
this
service
running
locally
within
my
ide
and
let's
say
I'm
going
to
make
some
changes
to
this
service.
So
how
can
I
go
ahead
and
do
that
using
the
tool
without
any
dependency
on
having
a
div
cluster
available
somewhere?
C
So,
as
vinky
mentioned,
what
we
do
is
we
are
leveraging
istio
and
the
lua
filter
to
capture
data
from
your
ci
pipelines
or
other
places
where
you
might
be
producing
reliable
data.
So
here
we
have.
I
have
one
source
open
here,
so
what
I
can
do
is
since
I'm
working
on
this
api.
I
can
just
take
a
couple
of
examples
for
this
and
say:
okay,
I'm
going
to
use
those
as
my
examples
for
for
the
next
few
requests
for
my
development,
and
I
have
the
service
here
running
in
my
eclipse.
C
C
Here
are
the
egress
requests
that
are
typically
associated
with
when
we
are
when
we
capture
the
data
from
the
ci
pipeline,
so
we
are
automatically
mocking
all
of
these
requests.
All
of
these
egress
requests
for
this
particular
request
that
we
are
sent,
and
let's
say
this
is
a
the
use
case.
Here
is
a
refactoring
use
case,
so
we
don't
expect
any
significant
changes.
We
more
or
less
expect
the
same
egress
request
as
the
behavior.
To
be
the
same.
C
So
let
me
send
that
request
against
a
copy
running
in
my
ide,
so
I'll
just
say
run
here,
so
you
can
see
this
is
executing
here
in
my
eclipse
and
it
finished
so
here
I
can
now
see.
Okay.
How
does
this
look
given
it's
a
refactor
use
case.
We
expect
that
the
here's,
the
response,
here's
the
order,
the
left
hand
side
is
the
original
response
we
had
recorded
the
right
hand.
Side
is
the
new
response.
So,
as
you
can
see
it's
more
similar,
but
there
is
clearly
other
problem.
C
There's
this
actor's
first
name
area
that
has
been
added,
so
I
can
now
go
ahead
and
modify
my
code
and
fix
that
if
I
need
to
do
there's
the
order
of
the
names-
that's
different
in
this
one
particular
area.
Let's
ignore
that.
Let's
say
that
does
not
matter
for
us,
so
you
can
use
this
this
way
to
kind
of
do
the
refactor
case
make
the
changes
run
the
request
until
all
of
the
differences
that
you
care
about
are
gone
now.
Listen.
C
The
next
use
case
is
you're
actually
going
to
make
a
change
to
this
service.
And
oh,
the
other
thing
I
want
to
point
out
is
here
you
can
see
when
I
made
this
ran
this
request.
Once
again,
we
captured
the
full
tracer,
so
we
can
show
you
exactly
what
happened
with
the
egress
requests,
so
you
can
see
as
a
result
of
the
refactor.
C
The
order
in
which
these
requests
are
being
made
has
changed,
but
the
result
is
still
the
same
and
also
but
if
you
want
to
say,
for
example,
I
want
to
compare
two
of
these
requests,
since
these
are
mock
requests.
I
only
really
care
about
the
address
requests.
I
can
do
the
compare
and
let's
compare
their
requests.
So
if
I
look
at
the
outgoing
the
query
parameters
for
the
egress
request,
you
can
see,
there's
really
no
change,
so
it's
all
good
and
obviously
the
response
here.
Once
again,
we
are
doing
a
diff
here.
C
The
response,
obviously,
because
it's
coming
from
the
mock
the
response
will
be
consistent.
Given
that
the
request
is
fine,
okay,
so
that's
kind
of
the
refactor
kind
of
use
case.
Now,
let's
say
I'm
actually
going
to
make
a
change
to
this
service.
That
also
requires
a
change
to
one
of
these
egress
requests
and
let's
say
that
service
is
not
ready
right
in
a
conventional
approach.
You
will
have
to
either
build
new
mocks
for
it
or
you
have
to
wait
for
that
service
to
be
updated.
C
C
C
C
Save
it,
and
now
I'm
going
to
actually
use
this
new
version
that
I
have
just
created
for
my
use
with
this
updated
mock
all
right,
so
that's
the
one
that
I
have.
So
if
you
look
at
this
detail
service,
I
have
edited
the
mock.
The
mock
now
has
this
new
field
that
I
added
so
the
first
thing
I
can
do
is
I
can
just
run
that
same
request
against
this
to
make
sure
everything's
good.
So
I
will
go
back
here
say,
run
the
request.
C
Request
is
running
okay,
it's
back!
So,
if
I
now
look
at
the
result,
you
can
see
okay,
so
two
things.
I
want
to
point
out.
The
code
that
we
have
changed
here
that
we
are
going
to
change
is
going
to
make
us
change
to
this
book
info
when
it's
done.
But
as
you
can
see,
the
book
info
is
everything's
fine,
but
here
we
put
in
the
the
new
mock
the
updated
mark.
You
can
see
that
the
mock
response
has
now.
C
C
So
essentially,
what
we
have
done
is
we
have
leveraged
the
steel
capability
to
collect
a
lot
of
data
and
we
are
allowing
the
we
are
enabling
the
developers
to
make
all
these
changes
edit.
The
mocks
use
all
of
the
data
to
have
them.
This
handy
mocks
for
all
the
external
services
edit,
the
mocks
locally,
based
on
whatever
contract
changes.
They
are
planning
and
then
just
develop
everything
locally
to
edit
those
updated
mocks
until
the
new
services
are
available.
C
A
C
B
B
B
And
basically,
what
we,
what
we
are
seeing
our
customers
do
is
when
they
deploy
the
in
their
ci
pipelines
whenever
they're
bringing
up
these
two
clusters
or
if
they're,
existing
name
space
they'll
just
apply.
This
add
this
cube,
cut,
apply
line
and
then
the
traffic,
the
api
requests
and
responses
start
getting
recorded
in
the
mesh
dynamics,
services
and
their
developers
can.
A
B
D
C
So
there
are
kind
of
two
parts
to
that
answer.
One
is
since
we
are
you're
absolutely
right.
If
we
are
going
to
capture
this
data
from
production,
there
will
be
a
lot
of
sensitivity
issues,
but
because
we
are
focusing
on
the
ci
pipelines
or
your
staging
cluster.
Typically,
the
data
is
not
not
so
sensitive,
and
but
even
within
that,
what
we
are
finding
is
some
companies.
C
Actually,
a
lot
of
companies
have
policies
that
even
data
from
their
ci
pipeline
cannot
leave
the
premises
for
those
we
have
to
have
an
on-prem
deployment
of
the
back
end
as
well
as
the
data
is
stored
locally,
but
there
are
also
a
bunch
of
bunch
of
people
who
don't
care
about
their
ci
data
living
and
for
those
they
are
coming
to
our
cloud.
If
it's
production
data
yeah,
there's
not
a
chance
of
that
data
ever
leaving
the
the
customer.
B
Premise
and-
and
we
have
hooks
for
obfuscating
so
based
on
the
paths
like
the
json
pathway,
the
request
or
response
parameters,
we
can.
We
have
the
hooks
for
obfuscating
and
encrypting
those
fields.
So
it's
obfuscation
is
one
way.
Basically
is
an
assessment?
Is
obfuscated
and
even
no
one,
not
even
the
developers
can
see
what
the
actual
original
value
is
right.
So
if
it's
encrypted
then
there's
an
option
to
decrypt
it
again
when
we're
replaying
right
at
the
test
just
before
testing.
So
those
options
are
there
but
yeah.
C
A
E
B
A
F
Opinion
about
development
locally,
I
think
the
there's
some
extent
that
developers
can
work
locally,
but
as
the
number
of
resources
and
the
clusters
increase,
there's
a
increasing
need
to
go
remotely,
and
especially
because
when
you
talk
about
in
cloud
environments,
especially
where
ecu
is
is
in
context,
getting
development
remotely.
Has
me
more
pervasive
as
locally.
F
So
I
I
assume
that
we
get
to
start
moving
working
more
remotely
and,
of
course,
some
of
us,
especially
who
work
a
long
time
in
development.
They're
going
to
struggle
and
say
I
want
to
think
half
thing
locally
as
they
used
to,
but
the
whole
technology
is
moving
to
more
remotely.
And
that's
just
my
personal
opinion.
C
C
F
B
You
can
let
those
databases
be
remote,
it
doesn't
have
to
be
local.
So
that's,
okay
right.
Some
of
the
data
resources
can
be
remote,
but
then,
if
you're
anyway,
so
the
assumption
is
one
service
will
not
require
all
of
the
data.
It
may
be
a
small
database,
at
least
from
a
testing
perspective,
so
that
can
be
local
or
remote
and
you
can
also
mock.
Actually,
the
external
service
calls
like
twilio
or
ox0.
Whatever
you
have,
you
can
actually
mock
those
calls
too.
C
F
Yeah,
absolutely,
I
think,
mocking
is
one
strategy
you
can
apply
it,
but
just
bear
in
mind
like
every
single
time
you
market
and
then
go
to
deployment
and
go
into
production
and
then
something
fails.
You
have
to
go
mocking
again,
so
one
I
could
argue
like
mocking,
also
take
some
time
out
to
your
development.
B
B
C
E
So
I
think
there
are
multiple
ways
to
tackle
this,
and
certainly
this
is
as
good
a
a
way
as
good
an
approach
as
any.
It
has
advantages
and
disadvantages.
Obviously-
and
it's
similar
to
like,
if
you
look
back
to
what
happened
with
soap,
when
soap
was
introduced
and
you
had
esps
and
the
like
that
a
lot
of
the
tooling
there
did
some
very
similar
things
with
http
requests.
That
would
mark
it
out
there,
and
this
is
similar
to
that.
E
And
then
you
had
tools
that
came
along
like
our
killian,
that
managed
to
run
unit
tests
within
various
environments,
including
kubernetes.
So
you
could
run
against
live
services,
so
within
our
environment
within
istio
microservices,
there
are
a
number
of
options
as
well,
so
that
you
have
the
approach
that
you
have
documented
here
at
the
demo
here
should,
I
say,
there's
also
some
stuff
that
we
work
on
ourselves
and
we've
demoed
in
the
community,
which
tries
to
address
some
of
the
shortfalls
that
you
pulled
out
in
the
initial
deck.
E
E
So
squash
allows
you
to
attach
remote
debugging
sessions
to
a
service
that
is
running
in
the
cloud
somewhere
in
a
kubernetes
environment
somewhere,
so
you're
actually
debugging
something
live
there
and
telebrescence
allows
you
to
proxy
requests
down
to
a
local
running
service.
So,
like
you're
doing
here,
you
can
run
your
service
locally,
but
you're
actually
getting
live
traffic
from
the
cloud
redirected
into
your
service.
So
there
are
a
number
of
different
ways
that
are
possible
for
debugging
microservices
within
the
cloud
and
each
of
them
has
their
advantages
and
disadvantages.
E
E
F
One
thing
I
really
like
at
solution:
if
you
guys
is
I
I
we
don't
see
much
solution
for
developers
around
the
east
here.
Most
of
the
technologies
is
around
infrastructure.
People
talk
a
lot
about
networking,
which
is
some
developers
not
really
familiar
with
the
whole
networking
backgrounds,
and
when
you
bring
that
in
the
easy
way,
that's
that's
really
a
must
so
good
working
there.
F
A
A
A
A
A
A
Yeah,
I
I
think
you're
right,
I
mean
that's
why
I
am.
I
haven't
gotten
a
time
to
look
through
open
service
mesh
in
detail
yet,
but
I
mean
you
know
I,
so
I
don't
know
if
there's
any
particular,
you
know
new
novel
innovations
in
there,
but
certainly
I
mean
they
learned
a
lot
from
from
istio,
obviously,
and
what
they
did.
We
might
learn
something
from
what
they.
A
A
Same
thing
same
thing,
you
know
it's
it
I
mean
it
does
seem
to
have
the
only
thing
I
got
a
chance
to
look
at.
Is
that
there's
a
handful
of
you
know.
It
looks
like
there's,
you
know
two
or
three
main
contributors
from
microsoft
to
the
product
and
they
seem
to
have
done
the
bulk
of
it
and
then
there's
a
long
tail
of
about,
like
I
think
I
counted
like
seven
additional
or
seven
total
developers
and
the
tail
had
contributed
like
one
or
two
commits.