►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Panel: Is Service Mesh Ready for Edge-Native Applications? - Wendy Cartee, Ramki Krishnan, VMware; Srini Addepalli, Intel; Parveen Patel, Google; & Ravi Chunduru, Verizon
Edge deployments, in contrast to large public clouds, pose interesting demands since they are physically insecure & capacity constrained. Also, Edge Computing Apps such as AR-VR, have low-latency characteristics with RTT typically few msec and pose further demands to edge deployments. Edge Computing Apps like to use Service Meshes (SM) such as Istio/Envoy, Linkerd etc. to offload infrastructure related activities such as security. In this panel, we first examine the unique challenges in using SM technologies for Edge Computing Apps - especially the additional latency and resource usage to due to Kernel Networking. Next, we will explore software techniques such as Kernel Bypass, QUIC as an alternative to TCP/IP etc. to alleviate the performance bottlenecks introduced by SM technologies including early results. Last, we will touch upon hardware acceleration techniques for the above.
https://sched.co/UaZu
A
Okay,
so
we're
going
to
go
ahead
and
get
started.
I
want
to
welcome
everyone
thanks
for
coming
to
our
panel
at
4:25
today.
So
I
really
appreciate.
All
of
you
guys
being
here.
We
have
a
great
panel
lined
up
for
you
and
we're
going
to
address
is
service
smash,
ready
for
edge
native
applications.
Today
my
name
is
Wendy
Carty
I'm
with
the
VMware
service
mesh
team.
So
we're
going
to
go
ahead
and
get
started
and
half
the
panelists
introduce
themselves
Randi.
You
want
to
go
first.
B
From
VMware
I
lead
our
open
source
initiatives
on
edge
and
cloud
native,
specifically
focusing
on
the
convergence
of
telco
and
enterprise
applications
and
I'm
deeply
passionate
about
geo
distributed
applications.
People
always
think
about
edge
computing
as
just
edge,
but
it's
really
actually
do
distributed
computing.
C
C
Speaking
of
edge,
you
know
today,
Google
announced
the
launch
of
stadia.
So
that's
like
for
those
of
you
who
don't
know
stadia
it's
you
know
you.
Don't
you
no
longer
need
a
console
to
play
a
high-definition
high-performance
video
game.
All
you
need
is
a
controller,
and
you
know
the
game
runs
in
the
cloud
and
streams
to
your
device.
Just
like
YouTube-
and
you
know
it's
one
of
the
most
intense
applications.
It's
real-time,
its
interactive.
It
needs
high
throughput.
You
know
everything
be
networking,
guys,
love,
hi,.
D
My
name
is
Ravi
nuru
I'm
associate
fellow
at
the
res
on
network
systems,
so
I
come
from
a
group
called
G&T
global
network
and
technology.
So
my
group
essentially
does
the
provisioning
of
all
virtual
network
services
for
enterprise
customers
as
well.
I
believe
you
know,
customers
deployments
the
enterprise.
H
is
the
low-hanging
fruit
to
run
customers
own
applications.
So
we're
going
to
see
a
trend
of
you
know,
running
kubernetes
at
the
enterprise
premises
soon
enough.
E
Hi,
my
name
is
rainy
nepali,
I'm
a
senior
principal
engineer
in
Intel
I
did
edge
architecture
and
also
whoa
nap.
You
know.
Central
Orchestrator
teams
in
in
Intel
I
also
represent
one
app
TAC,
as
well
as
a
cry,
no
TAC
from
firm
Intel
and
also
we
started
a
new
project
in
acronym
called
ICN
I
integrated
cloud
native
blueprint,
which
is
supposed
to
is
a
stack
that
intends
to
run
both
CNF
Svea
naps
and
applications
as
containers.
Please
check
out.
Thank
you.
Okay,.
A
Great
Thank
You
panelist,
so
we're
going
to
go
ahead
and
kick
it
off
with
just
a
couple
of
slides
to
kind
of
set
the
framework
for
what
we're
going
to
talk
about
today.
As
most
of
you
know,
edge
applications
are
increasingly
moving
from
a
centralized
model
to
a
distributed
model,
and
this
is
primarily
to
be
closer
to
the
end
users
to
deliver
better
response
times
and
better
overall
experience,
and
there
are
really
four
key
drivers
for
this
shift.
A
So
these
drivers
are,
you
know
really
then
leading
into
you
know.
What
is
service
mesh
industry
distributed
edge
world?
And
you
know
what
are
the
use
cases?
What
are
the
challenges
of
the
scenario
and
we're
going
to
jump
right
to
the
panel
to
discuss
these
challenges,
use
cases
and
potential
solutions
as
well,
so
I'm
going
to
kick
it
off
with
by
asking
Ravi
the
first
question
being
a
service
provider?
Maybe
you
could
keep
this
off
by
explaining
what
is
exactly
edge
native
applications
and
what
are
some
common
use
cases
that
you're
singing
so.
D
I
believe
edge
computing
is
relevant
to
all
the
domains
where
you
want
to
improve
the
user
experience.
Let's
take
an
example,
so
in
a
typical
healthcare
facility,
a
patient
who
is
in
need
of
a
surgery
walks
into
the
facility,
he
is
undergoing
a
memory
scanner
and
if
the
Ameri
scanner
is
able
to
assist
the
operator
in
positioning
the
body,
so
only
few
stands
can
be
done.
That's
a
huge
experience
for
the
patient,
and
now
these
images
scanned
images
land
up
on
Amara
application.
D
That
does
superimpose
of
this
images
and
prepare
a
3d
model,
and
that
really
model.
If
it
is
given
to
surgeons-
and
they
can
collaborate
together
or
take
recommendations
from
analytics
engine
and
come
with
a
precise
procedure
of
surgery,
then
that
is
improvising.
The
doctors
experience
now
we
are
dealing
with
multiple
applications.
In
this
use
case
we
have
applications
such
as
a
your
more
VR
applications,
and
we
have
health
suite
application.
We
have
insurance
application.
You
know
persistent
storage
for
the
images,
so
there
are
multiple
applications
coming
together
to
perform
a
task
for
us.
D
So
in
this
example,
you
you
will
find
that
some
applications
are
running
on
the
premises.
The
M,
our
application,
is
running
on
the
Health
Care's
premise:
you
have
insurance
application
running
as
a
cloud
service.
You
have
some
applications
like
deep,
analytics
and
recommendations
engine
running
in
cloud
and
data
centers.
So
we
are
talking
about
a
very
distributed
nature
of
applications
here,
all
of
them
coming
together
as
a
serviced
mesh
and
performing
the
needed
tasks.
So
the
there
are
multiple
other
use
cases
and
two
in
this.
D
E
I
just
want
to
add,
you
know
the
it
is
actually
as
ready
mentioned
right.
It
is
increasing
the
user
experience
right
and
you
could
reach
large
number
of
geographical
locations
or
population
with
your
applications.
So
what
it
really
means
is
that
even
your
enterprise
applications
that
are
today
they're
big,
they
can
be
a
candidates
for
edge
chopped
legations.
Because
of
two
reasons,
as
Linda
mentioned,
one
is
that
proximity
to
the
user
to
increase
the
developer,
six
become
your
six
user
experience
and
second
one
is
the
data
sovereignty
right.
E
C
We
treat
edge,
as
you
know,
three
different
things.
You
know
one
is
on
net
edge,
so
that's
the
devices
that
live
at
the
edge
of
our
network.
So,
like
Styria
appliances,
they
live
at
the
edge
of
Google's
network.
Then
there
is
the
off
net
edge,
so
like
YouTube
cash
lives
in
ISPs,
that's
another
edge
and
then
there
is
on-premise
edge
that
lives
on
customer
premises.
So
all
of
those
are
edges
for
us
and
they
each
have
kind
of
different
requirements
in
different
scenarios
and.
B
So
tying
in
the
telco
view
and
then
the
enterprise
view
together,
we
can
really
classify
different
types
of
edges,
varying
from
micro
edges
and
restaurants,
to
sort
of
next
smaller
edges,
for
example,
in
retail
stores,
we're
actually
both
telcos
and
enterprises
are
converging
telcos
from
Estevan
perspective
and
enterprises
from
actually
you
know
improving
user
experience
right,
so
we're
telcos
could
be
managed.
Service
providers,
helping
enterprise
or
enterprise
could
be
managing
their
edge
stem
cells
or
the
next
interesting
category
is
more
of
medium
or
small,
medium
or
large.
B
Your
choice,
for
example,
you
know
stadiums,
you
know
or
hospitals
where
essentially,
the
goal
is
to
really
improve
the
quality
of
experience,
so
this
is
actually
very
key
to
determining
how
your
applications
are
going
to
be
distributed,
what
type
of
applications
you're
dealing
with
and
also
other
infrastructure
constraints,
such
as
security,
or
you
know,
the
resource
constraints.
So
basically,
there
types
of
edges
matter
a
lot
so.
E
Yeah
I
I
would
say
that
predominantly
there
are
few
challenges
right.
One
is
that
many
it
just
unlike
cloud
they're
resource
constrained,
you
know
we
are
talking
about
one
single
one,
single
server
node,
sometimes
in
edge
locations,
so
any
any
service
mesh
technology
which
we
are
thinking
should
work
in
constrained
environments
like
edges.
Right,
second,
is
that
HS
are
physically
insecure
right.
You
don't
have
security
guard
manning
the
edge
locations.
So
now,
if
I
talk,
you
put
service
mesh,
there
are
a
lot
of
key
material
there
that
need
to
be
secured
right.
E
That
is
second
thing,
and
the
third
thing
is
that
it
just
do
not
have
many
times
your
static
public
IP
addresses
so
any
distributed
application
which
we
are
talking
about.
Wait.
Some
micro
services
are
part
of
one
edge.
Other
part
of
application
micro
service
are
in
some
other
edge
and
when
they
don't
have
is
a
public
IP,
a
static
public
IP
addresses
cannot
communicate
with
each
other.
So
you
have
to
consider
in
my
mind
you
know
these
three
characteristics
in
figuring
out.
What
kind
of
challenges
are?
What
kind
of
solutions
you
require
or
enhancements?
D
D
Most
of
the
resources
are
consumed
by
our
wound
of
functions
like
SD
van
you
know,
firewall
or
van
optimation
type
of
functions,
and
we
leave
some
space
for
applications
to
run
and
the
growing
demand
of
a
lot
many
applications
to
run
on
the
customer
premises
at
the
enterprise
edge.
If
we
are
looking
towards
you
know,
taking
advantage
of
the
clone
a
to
tools
like
service
mesh,
if
they
themselves
take
too
much
of
resources,
then
would
be
net
tight
position.
D
So
we
really
like
you,
know
the
service
mesh
or
any
sense,
if
tools
to
be
really
as
more
as
lean
as
possible
and
take
advantage
of
the
hardware
that
is
there.
For
example,
you
know
hardware
acceleration
smart
make
GPUs
if
they
can
take
advantage
of
that,
and
if
the
application
can
only
focus
on
the
code,
logic
and
any
network
and
infrastructure,
religious
related
issues
are
offloaded
to
our
serviced
mesh
type
of
tools.
D
Then
it's
a
it's
a
better
way
of
utilizing
the
resources
at
the
enterprise
locations-
and
the
second
point
I
would
concur-
is
on
the
security
aspects
from
a
service
product
standpoint.
We
have
this
edges
deployed
remotely
at
numerous
locations.
It
will
be
good
enough
if
there,
if
the
security
is
taken
care
from
clone
a
to
standpoint,
that
is
another
value
proposition.
B
B
You
were
only
go
to
the
mobile
network
functions.
It
is
SP
gateway
right.
All
of
these
design
patterns
have
come,
I
mean
thought-out,
completely
separate
from
applications.
I
mean
there
are,
of
course,
a
few
unique
aspects
such
as
you
know,
multiple
network
interfaces
for
isolation,
but
the
problem
is
they're
considered
so
separate
that
the
whole
deployment
and
management
is
a
big
nightmare.
You
have
imagine
you
have
a
edge
with
just
three
to
five
servers
and
you
want
to
deploy
these
network
functions
and
then
also
application
of
constraint
environment
because
of
lack
of
a
converged
approach.
B
C
So
I'd
like
to
add
that
one
constraint
we
have
in
each
location
is
that
in
data
centers
were
used
to
doing
custom
hardware
to
accelerate
software,
especially
networking.
Well,
when
you
go
to
the
edge
you
know,
our
supply
chain
doesn't
always
extend
all
the
way
to
customer
edges,
so
you
have
to
deal
with
off-the-shelf
hardware
and
there's
not
always
standard
interfaces
through
which
we
can
use.
You
know
these
acceleration
that's
available
at
these
edges.
So
that's
another
constraint.
C
A
Edge,
usually,
are
very
lean,
our
compute
storage
bandwidth
right.
You
want
to
minimize
the
footprint
that
you
know.
You
concern
these
types
of
resources
and
Robbie.
You
mentioned
technologies
like
smart
Nix,
GPU,
for
example,
for
example,
can
help
us
celebrate
performance.
What
are
some
of
the
other
techniques?
Maybe
in
the
user
or
kernel
space
in
the
operating
system
that
can
be
leveraged
to
optimize
performance
as
well.
D
There
are
multiple
in
advancements
happening
in
the
kernel
to
speed
up
the
you
know
the
service
mesh
capabilities
in
stuff.
You
know
you
know
going
through
a
loopback
driver
and
if
we
can
take
advantage
of
you
know
several
less
proxies
or
you
know,
passing
the
packets
right
at
the
socket
layer,
then
going
all
the
way
down
below
to
the
tcp/ip
stack
that
would
be
of
greater
advantage,
I
see
and
we're
also
working
with
trainee
in
the
chrono
project,
where
we
are
coming
up
with
multiple
other
techniques,
which
you
can
add.
E
Why
can't
we
just
bypass
tcp/ip
stack
at
least
the
communication
between
on
y
2
and
y
within
a
node,
so
that
is
one
thing
which
we
are
looking
at.
How
do
we
speed
up?
You
know
and
again
our
the
main
intention
is
that
you
know
today.
The
the
belief
is
that
this
a
you
know,
sidecars
or
proxy
page
to
service
missions.
They
occupy
almost
50
percent
of
the
resources
and
only
50
for
the
resources
are
available
for
application
containers.
E
So
the
purpose
is
that
we
should
make
90%
of
the
course
for
applications
or
resources
and
ten
percent,
maybe
for
site.
So
that's
where
we
are
looking
at.
What
are
the
techniques
that
we
can
optimize
surface
mesh
technologies?
Of
course
tomorrow,
when
the
smart
picks
become
popular,
you
know
the
entire
community
is
networking,
including
service
mesh
or
unwise
can
be
offered
to
smartly,
possibly
that
that
could
be
another,
a
longer-term
item,
but
the
shorter
term.
C
Instead
of
doing
a
sidecar
per
pod,
you
could
do
a
multi-tenant
sidecar,
which
could
be
shared
by
you
know
all
the
containers
on
the
same
node,
but
then
the
challenges
you
have
to
provide
sufficient
isolation
between
different
customer
workloads.
But
if
you
can't
do
that,
then
maybe
you
don't
need
50%
resources
for
service
mesh.
B
Exactly
so,
I
think
the
edge
with
the
several
constraints,
security
resources,
it's
opening
up,
I,
would
say
new
design
patterns.
Certainly
just
add
to
that
point,
which
perving
said
a
new,
a
new
design
pattern
we
could
think
about,
as
essentially
in
this
example
just
coding
this
example,
you
have
several
micro
services
right,
for
example,
decoder,
encoder
even
distribute
you
could
consider,
though
one
is
like
view
them
as
separate
micro
services,
other
ways
to
think
about
them
as
containers
in
the
same
micro
service.
You
could
think
about
it
that
way,
because
you
could
say
hey.
B
These
are
all
mostly
co-developed
and
then
code
tested
it's
not
going
to
you're
not
going
to
have
possibly
independent
upgrade
cycles
for
each
one
of
them,
and
with
that
assumption,
what
is
totally
possible?
Is
you
could
package
them
together
right
and
then
naturally,
then
all
of
them
will
get
scheduled
in
a
single
node
through
an
external
load
balancer
you
just
direct
you
a
one
of
those,
my
Amin
instances
of
this
micro
services.
So
basically
that's
way
all
the
communications
between
these
macro
services
are
happening
in
a
single
node.
B
You
can
start
with
the
next
Colonel,
but
you
have
the
opportunity
of
also
going
user
space
communication
right,
which
definitely
brings
at
least
one
distinct
advantage
in
minimizing
the
kernel
context.
Switching-
and
we
have
seen
this
over
and
over
again
think.
Basically,
the
kernel
going
through
Linux
kernel.
The
biggest
problem
is
controlling
the
context,
switching
where,
as
user
space,
you
can
really
it's
much
more
fine
grained
control
and
when
you
go
to
use
a
space.
What
is
also
interesting
is
hardware
vendors
until
arm
everybody's
coming
up
innovations
on
just
the
communication
mechanism.
B
It's
all
happening
in
a
user
space,
not
in
the
kernel,
because
the
kernel
is
ideal
and
it's
got
so
many
challenges.
So
there
are
so
many
interesting
design
patterns
emerging
and
there
is
no
one
solution
fit
all
right.
I
mean
you
have
to
look
at
start
from
the
top
look
at
the
application.
Look
at
you
know
other
the
types
of
pages,
that's
very
key
characterized
to
edge
and
then
think
about
this
holistically
and
make
the
right
choice.
So.
A
So
far,
I
heard
Hardware
optimization
techniques.
Some
software
techniques,
especially
you
mentioned
proxy
lists
server
smash.
So
there
are
many
service,
much
technologies
out
there
that
are
based
on
proxy
psych.
Our
model
and
Proximus
models
are
coming
up
to
four
edge.
Specifically
I
mean
what
are
the
pros
and
cons
of
deploying
a
proxy
versus
a
proxy
less
model
other
than
you
know,
resource
consumption,
yeah.
E
One
thing
is
that
you
know
proxy
base
to
create
h2o
on
why
that
combination
is
the
proxy
base
to
service
mesh
right?
Essentially,
it
not
only
uses
lots
of
resources,
but
also
it
introduces
lot
of
latency
in
in
the
edges.
Typically,
the
intention
to
move
the
applications
to
the
edges
is
to
have
low
latency
kind
of
paradigm
right,
so
it
is
like.
So
how
do
we
basically
figure
out-
and
the
other
thing
other
pattern
is
that
the
most
of
the
proxy
based
service
machines
are
meant
for
higher
level
up.
E
You
know
protocols
like
TCP,
UDP,
G,
RPC
kind
of
things,
but
in
HS
and
I
were
T
kind
of
environments.
You
have
non-http
Longy
RPC
paste
applications
right,
so
the
thought
process
is
that
which
you
know
for
those
kinds
of
applications
and
applicants
that
require
low
latency.
You
need
proxy,
less
service
meshes
right.
So
that's
one
of
the
thought
process
we
have
in
creating
service
mesh
for
layer,
3
layer
4
again.
The
basic
advantage
is
that
you
know
it's
a
faster
low
latency
and
it
might
not
provide
the
entire
of
advantages
of
each
to
you.
E
For
example,
you
have
this
traffic
visibility
that
may
not
be
there.
To
that
great
extent,
it
might
have
visibility
at
the
fight
Apple
level,
but
not
at
the
API
level
and
and
also
maybe
what
traffic
distribution
will
be
at
the
fight,
Apple,
TCP
and
fight
Apple
level,
but
not
maybe
at
the
granular
level.
So
there
are
some
disadvantages
going
with
the
proxy
like
service
mesh,
but
the
advantages
being
low,
latency
and
higher
performance.
C
One
of
the
ways
people
are
trying
to
kind
of
eat
their
cake
and
have
it
too,
is
by
getting
visibility
into
traffic
inside
the
kernel
like
with
K
TLS
in
combination
of
K,
TLS
and
EBP
F,
you
can
actually
look
inside
the
packets
even
because
you're
offloading
encryption
to
the
kernel
so
that
that
could
work
for
lots
of
scenarios,
but
certainly
not
for
everything.
But
it
will
give
you
transparent
time
TLS
and
you
can
look
deeper
inside
your
payloads.
D
So,
even
though
we're
talking
about
proxy,
less
service
mesh
I
do
see
a
challenge,
and
you
know
how
we
can
get
deep
insights
into
the
API
level,
so
application
would
implement
multiple
ApS
so
with
our
upcoming
approach
of
programmable
networks
or
having
that
awareness
is
again
key.
So
the
challenges
and
how
can
I
still
get
that
APA
awareness
with
proxy
less
service
mentions
one
key
thing:
I
am
looking
towards
so.
B
One
thing
I
would
like
to
add
is
some:
the
proxy
list
should
be
thought
of
even
for
G,
RPC
or
HTTP
design
patterns.
It
all
depends
on
the
requirements.
It
may
be
that
the
axé
I
mean
the
APA
rate,
limiting
control
needed
only
for
certain
patterns,
communication
partners,
not
for
everything,
and
it's
really
a
design
choice.
B
A
E
Service
mesh,
of
course,
provides
security
for
micro
services,
but
the
problem
statement
is
really:
how
do
you
basically
secure
the
service?
Mashite
self
right?
So
in
case
of
cloud
we
are
service
meshes,
you
know
is
being
provided
by
cloud
provider,
and
you
know
the
private
keys
are
for
each
toc
title,
for
example,
our
user
certificate
private
case
of
an.
Why
is
not
a
big
concern
there
in
cloud,
but
in
the
80
locations?
It's
a
very
easy
to
steal.
E
Your
heart
mean
hard
drive
or
you
know,
SSD
drive
and
can
figure
out
your
private
key
secrets
mask
first
and
everything
like
that.
So
the
what
I
was
saying
is
that
when
we
deploy
is
do
in
edge
locations
which
are
physically
not
so
secure,
we
must
ensure
that
the
private
keys,
whether
the
CA
certificate,
private
key
or
whether
the
user
certificate
private
keys,
are
secured.
It's
the
harder
root
of
trust,
maybe
TPM
secure,
got
extensions,
trust
zone
and
things
of
that
nature.
B
I
really
like
the
point
Sweeney
brought
up
and
what
I
would
like
to
add.
Is
we
see
this
as
a
common
problem
in
all
service
meshes,
we
investigated
link,
ID
aspen
mesh
has
a
service
lashes
and
they
are
all
using
the
current
cloud
design
pattern
where
the
cloud
itself
is
more
secure.
So
basically,
this
sort
of
essentially
using
the
right
hardware
technologies-
I
mean
the
trusted
environments,
is
critical
across
all
service
meshes.
So
that's
the
point.
I
won't
erase.
A
The
scenario
that
we
just
talked
through,
where
you're
optimizing
hardware
with
GPU
and
smart
Nix,
etc.
You
have
user
space,
kernel,
space,
optimization,
perhaps
you're
using
proxy
or
proxy
list
based
service
match.
What
are
your
thoughts
on?
You
know
as
an
end
user.
You
know
you're
deploying
some
of
these
hardware,
software
optimizations.
You
have
a
centralized,
control
playing
and
a
distributed
data
playing.
How
do
you
manage
all
this?
You
know
for
us.
You
know,
for
example,
data
operations.
What
are
some
of
the
concerns
that
users
might
be
facing.
E
One
thing
which
we
need
to
ensure
is
that
you
know
there
is
no
changes
to
the
applications
applications,
so
developers
shouldn't
even
know
whether
that
service
mesh
is
optimized
for
hardware
and
secured
by
Hardware
and
things
of
that
nature.
That
is,
must
otherwise
there's
no
success
and
any
developer
who
develops
applications
for
cloud
they
will.
They
should
continue
to
work
in
in
80
locations
with
optimized
unsecured
service
mesh,
so
that
is,
that
is
must
so
what
can
we
say
that
you
know
service
mesh
needs
to
be
optimized
and
secured.
E
We
believe
that
you
know
the
service
mesh
technologies
that
are
designed
for
that
are
basically
tuned
for
edge
locations
would
be
a
separate
image
by
itself
like
each
to
your
Citadel.
Maybe
may
need
to
take
advantage
of
HSM
SR,
pkcs,
11
basic
systems
for
key
security
right
and,
and
then
you
know,
enhance
on
why
to
leverage
user
space
communication,
especially
if
it
is
other
micro
service
in
the
same
node
or
accelerate
using
crypto
accelerators,
which
we
have
all.
E
A
So
hopefully
this
panel
has
been
useful.
We
have
roughly
about
six
minutes
left
and
I
want
to
take
another
poll
and
now
we'll
open
it
up
for
for
Q&A.
So
first
I
want
to
ask
the
panelists
first,
as
your
concluding
statement
is
service
mesh.
In
your
opinion,
ready
for
edge
native
applications
today
well,
stock
was
trainee.
D
A
D
As
I
said
earlier
right,
so
it
has
to
be
as
lean
as
possible-
that's
a
main
requirement
for
us
and
then
insights
into
the
application,
traffic
and
everything
right.
So
the
important
point
here
is
imagine
a
customer
has
2,000
and
trace
premises,
and
if
there
is
a
issue,
developer
has
to
go
and
find
out
that
that
issue
is
in.
It
cannot
go
into
all
those
edge
deployments
and
then
debug
there.
So
what
we
need
is
what
we
are
looking
towards
is
a
centralized
management
pane
of
glass,
where
I
can
aggregate
all
of
that
issues.
C
So,
on
the
first
question:
whether
service
mesh
is
ready
for
cloud
edge
native
applications,
guess
it
depends
on
which
edge
in
which
applications
and
which
service
mesh
there
are
clearly
examples
of
deployed.
For
you
know,
Syrians
have
been
doing
this
for
a
long
time
and
things
like
stadia
exist
and
you
service
mesh.
C
But
if
you
talk
about
the
open
source
service
mesh
for
5g,
probably
not
there
yet
in
terms
of
the
wish
list,
I
would
say
you
know
we
have
to
work
together
as
a
community
to
find
a
common
way
to
take
advantage
of
accelerators.
You
know
specifically
for
networking,
you
know:
what's
the
API
to
offload
networking,
is
it
p4?
Is
it
EBP,
F
I?
Don't
think
we
have
a
clear
answer
yet,
but
we
should
try
to
get
their
ideas.
B
B
I
mean
there's
a
lot
more
to
go,
but
it's
a
good
progress,
we're
making
towards
service
mesh
for
edge
deployments
and
to
me
the
biggest
pain
point.
I
would
like
there
to
be
solved
as
essentially
the
convergence
of
layer,
2,
4
and
layer
7
right.
So
to
me,
that's
a
key
for
solving
the
proxy
list
service
measure
problem.
B
So
today
the
way
things
are
like
l/24
goes
on
one
path:
you
have
no
idea
what
you're
doing
there
right
I
mean
you
have
CNI
involved
there,
and
this
one,
like
you
have
is:
do
we
have
link
ready,
no
see
an
eye,
I
mean
it's
all
completely
fragmented.
How
do
you
bring
this
ecosystem
together?
It's
absolutely
key
to
solving
the
proxy
list
problem
and
especially
for
going
edge
native.
E
A
F
C
C
A
Many
people
in
the
audience
believe
service
mesh
is
ready
for
edge
native
application.
How
many
people
say?
Yes,
how
many
people
say?
No,
ok,
lots
of
those.
How
many
people
say
it
depends
depends
on
the
application.
Ok,
so
a
few
of
you,
ok,
good
I,
think
that's
kind
of
where
we
all
landed
in
this
panel
and
I.
Think
you
know
some
of
the
topics
that
we
addressed
in
the
panel
are
very
relevant
and
that
we'd
love
to
hear
from
you
are
there
any
other
questions?
We
have
a
few
more
minutes
left.