►
Description
1:1 with Christian Posta
Service Meshes: Why are there so many of them?
What nuances and similarities do most have?
Why is Envoy underneath the hood of so many of them?
This appears to be the thing after Kubernetes, no?
A
Hello
good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
a
very
special
episode
of
open
chef
tv
today,
we're
joined
by
the
one
and
only
christian
poster
who
happens
to
be
a
former
red
hatter.
So
he's
one
of
our.
You
know
brilliant
minds
that
escaped
us
kind
of
thing
that
I
I
feel
like
and
christian
is
someone
that
knows
an
enormous
amount
about
service
meshes
and
just
kubernetes
in
general,
and
how
to
build
on
top
of
kubernetes
in
an
effective
and
secure
way.
A
B
That
you
for
those
kind
words
yeah
and
thanks
for
having
me
on
on
this
program,
yeah,
I'm.
A
B
Yeah,
so
my
name
is
christian
posta.
I
live
in
phoenix
arizona
where
it's
still
pretty
hot
in
the
hundreds
yeah
I
work
for
a
company
called
solo.io
and
we
are
a
startup
focused
around
envoy
proxy,
around
service
mesh
technology
and
operating
service
meshes
in
in
real
enterprise
environments,
which
is
very
tricky,
and
actually
we
publicly
announced
that
solo
raised
their
series
b
round.
A
B
That's
one
of
the
hardest
rounds
and
yeah.
I
know
we're
we're
we're
doing
really
well
we're.
You
know
growing
the
company
hiring
like
crazy
and
yeah
things
are
going
well.
A
That's
awesome,
that's
great
to
hear
so
I
kind
of
just
laid
out
a
series
of
questions
for
us
to
kind
of
discuss,
and
I
want
you
know
audience
engagement
because
I
feel
like
to
me
and
this
kind
of
touches
on
my
first
question.
You
know
surface
meshes.
Why
are
there
so
many
of
them
like
there's,
there's
like
there's
this
over
abundance
of
them
and
I
kind
of
feel
confused
a
little
bit
at
this
point.
Right,
like
I
guess,
as
someone
that's
like
I'm
going
to
need
a
service
mesh
at
some
point.
B
B
Right
every
week,
every
month,
yes
new
handful
and
there's
a
lot
of
there's
a
lot
of
confusion
in
the
market,
there's
a
lot
of
overlap.
What
are
the?
Why
so
to
your
question?
Why
are
there
so
many
right
people
have
different
opinions
of
what
what
the
networking,
abstractions
and
apis
should
look
like.
B
What's
what's
quite
interesting,
however,
is
that,
although
there's
a
you
know,
a
large
number
of
service
meshes
and
more
seemingly
to
be
announced,
the
they
majority
of
them
are
picking
a
single
data,
plane
technology,
they're,
picking,
envoy
proxy
right,
and
so
then
what
is
the
difference
between
the
different
meshes?
Well,
it's
the
assumptions
that
were
built
into
it.
It's
the
apis
that
were
that
were
built
into
it.
There
is
the
user
experience,
the
manageability
of
it
and
so
on.
B
So
that's
where
those
are
the
axes
that
they're
trying
to
differentiate
on
but-
and
you
know
just
like
there
was
in
the
in
the
container-
you
know
ecosystem
a
few
years
back,
there's
different.
A
B
That's
right,
I
would
say,
similar
to
the
way
containers.
You
know.
Google
did
a
lot
of
work
in
the
container
world
c
groups
and
in
linux
and
so
on,
and
they
had
their
own
thing
internally
and
then
at
some
point
you
know
they
published
a
bunch
of
papers
about
what
they're
doing,
but
then
they
finally
said
all
right.
B
You
know
we're
going
to
jump
in
and
we're
going
to
build
it
the
way
we
would
build
it
if
we
were
doing
it
again
and
I
think
for
them
it
would
have
been
the
third
iteration
for
them.
Building
a
you
know
this
type
of
infrastructure
for
kubernetes.
Well,
they
have
something
similar
internally
that
resembles
a
service
mesh
right,
and
so
they,
you
know,
started
looking
at.
B
What
is
what
is
the
next
thing
that
goes
that
complements
kubernetes
when
you
start
to
build
out
this
cloud
up
to
these
cloud
platforms,
and
they
were
looking
for
something
that
resembled
or
something
that
fit
the
way
they
would
build.
This
next
generation
networking
infrastructure
and
they
stumbled
upon
envoy
proxy,
pretty
early.
C
B
Combine
that
with
the
the
open
sourcing
of
envoy
and
the
reasons
why
matt
klein
and
lyft
built
envoy
right,
you
know
they're
very,
very
similar
reasons
and
the
the
reasons
and
google
did
and
lifted
it.
Everyone
did.
Everyone
tried
to
build
this
application
layer,
networking
using
various
tools,
different
proxies
and
so
on,
but
so
I
would
say
that
you
know
for
all
these
different
reasons.
Envoy
got
open
source
google
jumped
in.
You
also
saw
people
like
apple
on
ebay
and
verizon,
and
a
lot
of
people
jumped
in
and
said.
B
Oh,
this
looks
this
looks
like
the
thing
yeah
and
and
so
that
that
that's
what
happened
and
now
you
know
since
then
I'll
fast
forward,
a
lot
of
investment.
A
lot
of
work
from
all
these
various
companies
has
gone
into
envoy
envoy
is
a
very
so
first
of
all,
it's
at
the
cncf,
it's
yeah.
It's.
B
Yeah,
it
was
one
of
the
very
first
few
graduated
projects,
it
was
kubernetes
and
an
envoy,
and
there
was
one
other
one.
Maybe.
B
There
was
just
a
small
subset
of
graduated
projects,
but
so
a
lot
of
effort,
a
lot
of
work
went
into
it.
It's
it's
open
source,
it's
cncf,
the
apis
for
extending
it
were
very
well
thought
out.
You
know-
and
maybe
that's
a
maybe
that's
a
common
theme
with
some
of
these
technologies
that
are
that.
Have
you
know
kind
of
crossed
that
chasm,
I
guess,
like
kubernetes,
also
had
this
idea
of
building
a
very
extensible
api,
so
you
can
extend
onto
it
and
and
so
on
that
led
a
lot
to
its.
B
A
B
B
For
about
a
year
or
so
year
and
a
half
before
I
joined
but
sola
was
interested
in
like
how
can
we
solve
the
enterprise
challenges
around
functions
as
a
service
and
serverless,
and
you
know
indeed,
and
the
team
started
digging
around-
they
realized
that
still
is
too
premature
for
that
right.
So
then,
the
next
thing
was
all
right:
let's
focus
on
applications
in
enterprise
today
and
how
we
can
modernize
them
and
and
so
on,
and
then
that
then
service
mesh
came
in
to
right.
You
know
they
started
looking
at.
A
B
What's
the
next
thing,
oh
on
toy
and
at
least
starting
to
get
traffic
into
your
clusters
into
your
openshift
cluster
into
your
kubernetes
cluster
into
your
you
know,
aws
investment
and
so
on,
and
so
that
we
started
with
a
single
on
boy
proxy
deployment
called
we
call
it
glue,
which
is
a
a
gateway
that
allows
you
to
kind
of
at
the
network
level
level,
bring
all
these
different
applications
together
and
and
then
I
started
to
build
from
there
right.
B
So
we
built
on
envoy-
and
this
is
the
same
approach-
that
we
recommend
people
to
adopt
this
type
of
technology
start
small
start
get
value
out
of
it.
Envoy
can
provide
a
lot
of
value
and
then
grow
into
well.
These
these
super
scaled
out
deployments
where
you
have
an
envoy
with
each
single
application
instance
managing
all
of
your
applications
and
so
on.
But
that's
a
that's
a
you
know,
201
or
301
level
course,
not
just
right.
You
know
start
start
at
the
beginning
and
and
work
your
way
into
it.
B
Just
like
you
did
with
kubernetes
right
so
that
that
that's
what
we
we
ended
up
doing-
and
you
know
the
now
the
rest
of
the
surface
mesh
ecosystem
has
has
sprung
up
and
is
continuing
to
evolve.
B
B
The
reason
why
you
might
go
to
a
service
mesh
and
how
to
start
off
adopting
it
and
without
my
own
biases
from
solo,
you
see
the
same
pattern
that
I
just
described
that
if
you
want
to
start
with,
for
example,
istio
95
of
the
time
people
start
with
the
ingress
gateway
from
istio
yeah
and
getting
traffic
into
their
clusters,
which
makes
sense
it's
an
understood,
pattern,
yeah
right
and
then
from
there.
What
they
go
to
is
well.
B
A
B
It's
something
that
that
that
people
didn't
do
they.
A
Didn't
want
to
do
because
tls
between
their
services
was
something
google
pioneered
right
like.
Why
would
you
need
to
encrypt
inside
your
network
right,
like
the
military,
been
doing
it
for
years,
but
it
was
never
like
a.
It
was
never
considered
like
a
normal
thing
in
the
private
sector,
which
I
thought
was
very
unusual,
coming
out
of
the
military
experience
into.
B
B
B
A
A
B
B
If
the
traffic
is
going
through
the
proxy
that
that
you
know
where
the
traffic's
originating
that
service
and
it's
going
to
another
application,
which
also
has
its
proxy
and
then
there's,
you
know
some
interesting
behaviors
that
you
can
do
between
that.
Those
those
two
services
and
one
of
those
is
encrypting
the
traffic.
B
A
B
Yeah
exactly
so
now,
instead
of
doing
that,
what
we
can
from
the
service
mesh
perspective
is
say,
hey
you
know,
let's
give,
let's
give
envoy
these
certs
and
let
envoy,
which
is
already
in
in
the
request
path
and
from
the
origin,
to
the
termination
side
of
the
of
the
communication
transport
encrypt.
It
there
right
encrypt
it
before
it
leaves
the
application
and
decrypt
it
when
it
gets
to
the
application
and
and
nowhere
in
between,
obviously
so
a
direct
end
to
end
encrypted
channel.
A
Right,
like
you
get,
you
get
an
authenticated
kind
of
trust
between
the
two
services
now
or
between
the
two
pods,
essentially
talking
to
each
other
through
the
cluster
network,
so
forth.
So
on
so
there's
some
questions
about
visibility
and
observability
into
what
is
actually
going
on
inside
that
service.
Mesh
right,
like
our
admin
folks,
are,
like
that's
great,
I'm
gonna
hand
off
tls
to
a
service,
but
I
need
to
know
how
it
works
right
like
can
you
explain
that
process
a
little
bit.
B
Yeah,
so
in
in
that,
in
that
model,
when
I,
when
I
hinted
at
you
know
well,
we
just
give
the
certs
out
to
envoy
right
right,
there's
a
level
of
the
control
plane,
part
of
the
service
to
mesh.
So
we
talked
about
how
the
the
data
plan
or
the
little
the
proxies
that
go,
live
with
the
application
they're
in
the
data
plane,
they're
handling
the
requests
and
the
messages
and
so
on,
but
there's
still
a
component
to
service
mesh
that
needs
to
operate
and
configure
these.
B
These
different
proxies
right
doing
that
by
hand
is
out
of
the
question.
So
there's
there's
a
you
know
so,
for
example,
istio
or
aws
app
mesh
or
any
of
the
any
of
the
service
meshes
follow
this
pattern.
Where
you
have
the
proxies
deployed
with
the
application
and
then
a
control
plane
to
be
able
to
drive
the
configuration
and
in
the
mtls
model
and
then
in
an
encryption
model.
What
happens
is
the
proxies
come
up?
B
They
say
hey,
I
am
service
xyz
and
then
they
announced
that
to
the
control
plane
and
the
control
plane
has
to
validate
and
verify
that.
Okay,
that
this
is
actually
service,
xyz
and
then
what
it
does
is
it
gives
that
service
a
certificate
that
has
been
signed
by
a
trusted
root:
okay,
a
certificate
that
says
yes,
you
are
indeed
xyz
and
so
now
service
xyz
serves
as
abc.
B
They
have
certificates,
x-519
certificates
that
have
been
validated
and
trusted
by.
You
know
a
trusted
third
party
and
now
when
they,
when
they
create
the
connection
to
each
other,
they
present
these
these
certificates
and,
as
part
of
you,
know,
managing
certificates
and
that
kind
of
stuff
there's
also
the
expectation
of
expiration
and
rotation,
and
so
the
service
mesh
control
plane
manages
manages
that
right,
so
it
rotates
the
certs
and-
and
you
know
before
they
expire
and
and
so
on.
B
A
It's
validated
it's
trusted.
It's
like
almost
certified
to
a
point
that
it's
like.
This
is
the
thing
that
it's
supposed
to
be
talking
to
yeah.
What
are
the
possibilities
of
somehow
injecting
code
like
vulnerability,
type
things
happening
in
that
process,
right
like
how
locked
down
is
that
process
so
between
so
sorry
before
I
say
that
to
be
graduated
from
cncf,
you
have
to
pass
a
security.
A
third
party
security
assessment,
obviously
envoy
did
that
years
ago
and
is
continuing
to
meet
that
compliance
from
cncf.
As
far
as
that
perspective
goes.
A
B
That's
the
thing
right,
so
what
you
you
could
end
up
in
a
situation
where
one
end
gets
compromised
right
so
for.
C
B
Reasons
maybe
your
pod,
your
your
cluster
has
some
vulnerability.
Somebody
and
you
can
get
access
to
to
the
pods
and
somehow
take
the
the
secrets
and
the
certificates
and
so
on.
In
an
istio
at
least
the
certificates
are
kept
in
in
memory,
so
they're
not
stored
onto
onto
disk
anywhere,
but
nevertheless
you
could
take
control
the
proxy
and
now
the
the
interesting
thing
about
that
is
you.
Can
you
know
the
the
idea?
Is
those
those
certificates
get
rotated
after
a
period
of
time?
So
if
something.
C
B
You
are
able
to
steal
a
certificate
in
some
way
and
try
to
exfiltrate
it
and
use
it
for
other
things,
then
that
first
of
all
will
expire
and
then
you
know
then
you're
in
that
situation.
How
do
you
deal
with
a
compromised
certificate
but
by
default
with
again,
for
example,
istio
and
seo
the
one
I'm
going
to
use,
as
has
my
go-to
reference,
because
I'm
writing
istio
in
action.
B
And
now
now,
we've
gotten
back
to
it
got
an
awesome,
amazing,
co-author
and
we're
shooting
for
published
by
spring
by.
A
B
Community
and
apis,
and
that
kind
of
thing,
so
I
think
we're
finally
hitting
a
part
where
it's
going
to
mature
and
it's
going
to
start
to
stabilize
a
lot
more
and
settle
down
and
and
that'll
be
the
thing,
but
coming
back
to
the
security
like
the
certificates,
if
they,
if
they
get
you,
you
can
in
istio
the
default
workload.
Certificate
expiration
is
24
hours,
wow,
okay,
so
you
get
a
new
server
every
day
you
can
use
cert
every
day.
You
can
change
that
you
can
lower
it.
B
A
So
here's
a
question
that
gets
asked
often
from
and
it's
from
the
get
from
one
of
the
guests
or
people
on
the
stream.
We
regularly
get
the
question:
how
can
glue?
How
can
we,
how
can
we
glue
the
creation
of
pki
certificates
used
for
mtls
to
an
hsm
and
a
central
ca?
So
a
hardware,
some
kind
of
hardware,
encryption
device
and
a
central
ca
like
is
that
possible
with
istio
or
envoy.
C
B
What
you
end
up
doing
is
from
your
hsm
or
your
root
ca,
or
you
know
the
pka
that
you
have
in
your
organization
today.
What
you
end
up
doing
for
istio
is
you
generate
an
intermediary
signing
certificate
and
you
give
that
to
istio
and
then
istio
will
mint
certificates
from
that
intermediate
certificate?
B
Now
there
is
work
being
done
right
now.
I
don't
know
if
it'll
be
in
for
1.8
there,
so
basically
in
the
istio
community.
What
happens
is
someone
you
propose
a
an
idea
or
request
for
enhancement
and
so
on
and
then
little
by
little
the
pieces
get
into
the
release
right
right.
So
what
what's
what's
been
proposed
is
to
be
able
to
plug
in
external
cas
and.
B
You
know
basically
send
their
certificate
signing
requests
to
an
external
ca
and
and
get
it
directly,
nice
and
so
being
able
to
plug
in
with
a
bunch
of
existing
cas,
and
that
extensibility
is
is
work
that
is
ongoing
right
now,.
A
A
Yeah,
that's
great
to
hear
that's
amazing,
so
yeah
that
answers
that
question
nail
is
right
on
the
head:
let's
see
as
an
app
developer,
I
don't
care
if
you
know
if
or
how
the
cert
was
issued
just
as
long
as
it's
got
the
right
roles
in
the
header
and
everything
else,
so
yeah
exactly,
let's
see,
we've
covered.
A
So
what
so
like
this
appears
to
me
to
be
the
thing
after
kubernetes
right,
like
everybody,
asks
me
or
not
everybody,
but
like
analyst
or
you
know,
vcs
I'll
talk
to
every
once
in
a
while
and
they're
like.
So
what
do
you
think
is,
after
kubernetes
or
just
friends
like?
What
do
you
think
is
after
kubernetes
chris
and
I'm
like
well,
this
is
it
service
meshes.
Are
it
clearly,
but
I
don't
understand
the
why?
Why
is
service
meshes?
A
B
Think
there's
two
big
two
big
reasons:
the
first
thing
the
first
reason
is
kubernetes,
and
you
know
that
that
kind
of
deployment
platform
is
amazing
at
taking
a
container
which
can
run
any
kind
of
software
or
any
kind
of
application,
and
and
doesn't
matter
what
it's
written
in.
B
Take
that
that
service
that
application
and
deploy
it
across
multiple
nodes
in
a
large
fleet
and
make
sure
that
there's
a
certain
minimum
number
of
replicas
up
start
them,
stop
them
when
they
need
to
re
move
them
around
when
they
need
to
check
their
health.
Make
sure
that
they're
healthy
all
right
so
kubernetes
is
an
amazing
deployment
platform
and
orchestration
tool.
Yeah.
B
Exactly
and
the
so
that
that's
the
number
kubernetes
is
great
at
doing
that.
But
then,
when
you
deploy
these
applications,
these
applications
need
to
talk
with
each
other.
They
need
to
send
messages,
they
need
to
authenticate
and
authorize
each
other
right.
You
need
to
understand,
what's
happening
at
the
network
layer
between
these
applications,
and
so
we
need
to
solve
that
problem.
Somehow
right.
So
that's!
That's!
That's
the
first
reason,
because
you
know,
what's
after
kubernetes,
well
kubernetes
lets
you
deploy
your
applications.
What's
after,
what's
after
you
deploy
your
applications
right.
B
And
so
the
second
reason
is
just
like:
kubernetes
solved
the
problem
of
deploying
and
managing
software
services,
and
so
on,
regardless
of
what
language
they
were
written
in.
We
have
that
same
challenge
of
how
do
we
solve
the
communication
challenges
right?
How
do
we,
regardless.
C
B
B
The
first
reason
was
because
you
need
to
solve
the
communication
challenges
you
can
do
that
in
application
code,
but
kubernetes,
like
I
said,
allows
you
to
deploy
java
node.js
python,
go
laying
based
services,
everything
and
now
you
have
to
solve
those
problems
in
every
single
language
across
every
single
framework,
across
every
different
version
of
those
languages
and
frameworks,
and
keep
it
up
to
date
and
hope
and
pray
that
it's
consistently
and
exactly
correctly
rather
implemented,
and
that
becomes
operationally
very,
very
difficult
and
expensive
and
so
on.
B
So
that's
that's
why
the
service
mesh
comes
in
to
solve
that
problem
in
an
application
frame
and
framework
agnostic
way,
similar
to
how
kubernetes
and
containers
solve
the
deployment
problems
in
an
application
and
framework
agnostic
way.
So
that's
that's
the
kind
of
the
larger
picture.
Why
why
that
is.
That
is
the
next
thing.
B
A
It
serverless
is
it
you
know.
Well,
maybe,
but
to
be
honest
with
you,
I
think
this
is
my
opinion
in
general,
like
kate,
serverless
is
an
answer
that
everybody
needed
to
like
justify
having
all
this
hardware
dedicated
to
all
this
application
work
right
like
they
need
to
be
able
to
do
serverless
stuff
on
top
of
it,
so,
okay,
native
et
cetera,
I
think,
is
a
necessary
tool
like
cubeless
those
those
things
are
necessary
tools
to
you
know
put
in
your
kubernetes
clusters.
A
A
You
know
skills
and
resources
with
a
tool,
and
it's
not
that
hard
to
actually
kind
of
glue
it
all
together
to
begin
with.
So
that's
my
opinion,
I'm
sure
christian,
you
have
other
opinions.
B
I
mean
it's
again:
it
just
goes
back
to
the
same
question
of
what
happens
after
you
deploy
your
application.
Oh
well,
they
need
to
talk
with
each
other
all
right
well
now
that
they
talk
with
each
other.
What
do
they
need
to
do
next?
What's
what's
next
right?
So
now
we
will
probably
look
at
ways
of
optimizing
that,
and
maybe
that's
a
you
know-
serverless
style
functions
and
service
style
mechanism,
but
the
the
infrastructure,
the
things
that
you
you
you
built
to
get
there.
B
You
know
those
are
those
are
necessary
pieces
of
functionality.
Now
the
the
you
know
get
ops
and
security
and
data,
and
all
of
these
things
are
all
kind
of
they
don't
they're,
not
necessarily
layers
per
se,
but
they
all
kind
of
work,
work
together,
right.
B
Yeah,
but
I
mean
you
deploy
your
application
and
you
find
out
whether
or
not
it's
successful,
then
you
make
money
right.
So
that's
the
next
thing.
A
Right
yeah,
so,
like
that's
the
thing
right
like
kubernetes
or
serverless,
or
you
know,
service
mesh,
whatever
it
might
be,
is
not
necessarily
destination.
It
is
just
a
step
along
the
way
right,
it's
complex.
We
get
that.
It's
not
exactly
easy.
You
know
there.
There
are
tools
now
that
have
significantly
eased
the
process
since
when
I
started
using
kubernetes,
so
I'm
happy
for
that,
but
there's
much
work
to
be
done
here.
B
I
I
think
I
think,
one
area
that
is
particularly
interesting
and
something
that
we're
very
interested
in
solo
is
all
right.
You
got
your
kubernetes,
you
got
your
surface
mesh,
but
now
you
gotta
run
them
in
big
organization
right
right,
all
right.
Well
now
we
need
this
customization
here.
We
need
to
extend
the
thing
here
so
in
in,
in
my
mind,
webassembly
becomes
the
next
big
thing.
I
guess
yeah.
A
Well
and
yeah,
I
did
state
that
last
year,
at
the
my
end-of-year
blog
post,
I
think
webassembly
would
be
a
bigger
thing
this
year,
then
go
what
happened,
but
you
know
so
talk
to
me
about
webassembly
a
little
bit.
What
is
it,
why
would
you
use
it?
What's
it
for
lay
it
out
for
the
audience.
B
You
can
take
code
written
in
your
preferred
language
up
to
an
extent
right.
It's
still
evolving,
there's
some
constraints
in
in
web
assembly.
Take
that
take
that
and
then
compile
it
down
into
a
binary
format
and
then
take
that
binary
format
and
run
it
in
a
vm
or
or
a
sandboxed
environment.
Like
a
web
browser
like
a
web
browser.
B
Same
model
and
say
well
when
I
deploy
my
glue,
edge
gateway,
for
example,
and
I
deployed
at
the
edge
I
wanted
to
do
open
id
connect.
I
wanted
to
do
a
couple
of
oauth
flows.
I
wanted
to
grab
some
telemetry,
but
you
know
what
I'm
you
know
citibank
and
I
have
all
of
these
non-standard
security
protocols
that
I
need
to
somehow
plug
into
the
gateway,
because
I
need
to
support
for
backward
compatibility
or
just
compatibility
with
the
rest
of
the
organization
yeah.
So
now.
B
You
can
extend
envoy
envoy's,
written
and,
like
I
said
earlier,
it's
very
extensible,
but
it's
written
in
c
plus
right
and
if
you
modify
it
with
c
plus
plus
now
you
have
a
different
distribution
of
envoy
that
you
have
to
maintain
and
right
so
that
there's
a
lot
of
work
that
goes
into
that
or
you
can
do
it
out
of
process
from
envoy
call
envoy
onboard
reach
out
to
a
different
service.
Do
your
custom
thing
and
then
and
then
return,
but
that's
expensive
right
in
terms
of
networking,
latency
and
so
forth.
B
B
Do
your
custom
code
custom
whatever
and
he's
still
running
the
same
base
envoy,
you
haven't
changed
onboard,
so
you're
not
you'll
have
to
maintain
that
right
fork,
and
so
it's
a
way
that
allows
you
to
extend
the
capabilities
of
your
networking
infrastructure
at
the
l7
or
application
level
without
having
to
stand
up
all
these
different
services
or
take
custom
built-up
envoy
and
so
on.
A
And
so
so
it's
a
way
to
customize
your
proxy
with
a
language
that
you're
familiar
with
that's
right,
yeah
and
just
plug
right
into
envoy.
That's
right!
That's
right!
So
what
can
wasm
do
or
what
web
assembly
itself
do
like
in
the
browser
right
like
it?
It's
its
capabilities
are
somewhat
limited.
I
think
right.
C
B
That's
where
it
excels,
even
I
would
say
not
in
injecting
into
envoy
there,
it's
a
very
strict
boundary
between
webassembly
and
the
host
right.
So
there's
no
shared
memory.
B
If
you,
if
you
want,
if
you
want
to
pass
data
into
or
out
of
the
webassembly
mode,
you
have
to
copy
it
between
the
vm
and
the
host,
and
if
you
want
to
call
external
services
or
external
functions,
those
have
to
be
made
available
to
you
and
very
explicitly,
and
so
there's
there's
there's
limitations
in
in
that
model,
but
for
the
browser
I
you
know
like
I
said
it
was
built
in
in
one
respect
to
oper
to
improve
the
efficiency
of
the
applications
that
you're
writing
right
for.
B
Technically
you
know
high
computational
tasks
and
and
in
envoy
it's
just
about
what
you're
doing
in
the
network
is
manipulating
headers
and
things
back
and
forth.
Yeah,
maybe
looking
at
the
body
and
and
of
a
request
or
something-
and
you
know
it
fits
the
model
fits
very
well
in
envoy
now.
B
The
interesting
thing
is
webassembly
as
a
technology
is,
is
useful
in
the
browser.
C
B
Useful
in
envoy,
which
is
where
we're
you
know,
pretty
excited
about
that
yeah,
but
it's
also
useful
outside
of
those
you
can
use
them
to
extend.
You
can
use
webassembly,
for
example,
to
extend
the
control
plane.
Components
right.
You
could
use
webassembly
inside
of
kubernetes
employee
was
modules,
maybe
to
extend
kubernetes
itself.
So
the
this
idea
of
webassembly
as
an
extension
mechanism
is
not
limited
to
just
certain
hosts
right,
like
a
browser.
A
A
B
B
Well,
so
it's
so,
for
example,
a
request
comes
in
and
I
want
to
pull
the
jot
and
do
some
evaluation
of
the
jot
jot
token.
More
than
just
you
know,
making
sure
that
it
was
signed
correctly
right,
and
so
you
pull
that
down.
You
do
some
calculations.
If
you
want
to
reach
out
to
another
service,
you
you
don't
actually
write
the
code
to
do
that
envoy
will
give
you
a
handful
of
functions
that
you
could
call
that
are
managed
by
envoy
to
be
able
to
reach
out.
B
You
know,
make
http
call
or
okay
or
whatever
cool,
so
the
actual
computational
code
is
pretty
small
right.
It's
it's
not
a
it's
not
like
deploying
when
I
say
vm
don't
get
that
mixed
up
with
like
a.
B
Yeah,
so
the
vm's
actually
baked
into
envoy
you
just
deploy
the
code,
which
is
highly
sandboxed.
If
you
want
to
do
call
out
to
the
network
and
that
kind
of
stuff,
then
you
use
envoy
for
that.
So
your
code
is
actually
pretty.
A
Pretty
isolated,
pretty
tight,
pretty
small,
usually
just
you
know
a
tiny
little
binary,
that's
actually
getting
around
there
on
the
edge.
That's
right.
B
C
B
Put
it
into
envoy
or
into
a
certain
splash
or
glue,
or
something
and
solo
we've
been
we've
been
looking
at
that
problem
since
at
least
december
last
year
right
we
announced
something
called
webassembly
hub:
okay,.
B
C
C
A
Folks
in
chat,
so
they
can
check
it
out
for
sure,
but
having
an
oci
compatible
spec
makes
it
so
that,
basically,
anyone
can
make
use
of
this
hub.
A
B
So
we
just
wrote
a
blog
called
the
state
of
web
assembly
in
envoy
proxy
okay,
and
I
can
share
that
with
you.
I
think
it'd
be
useful
to
share
with
people
who
are
looking
at
this,
because
web
assembly
is
not
production
ready
or
at
least
webassembly
in
envoy
is
not
production
ready,
and
in
this
blog
we
try
to
outline
well.
B
What
are
the
pieces
involved
right?
What
you
know,
what
level
of
maturity
are
each
of
these
pieces
and
what
to
expect?
If
you
want
to
start
kicking
the
tires
today,
because
this
is
the
go
forward,
you
know
solution
for
customizing
your
data,
plane
and
networking
environment,
but
it's
not
there
yet,
and
so
in
that
blog
we
talked
about.
B
You
know
the
envoy
filter
the
envoy
interfaces
between
the
via
webassembly
and
and
envoy,
the
state
of
those
the
state
of
the
sdks
that
you
might
use
to
build
these
these
webassembly
modules
and
then
what
to
expect
from
from
poc.
B
And
so
I'm
answering
your
question
by
saying:
well,
there
are
things
like
evaluating
the
jot.
There
are
things
like
evaluating
headers,
adding
headers,
removing
them
yeah.
I
think
there
are
a
couple
where
they're
looking
at
the
body
and
maybe
doing
some
light
transformation
and
so
on,
but
the
capabilities
will
expand
to
the
extent
that
the
apis,
solidify
and-
and
you
know,
expand
in
terms
of
what
what
they
enable
you
to
do,
but
then
also
solidify
and
stabilize
so
that
people
can
actually
start
using
them
and
building
on
top
of
them.
B
Things
like
sdks
and
and
so
on.
So
that
is
still
in
flight,
but
it
is
seeing
a
lot
of
forward
progress.
So
I
don't
expect
it
would
be
too
much
longer
that
we
see
web
assembly
land
in
upstream
envoy.
B
First
of
all
and
then
from
there
the
abis,
the
binary
interfaces
between
envoy
and
web
assembly
start
to
stabilize
and
solidify,
and
then
you
know
sdks
a
lot
of
you
know
the
sdks
start
to
build
and
we
start
seeing
more
more
modules,
webassembly
modules.
A
So,
okay,
so
there's
a
question
in
chat
and
it
helped
me
eliminate
some
confusion
here.
Right
like
there's,
js,
there's,
css
and
then
there's
wasm
right
like
web
assembly
is
something
that
sits
on
the
proxy
side
or
it
could
essentially,
you
know,
be
part
of
the
website
itself
or
be
delivered.
As
you
know,
a
binary
that
runs
so
web
assembly.
B
In
the
browsers,
yeah
is
is
something
that
gets
delivered
along
with
the
js
css
and
html
right,
webassembly
in
onboard
proxy,
so
onboard
proxy.
We're
a
lot
less
we're
not
talking
about
json.js
and
css,
and
that
kind
of
stuff
we're
talking
about
giving
envoy
configs
to
make
it
behave
a
certain
way
and
this
webassembly
module,
which
changes
some
of
the
capabilities
or
enhances
some
of
the
capabilities
that
that
onboard
has
right.
So
it
is
in
a
browser,
that's
something
that
actually
gets
delivered
to
the
browser
browser
executes
it
in
an
envoy.
A
Awesome:
okay,
thank
you
for
clearing
that
up,
so
brian
tannis,
who
is
a
co-worker
of
mine,
he's
on
the
dev
advocate
team.
Now
he's
been
here
for
a
while
he's
trying
to
get
into
the
envoy
community
what
is
kind
of
like
the
road
you
know
the
road
to
get
in
involved
and
get
started
with.
You
know
contributing
upstream
to
envoy
and
then,
like
you
know,
helping
out
with
things
like
you're
doing.
B
Yeah,
I
would
say
envoy,
is
a
fairly
complicated
piece
of
technology
to
operate
and
to
use,
I
would
say
things
like
contributing
how-to
guides
or
videos
about
the
there's.
So
many
like
hidden,
I
feel
like
capabilities
of
envoy
proxy
unless
you're
the
one
that
helped
drive
that
feature
right.
Yeah,
you
know
it's
it's
sort
of,
or
are
you
scouring
the
docks,
there's
a
lot
of
capabilities
that
get
overlooked.
B
One
of
my
one
of
my
favorite
ones
that
gets
overlooked
is
envoy.
Has
the
ability
to
do
locality,
aware
load,
balancing,
but
also
something
called
request,
racing
or
request
hedging,
which
allows
you
to
send
a
request
to
a
service
and
if
that
service
doesn't
respond
in
a
given
certain
amount
of
time
right
it
times
out
envoy
can
resend
the
request
and
it
won't
give
up
on
that.
First
send
right
right,
even
though
it
timed
out
and
it
reached
and
issued
a
retry.
B
It's
still
going
to
wait.
So
whichever
request
comes
back
first,
so
if
maybe
it's
just
the
retrieve
request-
or
maybe
it
was
the
original
one
right
envoy
will
send
that
back,
and
so
that's
that's
like
one
example
of
many.
Many
that
the
resilience
and
networking
resilience
capabilities
of
envoy
that
are
baked
in
there
so.
A
There's
a
lot
of
those
yeah
there's
like
I
like
my
head,
just
exploded
with
all
the
capabilities
that
you
could
do
like
interconnectivity
with
like.
Oh,
I
need
to
call
these
seven
apis
or
I
need
to
pull
these
eight
files
or
whatever
right
like
try.
Another
endpoint
try
another
endpoint
try
another
endpoint
right.
Like
that's
amazing
wow,
you
could
build
a
ton
of
resiliency
right
there
under
your
edge
layer,
no
problem.
B
That's
right,
that's
right,
and
so
I
my
suggestion
is-
and
this
is
what
I
do
as
I
go
in
there-
what
what
help
understand
some
of
these
capabilities
help
explain
that
to
people
write,
blogs,
videos
whatever
and
then
you
know
slowly
start
to
understand
all
right.
What
is
the
configuration
look
like
for
envoy?
What
is
the
configuration
model
and
the
api
that
gets
used
for
that?
What
a?
How
is
it
implemented?
B
And
so
then
you
can
start
to
dig
a
little
bit
deeper
into
oh,
you
know
this
is
c
plus
plus
code
and
how
is
it
structured
inside
of
the
code
and
they
start
to
answer
questions
and
in
issues
on
the
public
chat.
You
know
either
on
slack
or
the
google
group
or
whatever.
B
A
So
yeah,
what
is
so
you
know
glue
is
new
glue.
Glue's
a
startup
glue
just
got
a
series
b.
B
B
So
at
solo,
like
I
said,
we're
core
competency
is
envoy.
We
believe
envoy
is
a
foundational
piece
to
this
next
generation
application.
Networking
that
manifests
in
two
big
ways.
One
is
service
mesh,
which
we
talked
about
today
and
one
is
the
edge.
How
do
we
get
traffic
into
our
our
clusters
into
our
mesh
and,
interestingly,
across
multiple
different
clusters
or
deployments,
or
clouds
or
on-prem
or
a
cloud
right
right?
You
need
some
edge
security
rate,
limiting
plus
transformation.
B
These
types
of
things
yeah
that
that
so,
but
that
also
ties
in
and
plays
very
harmoniously
with
the
service
mesh
right.
So
it's
solo
we
built
glue,
which
is
our
gateway,
edge
gateway,
solving
some
of
the
edge
problems,
request,
transformation
rate,
limiting
oidc,
oopa,
open
policy
agent
integration.
All
all
these
things
that
you
might
want
to
do
at
the
edge
right
and
then
ties
in
very
seamlessly
and
natively
with
a
service
mesh.
So
you
can
get
traffic
into
your
mesh
and
then
for
service
mesh.
B
We
we
have
a
enterprise
distribution
of
istio,
for
example,
and
we
support
istio
but
the
more
interesting
challenge,
and
this
is
why
I
said
we're
focused
on
the
challenges
that
enterprises
have
when
they
adopt
technology
like
this
is
how
do
they
operate
it?
How
and
so
there's
a
lot
of
nuance
to
that.
How
do
they
operate
it
across
multiple
different
groups
and
in
their
enterprise
right?
These
enterprises
need
different
apis.
A
B
Don't
use
that
api
directly
yeah
so
something
like
so
our
product
service
mesh
hub
focuses
on
you
know
what
what
are
the
right
persona
driven
apis
in
a
different
organization?
How
do
you
operate
this
thing
across
multiple
clusters?
Because
that's
not
simple,
how
do
you
do
service
discovery,
right,
identity,
federation
service
failover?
This
kind
of.
B
Really
hard
stuff,
the
last
part
is,
we
know
people
are
going
to
go
from
on-prem
to
a
public
cloud
yeah.
We
know
that
they
might
start
in
a
public
cloud
and
might
want
to
use
a
different
public
cloud
at
some
point
right
sure.
So
we
know
that
at
the
application
layer
at
the
networking
layer
it
really
shouldn't
matter
whether
you're
using
istio
or
app
mesh
or
both
right.
B
So
we
built
our
technology
to
be
able
to
accommodate
those
those
use
cases
and-
and
so
that's-
that's-
that's
a
very
and
then,
of
course,
the
web
assembly
stuff
sprinkled
in
between
right.
How
do
you
extend
the
capabilities
of
these
different
pieces
of
infrastructure?
So,
though,
that
that's
that's
what
we're
focused
on
at
solo.
A
With
content,
enablement
is
awesome,
good
suggestion.
Thank
you.
This
is
from
brian.
What
would
you
suggest?
Where
would
the
main
places
be
to
get
the
word
out
to
people
who
are
using
envoy?
Is
there
like
a
slack
a
google
group
I'll,
send
you
a
note
to
not
derail
the
conversation
thanks
again
but
yeah
like
where
do
where
do
envoy
people
hang
out?
I
know
there's
an
envoy
slack.
I
know
oh.
B
Yeah
there's
an
envoy
slack,
I
would
say
istio
I
was
any
of
the
service
members,
so
aws
app
mesh
has
a
slack.
Istio,
obviously
has
theirs.
Console
connect,
also
uses
envoy,
microsoft,
azure
announced
open
surface
mesh,
they
use
they
use
envoy,
yeah
and
there's
a
couple
others.
So
definitely
those
are.
Those
are
areas
of
interest
for
envoy,
I
would
say
things
like
api
gateways.
Like
you
know,
hours
blues,
open
source
project
right,
you
can
look
at
contour.
Oh,
I
missed.
I
missed
kuma,
oh.
B
There's
so
many
of
them,
I
know
it's
hard
to
keep
track
of
them
now,
yeah
those
areas
definitely,
but
in
general
I
would
say
anybody.
Who's
interested
in
kubernetes
should
be
also
interested
in
how
their
applications
talk
with
each
other
and.
B
And
so
those
those
those
communities
are
are
good
areas
as
well.
A
B
Yeah
I'm
on
twitter,
at
christian
posta,
first
name
and
last
name
emails,
christian,
solo.I,
o.
I
I
try
to
share
as
much
as
I
can
time
permitting
right
with
my
writing,
so
blog
dot
christianposter.com.
I
I
try
to
share
about
patterns,
share
about
the
experiences
that
I'm
seeing
in
the
field.
So
I
work
very
closely
with
with
customers
at
solo
and
and
I
I
try
to
bridge
the
the
marketing
bs
stuff,
which
is
necessary
with
the
with
the
on
the
ground.
B
This
is
what's
really
happening
at
large
enterprises
or
anybody
trying
to
adopt
this
technology.
A
So
are
you
that
guy
in
office
space
that
takes
the
stuff
from
engineering
or
from
the
managers
and
gives
it
to
engineering
right,
like
I'm
a
people
person,
damn
it
yeah
exactly,
but
no!
Your
content
is
fantastic
and,
like
I
I
I
devour
it
right
like
so.
Thank
you
for
putting
it
out
there
it
it
really
sheds
a
light
and
opens
my
eyes
to
the
world
of
service
meshes
and
envoy
and
proxy,
and
what's
going
on
in
that
whole
landscape.
A
It's
amazing
to
me,
like
web
assembly,
is
quite
possibly
a
game
changer
for
a
lot
of
different
things.
So
I'm
I'm
trying
to
keep
my
pulse
on
it.
The
best
I
can
there
are
newsletters
out
there
about
it.
There's
newsletters
about
envoy,
there's
newsletters
about
istio,
there's
newsletters
about
solo
and
glue.
I
bet
so
yeah
subscribe,
get
all
the
information
you
can
definitely
check
out.
Christian's
blog,
follow
him
on
twitter
for
sure,
and
thank
you
again
everybody
for
joining.
Thank
you
christian
for
joining,
and
you
know
check
out
solo
or
solo.I.
A
Oh,
I
can
say
that
right
check
out
solo
io
see
what
they
got
going
on
and
yeah.
We
look
forward
to
seeing
you
tomorrow
for
an
open
shift,
commons
briefing
and
and
when
in
doubt,
check
out
the
calendar
to
see
what's
up
next
and
subs
like
and
subscribe
wherever
you're
watching
us
from.
Thank
you
very
much
christian
and
everyone
else
we'll
see
you.