►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Panel Discussion: Service Mesh Maturity: Are We There Yet? - Mitch Connors & John Howard, Google; William Morgan, Buoyant; Nitya Dhanushkodi, HashiCorp & Keith Mattix, Microsoft
This panel will bring together perspectives from contributors to four major service mesh projects on recent developments in the Service Mesh Landscape. Topics will include: The Gateway API (it's a real GAMMA changer), How Not To Use Service Mesh (2022 edition), and What is a Service Mesh (reprised from 2019).
A
Right
we've
got
all
three
mics,
so
I
think
we'll
go
ahead
and
get
started.
Welcome
everybody.
My
name
is
Mitch
Connors
I'm,
a
software
engineer
at
Google
and
a
Toc
member
of
the
istio
project
and
I'm
going
to
be
moderating
this
session.
So
I'd
like
my
panelists
to
introduce
themselves
if
they
would.
A
D
All
right,
I'll
go
I,
guess
yeah
I
mean
maturing.
Yes,
are
we
fully
there?
Yet?
No,
you
know
one
of
the
ways
I've
seen
that
that
we've
matured
is
that
it's
not
so
hard
to
just
go,
install
a
service
mesh
now
and
at
least
get
started
on
something
right.
If
you
look
years
past,
like
even
just
that
hurdle
was
was
quite
a
bit
for
some
people,
there's
still
a
lot
of
effort
to
reduce
the
cost
of
operations,
though
especially
Beyond.
D
You
know,
Day
Zero,
install
but
I
think
one
of
the
other
areas
of
maturity
is
kind
of
the
ecosystem.
Even
once
you
get
your
service
mesh
up
and
running,
you
know
largely
that
provides
a
lot
of
building
blocks
right.
You
have
identity,
you
have
the
ability
to
configure
Rich.
You
know
L7
routing
rules
to
Canary
rollouts,
but
you
still
have
to
make
use
of
that
to
actually
get
value
right.
So
there's
some
tools.
D
E
Yeah
I'll
say
from
our
you
know,
from
kind
of
the
Linker
D
perspective.
You
know,
we've
been
saying
the
word
service
mesh
since,
like
2016
or
something
and
one
thing,
that's
really
changed
for
us
over
the
past
year
or
two
has
been
kind
of
the
nature
of
those
conversations
where
a
lot
of
the
early
conversations
were.
E
You
know
people
who
are
enthusiastic
and
want
to
do
it
themselves
to
people
who
maybe
are
not
enthusiastic,
but
you
know
they
see
it
as
inevitable
and
and
they
know
they
can't
really
do
it
themselves,
and
so
that's
been
maybe
a
maturity.
You
know
more
of
the
of
the
audience
and
of
the
technology.
I.
Think
in
the
you
know,
are
we
there
yet
no
I
I,
don't
think
so.
I
think
there's
a
lot
of
maturity
still
ahead
of
us
I
think,
especially
when
it
comes
to
you
know,
kind
of
to
John's
Point.
E
It's
it's
really
hard
to
get
a
functioning
service
mesh.
It's
like
way
harder
than
it
should
be
and
I
think.
If
this
whole
you
know
system
is,
is
going
to
work,
it
needs
to
be.
You
know
it
needs
to
be
not
significantly
Harder
Than,
You
Know,
adopting
kubernetes
itself
like
it
needs
to
be
kind
of
like
the
next
natural
consequence
and
not
like
a
whole
new
team
and
a
whole
new
project,
and
so
I've
seen
you
know,
movement
in
that
direction,
but
I
wouldn't
say
we're
there.
Yet.
B
C
Yeah
I
agree
with
a
lot
of
what's
been
said,
I
think
for
me,
one
of
the
ways
I've
seen
service
meshes
mature
is
that
we've
got
it
in
the
hands
of
more
people.
We've
got
more
years
under
the
belt
of
this
word
service
mesh
and
so
because
of
that,
I
think
that
what
we're
seeing
is
a
lot
of
validation
of
some
of
the
problems
that
sort
of
mesh
started
off
trying
to
solve,
but
we've
also
seen
some
areas
where
you
know
we
anticipate,
as
you
know,
mesh
being
around.
C
C
One
of
the
areas
that
comes
to
my
mind
in
my
work
on
open
service
mesh
is
around
Advanced
use
cases,
pki,
infrastructure
handling,
CA
requirements,
compliance
service
measures
entering
any
of
those
conversations,
and
now
you
know
we're
seeing
custom
has
come
to
us.
Saying:
hey
we
know
mesh
is
how
to
how
we
solve
these
compliances.
A
Nice,
so
so
speaking
of
an
easy
button,
one
of
the
things
that
we've
heard
a
lot
about
at
this
conference
and
has
a
lot
of
press
releases
recently
is
the
Gateway
API
and
now
the
gamma
initiative,
which
I
think
you
guys
represent
four
service,
meshes
and
I.
Think
all
of
them
are
doing
something
with
gamma
initiative
and
Gateway
API.
So
it's
cool
to
see
that
I
think
we
call
it
coopetition
very
neat.
But
what
is
it?
A
C
I've
got
the
mic,
I
guess:
I'll
start.
You
know,
I'm
I'm
really
excited
at
the
work.
What
we're
able
to
do
in
Gateway
API
in
gamma,
because
here's
what
that
means
right
now,
if
you're
a
user
coming
into
kubernetes
and
you
learn-
okay,
I
see
the
Ingress
resource
exists
in
fact
match
your
taught
me
earlier
about
your
journey,
trying
to
use
something
besides
istio
you're
like
okay
Ingress
is
there
it's
been
mature,
and
so
they
go
towards
Ingress
and
then
okay,
now
I've
got
my
mesh
and
I've
got
to
learn.
C
So
that
way,
there's
not
that
Gap!
There's
not
that
jump
from
this
resource
to
that
resource
to
this
resource.
It's
one
set
of
resources,
one
set
of
configuration
for
traffic
routing
for
exploring
policy
obligation
policy
and
that
can
be
consistent
across
Gateway
or
across
Ingress
and
mesh
use
cases,
and
so
from
a
user
experience
perspective
and
an
education
perspective.
That's
very
exciting
to
me.
D
So
that's
everything
from
documentation,
tutorials,
YouTube
videos,
that's
Integrations
that
are
doing
things
like
cert
manager
or
external
DNS
or
Argo
CD,
or
all
these
types
of
things
right.
You
know
some
of
those
Integrations.
They
may
happen
to
integrate
with
your
mesh.
They
may
integrate
with
15
meshes
and
have
a
huge
maintenance
overhead,
so
they
can't
actually
work
on
features.
D
You
know
now,
there's
just
one
API,
that's
common
for
Ingress
for
mesh
to
integrate
across
the
board,
so
I
think
we'll
see
a
lot
more
Integrations,
which
will
allow
kind
of
what
I
mentioned
earlier,
like
actually
expanding.
Take
the
service
mesh
and
get
the
building
blocks
actually
used
for
something
useful,
so
see
a
lot
of
product
offerings
and
we're
already
starting
to
see
that,
on
top
of
the
Gateway
API.
E
So
we
had
to
adopt
it
in
kind
of
like
a
slightly
funky
way,
which
I
hope
to
correct
in
the
future.
But
it
really
solved
an
immediate
problem
for
for
Linker
D,
and
that's
why,
as
soon
as
Keith-
and
you
know,
all
the
gamma
stuff
kicked
off,
I
was
like
you
know,
even
though
I
hate
standards
or
you
know,
don't
care
about
them,
or
you
know
maybe
I'm
at
best
I'm
I'm,
wary
of
them,
because
I've
seen
them
weaponized
in
a
road
blog
post.
Complaining
about
this
we're.
E
B
Cool
yeah,
I
think
I'm
going
in
A
and
A
Plus
winning
a
lot
of
what
what
people
said
so
yeah.
It's
exciting
that
that,
hopefully,
users
of
servicemen
shall
be
able
to
focus
Less
on
the
ux,
because
that
will
be
consistent
and
documented
kind
of
across
multiple
meshes
and
stuff
and
and
care
more
about
their
more
advanced
use,
cases
and
stuff
and
I.
Think
I'm
especially
excited
to
see
how
the
apis
will
evolve
for
kind
of
East-West
traffic
and
also
for
multi-cluster
and
multi-platform.
So
yeah.
E
Yeah
no
I
think
that's
a
really
good.
Point,
too,
is
that
you
know
I
think
there
is
a
nice
world
in
the
future,
where
we
can
think
about
configuring,
our
Ingress
traffic
with
the
same
you
know,
with
the
same
kind
of
core
building
blocks
as
our
mesh
traffic
and
configure
the
policies
in
the
in
the
same
way,
and
that
wasn't
something
that
I
had
thought
was
really
going
to
be.
You
know
a
possibility,
but
it
seems
like
it's
in
it's.
E
It
is
a
possibility
now
and
I
think
that
would
be
really
great
for
for
users,
because
at
least
from
my
experience
like
one
of
the
hardest
parts
of
kubernetes,
is
just
the
fact
that
you
have
all
these
configuration
objects
that
all
have
their
own
semantics
and
you
have
to
like
figure
out
how
to
you
know,
make
that
work,
and
this
is
why
people
complain
about
like
oh
I'm
spending,
all
my
life
in
yaml.
Now
you
know
it's
not
really
yaml's
fault.
It's
just
like
this
is
a
mechanism
by
which
we,
you
know
you.
E
You
have
kubernetes
power
at
your
disposal
right
and
so
getting
that
getting
that
right
and
having
a
an
API
that
you
know
can
both
span
the
full
breadth
of
use.
Cases
that
you
need,
plus
it
makes
sense
and
like
kind
of
has
these
logical
building
blocks
really
really
really
really
important,
yeah
and
and
yeah
again,
I.
Think
Gateway.
Api
is
awesome
as
an
example
that.
A
Nice,
so
one
other
Trend
that
we've
heard
at
the
conference
this
year
and
we
heard
about
it
at
service
metricon
Europe
is
sort
of
the
sidecarless
model
for
service
meshes,
I.
Think
actually,
just
before
this
we
heard
from
Ice
surveillance
about
psyllium
and
the
way
that
they're
doing
sidecar
lists.
We've
also
had
a
few
sessions
on
istio's
new
ambient
mode.
That
is
sidecarless.
So,
what's
the
motivation
behind
these
models
and
is?
Is
it
really
still
a
service
mesh
with
outside
cars?.
D
D
D
That's
one
huge
Trend
we
see
with
these
Geo
users
is
that
they,
you
know,
we
release
CV
fixes
and
then
users
don't
actually
upgrade,
because
it's
too
painful
right,
that's
not
something
that
you
see
as
often
with
say
your
Ingress
Gateway,
because
you
can
do
a
rolling
restart
and
you
know
kind
of
gradually
deploy
it
out.
It
doesn't
impact
their
applications
at
all.
D
So
you
know
some
other
things:
the
cost
every
pod
now
has
this
sidecar
process
running
which,
even
if
it
happened
to
be
using
almost
no
resources,
you
certainly
have
to
request
some
resources
for
it,
which
has
some
overhead.
So
we
often
see
a
lot
of
if
not
CPU,
usage,
CPU
and
memory
requests
that
are
just
burning
through
users.
Budgets
I
mean
the
list
goes
on
right,
there's,
there's
all
sorts
of
issues
we've
uncovered
with
sidecars.
E
E
No
no
I
mean
no.
That
also
seems
right,
like
you
know,
I.
So
there's
another
thing:
I've
written
a
Long,
blog
post.
You
know
outlining
all
my
complaints
and
opinions,
but
you
know
I
sidecars
have
a
lot
of
problems
and
there's
a
lot
of
you
know
kind
of
annoyances
that
you
have
to
go
through
to
navigate
them.
You
know
of
which
you
mentioned
a
couple.
You
know
the
fact
that
pods
are
immutable
in
kubernetes.
If
you
want
to
upgrade
your
sidecar
well,
you
got
to
roll
the
whole
Bond
and
and
so
on.
E
I
believe
that
the
sidecar
model
is
still
the
best
model.
From
the
perspective
that
I,
you
know,
I
am
most
interested
in
which
is
kind
of
the
operational
Simplicity
one,
because
it's
the
one
that
has
really
understandable.
It's
the
one
where
it's
very
clear.
You
know
what
component
maps
to
what
and
especially,
as
you
start
getting
into
the
world
of
like
zero
trust
security
and
all
that
stuff,
where
you're
trying
to
enforce
everything
at
the
most
granular
level,
you
have
a
very
clear
model.
It's
like
here
is
the
side
car.
E
It
enforces
policy
and
TLS
for
this
pod.
It
contains
the
secret
for
that
pod
and
everything
is
very
straightforward
from
there.
So
I
don't
want
to
Discount.
The
utility
of
you
know:
non-side
car
approaches,
at
least
from
the
ambient
perspective,
which
I
believe
preserves
the
security
things
that
I
like
about
the
sidecar
model,
but
I
think
given
the
Simplicity
and
given
the
fact
that
I
you
know
these
warts
will
largely
be
well.
You
know,
maybe
it's
me
being
optimistic,
I
think
a
lot
of
these
words
will
be
fixed
by
kubernetes.
At
some
point.
E
You
know
we'll
figure
out
how
to
do
startup
ordering
you
know
ordering
and
like
all
that
other
stuff,
you
know
I
I've,
looked
at
the
options
and
you
know
I'm
I
continue
to
be
a
fan
of
the
sidecar
model
and
we
continue
to
push
that
forward.
You
know,
with
kind
of
the
underlying
difference,
maybe
being
that
we've
been
spending
all
this
time,
trying
to
make
our
side
cars,
small
and
fast
as
possible
to
reduce
the
impact
of
the
extra
resource
usage
and
and
so
on.
E
So
it's
I
think
this
is
a
I
think
it's
an
interesting
conversation
to
have
because
it's
a
it's
a
there
are
a
set
of
engineering
and
security
trade-offs
that
you're
making
at
every
step
here
and
I.
Don't
you
know
as
much
as
I'd
like
to
say
that's
you're,
wrong
and
I'm
right,
because
that's
you
know
what
I'd
love
to
say:
I,
don't
think!
That's
really
the
case
I
think
it's
a
lot
more
nuanced
than
that.
A
A
A
E
Oh,
you
really
want
to
hear
about
this.
Okay,
so
you
know
I
think
the
best
way
to
deliver.
If
you
really
don't
want
to
see
the
side
car
like
I
can
just
hide
the
sidecar
from
you.
Okay,
so
like
I,
can
give
you
a
cube
cuddle.
If
you
want
sidecar,
let's
link
ready
I
can
deliver
a
cube
cuddle.
You
know
that
just
like
removes
Linker
D
from
the
output
and
in
fact
we
can
use
ebpf
to
do
this,
and
then
you
get
the
best
of
both
worlds.
So
we
can
have
Cube
cuddle.
E
You
know,
do
the
string,
manipulation
in
kernel
land,
which
is
incredibly
fast
and
efficient
and
bypasses
all
the
network
Hops,
and
we
can
harness
the
true
power
of
ebpf
and
then
you
get
the
best
of
both
worlds.
You
have
the
sidecar
model
under
the
hood,
but
you
never
have
to
see
the
fact
that
you
have
a
sidecar.
E
C
But
yeah
you
know,
thinking
about
side,
cars
and
shot
car
lists.
I
actually
have
kind
of
this.
This
Vision
I
like
to
see
for
for
service
smash
where
things
are
even
more
transparent.
You
know
service
mesh
took
off
as
being
a
transparent
proxy.
You
put
your
sidecar,
you
inject
your
side,
car,
you
use
the
same
URL
and
then
the
magic
just
happens.
You
got
traffic
splitting
you
get
metrics
and
it's
just
it
just
works,
but
you
know
at
open
service
mesh.
C
We
weren't
talking
to
a
lot
of
our
customers.
What
we're
actually
seeing
is
that
a
lot
of
the
you
know.
You
often
hear
the
term
like
ownership,
cost
cost
of
ownership
a
lot
of
our
users.
Our
customers
are
saying
even
still
like,
where
we
just
want
ntls.
You
know
we
just
want
encryption
and
we've
driven
to
try
to
make
osm
as
simple
as
possible,
but
I
can't
help
but
feel
that
there
is
an
easy.
C
C
No,
no
the
the
identity
can
come
from
something
hosted.
The
the
you
know
something
in
your
cluster
takes
care
of
all
that,
and
you
don't
have
to
see
it.
You
don't
have
to
worry
about
your
application
container
restarting
and
like
I,
said
sidecar
list.
Is
it's
attractive
to
me
because
of
how
it
aligns
with
that
Vision?
But
you
know,
there's
you
know
so
many
different
ways
to
skin
the
proverbial
cat
and
I'm.
B
E
Okay,
I
just
want
to
respond
to
Keith
Keith's
point,
because
you
know
we
also
see
that
right.
We
see
a
lot
of
people
who
are
coming
to
Lincoln
and
they're,
like
you
know
what
you
know
I'm
like.
Why
are
you
doing
this?
Oh
okay,
because
we
want
mtls.
You
know
we
need
encryption
of
traffic
and
trans
and
they're
a
lot
they're
like
apologetic.
They're,
like
you
know,
I
know,
linguity
has
all
this
other
cool
stuff,
but
like
this
is
all
we
need
and
I'm
like.
E
Well,
if
you
just
care
about
encryption
in
transit,
like
you
know,
just
you
know,
ipsecur,
like
you
know
like
you
can
do
this,
you
don't
need
a
service
much
for
any
of
this.
If
you
dig
in
what
we
find
is
often
you
know
they're
using
encryption
and
kind
of
like
this
very
loose
word
where
like
well,
we
don't
just
want
encryption.
We
want
like
policy
right
and
we
want
policy
at
like
the
layer,
seven
level
and
and
stuff
and
so
like
once
you
start
unwinding
what
they
actually
want.
It
gets
much
closer
to.
E
Oh,
this
is
something
that
we're
going
to
have
to
solve
in
layer,
seven
one
way
or
another
than
just
like.
Oh,
we
can
slap
ipsec
on
it
and
like
hey,
everything's,
encrypted
The
Regulators
are
are
happy
or
whatever,
so
you
know
often
I
find
we
have
to
kind
of
educate.
You
know
some
of
the
would-be
adopters
like
MTL.
If
all
you
really
care
about
is
encryption
and
like
that's
it
like
mtls
is
total
overkill.
E
A
So
you
all
talked
a
lot
about.
You
know
the
sort
of
operational
burden.
How
should
users
be
thinking
about
the
total
cost
of
ownership
of
a
service
mesh,
not
just
onboarding,
but
all
through
the
life
cycle
of
their
adoption?
How
do
they
compare
and
contrast?
How
do
they
prepare
for
a
total
cost
of
ownership?
And
what
do
you
all
do
to
help
mitigate
the
total
cost
of
ownership
for
your
users.
B
Yeah
so
I
think,
when
I
think
about
total
cost
of
ownership.
That
includes
things
like
operating
your
service
mesh
scale
upgrades.
How
does
it
fit
with
how
your
organization
is
structured
and
so
I
guess?
One
example
of
that
is
that
when
you
install
a
service
mesh,
you
have
a
bunch
of
Secrets
and
certificates
that
are
associated
with
it
and
I
guess.
B
The
default
kind
of
thing
for
managing
those
Secrets
now
is
is
to
use
kubernetes
secrets,
and
maybe,
if
you're
in,
like
a
multi-cluster
setup
or
something
right
or
you're
federating
those
then
you're,
copying
kubernetes
secrets
from
one
cluster
to
the
other
and
I
guess.
One
way
that
that
console
kind
of
helps
with
with
that
problem
of
Secrets
management
is
is
just
by
having
a
tight
integration
with
with
vault,
which
is
an
open
source
tool
for
managing
your
credentials
securely.
B
C
So
if
you
want
to
use
a
service
mesh
and
you
want
Canary
deployments,
there
are
lots
of
ways
to
do
that
wrong,
not
not
necessarily
wrong,
but
lots
of
ways
to
do
that.
That
aren't
up
to
say,
quote
unquote.
Industry
standard
I
did
a
talk
a
couple
months
ago,
walking
through
kind
of
evolution
of
networking
and
kubernetes,
and
you
know
the
the
one
of
the
points
that
I
made.
C
That
I
think
is
applicable
here
is
that
organizations
have
to
make
decisions
based
on
their
problems,
based
on
the
things
they're
trying
to
accomplish
whatever
it
is
they're
trying
to
solve
now.
Nowadays,
if
you
want
a
some
some,
a
production
ready
service
in
the
cloud
that
looks
very
much
like
the
way
that
giant
Cloud
providers
giant
companies
deploy
their
software,
and
that
means
you've
got
the
complexity
of
those
giant
companies,
but
you
might
not
have
the
resources
for
that
and
so
for
a
service
mesh.
C
C
C
What's
going
on
to
be
involved
in
open
source,
which
I'm
always
an
advocate
of
having
come
from
a
back
end
from
for
an
end
user
company,
but
I
would
just
say
kind
of
beware
and
as
much
as
all
of
us
and
our
respective
projects
can
try
to
simplify
things,
there
is
an
inherent
cost
to
running
something
and
getting
some
of
these
features
so,
and
software
sucks
yeah
in
a
lot
of
ways.
I
think
yeah
software
sucks.
So
you
love
it.
You
hate
it.
D
Yeah
I
mean
obviously
from
our
perspective,
as
you
know,
developers
of
service
meshes.
You
know
we
try
and
chip
away
at
the
friction,
points
that
users
hit.
You
know
small
issues
to
big
issues
like
the
kubernetes
cap,
Gateway
API
ambient
those
types
of
things,
but
there's
also
you
know
the
burden
on
the
user.
There's
never
going
to
be
a
service
match.
That
I
would
imagine
that
you
just
press
a
button
and
you
never
have
to
think
about
anything
at
all
about
how
a
service
mesh
runs
or
what
it
does
right.
D
You
have
to
have
some
level
of
knowledge
of
what's
going
on
in
the
system,
just
like
you
do
with
kubernetes
or
even
Linux,
or
you
know
whatever
you
look
at
that
you're
running,
so
my
recommendation
would
be
to
digest
it
slowly.
Right,
there's
no
need
to
go
use
all
14,
East,
Geo,
custom
resources
on
your
first
day
right
most
users
are
adopting
service
mesh
for
some
particular
reason.
Maybe
they
want
Ingress
start
with
Ingress,
add
sidecars
later
as
you
need
them,
or
maybe
they
won't
until
us.
E
E
Yeah
I'm,
all
on
the
managed
service
mesh
train
I
think
that
the
number
one
cheapest
way
to
actually
operate
a
service
mesh
in
production
is
to
use
a
managed
solution.
Not
coincidentally
I
also
sell
a
managed,
Linker
D
solution,
which
I
highly
recommend
that
you
adopt
immediately
and
come
see
me
after
this
talk
and
I'll
tell
you
it's
extremely
expensive,
but
it's
awesome.
E
It's
funny
because
you
know
we
kind
of
we
pick
it.
You
know
we
pick
on
istio
all
day
and
we
talk
about
you
know,
hey
Linker
be
faster
and
Linker
is
lighter
and
like
latency
is
lower,
and
you
know
I
like
doing
that,
just
because
I'm
kind
of
a
mean
person,
and
also
because
it's
true,
but
at
the
end,
at
the
end
of
the
day,
like
what
we
find
is
that
that
stuff
doesn't
really
matter
to
you
know
the
people
who
are
adopting
Lincoln.
They
don't
really.
E
E
Kind
of
factor
in
here
is
the
humans
that
you
have
to
dedicate
to
that,
and
you
know,
of
course
we
try
and
make
Linker
to
you
as
simple
as
possible,
and
you
know
a
Simplicity
for
me
is
just
like
really.
You
know,
like
long
conversation
about
simple
versus
easy
and
You
Know,
Rich
hickey
and
like
all
this
stuff-
and
you
know
a
lot
of
how
linkerty
has
been
has
been
designed
is
with
that.
You
know,
philosophy,
kind
of
consciously
in
mind.
E
It's
also
why
we're
adopting
the
Gateway
API,
like
you,
know
those
if
those
crds
are
going
to
be
on
your
cluster
anyways,
okay,
you
know.
Well,
now
you
don't
have
to
learn.
We
don't
have
to
introduce
anything
new,
so
like
you're
kind
of
like
sticking
to
kubernetes.
As
you
know,
surface
area
as
much
as
possible,
but
at
the
end
of
the
day,
like
human
beings,
are
like
the
expensive
and
and
horrible
parts
of
this.
So
reducing
you
know,
the
amount
of
humans
involved
is.
A
E
A
I'm,
sorry,
you
already
went
I've
lost
track,
so
each
of
you
touched
on
when,
in
terms
of
total
cost
of
ownership,
sort
of
power
and
simplicity
of
service
mesh
across
the
board,
regardless
of
which
product
you're
talking
about.
How
do
you
go
about
balancing
those
things
for
your
users,
giving
them
something
that
is
powerful
but
simple
enough,
that
they
maybe
can't
shoot
themselves
in
the
foot
with
it?
E
D
D
D
So
you
know
once
you
have
a
proxy
there's
a
tendency
to
want
to
put
everything
that
you
could
possibly
ever
want
to
do
there
right.
It's
like
oh
I,
know
I,
just
compile
my
entire
application
of
wasm
and
put
it
in
the
proxy
right
as
an
extreme.
But
you
know
we
have
to.
You
know,
draw
boundaries
like
do
we
want
to
be
a
full-fledged
API,
Gateway,
probably
not,
but
someone
out
there
does
and
they
should
do
that,
and
then
we
should
integrate
with
them
right.
D
You
know:
we've
done
similar
things
with
the
ambient
magic,
where
we're
splitting
out,
like
The
L4
encryption
layer
from
the
L7
processing,
those
sort
of
things.
So
it's
really
not
about,
like
restricting
you
know,
features
and
that
sort
of
thing
to
provide
Simplicity
but
having
different
layers
that
users
can
choose
like
at
what
layer
they
need
to
solve
their
problem
at
so
that
they
don't
need
to
digest
everything
at
once.
And
you
know
one
product.
C
When
you
are
talking
about
balancing
power
and
simplicity
for
for
those
of
us
who
like
to
use
Envoy
as
a
proxy,
it's
darn
complicated.
It's
it's
pretty
difficult
to
go
and
program.
That's
why
mentions
do
that,
for
you
at
least
on
by
basement.
Just
do
that
for
you
and
so
I
I
think
that's
a
model
to
think
about.
Moving
forward.
If
meshes,
you
know,
kubernetes
provides
one
level.
One
layer
of
you
know
functionality
then
maybe
onward
products
another.
C
But
then
mesh
is
an
interface
for
that
and
by
doing
this
work
out
in
the
open
by
creating
extensible,
flexible
apis
I
think
we
paved
the
way
forward
for
people
to
come
after
us
and
to
add
more
layers
on
top
of
that
Gateway
API
gamma
is
is
one
area
where
I
think
that
happens.
It
was
it's
often
to
be
to
be
part
of
SMI
as
well
and
and
see
things
like
Argo,
rollouts
and
Flagger
built
on
top
of
that
to
provide
Progressive
delivery.
I
think
I
saw
Flagger,
announced
Gateway
API
support.
B
Yeah
I
think
yeah
when
I,
when
I
was
thinking
about
power
and
simplicity,
I
feel
like
yeah
across
many
missions.
We're
seeing
this
kind
of
shift
and
focus
on
on
making
it
easier
to
use
like
a
lot
of
them
have
really
powerful
features.
At
this
point,
and
so
I
think
a
lot
of
it
will
just
be
like
continuing
to
look
back
at
the
models
that
that
we've
built
and
and
rethink
them
and
and
iterate
on
them,
and
so
yeah
like
I,
guess.
B
E
So
the
question
was:
how
do
you
balance
features
and
and
simplicity,
yeah,
so
I,
you
know,
I
think
it's
probably
one
of
the
core
questions
of
of
any
kind
of
software,
not
just
the
service
mesh
you
know
or
like
you,
don't
want
to
end
up
with
like
the
worst.
Is
you
end
up
with
like
a
leaky
abstraction
where
you
know
you're
describing
this
beautiful
model?
E
E
How
do
we
make
this?
You
know
feel
and
smell
as
much
like
kubernetes
as
possible.
You
know
so
when
you're,
when
you're
learning
it
you
can
at
least
kind
of
relate
it
to
all
these
other
things
that
you've
just
absorbed-
and
you
know
there's
like
so
many
nuances
in
how
you
in
how
you
do
that,
but
I
think
for
us.
That's
that's
been
kind
of
the
principle
is
make
this
make
this.
E
You
know
stick
as
tightly
as
possible
to
the
surface
area
of
kubernetes,
make
it
feel
and
smell
like
the
rest
of
kubernetes,
and
of
course
you
know
as
soon
as
you
get
outside
of
kubernetes
and,
like
things
start
breaking
down
right
and
then
you
know
like
you,
don't
really
necessarily
have
that
to
to
to
to
rely
on.
So
it
only
takes
you
so
far,
but
at
least
within
the
context
of
the
cluster,
we
can
give
it
to
you
in
like
familiar
terms.
E
So
that's
kind
of
like
the
configuration
side
and
there's
also
the
operational
side,
which
is
like
okay,
I'm
now
I'm
running
ten
thousand,
you
know
linkery
proxies
or
ten
thousand
envoys.
You
know
what
is
that
like
how
much
tuning
am
I
doing
and
how
much
you
know
how
much
do
I
have
to
become
an
Envoy
expert
to
do
this
versus
an
issue
expert,
how
much
to
become
a
link
or
D
proxy
expert
versus
a
Linker
expert
and
that
you
know
I,
don't
know
that
there's
a
good
solution
there.
You
know
I,
think
that's!
E
E
Oh,
it's
just
a
magical
thing
and
like
I,
don't
really
know
what's
going
on
here,
because
that's
when
you
get
into
like
the
dark
territory
of
like
I,
don't
know
we'll
just
try
rebooting
it
and
see
if
it
works
any
better
right
like
yes,
that's
an
approach,
but
it's
not
like
the
good
approach.
So
it's
all
to
say:
I,
don't
know
man.
This
is
really
hard.