►
From YouTube: Ask Me Anything About Service Mesh
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
Ask Me Anything About Service Mesh
Speakers: Christian Posta, Louis Ryan, William Morgan, Lin Sun, Idit Levine, Zack Butcher
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 experts from ServiceMeshCon program review committee will address your most challenging inquiries around service mesh!
A
We're
waiting
for
one
more
microphone
and
then
we're
gonna,
we'll
get
going
in
the
meantime.
Think
about
the
questions
you
want
to
ask
them.
You
just
sat
through
a
full
day
of
bombardment
about
service
mesh
and
all
the
exciting
things
that
are
happening
in
this
ecosystem.
I'm
sure
it
jarred
some
questions.
So,
let's,
let's
get
them
going
all
right
all
right
to
kick
off
we're
going
to
have
the
panelists
here
introduce
themselves
and
explain
what
they
are
excited
about
in
service
meshlab.
So.
B
I
mean
I'm,
the
boss,
apparently
and
so
I'm
from
so
I'm,
the
founder
and
the
CEO
of
solo
in
Christian,
voice
and
yeah,
and
what
else
so
I
yeah
so
we're
building
a
lot
of
stuff,
like
you
heard,
I
think
before.
So
we
we
all
in
in-service
mash,
a
kind
of
like
we
don't
have
a
service
which
we
are
not
owning
a
service
at
I.
Know
it
strange
in
this
ecosystem.
We
actually
just
orchestrating
those
service
managed
to
your
choice.
We
are
the
one
who
founded
this.
Am
I
as
well
and
the
others
and
yeah.
D
C
E
Hey
I'm
Zack,
I'm
founding
engineer
at
Tetris,
and
what
about
early
engineers
on
Sto?
And
you
know
what
excites
me
to
say,
the
same
is
William
right.
I
think
both
of
us
have
been
working
in
the
service
specification
for
a
little
while
now
and
it's
really
exciting
to
you
to
see
what
people
can
go
and
do
once
they
actually
adopt
it
right.
It's
it.
That's
kind
of
when
the
the
journey
starts.
F
Hi
I'm
Louie
Ryan
I
work
on
sto
for
Google,
like
Zack
I've,
been
on
the
project
since
the
dawn
of
time.
I
think
what's
exciting
to
see
particularly
today,
and
maybe
a
bit
of
a
shift
from
previous
coop
cons
is
the
number
of
things
being
built
on
top
of
service
meshes
right,
I,
think
service
mesh
is
infrastructure.
Infrastructure
is
supposed
to
be
boring,
we're
working
very
hard
to
make
it
boring
and
all
the
exciting
stuff
should
happen
on
top
so
more
exciting
stuff
web
assembly.
D
G
Hi,
my
name
is
Lin
Tsai
I
shouldn't
worry
my
Easter
shirt,
but
I
was
trying
to
be
Wender
neutral
for
this
morning.
So
apologies
for
that
I
work
for
IBM.
What
excites
me
about
SEO
is
I.
Remember
about
service
machine
general
is
I.
Remember
two
years
ago
when
I
started
working
on
service
magic.
Oh
my
gosh
is
so
hard
to
use.
I.
Remember
I
was
trying
to
move
one
single
application
on
to
service
manager.
It
took
me
a
week,
but
recently
when
I
try
the
sum
of
all
the
service.
G
My
project
not
just
is
do
I
actually
try
some
of
the
other
project.
It's
just
amazing.
How
easy
it
is
to
use
them.
How
easy
it
is
to
onboard
in
your
application
so
to
serve
as
much
so
I
think
the
community
has
done
tremendous
work
to
make
service
much
more
consumable,
more
adaptive
to
you
guys.
So
that's
why
I'm
really
excited
about.
H
Hey
my
name
is
Luke
I
managing
around
the
console
team
and
what
I'm
excited
about
is
I
mean
it's
kind
of
funny.
When
Michelle
asked
like
how
many
people
running
service
mention
production
still,
it
was
like
not
that
many
people
so
I
think
there's
a
lot
more
lessons
and
things
to
learn
from
real
practitioners
once
that
actually
starts
to
grow
and
I'm
also
really
excited
about
the
ecosystem.
I
think
you
just
mentioned
that,
like
I,
think
there's
a
lot
of
really
cool
things.
H
A
I
When
actually
I
have
a
two
kawin
question,
we
two
parts
one
is
that
we
have
seen
in
case
of
container
orchestration
platforms.
We
saw
there
was
a
alphabet
soup
of
platforms,
communities
and
swarm
and
missiles,
and
all
this
thing,
and
eventually
one
one
out
why
and
in
this
I
heard
MSI
and
MSI's
purpose-
is
to
make
a
neutral
layer,
so
multiple
service
meshes
can
coexist.
So
why
is
an
emphasis
on
that?
Why?
What
makes
you
guys
think
that
one
service
mash
will
not
run
out?
I
The
second
part
of
the
same
question
is
that
service
fish
is
very
hard
not
to
you,
because
you
live
and
breathe
it,
but
to
an
ordinary
developer,
kubernetes
and
service
matches
very,
very
hard
to
learn
to
learn
and
master.
Do
you
really
think
an
enterprise
would
be
running
like
three
different
type
of
meshes
and
it
would
need
a
layer
on
top
of
it
to
talk
to
each
other.
I,
don't
see
it
happening.
If
you
could
please.
H
I'll
get
my
quick
answer
and
I'll
pass
it
over
to
the
folks
over
here.
I
think
there
probably
will
be
some
service
meshes
that
went
out.
I.
Think
that
makes
sense.
There's
gonna,
be
a
consolidation.
I
think
it
might
be
a
little
bit
different
than
kubernetes
and
that
networks
might
have
a
little
bit
way
more
kind
of
different
use
cases
and
so
I
think
there.
There
is
some
more
complexity
there,
but
that's
my
short
answer:
who
wants
it?
Oh.
G
Quickly
onset
to
you
before,
I
pass
it
over
here,
so
the
way
I
look
at
the
SMI
is
interesting
demo
from
Missha
today,
but
I'm
looking
at
SMI
as
stuff
we
accomplished
like
two
years
ago.
That's
when
I
go
to
cue
con
2017,
North,
America
I
would
demo
canary
deployment
with
Sto,
so
I
I.
Think
SMI
is
a
nice
concept,
but
it's
really
hard
to
bring
all
the
vendors
together
and
the.
At
the
end
of
the
day,
it's
going
to
demonstrate
capabilities
for
vendors.
G
B
Here's
the
thing
why
covenants
one
he
didn't
want
because
it
was
the
best
it's
pretty
good,
but
when
he
started
it,
wasn't
that
good?
The
reason
it's
actually
one
is
because
the
big
cloud
and
the
big
provider
chosed
it.
Now
all
those
people
create
this
community
and
make
it
better.
That's
not
the
case
with
service
mesh.
The
service
mesh
has
the
big
three
cloud.
Each
of
them
has
their
own
service
mesh.
Not
talking
about
the
fact
that
this
guy
started
the
service
mashup
of
system
right.
B
So
yeah
just
give
me
the
credit
right,
so
I
mean
n
he's
doing
really
well
right.
So
the
point
is
that
the
reason
they're
going
to
be
more
is
because
I
don't
see
that
there
is
a
huge
kind
of
like
it's
again.
Someone
is
looking
at
this
up
by
the
way.
I
don't
have
a
service
mention
I,
don't
care!
What
was
one
is
that
they
might
that
them.
B
It
doesn't
look
that
the
big
guys
actually
agree
and
if
they
are
not
agreed,
they
would
compete
and
if
they
are
compete,
they're
going
to
be
more
than
one
that's
number
one
and
number
two
that
I
will
tell
about
server
smash.
Is
that
the
service
machine
interface
and
again
this
is
not
technically
doesn't
matter.
Who
is
the
best
one?
It
you
know,
that's
right,
not
always
the
best
technology
went
so
it's
not
about
if
it's
good
or
not
right.
B
So
that's
that
now
I
can
tell
you
that
I
have
a
customers
and
they
came
to
us
in
the
beginning
and
they
say
well
omens
in
this
you
and
they
change
your
mind.
Why?
Because
they
understand
that
in
a
big
organization
like
this
specific
bank
that
I'm
talking
about
it,
there
is
well
more
than
one
group,
and
if
you
will
go
to
Google,
you
should
use
Sto,
you
should
it's
probably
building.
You
know
to
the
gifts
and
the
guts.
B
If
you're
going
to
up
to
AWS
same
thing
right,
they
will
give
it
to
you
for
free
I
mean
it
doesn't
make
sense,
it
will
connect
you
your
AC
to
you,
have
to
use
this
right
and
then,
if
you
kind
of
remember,
you
want
to
use
that
then
Kathy.
So
the
thing
is
that
big
organization
has
different
groups
there
with
different
needs.
Maybe
they
want
VM,
maybe
it's
a
Greenfield
they're
going
to
be
more
than
one
and
I,
don't
see
the
collapse
happening.
E
E
There's
many
reasons
press
my,
but
it's
a
it's
a
nice
part
of
it
right
I,
don't
think
that
that's
actually
particularly
likely
in
most
organizations,
and
the
reason
for
that
is
because
the
single
benefit
of
a
service
mesh
is
consistency,
right,
consistent
policy,
consistent
limitary,
consistent
traffic
control
and
so
by
adopting
a
variety
of
mesh
implementations.
You
you
largely
give
up
that
consistency,
and
so
I,
just
don't
see.
E
I
have
not
witnessed
organizations
making
that
decision
right,
I
have
certainly
made
witnessed
organizations
investing
in
in
investigating
multiple
meshes,
but
my
experience
has
been
that
once
they
they
make
the
technical
determination
around
which
one
fits
their
case.
They've
gone
all
in
on
that
and
it's
served
them
better
right
again.
The
the
watchword
for
a
mesh
is
consistency
right
and
so
SMI,
provided
it
tries
to
provide
consistency
via
the
API
but
to
Linds
earlier
point.
The
problem
with
that
is
that
today
it's
it's
a
lowest
common
denominator
right
and,
in
my
opinion,
I.
F
F
They
have
a
lot
of
internal
operational,
best
practice
that
they're
trying
to
represent
in
some
complex
set
of
systems
like
kubernetes
and
a
service
mesh
and
they're,
trying
to
meld
that
with
their
internal
business
process,
and
so
what
you
see
them
doing
is
creating
abstractions
their
own
api's
for
their
own
business
process
and
then
writing
their
own
tooling,
to
convert
the
VAS
into
the
underlying
infrastructure
right.
So
when
I
say
yes
to,
you
is
infrastructure
right.
It's
a
target
for
a
derivative
of
a
higher-level
process
that
you
want
to
represent.
F
I
mean
one
of
the
things
I
was
excited.
Seeing
the
demo
today,
from
solo
on
autopilot,
was
tooling
to
help
the
people
build.
That
kind
of
process
easily,
but
they're
just
lots
and
lots
of
examples
out
there
of
you
know
when
a
business
wants
to
represent
their
business
process
right.
There's
a
lot
of
information,
that's
proprietary
to
them
to
how
they
review
things.
Have
they
ploy
have
a
name
how
they
structure,
how
they
approve?
F
You
know
the
services
and
workloads
and
everything
else
to
rolling
out
in
their
environment
and
the
nice
thing
about
kubernetes
and
all
everything
everybody's
done
and
serviced
much
landon
in
this
world.
Is
they
built
good
api's?
So
it's
fairly
easy
for
an
internal
IT
shop
to
take
their
representation,
their
approval
flow.
F
You
know
the
information
they
care
about
and
convert
it
down
into
that
system
right
and
that's
actually
not
that
hard
to
do,
and
so
we've
seen
a
lot
of
people
doing
that
and
that
that's
really
valuable
right,
because
they
get
to
think
in
their
own
business
terms
and
that
there's
only
a
small
amount
of
code,
that's
converting
down
into
an
internal
infrastructural
representation,
and
we
saw
that
with
cloud
in
general
for
years
right.
This
isn't
unique
to
service
mesh
or
kubernetes
right.
This
has
been
a
pattern
and
internal
IT
for
well
over
a
decade.
D
So
the
question
is:
linker:
dv1
was
initially
focused
on
using
node
agents
and
then
switch
to
sidecars
afterwards
with
v2
and
East.
You
just
made
a
decision
on
by
using
sidecars
right
away.
So
the
first
question
is:
what
made
you
like
make
the
decision
around
doing
the
switch?
The
second
one
is:
do
you
ever
foresee
that
later
on
we're
gonna
just
go
back
to
no
agents.
C
No,
that's
a
linker
D
question.
All
right,
yeah
I
can
tell
you
why
we
made
the
switch,
and
you
know
like
any
engineering
choice.
There
are
trade-offs
and
not
everything
is
you
know
a
hundred
percent
in
in
either
direction
but
yeah
in
in
one
dot
X
we
well
so
actually
a
1
dot
X
you
could
deploy
it
either
way
right.
You
could
deploy
it
as
a
sidecar.
You
could
deploy
it
as
the
demon
said,
and
we
mostly
push
the
daemon
set
a
pattern
because
you
know
on
the
JVM.
C
It
was
kind
of
by
virtue
of
being
on
the
JVM,
that's
kind
of
a
heavyweight
process,
and
so
you
got
better
resource
usage
amortization
if
you
doing
it
per
host,
but
there
were
certainly
organizations
that
were
deploying
one
Dex
JVM
linker
D
as
a
sidecar
and
we're
kind
of
okay
with
it.
Given
the
benefits
they
were
getting
out
of
it,
but
for
two
Dex
you
know
we
went
down
the
sidecar
path,
mostly
because
it
makes
a
couple
things
easier.
C
One
is
it
just
I
think
it
all
comes
down
to,
like
you
have
better
kind
of
compartmentalization
of
what
the
sidecar?
What
the
proxy
is
actually
gonna
do
all
right
by
attaching
it
to
an
individual
application
instance.
Then
the
security
boundary
is
really
clear.
A
lot
of
the
operational
aspects
of
it
get
get
very
clear
to
like.
If
you
know,
if
it's
in
a
weird
state,
you
kill
it
and
restart
it,
and
we
have
all
sorts
of
semantics
and
mechanisms
for
doing
that
in
kubernetes.
C
If
it's
in
per
pod,
you
have
this
multi-tenant
thing
and
then
then
it's
like
it's
harder
to
do
that
and
then
upgrading
things
is
harder.
Like
you
just
have
a
decoupling,
you
know
in
a
bad
way,
between
the
services
and
and
the
kind
of
the
proxy
that's
sending
traffic
to
and
from
them.
So
overall,
the
other
big
thing
for
us
was
we
really
wanted
to
have
mutual
TLS.
C
C
In
a
sidecar
model,
we
had
to
rebuild
linker
D
from
the
ground
up
and
you
know
get
off
of
the
JVM
and
do
a
bunch
of
other
work
to
get
it
down
to
the
point
where
it
was
small
enough
and
fast
enough
that
it
made
sense
to
deploy
it
as
a
sidecar,
where
you
would
end
up
with
thousands
or
tens
of
tens
of
thousands
of
these
things.
But
yeah.
Those
were
the
main
benefits
for
doing
that
and-
and
it's
worked
out
pretty
well
sign
into
your
question.
J
So
we
had
a
really
quick
talk,
extremely
quick
talk
on
network
service
mesh,
and
you
know
it's
interesting
because
a
lot
of
things
he
talked
about
you
know
like
Federation,
federating,
different
service
meshes
and
things
like
that.
Technically
we
can
do
it
layer,
7,
maybe
not
as
efficiently,
but
we
can
so
I
guess
the
question
I
have
is:
do
you
really
see
benefit
in
having
a
network
server
service
mesh
and
an
application
service
mesh?
Or
does
it
just
clutter
the
conversation
and
make
things
harder
to
configure
yeah.
E
So
that's
I
think
it's
a
really
interesting
question.
I
think
part
of
this
gets
to
what
service
mesh
will
evolve
into
right.
So
one
way
to
look
at
that
network
is
that
it
is
another
accelerator
right.
So
your
GPU
is
an
accelerator
that
I
can
offload
embarrassingly
parallel
computation.
It
turns
out
that
you
can
do
like
HTTP
header
parsing
in
a
switch
or
in
an
nfe
right.
You
can.
E
Obviously,
that's
gonna
be
a
long
way
away
right,
so
in
the
interim
it
obviously
I.
You
know:
I
I
have
a
particular
hat
in
this
in
this
race.
So
in
the
interim
I,
don't
see
the
layer
3
the
lower
layer,
something
as
compelling
because
we
can
do
it
with
an
overlay.
So
for
cases
where
are
not
necessarily
an
overlay,
but
we
can
do
it
at
l7
right
so
for
cases
where
the
performance
isn't
so
essential,
I
think
it's
a
lot
easier
to
operate.
It's
a
lot.
A
E
F
E
That's
another
particular
area
of
interest
of
mine,
so
we
do
you
know
we,
the
inmates
networking
stuff
is
free,
interesting
right,
so
yeah
there's,
obviously
there's
a
whole
lot
of
really
interesting
capabilities
that
the
mesh
provides
that
are
that
are
very
interesting
for
an
IOT.
I
would
argue.
I.
Think
I've
said
before
that
the
single
most
important
feature
that
amesh
provides
is
identity.
It
identity
is
maybe
one
of
the
most
essential
building
blocks
of
anything
on
IOT
right.
E
If
you
don't
know
what
that
device
is,
if
you
can't
positively
authenticate
it,
then
it's
not
really
very
valuable
to
do
anything
else,
and
so
in
particular
I.
So
obviously
the
whole
range
of
network
resiliency
features
are
pretty
compelling
in
this
IOT
use
case,
where
we
have
worse
networks
and
things
like
that.
But
I
really
think
a
lot
of
the
killer'
use
cases
are
gonna,
be
around
identity.
I
think
we
can
look
at
Android
and
how
the
the
Google,
what
is
it?
E
H
F
There's
also
the
boring
plumbing
part
right,
I
mean
most
the
IOT
devices
out
there
want
to
speak
some.
You
know
low
footprint,
protocol,
co-op,
mqtt,
I,
run
out
of
the
names
of
acronyms
pretty
fast,
and
you
know,
there's
a
large
number
of
those
running
out
on
either
internally
on
your
network
or
at
the
edge
or
beyond
the
edge
of
your
network
and
you're
gonna
want
to
be
able
to
bridge
those
in
and
have
them
talk
to
services
and
do
all
the
regular
service
mesh,
ready
things
right
and
the
policy
things
and
the
identity
enforcement
things.
F
So
you
know
one
of
the
reasons
why
we
were
super
interested
in
webassembly
is
because
we
think
it
gives
us
the
ability
to
add
dynamic
protocol
support
to
the
network
right.
So
you
could
start
to
treat
clap
and
rout
co-op
like
you,
routed
HDPE,
for
example,
or
do
the
same
thing
with
mqtt
right
and
hopefully
we'll
start
to
see
those
types
of
things
happen
or
people
can
add
extensions
at
the
edge
too
or
even
inside
cars
to
route
these
kinds
of
protocols,
because
you
gonna
need
the
plumbing
as
well.
I
was.
G
M
Hello
yeah
so
I
think
just
to
add
to
the
current
topic
on
IOT
and
also
possibly
network
service.
Mesh
I
mean
how
do
you
guys
in
envision
all
this
I
mean
I,
know,
there's
a
lot
of
standards
related
that
that
are
not
necessarily
fall
in
place.
But
how
do
you
say
this?
You
know
in
terms
of
roadmap
for
any
of
the
service
mesh
that
we
are
saying.
No,
maybe
I
would
want
to
say
like
next
five
years
or
two
years,
yeah.
E
For
things
like,
like
some
of
those
IOT
use,
cases
and
and
stuff
like
that,
yeah
I
would
be
I
would
be
very
happy
if,
in
five
years
we
have
people
doing
like
production
use
cases
with
that
right,
I,
it's
it's
very
hard
to
guess
to
some
degree
right.
It's
really
gonna
boil
down
to
do.
People
are
people
gonna
pay
money.
They
do
people
that
are
paying
money.
Have
that
use
case
in
the
next
five
years
is
really
gonna,
be
the
differentiator
for
that,
and
that's
really
gonna
boil
down
to
do.
E
You
need
really
extreme
performance
while
still
keeping
a
lot
of
this
consistency
right,
at
least
for
the
for
the
network
service
mesh
side
of
it.
In
my
mind,
right
the
device,
identity,
side
of
IOT
I
think
is
actually
a
much
more
pressing
reason
for
that
to
start
to
happen
sooner,
but
I
think
that
it's
more
likely
that
identity
there
manifests
in
different
ways
first
and
that
a
service
mesh
will
use
those
rather
than
the
service
measure,
being
the
answer
for
identity
in
IOT
devices.
Out
of
the
box.
N
So
how
many
sidecars
is
too
many,
sidecars
I
know
it's
not
specifically
a
server
mass
mass
question,
but
I've
had
like
five
sidecars
before
and
that's
a
lot
of
sidecars
but
I
also
haven't
seen
a
problem
with
it,
like
I,
haven't
necessarily
seen
huge
hits
and
performance.
So
is
it
a
problem
or
does
it
just
kind
of
look
silly?
This.
C
K
E
Like
the
worry
with
the
sidecars,
it's
less
efficient
than
doing
it
in
binary
in
binary
in
some
sense
right
and
so
the,
but
the
other
side
of
that
is
you're,
also
not
doing
it
in
your
binary.
So
the
cost
accounting
is
kind
of
hard
there
right.
So
as
long
as
you're
comfortable
with
the
cost
of
your
sidecars
and
the
value
that
you're
getting
out
of
that
relative
and
it's
not
a
very
hard
answer.
But
as
long
as
you're
happy
with
the
value,
it's
the
money
that
you're
spending
and
you
keep
slapping
those
sidecars
in
there.
E
F
I
mean
some
of
the
site:
cars
are,
you
know
not
playing
a
strong
role
in
security,
probably,
and
so
should
really
be
shared
resources,
but
haven't
been
implemented
that
way,
and
so
it's
a
convenience,
not
a
necessity
right
if
they're
playing
a
strong
security
role,
all
right,
so
the
people
that
the
five
sidecars
that
are
not
doing
strong
security
things
right
and
should
be
running
a
shared
infrastructure
go
nag,
those
people,
so
you
can
get
back
down
to
six
or
four.
However,
many
we
below
what
the
seven
is
or
whatever
we'd
read
the
limit.
Yeah.
M
B
C
Said
no,
but
I
actually
need
to
expand
on
that.
Like
you
can
use
it
right,
you
can
proxy
anything.
I
mean
I,
don't
know
at
least
in
linker
deal
and
if
it's
a
TCP
connection,
we'll
proxy
it
for
you.
We
don't
have
protocol
support
specifically
for
Kafka,
but
that's
something
that
could
be
add
and
I.
Think
history
Oh.
Has
it
I
think
the
reason
I
wrote?
No
is
because
it's
more
because
the
the
value
prompts
are
not
quite
as
strong
in
that
world.
C
You
know,
especially
the
kind
of
reliability
aspect
of
things
as
it's
done
in
a
different
way
in
in
the
queueing
based
system,
and
you
know
so
a
lot
of
the
kind
of
the
cool
things
that
the
service
mesh
can
do
around.
Even
some
of
the
observability
stuff
is
just
not
that
interesting
when
you're
working
with
queues.
So
it's
not
that
it's
zero
value,
it's
just
that
it's
a
lower
value
for
the
same
cost,
a.
E
Lot
of
that
has
been
built
into
the
SDK,
so
you
would
use
to
talk
to
the
queue
right.
Then
that's
why
it's
lower
value
the
other.
The
other
problem
is
just
it's
a
black
box
right,
so
we
don't
like
it's
a
it's,
a
bus
that
things
go
into
and
things
come
out
of
and
today
the
service
messed
up.
Limitations
require
causality.
F
Yeah
I
mean
most
of
the
you
know
all
the
things
that
the
mesh
would
be
helping
you
with
would
be.
You
know,
transport
security.
If
you
weren't
implementing
that
consistency
with
the
library
you
know,
maybe
the
ability
to
try-
and
you
know
across
some
network
boundary
right-
some
basic
kind
of
lower-level
network
thing
unless
you
had
actual
protocol
support
for
that
thing
and
then
the
question
is
what
would
you
be
doing
with
the
protocol
support?
F
For
that
thing,
the
primary
reason
we
here
for
people
asking
for
support
for
that
thing
is
so
they
can
get
to
lemon
tree
out
in
ways
that
are
non-standard
baked
into
the
library
right,
so
they
want
to
kind
of
bridge
a
gap
there
and
that's
a
real
use
case.
So
you
know
that's
why
we're
doing
it,
but
the
libraries
do
a
lot
of
work
at
the
protocol
level,
so
you
have
to
look
at
the
gaps
so.
G
What
we
find
out
a
lot
of
users
are
using
Kafka
type
of
messaging
service
as
an
external
services.
We
Cisco
and
main
reason
is
because,
for
example,
the
Envoy
cycle-
usually
it
still
doesn't-
have
support
for
Kafka
protocol
I,
believe
it's
on
their
roadmap,
so
we
couldn't
add
more
native
support
for
messaging
systems,
we're
saying
it
stills,
but
that's
something
you
know
we
find
a
lot
of
people
interested
in
they're,
just
building
external
services
as
a
stopgap
solution.
L
F
F
A
couple
of
key
things:
you
know
it's
st
was
gone
through.
You
know
a
lot
of
user
feedback,
we've
taken
a
hard
look
of
the
api's
and
continue
to
try
and
involve
them,
and
one
big
mistake
I
think
we've
already
made
early
on
in
the
api
was
not
considering
the
kind
of
human
unit
of
edit,
where
you
basically
you'd,
have
a
resource
for
every
individual
HTP
route
right
and
so
then
you
asked
a
human
being
to
go
and
understand.
F
Well,
how
is
the
system
routing
your
traffic
and
they
had
to
go
and
look
at
60ml
files
right
so
that
that's
just
not
a
good
API
right?
That's
gonna
just
destroy
people's
ability
to
understand
the
system.
So
you
know
the
vedat
is
really
crucial
and
we've
actually
done
a
lot
of
work
to
kind
of
take
api's
that
were
disaggregated
and
aggregate
them
back
again,
and
then
you
still
have
to
have
situations
where
you're
composing
resources
right.
F
So
then
you've
to
be
very
careful
about
the
semantics
of
composition
right
and
how
that
cooperates
with
unit
of
edit.
So
you
know,
if
you
look
at
the
earlier
versions
of
sto,
0.7
or
0.8
you'll
see
a
cheapy
route,
and
now
you
see
virtual
service
and
there
they
do
the
same
thing.
They
just
do
it
very
differently
and
we're
much
more
specific
about
how,
when
you
compose
a
virtual
services
into
one
gateway,
what
the
semantics
are-
and
that
was
a
very
big
thing,
because
that
was
hugely
impacting
the
usability
of
the
system.
E
C
Yeah
I
really
like
that
question,
because
I
think
you
know
so
one
of
the
goals
for
linker
D
is
we
want
to
reduce
as
much
as
possible
the
operational
overhead
of
running
the
system,
because
our
adopters
are
our
users
and
there's
all
these.
Like
crazy
touch
points
that
happen.
You
know,
if
you
think
of
like
the
engineering
team
roughly
being
composed
and
of
platform
owners
who
are
like
doing
kubernetes
and
service
mushy
things
and
then
service
owners
who
are
writing
code
and
deploying
it
to
the
platform.
C
There's
all
these
weird
touch
points
that
the
service
mesh
is
kind
of
in
the
thick
of
between
those
two
teams.
You
know
especially
around
like
what
is
the
behavior
of
this
particular
service.
How
should
retry
policy
like
be
affected
or
what's
the
rate
limits
for
the
service?
That's
information
that
you
know
that
the
service
owner
kind
of
understands
and
needs
to
encode
into
the
platform.
C
The
platform
owner
doesn't
understand
the
mechanics
of
an
individual
service,
but
maybe
he
is
providing
the
platform
by
which
that
information
gets
expressed,
and
so
a
lot
of
you
know
kind
of
the
the
design
time
and
energy
on
the
link.
Rd
side
is
into
you
know.
How
do
we
I
think?
Lou
is
exactly
right.
You
know
what
is
the?
What
which
human
being
is?
Gonna
be
editing
this
and
what's
their
role,
and
what
do
they
have
to
know
about
the
rest
of
the
system
and
so
in
linker
D?
C
We
have
this
thing
called
service
profiles
where
you
define
configuration
on
a
per
service
basis
and,
like
you
could
express
this
in
70
different
ways.
We
could
have
spread
it
out
differently,
but
we
attach
it
to
a
service,
because
that
was
kind
of
the
the
most
natural
way
from
the
human
perspective
of
how
you're
going
to
configure
this
stuff.
C
The
other
thing
that's
been
really
interesting
for
us
now
that
you
know
we
are
not
just
producing
link
ready
but
but
running
dive
is
that
dive
runs
on
link
ready
so
now
we're
actually
running
link
Rd
and
production
ourselves
for
the
very
first
time
it's
an
hour
like
really
feeling
the
pain
you
know
so
we've
gone
from
like
having
you
know
what
I
thought
were
pretty
good
conversations
with
our
users
to
like.
Oh
man,
we're
using
this
thing.
We're
waking
up
at
3:00
a.m.
B
Want
to
do
it
is
this
kind
of
like
a
try
and
do
it
like
you
have
the
ability
to
make
a
very
opinion,
a
P
I,
which
would
be
very
easy
to
you.
Is
there
a
vs.
to
actually
have
an
API?
That
would
be
so
generic
that
this
would
be
very
hard
to
do
at
the
end
of
that,
but
it
can
use
every
use
case
that
anybody
wants
and
I
think.
This
is
always
a
thread
of
that.
You
know
people
are
talking
about
it.
I
mean
to
me
I'm,
really
good.
B
You
know
it's
all
I
or
the
SMI
Oh
everything
that
we're
doing.
We
kind
of
like
trying
to
think
about
the
user,
but
but
that
means
that
we
open
a
tie
right,
and
this
is
what
we're
doing
we
are
open
in
and
then
it
would
be
perfect
sue
to
that
solution
that
we're
trying
to
solve
but
is
not
going
to
solve
any
problem
in
the
world.
B
H
Gonna
say
for
from
the
console
point
of
view,
we're
trying
to
have
like
make
easy,
easy
and
then
have
kind
of
escape
hatches
where
you
can
kind
of
do
the
really
complicated
power-user
things,
and
the
other
thing
that
we're
dealing
with
the
RPI
is
is
because
we
came
from
like
a
VM
world
and
now
we're
also
supporting
kubernetes.
How
do
you
balance
like
cube
native
with
also
like
how
people
can
run
things
on
their
data
centers?
H
O
Kind
of
like
almost
a
follow-up
to
that
question,
I
was
wondering
if
you
had
any
thoughts
on
how
to
handle
the
conceptual
overload
that
so
many
engineers
have
now
like
those
of
us
on
the
infrastructure
network
teams
mostly
get
high
like
kubernetes
and
service
mesh
type
works,
but
are
poor
application
developers
we're
trying
to
understand
these
kind
like
layered,
abstractions
and
like
edge
cases
on
actual
implementation?
It
gets
it's
a
lot
to
fit
in
your
brain.
So
any
thoughts
on
how
to
we
could
talk
out
tackle
that
totally.
H
Yeah
I
think
like
from
the
way
we
look
at
things
as
this
personas
right
and
who's
doing
what
so
from
like
the
service
owner
they
they
know
which
upstream
they
want
to
talk
to
right,
but
then
who
approves
whether
they
can
talk
to
that.
So
that
might
be
like
the
security
team
or
someone
on
there
who
has
like.
So
that's
why,
like
in
console,
you
can
annotate,
which
upstream
you
want
with
any
intentions
which
are
allow.
Are
you
allowed
to
talk
to
that
upstream
or
not
as
a
separate
ACL
token?
H
It's
a
separate
kind
of
persona
there
in
terms
of
like,
like
routing
config,
that's
kind
of
like
it
depends
on
the
team.
So
some
teams
don't
want
to
think
like
I
know
a
lot
of
developers,
just
don't
want
to
ever
think
about
like
routing
and
stuff
like
that,
they
just
want
it
all
to
work
and
whoever
can
just
DevOps
scheme
can
handle
it,
but
you're
always
gonna
have
some
people
that
are
like
ok,
well,
I
actually
want
to
know
why
my
app
is
retrying
and
you're
like
oh,
that's
cuz,
it
was
returning
it
to
hunt.
H
I
was
a
get
call
and
we
were
trying
get
calls
right
and
they're
like
oh
no.
This
is
a
specific
thing.
I,
don't
want
to
retry
that
get
call
so
I
do
think
you
need
to
have
kind
of
like
that.
That
way
that
that
developer,
who
wants
to
get
into
that,
can
actually
configure
those
those
things
as
well,
so
I
think
it's
how
it's
hard.
G
Would
say
this
is
something
a
service
must
really
make
it
easy
to
separate
from
the
messy
operator
and
your
security
operator
to
the
developers.
What's
really
interesting
is
that
the
mesh
operator
and
security
operator
can
be
more
in
charge
of
the
service
mesh
llaman
file
without
and
be
able
to
tweak
it
without
having
the
service
owner
that
the
the
developer
to
rebuild
the
images
sometimes
a
lot
of
times.
It
doesn't
even
need
to
redeploy
their
services
because
you
could
trick
like
the
timeout
retries
circular.
G
Breaking
all
that
without
even
consulting
the
developer
is
the
only
if
there's
a
need,
so
the
nice
separation
brought
by
service
mesh
really
made
it
easy,
and
what
we
see
heard
a
tremendous
trend
is
to
develop
different
services
to
divide
them,
maybe
by
namespaces,
and
then
you
can
have
different
configuration.
/
namespaces
to
have
each
of
the
team
are
separated
nicely.
E
Yeah,
so
this
is
one
of
the
most
common
problems
that
I
run
into
when
we
talk
with
users.
Right
is
how
do
I
give
my
app
developers
the
control
that
they
need
over
the
parts
of
the
message
that
they
need
to
control,
but
hide
the
complexity
right,
and
so
this
is
where,
to
the
point
that
Louis
opened
up
the
discussion
with
around
people
building
management
planes.
That's
a
large
piece
of
it
right.
So
I
think
that
this
is
really
the
role
of
the
platform
team
in
an
organization.
E
What
you
really
should
be
doing
is
not
giving
your
developers
the
mesh
API.
You
should
be
giving
them,
though
some
boxed
version
of
that
some
subset
of
it,
which
covers
the
use
case
that
they
that
they
should
be
addressing
right.
Certainly,
at
least
that's
that's
closer
to
the
intended
use
case
with
SEO
right.
E
So
just
don't
even
give
them
those
api's
right
and
it
says:
well,
you
know
if
you,
if
you
need
that
break
glass,
you
have
the
full
api's
behind
the
scenes
that
you
can.
Those
teams
that
are
that
that
are
sophisticated,
that
want
more
control.
Take
it
upon
themselves
to
learn
that
right
and
that's
a
reasonable
trade-off
right.
So
you
provide
an
easy
happy
path
and
you
and
allow
them
to
drop
down
if
you
have
to
and
that's
what
we've
seen
at
least
within
the
people
and
I've
been
working
with.
E
B
So
I
just
say
that
to
me
that
the
patient
doesn't
need
to
know
that
service
meshes
have
been
running
in
your
infrastructure.
Right
I
mean
they
shouldn't
know,
it's
a
feature
to
them.
They
want
to
reach
right.
They
should
tell
me
that
need
a
rich,
why
they
shouldn't
even
think
about
the
API
all
about
service
machine
in
general.
They
shouldn't
know
they
will
not
know
right,
doesn't
make
any
sense
to
refer
there
to
ask
them
to
write
all
those.