►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Wrap Up of Sessions & Panel Discussion Louis Ryan, Prajakta Joshi, Google & Thomas Pampelberg, Buoyant
A
B
I
actually
know
every
actual
that
was
probably
the
one
I
enjoyed
the
most.
You
know
I
I
kind
of
live
eat
and
breathe
service
mesh,
and
so
it
was
just
really
interesting
to
hear
kind
of
three
different.
You
know
implementers
of
service
mesh
agree
on
so
many
things
so
vehemently,
so
that
was
you
know.
That
was
definitely
a
highlight
for
me,
covering
you
know.
B
B
A
Yeah,
I
I
think
that's
something
that
we've
all
been
trying
to
achieve
with
kubernetes
and
service
mesh
is
kind
of
the
next
step
that,
like
common
environment,
the
idea
that
they
are
taking
service
mesh
and
getting
it
into
satellites
and
fighter
jets
and
normal
deployments
is
like
one
of
the
coolest
things
for
me,
because
you
get
this
like
common
api
that
you
can
then
build
on
top
of
really
exciting.
You
know,
as
we
start
to
get
this
like
cloud
native
world,
where
the
cloud
isn't
just
an
aws
data
center
anymore.
A
It
highlights
something
that
I
think
is
awesome
about
service
mesh
that
we
don't
spend
a
lot
of
time.
Talking
about.
Is
that
a
lot
of
where
we
are
today
as
a
community
is
building
out
the
primitives
that
you
can
go
build
on
top
of
like
with
service
mesh
interface
and
traffic
split?
There's
some
awesome
primitives
that
you
can
go
do
things
with
that?
A
A
B
C
And
actually
I
was
not
psy.
I
was
not
silent
by
design,
it
was
just.
My
stuff
was
echoing
a
lot,
but
now
that
we
got
that
fixed,
I
do.
I
was
actually
excited
to
see
a
whole
bunch
of
new
talks.
I
think
I
mean
both
of
you
made
great
points.
The
reason
I'll
tell
you
the
motivation
for
doing
the
telco
talk
in
the
first
place.
Traditionally
we
always
assume
telco
edge
enterprise.
These
are
very
different
things
and
we
treat
them
like
individual
silos
and
I
have
half
my
background.
C
C
Sometimes
the
starting
points
might
be
different
and
sometimes
the
technologies
might
be
slightly
different,
but
when
we
really
talk
service
mesh
like
today
in
my
slide,
for
example,
I
had
about
12
plus
implementations,
including
kelsey
service
mesh,
and
that
is
just
half
ingest,
but
I
think
the
key
part
is
that
service
mesh
is
here
to
stay.
That's
that's
what
all
these
implementations
show.
C
That
is
the
the
paradigm
has
to
adapt
to
the
use
case
and
not
the
other
way
around.
So
I
think
it
just
showed
to
me
also
another
thing
that
we
need
to
keep
expanding
the
bounds
of
what
service
mesh
isn't
us,
and
so
that
was
the
motivation
behind
doing
the
talk,
and
I
just
wanted
to
add
actually
my
observation
on
the
other
talk
which
was
done
from
by
eriksson,
and
this
was
gabor
who
was
doing
the
gabor
ratwari
from
eriksen.
C
I
was
actually
excited
to
see
because
he
picked
up
a
really
legacy
thing,
which
is
the
session
border
controller.
It
is
as
legacy
as
you
can
get
in
some
ways.
He
picked
up
a
protocol
that
is
not
http
based,
so
he
picked
up
rtp
over
udp
and
then
he
started
laying
out
how
you
know
we,
when
we
look
at
it
from
a
cloud
native
lens,
we
are
seeing
everything
http
websocket,
grpc,
based
that
is
not
the
real
world
in
telco.
So
how
do
we
bridge
these
things?
Then?
C
He
talked
about
the
profile
like
one
is
long
waited
one
is
short-lived
talked
about
kpis,
but
then
he
went
back
to
the
commonness,
which
is
service.
Mesh
is
nothing
but
separating
control
and
data
plane
of
services,
and
then,
if
we
can
figure
out
how
to
bridge
some
of
these
nuances
every
bit
of
what
we
talk
about
in
service
mesh,
whether
it's
traffic
control,
whether
it's
security,
whether
it's
observability
scale
out
all
of
those,
are
equally
relevant
and
obviously
a
lot
more
work
to
be
done
there.
But
I
was
super
excited
to
see
that
talk.
A
Me
too,
in
fact,
we
haven't
implemented
it
yet
in
linker
d,
but
by
far
the
two
most
exciting
protocols
that
I
want
to
see
are
mysql
and
kafka
so
that
you
bridge
this,
like
traditional
http
microservices
world,
into
a
bunch
of
different
paradigms,
because
in
the
end
we're
all
trying
to
solve
the
same
problem.
It
just
happens
that
protocols
are
unique
to
our
problem
spaces,
which
is
a
pretty
cool
way
to
look
at
it.
B
Oh,
my
od
is
a
bit
laggy
yeah
I
mean,
I
think
you
know.
Http
is
obviously
the
kind
of
early
sweet
spot
for
meshes
right.
It's
it's
the
most
widely
used
protocol.
It's
the
protocol,
that's
most
used
by
the
people
that
we
targeted
first
right,
kubernetes
users,
building
kind
of
distributed
apps
and
they
kind
of
microservices
paradigm
right,
http,
rest,
json,
grpc
and
things
like
it
will
dominate
there.
But
yeah
I
mean
my
sql
kafka.
B
You
know,
you
know
other
kind
of
database
protocols.
You
know
postgres
jdbc
right.
This
is
a
very,
very
long
list.
A
lot
of
these
protocols
have
a
lot
in
common
right.
There
are,
generally
speaking,
only
a
few
different
shapes
of
protocols
out
there
you
know
kind
of
command
body,
oriented
ones,
things
that
have
are
more
resource
oriented
and
then
almost
all
of
them
have
headers
of
some
form.
B
It's
an
interesting
design
challenge,
and
it
you
know
it's
not
something
that
we've
shipped
or
made
a
ton
of
progress
on,
but
it's
something
that
I
I
think
about
a
lot.
If
I
look
at
the
kafka
protocol
or
I
look
at
stomp
or
something
else
right,
I
see
a
lot
of
similarities
between
that
and
other
protocols
that
we
have
pretty
good
support
for
and
if
you
look
at
a
lot
of
the
http
routing
stuff
that
exists,
a
fair
amount
of
it
is
pretty
generalizable
to
other
protocols
right
match.
B
Headers
with
regex's
prefix
suffix
match
path
is
just
really
a
special
type
of
header.
Query.
Params
are
headers
passed
in
something
else
right.
It's
pretty
easy
to
come
up
with
generalizations,
but
I
think
that
would
be
an
interesting
space
and
if
we
lay
the
foundation
for
that
pretty
well,
then
you
know
it
might
be
easy
to
expand
the
universe
of
supportive
protocols
pretty
quickly
and
those
same
things
apply
to
policy
and
telemetry
right
those
same
kind
of
sets
of
attributes.
B
A
Oh
100
percent
me
too,
and
it's
it's
always
the
trade-offs
there
in
particular.
That
like
do
you
want
to
how
general
can
you
get
before
you
start
losing
fidelity
like
you,
don't
want
to
do
something
that
is
a
hundred
percent
unique
just
to
kafka,
because
there
are
general
generic
important
abstractions.
A
You
can
pick
there,
but
on
the
other
side
you
don't
want
to
lose
all
of
the
important
information
that
you
get
out
of
that
like,
if
you
start
talking
about
policy
policy
that
I
would
love
to
write
someday
is
the
ability
for
limiting,
select
statements
on
mysql
at
the
service
mesh
level,
which
is
a
pretty
interesting
like
super
unique
integration
with
the
actual
protocol,
but
like
how
do
you
make
sure
that
the
extensibility
is
there
without
actually
having
to
do
a
special
implementation?
Each
time
I.
A
B
About
that,
the
other
canonical
example,
I
hear
is,
you
know,
send
select,
requests
to
read
replicas
of
my
sequel
and
send
inserts
and
updates
to
the
master
right.
I
think,
there's
a
pretty
you
know
lots
of
people
who
scaled
out
sql
have
written
proxies
to
do
just
that.
So
those
are
super
powerful
use
cases.
C
Actually,
I
would
add,
because
I
mean
just
adding
to
what
you
were
saying
thomas-
we
see
you
know
there
are
these
requirements
for
customization
and
I
think
christian,
who
did
the
talk
from
solo.I
o.
He
called
out
several
of
those
needs,
including,
for
example,
you
need
new
wire
protocols
or
you
want
your
own
custom
metrics
or
maybe
you
want
to
implement
custom
security
exchanges,
maybe
because
you've
not
upgraded
lots
of
things
around
here.
Header
message,
transformation,
firewalls
and
so
on
so
forth.
I
think
wasm,
custom
filters.
C
This
level
of
customization
is
also
important
to
help
vendors
of
products
plug
in
to
things
without
really
going
and
touching
the
core
framework
of
a
service
mesh
paradigm
right.
So
it
gives
them
a
way
to
put
in
their
proprietary
stuff
in
a
way
that
we
preserve
the
paradigm
and
what
it
stands
for
and
also
preserving
a
lot
of
the
openness
that
comes
from,
for
example,
following
an
xps
protocol
for
talking
to
envoy.
So
to
me
that
was,
I
think
it
is
a
very
key
area.
C
It's
relatively
new,
but
I
was
excited
to
see
their
demo.
It
was
pretty
nice
and
then
he
talked
about
the
web
assembly
hub,
which
was
an
interesting
concept.
I
think
it
was
about
the
community
coming
together
to
share
stuff.
Broadly,
I
think
wasm
will
open
up
use
cases
that
we
would
have
normally
otherwise
struggled
to
implement.
Obviously,
we
need
to
make
sure
we
make
it
production
grade
and
we
all
put
resources
into
it,
but
it's
a
great
area
for
the
community
to
collaborate
on
as
well
louie.
B
B
They
certainly
acquired
a
number
of
companies
in
that
space
over
the
course
of
the
last
18
months.
I
think
so
clearly,
that's
an
important
thing
for
them
to
be
able
to
bring
that
portfolio
into
their
service
mesh
product,
and
it
looked
at
least
from
the
diagram
that
they
were
going
to
think
may
be
thinking
about
using
web
assembly
to
do
it,
so
that
was
kind
of
exciting.
B
A
I
think
this
actually
loops
back
to
mitch
and
my
talk
as
well
in
that
wasm
also
really
provides
us
as
service
mesh
implementers.
A
really
unique
tool
to
keep
our
service
meshes
light
and
fast,
because
when
users
who
have
totally
valid
user
requests,
come
and
ask
for
something,
that's
very
specific
to
their
environment,
we
can
say:
hey,
you
know,
that's
a
really
awesome
user
request.
Why
don't
you
implement
it
in
wasm
yourself?
A
This
isn't
something
that
needs
to
go
into
the
core
service
mesh
and
potentially
reduce
security
or
increase
the
amount
of
tests
and
all
the
rest
of
that.
Because
it's
a
small
plugable
piece.
We
have
a
lot
more
freedom
in
what
the
service
mesh
does
and
doesn't
and
being
able
to
define
that
which
is
also
super
exciting.
C
C
I
would
say
all
of
your
conversation
like,
for
example,
mitch
brought
up
the
whole
issue
of
istio
control,
plane,
simplification
and
you
said
an
interesting
thing
where
service
mesh
is
not
really
about
technology.
It's
about
people
that
really
resonated
with
me.
It's
really
about
that.
Obviously,
we
need
to
make
things
more
simpler,
but
broadly,
it
is
really
about
solving
that
problem.
C
And
then
I
like
the
fact
that
console
sabine
from
console
came
up
with
a
different
angle
around
how
they
didn't
want
to
be
an
apm
product
and
then
how
they
went
about
it,
and
I
think
I
saw
the
theme
around
wasm
in
all
of
your
conversations
as
well.
It
seems
that
you
folks,
are
also
putting
a
lot
of
emphasis
on
the
user
experience
and,
I
think,
broadly
as
a
community
in
our
own
open
source,
as
well
as
managed
implementations.
C
We
should
keep
that
in
mind
and
then
I
think
there
were
some
lots
of.
There
was
a
lot
of
mesh
humor.
I
should
say
I'm
going
to
steal
some
of
those
lines,
but
I
really
like
the
three
perspectives.
So,
for
example,
when
there
was
an
issue,
you
know
how
does
istio
deal
versus
it
with
it
versus
console
versus
linker
d,
and
I
think
you
spoke
about
taps
and
wire
sharks
and
so
on
so
forth.
B
C
Just
I
just
love
that
talk
from
the
for
the
fact
that
I
think
we
spend
too
much
time
thinking
about
how
different
we
are.
I
love
the
fact
that
you
brought
three
different
perspectives
and
you
raise
some
really
good
issues
that
all
of
us
across
the
board
can
use
and
bring
into
our
own
implementation.
So
so
just
thank
you
for
that
talk
louis.
I
know
you
you.
A
I
was
gonna
say
you
bet.
I
think
I
think
the
fun
thing
for
me
is
how
much
we
end
up
riffing
on
each
other,
like
a
really
great
example,
is
the
original
istio
in
it
container
code
we
borrowed
heavily
on
the
linker
d
side
of
things
and
now
istio
has
gone
and
picked
up
a
lot
of
our
czech
infrastructure,
which
is
great,
like
it's
super
fun
for
me
being
part
of
the
ecosystem.
A
Just
to
see
when
you
do
something,
that's
really
great,
everyone
goes
and
picks
it
up
and
adopts
it
and
that's
awesome.
It
makes
me
so
happy
because
we
can
go
and
pick
the
things
that
are
unique
to
us
and
go
double
down
on
that
and
have
the
rest
of
the
community
build
out
really
great
solutions
that
work
for
everybody.
C
B
Yeah
I
mean,
I
think,
there's
there's
a
transition
going
on.
I
think
right.
It's
kind
of
this,
this
crossing
the
chasm
moment,
because
the
kind
of
proof
of
that
was
that
there
were
talks
by
people
who
had
gone
through
real
deployment
struggles,
persisted
become
familiar
with
the
tools
and
gotten
real
demonstrable
value
from
the
deployment.
B
B
I
think
we're
getting
to
the
point
where
there's
enough
critical
mass
of
people
who
understand
the
value
that
are
able
to
bring
that
value
into
their
organization
and
explain
it
to
other
people
who
don't
necessarily
understand
it.
Yes,
but
when
they
can
show
the
value
in
the
context
of
their
own
business
right.
B
B
A
Almost
almost
a
theme
that
we
had
from
today
is
this:
like
real
world
use
cases
that
are
concrete,
you
know
talking
about
telco
and
the
interesting
unique
problems
that
comes
from
that
and
why
a
common
service
mesh
pattern
can
work
there.
The
machine
learning
and
you
know
making
something
that
maybe
was
originally
just
for
microservices
work
there
and
going
through
the
hero's
journey
and
figuring
out
how
to
have
it
all
fit
together.
The
multi-cluster
talk
was
fantastic.
C
Basis
yeah,
I
think
I
mean
I
would
just
echo
that
great
great
points,
and
I
think
maybe
you
know
what
we
should
do.
We've
got
five
minutes,
maybe
recap
our
takeaways
of
the
day.
I
think
it
would
be
great
also
later
to
talk
to
folks
over
chat
and
see
what
they
thought
of
the
day.
But
I'll
just
summarize
mine-
and
I
do
think
I
mean
you
touched
on
one
of
the
talks
we
didn't
necessarily
dive
into,
but
multi-cluster
is
important
and
in
fact
everything
is
important,
multi-platform,
multimedia
and
multi-group.
C
I
think
broadly.
There
was
one
interesting
thing
for
today,
which
is
certainly
smash.
Everybody
agrees
to
reducing
complexity
of
applications,
but
I
think
each
one
of
us
needs
to
manage
the
complexity
of
the
service
mesh
implementations
themselves.
So
we
need
to
work
on
making
the
implementation
simpler
to
consume
and
we
should
think,
like
a
user
and
not
like
somebody,
who's
building
a
distributed
system
or
some
some
piece
of
infrastructure.
C
Debugging
was
another
theme
that
came
up
in
several
talks.
I
think,
for
example,
istio
seemed
to
be
the
flavor
of
the
day,
but
I
think
they've
also
lots
of
interesting
suggestions
about
doing
better
on
the
debugging
side.
Then
I
would
say
number
of
service
mesh
implementations.
I
think
the
market
will
decide
and
I
think
the
key
takeaway
for
there
is
service
meshes
here
to
stay.
We
need
to
make
our
thing
simpler,
better
security.
I
heard
the
last
statement
in
the
dod
talk
which
was
mesh
is
key
to
security.
C
I
would
say,
as
I
would
just
say,
as
a
community,
we
should
really
think
of
all
of
the
significant
collaboration
opportunities
that
surfaced
up
today.
Sometimes
I
feel
like
we
spend
far
far
too
much
time
talking
about
our
differences.
Not
so
much
about
the
things
we
could
do
together
and
I
think
the
latter
far
outweighs
the
former
and
I
would
say
we
should
keep
expanding
the
definition
of
mesh.
Let's
support
our
open
source
communities
like
esther,
kumar,
lincoln,
whatever
is
out
there.
Let's
go
support
that
and
I
think
you
know
for
us.
C
We
will
continue
to
bring
the
best
of
google
into
our
managed
solutions
like
traffic
director
and
the
service
measure
with
a
lot
of
humility,
because
we
are
also
learning
in
this
journey
from
all
of
you
from
customers.
So
we
look
forward
to
collaborating
and
with
that
I'll
hand
off
to
thomas
and
louis
would
love
to
hear
what
you
have.
What
you
took
away
from
the
day.
A
I'll
I'll,
actually
just
put
a
a
little
blurb
in
here,
which
is
we'd
love
to
work
with
everyone
in
service
mesh
interface
to
go
and
build
out
that
api
and
the
common
patterns
and
use
cases
there.
So
folks
want
to
jump
over
to
the
smi
slack
channel
and
chat
with
us.
There
show
up
at
our
community
meetings
would
love
to
work
with
expanding
out
what
those
apis
mean.
What
the
core
problems
that
service
meshes
solve
are,
and
you
know,
moving
that
discussion
forward
since
I'm
talking
I'll
give
my
two
cents.
A
Multi-Cluster
was
a
theme.
It
was
a
great
takeaway.
I
love
getting
together
and
hearing
again
the
use
cases,
what
everybody's
up
to
and
the
differing
perspectives.
It's
why
we
had
the
talk
that
we
did
to
chat
about
the
trade-offs
and
understand
it.
I
had
one
of
the
funnest
days
putting
that
together,
just
because
it's
so
much
fun
to
chat
through
how
all
the
pieces
fit
together
and,
like
I
have
so
many
blind
spots,
it's
fun
to
see
the
elephant
from
someone
else's
perspective
for
sure
louis.
How
about
you.
B
We
are,
you
know,
the
different
service
mesh
implementations
are
mostly
seeing
the
same
set
of
requirements
from
their
users.
There's
a
lot
of
commonality
there,
which
indicates
that
the
kind
of
base
set
of
features
that
service
meshes
present
are
pretty
well
entrenched.
Now,
in
the
minds
of
you,
know
the
potential
users
and,
to
some
degree
they're
looking
for
consistency.
B
It's
a
great
challenge
to
have
because
it
means
you
have
things
that
people
want
you
to
do,
but
it's
hard
to
get
right
and
we'll
probably
get
it
wrong
several
times
before
we
get
it
right.
Hd
has
already
had
a
couple
of
stabs
about
it
in
a
couple
of
different
ways
and
we've
learned
from
those
mistakes,
and
I
expect
that
we'll
keep
doing
that
and
we'll
see
which
patterns
the
industry
is
willing
to
accept
and
which
ones
it
isn't,
and
I
think
that's
going
to
be
a
big
part
of
2021.
B
B
C
C
So,
in
fact,
in
our
talk,
we
spoke
about
a
use
case
called
cap
grow
drain,
which
describes
this
exact
thing
like
how?
How
do
you
manage
your
vm
or
open
stack
based
deployments
and
your
kubernetes
deployments
by
using
the
service
mesh
layer
to
treat
them
more
consistently?
So
I
I
would
say
that
is
the
key
right.
We
should
not
assume
service
mesh
is
only
for
containers,
it
is
compute
agnostic.
It
should
work
on
containers,
vms
and
bare
metal.
B
Yeah,
I
just
wanted
to
thank
everybody
for
their
time
and
you
know
it's
always
good
to
be
involved
in
these
events.
I
I
know
it's
something
difficult
being
remote,
but
I
I
I
found
a
lot
of
the
content
very
informative.
It
was
great
to
see
some
of
the
dialogues
and
the
use
cases,
examples
of
user
perseverance
and
success
in
particular.
That's
always
heartwarming,
and
you
know
it's
an
opportunity
to
talk
to
peers
in
the
industry
and
folks,
I
don't
see
in
an
everyday.