►
From YouTube: Panel: Ask Me Anything About Service Mesh
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Panel: Ask Me Anything About Service Mesh - Lin Sun & Daniel Berg IBM; Christian Posta, Solo.io; Oliver Gould, Buoyant; & Sven Mawson, Google
As part of the cloud native journey, users are leveraging service mesh to solve the rising challenges of microservices in a consistent manner such as how to observe microservices, how to handle network failures, how to control traffic and how to secure microservices etc. without redeploying their services. Join us for a live interactive session where our panel of service mesh experts will address your most challenging inquiries around service mesh!
https://sched.co/ZejT
A
A
D
Yep,
hopefully
you
can
hear
me
it's
it's
good
to
see
you.
My
name
is
christian
posta,
I'm
a
field
cto
at
a
company
called
solo.io,
where
we
focus
on
helping
customers
use
service
mesh
in
production
and
kind
of
meet
them
where
they
are
figure
out
what
their
challenges
are
and
help
them
to
be
successful,
and
we
have
a
few
products
that
we've
built
to
to
help.
Do
that
and
I've
been
involved
in
building
distributed
systems
and
an
open
source
for
for
quite
a
long
time.
E
A
That's
awesome.
Thank
you.
Everyone,
let's
go
ahead
and
start
with
some
of
our
questions,
so
we
have
a
few
initial
seating
questions
we're
going
to
go
through
those
first
in
the
meanwhile
for
all
the
audience,
please
go
ahead
and
type
your
questions
and
I
will
prioritize
them
after
we've
gone
through
our
initial
questions
and
read
out
for
our
panelists
to
answer
them.
A
C
C
So
you
have
to
build,
you
know
routing
and
observability
and
security,
and
all
these
other
pieces
in
with
code,
and
that
was
kind
of
the
historical
view
and
what
service
meshes
do.
Is
they
come
in
and
provide
that
as
an
infrastructure
layer?
So
you
get
all
those
capabilities
without
having
to
make
changes
to
those
applications,
and
then
you
can
sort
of
decouple
that
operations
from
that
development
and
you
can
push
changes
rapidly.
B
D
D
D
A
B
Yeah,
I
was
just
going
to
add:
all
these
points
are
absolutely
correct.
The
one
one
thing
I
was
going
to
add,
which
is
similar
to
what
christian
was
saying,
is
that
a
mesh
is
really
the
ability
to
programmatically,
define
your
policies
and
rules
at
the
networking
level,
and
I
think
that's
a
key
aspect
here
is
that
you
can
actually
start
programming
these
rules,
as
opposed
to
coding,
codifying
them
directly
into
your
application.
E
And
I'll
just
add
a
little
twist
on
all
these,
which
I
mean
all
these
are
right,
but
I
view
service
mesh
as
really
a
pattern
right
and
it's
a
pattern
for
extracting
a
bunch
of
the
kind
of
connectivity
and
communication
reliability,
logic
out
of
the
application,
and
you
can
have
service
meshes
that
are
really
good
security
or
service
meshes
that
are
really
good,
observability
or
policy.
But
really
what
we're
talking
about
is
the
pattern
of
having
sidecar
proxies
or
rich
data
planes
that
are.
A
E
D
Like
some
service
meshes
have
a
lot
that
it
can
do
so
that
creates
some
complexity,
but
that
also
creates
a
you
know:
a
people
problem
how
what
or
what
part
of
the
organizations
which
already
have
these
silos
need
to
be
involved,
and
if
it's
all
of
them,
then
that
that
makes
things
a
lot
a
lot
more
difficult,
so
that
that's
that's
a
big.
That
is
a
big
challenge.
D
Another
one
is
that
the
idea
that
the
surface
mesh
is
just
transparent
and
you
just
put
it
in
your
applications
and
and
it
just
works,
but
what
again?
What
we've
seen
is
these
applications
aren't
exactly
cloud
friendly
and
they
don't
you
know
they're
there.
There
are
gotchas
and
there's
not
there's
not
the
transparency
that
they
expect,
and
so
there's
there's
some
hurdles
in
in
adopting
it
in
an
existing
organization.
C
I'll
add
one
thing:
one
challenge
we've
actually
seen
in
a
lot
of
companies
is
actually
that
they
have
a
lot
of
this
stuff
in
a
rudimentary
form
in
their
own
home
brewed
way.
So
a
lot
of
companies
have
something
like
a
service
mesh.
Maybe
it's
through
libraries.
Maybe
it's
through
some
proxies.
You
know.
Maybe
it's
a
combination,
and
I
think
one
of
the
big
challenges
is
migrating
from
that
state
of
your
own
custom
stuff.
That
kind
of
does
something
well
and
something
specific
to
your
your
organization,
but
not
everything
and
migrating
to.
D
C
A
A
B
B
E
I
have
another
opinion
on
that,
so
I
I
think
anyone
needs
a
service
mesh
who
has
pod
to
pod
communication
they
care
about,
and
that
is
you
know
it's
production
traffic
between
instances
running
your
kubernetes
cluster.
I
I
definitely
agree
that
you
should
be
really
aware
of
what
value
you're
getting
into
that,
but
I
think
things
like
mtls
and
load
balancing
are
kind.
E
C
And
I
I
want
to
really
quickly
generalize
that
a
little
bit
more.
I
think
it's
not
just
for
pods
right
any
anytime.
You
have
lots
of
different
services
talking
to
each
other,
whether
they're,
kubernetes,
pods
or
vms,
or
you
know
mobile,
apps
or
iot
right
like
that's,
where
service
meshes
can
be
useful,
and
you
know
we
don't
all
solve
all
those
use
cases
yet,
but
actually
it
really
is
when
you
have
that
sort
of
lots
of
things
communicating
with
each
other,
and
I
really
like
what
dan
said.
C
I
think
we
want
to
make
sure
people
don't
think
if
you,
if
you
don't
think
you
need
a
service
mesh,
you
don't
need
one.
It's
really.
If
you
have
the
problems
service
mesh
is
trying
to
solve.
You
need
one
right.
So
it's
look
at
the
look
at
the
problems
problem
space
and
if
there
are
things
that
you
know,
service
measures
are
solving
that
observability
security
and
and
traffic
routing
and
rollout
and
all
those
other
problems.
If.
D
A
Okay,
great,
let's
go
through
our
questions.
I
actually
saw
a
lot
of
questions
coming
in
so
bell
with
us
if,
before
we
get
to
your
channel,
also
some
of
you
are
asking
what
select
channels
we're
using
we're
going
to
announce
that
at
the
end,
just
because
we
want
all
the
questions
come
through
this
platform
for
now
and
then
at
the
end,
we're
going
to
take
questions
on
slack.
A
D
This
is
definitely
an
area
of
our
expertise
at
solo
because,
like
I
said
we
we
we
meet
people
where
they
are
right
and
some
people
are
able
to
adopt
service
mesh
today
and
some
people
are
not,
and
the
api
gateway
pattern
is
something
that
is
familiar
with
folks
and
as
they
start
to
modernize
they.
You
know
they
want
technology
that
fits
better
with
the
get
ops
model,
that's
declarative,
that's
very
flexible
and
extensible
and
so
forth.
D
So
an
api
gateway
in
general
is
going
to
be
different
than
a
service
mesh,
and
then
it
solves
those
those
application
problems.
You
know
getting
access
to
applications
and
apis
at
the
edge
of
your
boundary,
and
so
we've
seen
people
deploy,
for
example,
our
our
api
gateway,
that's
built
on
envoy
glue
at
the
edge
of
multiple
clusters
and
then
federate
them
right,
but
we've
also
seen
this
seems
to
be
a
more
prevailing
pattern.
D
Now
that
folks
are
going
to
put
they
put
glue
or
put
their
api
gateways
into
centralized
clusters
and
then
route
those
to
the
leaf
clusters,
which
would
have
the
the
service
mesh
and
then
maybe
using
something
like
a
simpler
ingress.
On
on
those
clusters,
so
we've
seen
both
folks
who
have
an
aversion
to
centralization,
are
going
the
federated
model.
Folks,
who
already
have
their
processes-
and
you
know
their
familiarity
with
the
centralized
model-
are
going
down
that
path.
So
it's
just
there's
not
a
right
or
wrong
answer
for
them.
C
A
E
Yeah,
you
should
use
linkedin
easy.
No,
I
mean,
I
think
you
know
I,
how
do
you
choose
any
software
right?
You
you
look
at
the
the
community,
that's
around
it
and
you
look
at
the
kind
of
use
cases
that
are
that
it
excels
at
linkery.
Are
our
goals
to
you
know,
make
it
easy
to
install
and
get
out
of
your
way?
So
I
don't
think
people
should
want
a
service
mesh
should
be
able
to
install
linkery,
get
mtls,
get
load,
balancing,
get
visibility
and
then
move
on
with
your
life.
E
B
Yeah
I
mean
I,
I
definitely
agree
with
you.
It's
like
any
any
software.
I
mean
once
you've
done
your
initial
investigation
and
narrowed
the
field
down
to
let's
say
three
options:
you're
gonna
have
to
take
them
for
a
test
drive
right,
put
them
through
the
paces
test.
Your
use
cases
test
to
make
sure
that
it
fits
your
operations
and
development
style.
At
the
end
of
the
day
you
have
to
evaluate-
and
you
have
to
be
comfortable
with
the
technology.
It's
I
mean.
B
C
C
I
add
that,
just
to
add
one
little
extra
piece,
I
would
definitely
agree
with
actually
everything
dan
oliver
said.
I
piece
out
of
that
is
that
I
would
recommend
looking
at
service
meshes
that
have
actual
production
users-
and
you
know
maybe
favor
favor,
using
ones
that
have
a
community
around
them,
have
production
users
and
have
sort
of
a
track
record
of
actually
being
deployed
in
production
and
used
at
scale.
Because,
as
we've
discovered,
you
know
it's,
it's
really
easy
to
launch
something
that
that
sort
of
ticks
all
the
boxes.
C
Right
like
we
launched
istio,
you
know
0.1,
I
don't
remember
how
many
years
ago
and
it
had
basically
all
the
functionality
issue
has
today
and
the
inner
reading
years
has
been
spent,
making
it
scale,
making
a
production
ready
and
making
it
actually
able
to
meet
customer
needs
at
scale
in
production
in
real
usage,
and
I
think
you
know
people
underestimate
how
difficult
that
is
and
how
much
time
is
spent
on
making
something
production
ready
rather
than
just
yeah.
It
does
all
the
features
that
you
need.
So,
yes,
try
it
out.
Use.
D
D
But
from
the
outset
I
mean
there's
a
new
service
mesh
released
every
week
right
and
you
you
can
see
it's
like
like
spent
said
through
through
istio
and
even
look
at
aws
app
mesh.
You
know
they
announced
almost
two
years
ago,
but
they're.
You
know
my
opinion
is
they're.
Just
now
becoming
ready
to
be
used.
D
You
know
and
same
thing
with
the
with
the
linker
d:
it's
been
around,
they
learned
a
lot:
they
they
pivoted,
they
got.
You
know
linker
d2
and
you
know
probably
a
lot
of
people
running
in
in
production
that
those
are
real
service,
meshes
that
usually
bubble
to
the
top
of
an
evaluation
criteria
that
we've
seen.
A
A
C
C
So
right
now
it's
it's
doable
you.
If
you
have
tons
of
services,
you
should
write
a
controller
that
is,
is
basically
copying
those
everywhere
and
configuring
them,
because
astute
doesn't
do
that
out
of
the
box
today.
But
once
that
done,
that
is
done,
it
does
scale
and
does
handle
the
traffic,
but
we.
D
Are
don't
write?
Your
own
controllers?
Don't
write
your
own
controller.
Well
as
we
we
have
a.
We
have
a
project
so
called
service
mesh
hub.
That
does
exactly
that
for
you
and
does
other
things
in
terms
of
federation.
So
there's
there's
an
admiral
from
the
intuit
folks.
So
there's
there's
some
there's
some
things
to
look
at
for
that.
Yeah.
A
A
A
B
B
D
D
D
Okay,
yeah,
I
know
all
I
was
saying
is
I
agree
with
that.
The
business
logic
thing
is
just
that's
going
to
be
a
slippery
slope.
I
mean
this
is
the
same
thing
that
happened
with
the
enterprise
service
bus
technologies
over
15
20
years
right,
the
the
the
the
challenge
will
be.
You
know
when
you
need
to
make
a
change
to
some
functionality.
D
D
C
And
I
think
the
one
thing
not
to
do
with
service
measures
to
rely
on
it
as
a
you
know,
as
an
answer
to
all
your
problems
right,
you
still
need
a
good
distributed
systems
architecture.
You
still
need
to
think
about
how
your
systems
are
laid
out
and
how
they're
communicating
right,
don't
expect
it
to
solve
all
those
problems
for
you
right,
it's
just
it's
just
that
common
layer.
It's
not
it's
not
solving
your
business
problems.
A
Yeah,
I
think
these
are
really
good
answers.
Let's
moving,
we
got
a
question
51
from
herland
how
about
resources,
overhead
of
istio
and
link
d,
especially
memory
when
you
have
a
big
cluster,
more
than
100
nodes
and
springboard
microservices.
Well,
the
memory
is
about
450
megabytes
per
each
of
the
micro
services.
D
A
C
C
Big
clapper
is
5000
nodes,
10
000
nodes,
sorry,
those
are
big
clusters.
100
nodes
is
small.
If
you're
having
problems
with
your
current
system
at
100
nodes,
then
yeah
you
need
to
you
need
to
switch
to
something
that
can
scale.
That
goes
to
my
point
about
you
know
things
that
can
can
scale.
You
know
that
that
have
been
tested
at
large
sizes
and
the
the
memory
usage.
So
I
can.
I
can
talk
about
istio.
C
E
E
Yeah
the
benchmarks
I've
seen
last
the
linkedin
proxy
was
running
between
20
and
30
megs
per
sidecar
and
envoy,
I
think,
is
probably
100-ish
in
the
similar
use
case.
So
there
there
are.
I
mean
those
are
the
benchmarks.
I've
seen
so
run
your
own
for
your
application.
Please,
but
we've
tried
to
make
our
proxy
really
lightweight
and
small,
but
that's
just
a
one
data
point.
B
Yeah
and
people
do
need
to
realize-
I
mean,
even
even
with
the
small
proxies-
and
I
believe,
linker
d
and
sdo
both
have
fairly
small
proxies.
It's
the
number
of
pods
you
have
in
your
system.
I
don't
care
how
many
nodes
you
have,
how
many
pods
do
you
have
running
that
are
part
of
that
mesh,
because
at
the
end
of
the
day
it's
it
does
add
up.
I
mean
it
will
have
an
impact
at
some
level
you're
getting.
B
B
I
guess
I
talked
too
fast.
I
was
just
gonna
say
it's
really
dependent
upon
the
number
of
pods
that
you
have
at
the
end
of
the
day,
because
even
with
a
small
incremental
at
addition
to
the
performance,
the
memory,
it
adds
up
over
time,
so
you
do
have
to
account
for
it,
even
though
it
is
still
very
nominal.
A
D
D
Absolutely
absolutely,
but
the
point
that
I
always
make
is
you:
can
you
if
you're
gonna
run
these
large
distributed
systems
in
cloud
infrastructure,
for
example
kubernetes?
You
have
to
solve
these.
These
problems
around
resilience
around
security,
around
observability
and
so
forth.
So
it's
not
optional.
Really,
you're
gonna
have
to
pick
one
pick,
the
one
that
best
suits
the
resource.
You
know,
constraints
that
you
have
and
putting
it
in
the
application
may
not
be
the
the
best
choice
it
might,
but
it
might
not.
A
D
A
E
Measures
can
reduce
latency
by
load,
balancing
load,
balancing
is
a
great
tool
and
it
can
be
very
difficult
to
wire
this
in
your
application
directly.
Although
the
grpc
world
is
definitely
growing
these
things
internally,
but
you
know
if
you're
talking
to
many
pods
or
you
say
you
have
10
to
100
pods
you're
talking
to
choosing
the
least
loaded.
One
is
absolutely
going
to
impact
latency
in
a
busy
system,
so
great
great
tool
to
use
service
mesh
for.
D
Choosing
the
least
loaded
one
choosing
the
one
that
might
be
closer
to
you
in
terms
of
locality.
You
know
trying
to
respond
to
a
client
when
a
request
to
one
of
the
upstreams
isn't
returning
and
then
you
might
need
to
send
out.
You
know
a
a
second
request,
so
the
the
the
mesh
definitely
does
a
lot
of
kind
of
application.
Networking
under
the
covers
for
you
that
can
definitely
increase
improve
your
latency
numbers.
B
The
the
interesting
thing
about
the
points
that
you
guys
just
raised,
I
was
scanning
through
some
of
the
questions,
and
one
of
the
questions
was:
what's
what's
one
of
the
gaps
that
a
service
mesh
provides
over
and
above
kubernetes
itself
and
and
the
one
of
the
number
one
things
for
me-
is
the
load
balancing
anyone.
That's
used
coup
proxy
realizes
that
coup
proxy
is
not
really
a
load
balancer
at
all.
E
B
D
B
C
Real
quick,
add
two
other
ways
that
two
other
ways
that
actually
they
reduce
latency,
that
we've
seen
with
production
users.
So
one
is
that
actually,
the
the
proxy
implementations
of
these
systems
are
often
better
than
the
native
language.
If
you
know
you're,
not
using
c
plus
natively,
and
so
we've
actually
seen
immediately
in
c
increases
just
by
having
a
better
implementation
of
like
http,
2
or
being
able
to
upgrade
to
http
2,
so
that
the
tunneling
sometimes
actually
can
increase
improve
latency.
The
other
way
is
actually
they
will
help.
C
A
A
Okay,
I
think,
unfortunately,
we're
running
out
of
the
time.
I
want
to
take
a
minute
to
thank
all
the
panelists
for
answer.
Questions
today
really
appreciate
it
also
keep
in
mind.
We
do
have
two
dash
kubecon
service
mesh,
where
you
guys
can
you
know
answer
keep
asking
us
questions
for
the
next
15
minutes
we
will
be
around.
I
have
to
apologize.
There
are
just
about
100
questions
coming
in
and
we're
gonna
answer
most
of
them,
so
we
will
take
the
conversation
over
to
slack
on
the
kubecon
server
smash
channel
thanks.
Everyone.