►
From YouTube: Panel: Tales from the Edge: Is the Edge More Important Than the Service Mesh? - Matt Klein
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.
Panel: Tales from the Edge: Is the Edge More Important Than the Service Mesh? - Matt Klein, Lyft; Alyssa Wilk, Google; Lin Sun, IBM; & Bjorn Freeman-Benson, Ambassador Labs
The service mesh hype cycle is well and truly in effect, and almost everyone believes their organization needs a service mesh, even if some don’t fully understand the use case this technology covers. But what about the edge? Practically every Internet-based application needs to get traffic from users into backend services. Join this panel to learn about the importance of both use cases from a range of experts in the traffic management domain. Topics to be discussed include: - Opinions on the relevant importance of both the north-south (ingress) and east-west (service) traffic management use cases - Real-world adoption stories of cloud native proxies, such as Envoy - Experiences on migration to cloud native edge gateways - Tell-tale signs that an organization should consider adopting a service mesh (or not) - Technology choices in the edge gateway and service mesh space
https://sched.co/ekD6
A
B
Okay,
so
hi,
my
name
is
alyssa.
I've
been
at
google
for
about
13
years
working
on
the
gfe,
which
is
google's
front
line
proxy.
It
takes
in
all
of
google's
web
traffic
everything
from
gmail
to
ads
to
web
search.
So
it's
pretty
critical
bit
of
google's
infrastructure.
So
I
worked
on
that.
For
a
decade
I
launched
http2
at
google,
I
launched
http3
at
google,
and
then
google
got
interested
in
this
proxy
called
envoy,
and
I
was
kind
of
like
why
are
you
know
we
spent
a
decade
working
on
the
gfe?
B
You
know
why
envoy
and
started
playing
around
with
it
and
got
really
interested.
It's
just
a
beautiful
architecture.
It's
super
pluggable,
and
so
I
spent
the
last
three
years
working
on
envoy
both
trying
to
get
it
up
to
kind
of
the
google
level
cloud,
reliability,
standards
and
also
adding
features
and
becoming
a
senior
maintainer
along
the
way.
A
C
C
A
D
Thanks
for
having
me,
my
name
is
matt,
I'm
a
software
engineer
at
lyft,
where
I've
been
for
five
and
a
half
years.
These
days,
I
spend
about
half
of
my
time
leading
our
infrastructure
team
at
lyft,
so
things
like
networking
and
kubernetes
and
deploys
and
all
of
those
types
of
things,
and
then
I
spend
about
50
to
60
percent
of
my
time,
working
on
envoy
in
the
open
source
domain
prior
to
lyft.
D
I
was
at
twitter,
where
I
built
twitter's
edge
proxy,
so
that
was
actually
my
first
main
experience
with
the
edge,
and
you
know
having
that
experience
back
at
twitter
was
was
what
led
me
to
build
envoy
and,
of
course,
envoy,
is
used
in
a
whole
different
number
of
domains
from
service
mesh
systems
to
api
gateways.
So
my
my
experience
spans
all
those
domains.
A
B
Yeah
I
mean
I
would
say
that
that
any
migration
comes
with
migration
pain.
My
my
new
higher
project
at
giggle
was
launching
gfe2,
which
was
taking
the
proxy
handling
all
of
our
traffic
and
hot
swapping
it
to
any
proxy,
which
of
course,
you
know.
A
thousand
small
differences.
Add
up
to
a
bunch
of
interesting
debugging.
B
Examples
and
envoy
is
is
no
exception.
Right,
like
one
of
one
prime
example
that
we
had
early
on
was
that,
because
envoy
was
written
for
http
2,
it
lowercases
all
header
keys
right,
which
is
http
standard,
but
we're
dealing
with
legacy
traffic
legacy
traffic
often
expects
http
one
one
style,
capitalization
right.
You
have
a
content
length
header,
it
starts
with
capital
c,
it
has
a
capital,
l
and
theoretically,
if
you're
following
the
spec,
which
no
one
does
you
should
be
able
to
handle
either
casing,
but
no
one
does
right.
B
So
when
you
have
say
20
000
cloud
customers,
it's
guaranteed
that
not
all
of
them
do
it
right
right,
and
so
you
know.
For
example,
there
were
a
lot
of
internal
debates
as
to
how
that
google
should
handle
that
in
envoy
which
were
preempted
by
someone
else
running
into
it
first
and
writing
the
camelcase
http11
option.
So
you
can
you
can
kind
of
work
around
that
particular
issue
right,
but
for
any
migration
there's
going
to
be
dozens
of
little
impedance
mismatches.
B
Oh,
you
reordered
the
headers
differently
or
I
expected
a
space
here
between
commas
which
which
we
hit
internally,
and
it
just
takes
time
to
debug,
and
we've
done
a
lot
of
work
in
the
last
year
for
envoy,
making
it
easier
and
easier
to
debug
what
is
actually
flowing
through
the
system.
What
your
data
actually
looks
like
when
things
are
rejected,
why
they
are
to
try
to
at
least
ease
the
pain
of
that
migration.
D
Yeah,
that's.
The
really
key
point
is
that
you
know
all
of
these
systems
theoretically
exist
on
standards,
but,
as
alyssa
said,
it's
pretty
pretty
fuzzy
right.
You
know
it's,
and
I
think
everyone
runs
into
these
issues
and
stepping
back
to
envoy
itself
and
in
terms
of
one
of
the
original
value
propositions,
at
least
at
least
compared
to
its
open
source
competitors
is
envoy,
has
really
focused
on
the
observability
side
of
things
so
so
trying
to
better
understand.
D
What's
going
on
through
metrics
logging
tracing
things
like
that,
and
I
think
just
given
that
you're
going
to
hit
not
only
all
of
these
migration
problems,
but
even
apart
from
migration,
just
trying
to
roll
out
a
system
just
just
a
service
measure,
any
other
component,
where
you're
dealing
with
a
polyglot
code
base
with
10
different
languages
and
frameworks,
it
gets
super
super
messy.
So
I
I
think
that
that
is
really
the
underlying
crux
of.
D
A
D
It
ends
up
becoming
very
tricky
very
quickly
because
of
different
languages
because
of
bugs
just
just
because
of
faults.
Right
I
mean
it's
just
so
many
things
can
go
wrong,
that
my
advice
to
people
typically
is:
don't
don't
do
any
of
this
unless
you
actually
have
to,
because
it's
very,
very
painful
right.
So
I
I
think
that,
to
the
extent
that
folks
can
look
at
the
problems
that
they're
trying
to
solve
in
terms
of
if
they
can
limit
the
number
of
application
languages,
do
that
right.
D
If
you
can
limit
the
number
of
services
do
that,
if
you
can
use
a
cloud
provider
for
ingress,
do
that
right?
It's
like!
Don't
just
don't
implement
any
of
this.
I
think
at
a
certain
organizational
size.
You
know
that
becomes
un
unrealistic
and
you
end
up
with
services.
You
end
up
with
an
api
gateway,
and
you
end
up
with
all
of
these
things,
but
the
the
problems
in
my
experience
and
I'd
be
curious
to
hear
from
others
they're
just
endless.
It's
like
they
just
never
end.
B
I
mean,
I
wouldn't
say:
oh
go
for
it
go,
go,
go
ahead,
they
the
kind
of
two
classes
of
bugs,
are
going
to
be.
You
know,
control,
plane
or
data
plane,
right
and,
and
we've
done
a
lot
of
work
to
make
them
easier
to
diagnose
right.
So
a
lot
of
the
time
for
control
plane
bugs
you
have,
especially
for
as
lin
said,
the
the
configuration
language
is
not
the
easiest.
It
at
least
explains
what
you're
doing
wrong
hey.
B
You
have
field
a
that
means
you
need
field
b
or
this
is
out
of
bounds,
range
you're,
not
setting
a
reasonable
value.
You
know
maybe
look
at
the
docs
for
data
plane
again.
I've.
I've
personally
done
a
bunch
of
instrumentation
over
the
last
year.
So
this
morning
I
got
into
a
bug
report,
saying:
hey,
you
know,
connect,
isn't
working.
When
I
try
to
do
domain.
B
You
know
if
I
say,
match
all
wild
card
domains
it
passes
through
and
if
I
say
match
localhost
it
it
bounces-
and
I
was
like.
Oh
no,
I
didn't
test
this.
Let
me
go,
let
me
go
debug.
What's
going
on,
and
so
I
wrote
an
integration
test
and
ran
it
and
the
debug
details
said
route
not
found.
So
that's
great.
I
know
that
it,
the
rap
match,
failed
and
then
the
log
said
you
know
that
host
colon
80
didn't
match
and
I'm
like,
oh
yeah,
I
wrote
I
copied
what
they
did.
B
I
did
loco
host
or
or
host,
and
the
matcher
should
be
colon
80.
right.
It
took
me
five
minutes
to
debug
it
basically
between
between
logs
and
response,
good
details
right
and
so,
as
you
know,
you
ask
kind
of
what
are
the
common
gotchas
and
what
we've
done,
because
the
envoy,
the
actual
core
envoy
maintainer
community,
is,
is
quite
small.
B
There's
a
group
of
devs
who
aren't
maintainers,
you
know
who
are
who
are
awesome
and
really
good
at
answering
questions,
but
when
we
see
questions
like
this
happening
over
and
over,
why
is
unvoiced
sending
this
response?
You
know
why
is
mike
and
fig
not
working,
we'll
put
up
an
example,
so
people
can
copy
paste
at
it
or
you
know.
Well,
we
wrote
a
fact.
You
know
why
is
envoy
sending
this
response?
C
I
remember
even
earlier
this
year,
just
the
israel
project
itself
right,
we
actually
went
back
from
microservices
to
monolithic
and
because
of
some
of
the
challenges
are
hard
right.
Some
of
the
we
have
like
four
five
six
control
plane
components
and
we
consolidate
it
into
one
single
component
because
we
find
out
we're
not
enjoying
the
benefit
of
microservices.
C
We
don't
have
multiple
languages
and
we
had
a
lot
of
communication
issues
among
our
own
micro
services,
which
could
be
solved.
They
would
just
communicate
through
local
hosts
and
we
would
deliver
and
release
all
these
components
always
together.
So
we
actually
went
back
to
say
you
know
we
don't
need
microservices,
so
we
don't
need
to
consume
our
own
service
mesh
and
we
were
actually
a
lot
happier
now
just
having
one
single
control
plane
component,
like
matt
said
I
mean,
if
you
don't
actually
need
it,
the
best
might
be
just
avoid
it.
C
In
fact,
from
our
project
perspective,
we
were
amazed
on
how
many
issues
we
have
and
how
many
issues
we
discover
with
envoy.
Also
it's
just
like
you
know.
We
think
you
know
the
project
like
istio
is
almost
four
years
and
if
you
count
the
pre-incubation
it's
almost
five
years
and
envoy
also
being
along
around
for
a
long
time,
but
like
matt
said
you
know,
it's
just
people
have
different
scenarios
and
someday.
You
know
people
are
going
to
discover
something
new
and
there's
also
regression
and
all
that.
C
So
it's
super
complicated
and
the
one
thing
I
would
highlight
is
someone
from
auto
trader.
Carstony
wrote
a
really
good
blog.
You
know
when
you
have
service
a
talk
to
service
b,
direct
without
cycle
you're
worried
about
one
connection
pool
right,
but
the
moment
you
inject
the
side,
car
you're,
worried
about
like
three
connection
pools,
so
you
actually
increase
your
chance
of
things
might
going
wrong
and
the
most
common
problem
in
service
mesh
is
the
503
arrow.
So
any
of
the
time
out
configuration
if
the
conflict.
C
D
Yeah,
that's
a
great
point,
and
I
actually,
if
you
were
to
push
me
to
one
of
the
most
common
issues
that
comes
up
over
and
over
and
over
again,
is
that
in
these
architectures
you
wind
up
with
this
chain
of
proxies
right.
Just
like
lynne
was
saying
I
mean
you
can
have
an
edge
proxy,
a
second
layer
edge
proxy,
a
service,
a
sidecar,
some
intermediary
and
often
it's
the
timeout
config
that
ends
up
getting
really
messy
and
confuses
people
a
lot,
and
particularly
with
protocols
like
http11,
which
don't
deal
with
those
timeout
races
very
well.
D
That
was
solved
in
http
2.,
but
we
have
a
constant
stream
of
issues
that
come
into
envoy
and
to
other
projects
about.
Why
is
it
disconnecting,
and
you
have
to
explain
that?
Well,
you
have
to
actually
configure
the
timeouts
correctly
across
all
the
different
layers.
It's
just
it's
very
complicated
avoid.
Instead.
B
The
details
I
mean
I
added
this
into
envoy,
but
I
added
it
because
it's
one
of
our
most
powerful
debug
tools
for
the
gfe,
so
every
single
time
envoy
sends
a
local
response.
It
tags
a
specific
detail
that
is
unique
across
the
code
base,
so
you
can
literally
say
say:
detail
a
maps
to
this
line
of
code
in
this
file
right,
so
you
can
see
exactly
which
timeout
caused
and
if
you
chain
those
in
headers.
B
So
in
your
in
your
response,
headers,
you
always
say
the
details
of
this
response
was
forwarded
by
the
back
end
and
the
details
of
this
one
was
whatever
then
either
by
looking
at
access
logs
or
response
headers.
If
they
make
it
to
you,
you
can
see
exactly
which
proxy
in
the
chain
failed
and
exactly
what
line
of
code
it
failed
at.
Then
you
still
have
to
debug
wait.
Why
did
this
one
time
out
and
these
two
not
time
out,
but
at
least
you've
you've
root
caused?
You
know
where
it
happened,
not
why
it
happened.
C
And
I
would
add,
you
know
thanks
to
envoy
and
service
mesh
project.
These
problems
are
actually
surface
a
lot
easier
than
used
to
right,
because
now
you
can
observe
what's
going
on
with
your
microservices,
it's
a
lot
easier,
so
you
can
actually
see.
Maybe
you
have
this
problem
at
tonight.
It's
just
0.5
percent.
Where
before,
if
it's
zero,
five
percent,
you
may
not
even
know-
and
you
may
just
live
with
it-
it's
just
because
of
the
service
measure
and
the
platform
like
envoy.
C
All
these
issues
that
surface
to
the
user
right
away,
so
they
actually
have
the
chance
to
debugging
and
troubleshooting.
Like
elisa
said,
you
know,
having
like
the
debugging
tool
to
figure
out
what
might
go
wrong
so
that
you
can
tweak
that
timeout
and
maybe
tweak
out
retry
and
to
further
configure
your
system
to
be
to
be
more
tolerant.
D
What
I
would
add,
too,
which
is
which
is
super
interesting,
is
that
when
we,
when
we
raise
a
bunch
of
these
issues
to
the
user,
what
I
found
personally
and-
and
this
is
there's
a
fair
amount
of
irony
here-
is
that
issues
that
a
user
may
never
have
noticed
previously,
like
very
low
rate
issues.
They
now
notice
and
they
think
it's
a
severe
problem
right
and
then
they'll
spend
a
bunch
of
time,
debugging
it
or
asking
questions,
and
that's
fine.
D
So
I
think,
as
operators
of
the
system.
This
is
where
what
I
was
saying
before,
I
I
don't
mean
to
keep
saying:
don't
use
this
technology,
I'm
just
saying
that
it
is
a
powerful
system.
As
you
add
on
all
of
these
layers,
it
becomes
more
and
more
complicated,
and
I
just
think
it's
important
to
realize
that
there's
a
lot
of
intuition
here,
like
there's
a
reason
that
alyssa
has
been
working
on
this
for
like
15
years
right.
D
It's
because
there's
a
lot
of
experience
that
you
gain
from
the
way
the
patterns
that
that
things
break
and
then
being
able
to
look
at
the
big
picture
and
try
to
understand.
Is
that
really
a
big
issue
or
not?
So
I
would
just
add
that
it
gets
really
complicated,
not
even
just
the
system
but
just
trying
to
take
in
all
of
the
inputs
and
understand.
Should
you
even
action
on
them
right,
it's
like
what
should
you
alarm
on?
Should
you
care
about
this
and
that's
where
there's
no?
B
Yeah,
I
actually
want
to
add
on
to
that,
because
that
that
is
a
huge
problem
and
that's
not
one
that
any
proxy
can
solve.
You
know,
as
matt
says
you
often
have
these
really
low
rate
of
errors
right
and
low
rate
of
error.
It's
not
a
big
problem
unless
it's
consistent,
100
error
for
some
user
on
some
platform
in
some
country
right
and
it
and
it
gets
really
hard
to
figure
out.
Is
this
a
low
rate
of
error
but
a
high
rate
for
some
class
of
users
or
some
class
of
networks?
B
A
Other
sort
of
key
measures
or
thought
processes,
might
you
imagine
or
not
imagine
that
you've
seen
for
success
or
not
success
on
going
to
say
a
service
mesh
sort
of
situation?
What
other
things
might
people
who
are
watching
this
panel
use
as
criteria
to
decide?
Oh,
this
is
a
good
way
for
us
to
go,
or
this
is
maybe
not
a
good
way
for
us
to
go.
We
should
have
fewer
services
or
a
monolith
or
something.
C
Yeah,
I
would
say
you
know:
science
is
certainly
an
important
characteristic.
The
second
thing
I
will
look
at
is
what
programming
languages
are
they
using?
You
know
they
really
have
multiple
programming
languages,
or
are
they
just
primarily
using
one
single
programming
language
like
we
have
in
istio
with
our
control
plane,
we
have
six
seven
components
but
all
using
the
same
language,
so
it
didn't
make
sense
for
us.
The
third
thing
I
would
look
at
is,
you
know:
are
they
actually
operating
the
services
by
different
people?
C
C
How
much
experience
the
organization
have
to
consume
open
source
technologies
if
they're,
just
consumer
envoy
and
istio
and
other
open
technologies
out
there,
because
it
does
require
a
lot
of
experience
in
adopting
open
source
technologies?
So
hopefully
they
have
some
experience
in
the
past.
That
would
help
them
easy.
The
transition
to
adopt
these
technologies.
B
I
guess
one
thing
I
would
add
is
not
just
considering
team
size,
but
also
for
larger
companies,
considering
where
you
can
join
forces.
You
know,
lynn
mentioned
the
control
plane.
Well,
if
you
know,
if
you're
one
team
of
five
people
yeah,
it
doesn't
make
sense
to
run
your
own
micro
services
and
run
your
own
control
play
like
that.
B
That
would
take
a
lot
of
your
people,
but
if
you
have
a
bunch
of
different
small
teams
across
a
company
right
where
you
could
join
forces
and
have
you
know,
one
operations
team
that
that
kind
of
handled
that
and
had
an
escalation
path
and
build
those
muscles
and
a
bunch
of
small
teams
leveraging
it
that
can
be
a
really
powerful
model.
We
tend
to
have
a
very
strong
infrastructure
teams
at
google
and
I've
been
surprised
kind
of
repeatedly
working
on
the
envoy
side.
B
How
many
companies
kind
of
are
more
siloed
right
and
have
different
teams
kind
of
all
rolling
their
own?
And
again
it's
harder
it's
harder
to
work
together
right
to
be
able
to
coordinate.
You
know
what
role
out
schedule
makes
sense
and
what
you
know
what
the
security
release
processes
make
sense
for
each
team.
But
if
you
can
do
it,
you
can
avoid
a
lot
of
repeated
work
and
you
can
really
build
up
those
those
strong
teams
with
deep
expertise.
D
Yeah,
those
are
both
super
answers.
The
only
the
only
other
thing
that
I
would
add
is
that
when
it
comes
to
the
api
gateway
side
of
things,
you
know
the
north-south
or
the
service
mesh
east-west.
I
would
also
ask
people
to
really
look
at
a
what
what
problems
are
they
actually
trying
to
solve?
And
by
that
I
mean,
is
your
system
actually
actually
real
time
right?
It's
like
do
you
do
you
have
to
have
low
latency
right?
D
It's
like
do
you
do
you
have
to
have
synchronous,
api
calls
and
sometimes
stepping
back
and
trying
to
understand.
Could
you
develop
your
system
on
top
of
pub
sub?
You
know,
could
it
be
lossy
right?
It's
like
there
can
be.
It
can
be
other
architectural
patterns
which
are
just
much
simpler
than
trying
to
get
a
giant
micro
service
call
graph
to
actually
work.
It's
a
very
complicated
technical
thing.
That
is
not
that's,
not
easy
to
do
so.
My
advice
from
people,
even
apart
from
the
you
know,
stay
on
your
monolith.
D
Don't
adopt
microservices,
if
you,
if
you
can
you
know,
is,
is
to
look
at
the
actual
application
use
case
and
say:
do
I
need
real-time
communication?
Does
it
have
to
be
synchronous?
Are
there
simpler
ways
that
I
can
actually
do
this?
That
tend
to
be
easier
to
debug,
a
bit
more
reliable
so
that
that
would
be
my
other
main
high-level
piece
of
advice.
A
I
I'll
give
you
all
a
final
chance
to
say
anything
that
you,
you
wanted
to
say
other
than
thanks,
and
you
know
so
long
and
thanks
for
all
the
fish
but
and
then
we'll
we'll
call
it
good
and
answer
questions
from
the
audience
during
during
the
actual
panel
broadcast.
So
is
there
anything
that
you'd
like
to
like
to
sum
up
with
there
alyssa.
B
I
guess
I
would
say
that
if,
if
you
have
done
the
analysis,
matt
suggested
and
decide
that
that
microservice
is
the
way
to
go
or
or
envoy
for
your
ingress
traffic
or
you
decide
to
adopt
istio
is
a
recommendation
to
just
really
try
to
get
involved
in
the
community.
It's
it
open
source
is
an
amazing
thing
because
you
can
be
like
hey.
B
B
I
need
help
figuring
this
out
or
how
to
add
this
thing
or
I
want
to
do
this
flourish
and
if
you
get
involved
in
the
communities
early,
both
istio
and
envoy
have
really
strong
developer
communities.
We've
got
a
great
maintainer
team,
there's
you
know
active
slack
channels
and
if
you
get
involved
the
more
you
get
involved
in
the
community,
the
faster
you
get.
Your
questions
answered
the
easier
it
is
to
get
your
features
landed,
the
easier
it
is
to
to
basically
get
everything
working.
The
way
you
want
to
work.
B
So
it's
it's,
this
kind
of
bootstrapping
thing
where,
like
you
put
in
that
initial
effort
and
you
get
way
more
out,
so
it's
an
option.
Not
everyone
has
the
time
to
do
it.
Not
everyone
has
the
cycles
to
do
it,
especially
if
you're
early
on
in
a
startup.
But
once
you
get
to
the
point
where
you
have
some
breathing
room,
it
really
is
valuable
to
be
proactive
and
just
reach
out
and
be
like
hey.
C
I
would
say
you
know
definitely
spend
time
to
understand
whether
you
need
surface
mesh.
I
think
it's
really
worthwhile
your
time
to
spend
that
time
up
front
to
do
solo
evaluations
and
then
once
you
decide
which
project
you
are
going
to
land-
and
I
definitely
agree
with
elisa
you
know,
spend
that
time
to
work
with
community
and
don't
be
frustrated
because
we
are
all
volunteers,
so
sometimes
it
might
take
a
little
bit.
Patience
take
a
little
bit
of
pain.
You
may
need
to
attend
the
community
meeting
or
even
a
work
group
meeting.
D
A
Fabulous
well,
I'm
going
to
summarize
your
three
final
points
with
I'm
going
to
say
that
matt
said:
look
for
simpler
options,
which
I
like
as
a
general
life
philosophy,
and
definitely
when
you're
writing
software
lin
said
carefully.
Consider
your
requirements,
which
again,
I
think,
is
a
fabulous
thing
when
you're
doing
software
and
alyssa
said
make
friends
early,
which
I
think
we
all
learned
when
we
were
in
kindergarten
and
with
that
I
thank
all
of
you
for
being
part
of
this
panel.