►
From YouTube: Panel Discussion: Ask Us Anything: Microservices and Service Mesh - Moderated by Jason McGee
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Panel Discussion: Ask Us Anything: Microservices and Service Mesh - Moderated by Jason McGee, IBM (Any Skill Level)
Have you heard the buzz around microservices and containers lately? With containers becoming the new standard to building microservice based applications for production, users are leveraging the service mesh to solve common issues with routing, re-routing for graceful degradation as services fail, secure inter-service communication and rate limiting between services. Join us for a live interactive session where our panel of experts from IBM, Google, Envoy, and RedHat will address your most challenging inquiries around microservice and service mesh!
About Matt
Matt Klein is a software engineer at Lyft and the architect of Envoy. Matt has been working on operating systems, virtualization, distributed systems, networking, and making systems easy to operate for over 15 years across a variety of companies. Some highlights include leading the development of Twitter’s C++ L7 edge proxy and working on high-performance computing and networking in Amazon’s EC2.
About Sven
Sven is a Senior Staff Software Engineer at Google, and one of the founders of the open source Istio project. He joined Google in 2006, and has spent the past 10 years working on several generations of Google's API Management platform, starting with the AtomPub-based Google Data APIs. Prior to joining Google, Sven worked for Salesforce.com, where he helped design and build the SOQL language for querying hosted object databases. Sven received his BS in Computer Science from Stanford University and his PhD in Computer Science from UCLA. He currently resides in a redwood forest in the Santa Cruz mountains, east of Half Moon Bay, and enjoys spending time with his wife and three children hiking through the woods and counting banana slugs.
About Joy
Joy is a software engineer at Google and a technical lead of the Istio Config Working Group. She also contributes to Istio service broker and Istio integrations. Prior to that, she spent 10+ years in software development and research across a variety of areas: mobile clients, data analytics, and optical networks. Joy received her PhD in Electrical and Computer Engineering from University of Illinois, Urbana-Champaign. She currently lives in Kirkland, Washington with her husband and 3 kids.
About Jason
Jason McGee, IBM Fellow, is VP and CTO of Container and Microservice Tribe. Jason leads the technical strategy and architecture across all of IBM Cloud, with specific focus on core foundational cloud services, including containers, micro-services, continuous delivery and operational visibility services. Previously Jason has served as Chief Architect of PureApplication System from inception to a mature $100+ million product.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
All
right
we're
gonna
go
ahead
and
get
started.
So
thanks
for
coming.
This
is
a
ask
us
anything
panel
on
surface
mesh
and
micro
services.
So
this
will
only
be
interesting
if
you
guys
have
questions
and
things
you
want
to
talk
about.
It's
not
a
presentation.
Maybe
we'll
start
with
introductions.
I'm
Jason,
McGee
I'm
from
IBM
I
run
our
container
and
kubernetes
services
at
IBM
Matt
you
want
to.
He
has
a
mic
hi.
B
C
E
A
So
maybe
I'll
kick
it
off
with
the
question
to
you
guys,
because
we've
we've
been
talking
about
surface
mash
a
lot
so
how
many
people
in
the
room
I
think
they
understand
what
service
mesh
is
about.
Let's
start
with
some
basics,
all
right
good,
because
you
wouldn't
come
to
this
panel,
if
you
didn't
so
maybe
we
can
start
with
a
little
bit
of
perspective
from
you
guys
and
kind
of
where
we
are
with
service
meshes.
C
How
do
they
go
about
adopting
it
and
I've
seen
several
different
patterns?
One
of
the
patterns
is
just
getting
a
better
understanding
of
what's
running
in
my
environment,
so
installing
sto,
enabling
the
sidecar
proxy
with
Envoy
gives
them
immediately
a
set
of
metrics
and
telemetry
that
from
day
one
just
by
turning
it
on
they
start
to
be
able
to
see.
Oh,
these
are
the
interested
services
that
are
participating
in
my
mash
and
here's
the
traffic
going
between
them.
C
D
Sure
yeah
I
think
the
we've
seen
something
very
similar,
but
the
people
we've
been
talking
to,
although
we
also
we
have
different
sets
of
people
that
are
interested
in
different
things,
which
is
kind
of
fun.
So
there
are
people
that
just
are
like
hey
I
want
to
know
what
the
heck's
going
on.
There
are
other
people
that
are
really
really
interested
in
the
security
aspects.
They
tend
to
be
banks,
and
you
know
financial
institutions,
things
that
need
to
protect
their
data
really
really
carefully.
D
So
they
were
interested
in
that
and
then
we
also
get
people
that
just
want
the
traffic
management
parts,
so
they
want
to
canary
rollouts.
I
saw
the
thing
on
get
ops
earlier
right.
People
really
liked
that
kind
of
just
roll
things
out
slowly
and
you
know,
try
out
the
different
features
and
get
the
retries
and
all
that
kind
of
good
stuff
right.
A
F
So
I
have
follow
a
lot
of
presentation
on
this
tracking
service
mesh
and
then
just
before
this
one
I
went
to
Nats
presentation
that
I
would
qualify
as
a
traditional
message,
oriented
middleware
and
within
our
company
we
are
trying.
We
are
thinking
about
moving
from
a
message
oriented
middleware
towards
a
service
mesh.
What
would
be
for
you?
They
the
main
difference
and
the
main
reason
to
move
from
a
message:
oriented
middleware
to
a
service
mesh
architecture,
I.
B
Guess
I
would
start
by
saying
I,
don't
I,
don't
think
it's
an
either/or,
I
I
think
there's
I
think
we're
seeing
a
big
movement
towards
people
building
dual
architectures.
You
know
that
are
both
message
based
as
well
as
pops
up
and
I
think
my
recommendation
would
be
to
look
at
the
problems.
You
know
that
you're
trying
to
solve
from
a
business
perspective
and
I
think
you'll
you'll
pretty
naturally
see
that
some
of
them
are
pub/sub
problems
and
some
of
them
are
you
know,
messaging
problems
or
just
basic
RPC
problems.
B
I
think
the
larger
question
is,
you
know:
can
service
mesh
help
you
with
pub/sub
and
so
so
far
I
think?
That's
not
the
case.
I
I
think
most
of
the
service
mesh
deployments
have
been.
You
know
very
RPC,
focused
I,
think
it's
gonna
change
I,
like
I'm,
expecting
there
to
be
Kafka's
support
and
I'm
boy,
probably
by
the
end
of
the
year
and
they're.
Actually
a
company
already
did
not
support
in
anon
boy,
so
I
think
you're,
gonna
start
seeing
actually
even
they're
being
like
a
dual
deployment.
D
D
C
Well,
definitely
in
the
modern
service,
Metra
is
one
of
the
the
biggest
value
propositions
is
that
you're
you
get
the
benefit
of
taking
a
lot
of
the
specific
complexity
that
you
have
to
add
to
your
application
that
gets
removed
from
your
application
and
is
pushed
into
the
mesh
itself
into
the
network
to
handle
a
lot
of
that
complexity,
the
routing
decisions,
the
metering,
the
telemetry,
the
policy
enforcement,
the
security
aspects,
mutual
TLS
communication
between
the
services.
You
don't
build
that
into
your
application.
C
A
Mean,
though
I
guess,
the
one
other
thing
I
would
add
is
I,
think
the
kind
of
traditional
reverse
proxy
or
edge
architectures,
or
you
have
something
sitting
in
the
edge
we're
designed
around
a
kind
of
more
classical
one
directional
tear
flow.
You
know
you're,
coming
in
from
the
outside
you're,
going
into
a
web
tier
and
back
and
I
think
with
the
adoption
of
micro
services.
You
have
a
much
more
complex
flow
of
messages
between
services.
Some
things
are
on
the
edge.
D
As
a
an
anecdote
at
Google,
we
used
to
run
a
giant
edge,
reverse
proxy
written
in
Java,
and
it
got
we
were
running
in.
You
know
not
quite
double-digit
millions
of
QPS
but
close
to
that,
and
we
just
started
to
fall
apart
scaling
was
it
just
couldn't
handle
it,
and
so
we
rewrote
everything
from
scratch
as
a
distributed
proxy,
and
now
it's
you
know
10x
that
and
no
problem,
so
there's
definitely
scaling
limits
to
the
edge
proxy
model
as
well.
F
D
Say
absolutely:
it's
depends
on
what
you
what
you're
getting
out
of
it,
but
if
you
want
to
do
Canaria
rollouts
of
any
of
those
services.
So
if
you
just
have
one
service
and
you
want
to
Canary
rollouts,
it
can
help
you.
If
you
have
two
services
and
they're
talking
to
each
other,
and
you
want
that
security.
It
can
help
you
so
yeah,
I
think
unless
you,
you
know,
don't
run
anything
and
you
should
probably
give
the
service
man
if
the
numbers
zero.
Now.
C
E
Yeah
I
agree
with
that,
because
how
we
evolving
to
have
surveyed
Amash
is
we
looking
at
those
common
features
between
services?
So
we
kind
of
forgiving
a
abstraction
of
those
among
features
and
put
a
provider
into
service
mesh,
and
you
can
do
it
through
configurations,
and
so,
when
you're
looking
at
each
services,
then
developer
can
focus
on
their
business
and
that
they
don't
need
to
worry
about
developing
all
those
networking
code
or
there's
how
to
worry
about
how
I
can
kind
of
put
into
my
code
how
to
get
connected
and
putting
on
security
authorizations.
E
You
don't
need
to
worry
about
that
or
this
and
we
were
putting
like
features
like
transcoding,
and
you
can
pretty
much
write
your
service
in
G
RPC,
for
example,
and
we
can
having
API
service
for
you
to
expose
as
HTTP
REST
API.
So
things
like
that
so
and
there's
a
lot
of
advantages
and
I.
Don't
think
really
you
need
to
think
about
if
we
have
to
do
service
mesh
at
the
scale
and
it's
pretty
recommended
to
studying
day
one
I.
B
Will
give
you
probably
a
slightly
less
bullish
answer?
I
I,
think
I
agree
with
everything
that
was
said
in
terms
of
the
the
benefits
are
large,
but
I
would
say
that
we're
in
pretty
early
days
kind
of
some
of
the
tooling
around
around
these
products
and
it's
not
free
to
roll
this
out.
So
it's
like
you,
know,
I
lift.
Now
you
know
we
have
hundreds
of
services,
but
you
know
we
have.
B
C
But
you
got
to
be
aware
that,
as
as
you
grow,
you
do
have
to
manage
the
the
control
plane
if
you're
installing
it
yourself,
you
do
have
to
manage
the
the
service
mesh
helps
with
complexity,
but
in
and
of
itself
introduces
its
own
set
of
complexity,
because
there's
a
lot
of
policies
potentially
over
time
that
you
now
have
to
understand
and
manage
those
so
having
a
good
CI
CD
process
around
those
things.
It's
still
critically
important
in
order
to
support
those
and
you're
also
dealing
with
kubernetes
and
kubernetes
scale
numbers
right.
C
There's
there's
like
physical
numbers.
Like
the
number
of
containers,
you
can
run
on
a
a
node
and
that's
gonna.
Have
some
bearing
when,
as
you
scale
up,
okay
you're,
adding
a
side
card
to
every
pod?
Well,
that's
a
container
if
you're
running
three
or
four
not
a
big
deal.
If
you're
running
10,000,
that's
a
big
deal
and
they
start
to
add
up,
so
you
got
to
be
aware
of
that
and
what
the
impact
is
to
your
system,
so
nothing's
for
free.
I
B
B
Recently
we
built
like
a
G
RPC
access,
log
streaming
system
and
now
at
lift.
We
have
a
huge
amount
of
effort
going
into
taking
those
proto's
and
putting
them
into
like
a
Hadoop
style
MapReduce
system
so
that
we
can
do
long-running
queries.
It's
like
there.
There
are
just
questions
that
you
cannot
answer
any
other
way
other
than
doing
potentially
long
long
running,
queries
over
access,
log
data.
C
J
Hello
I
have
a
question
regarding
we
are
creating
a
product
that
is
installed
in
someone
else's
cluster
on
premises
and
during
development,
we'd
like
to
strip
out
all
that
circuit
breaking
stuff
and
push
it
put
it
to
a
service
mesh,
but
the
service
measures
are
quite
a
cluster
ineffective.
So
if
you
want
to
use
it,
you
use
it
for,
like
all
your
services.
Basically
at
least
that's
what
I
understood
so
far.
Are
there
any
possibilities?
How
I
could
make
use
of
it
in
a
limited
set
of
use
cases
yeah.
D
That's
a
great
question
actually
so
today,
not
really
at
least
not
with
sto
and
so
alright,
because
you
have
to
kind
of
install
the
whole
control
plan
and
stuff
with
with
just
envoy.
Absolutely
you
can
do
that.
You
can
just
run
envoy
on
the
on
your
parts
and
you'll
get
it
for
your
connections.
That
is
something
that
the
ISTE
o
project
has
looked
at
as
a
potential
area
to
try
to
fix
more
and
I
think
sort
of
to
what
Matt
was
saying.
As
companies
start
offering.
B
There's
there's
one
thing
that
I
would
add
to
that:
is
that
I
think
the
way
that
people
deploy
service
matches
currently
there's
kind
of
two
ways
of
doing
it.
The
first
way
is
what
I
would
call
the
fully
transparent
service
mesh
and
that's
typically,
where
you'll
run
the
sidecar
you're
gonna
use
a
bunch
of
IP
tables
magic,
it's
a
kind
of
redirect
a
bunch
of
ports
and
things
to
your
sidecar
and
it's
all
magical.
Maybe
she
don't
do
that
at
at
lyft.
B
Everything
else
goes
direct,
so
I
I
think
that
the
flipside
of
that
is
that
you
know
just
envoy.
It's
there's
a
lot
of
configuration
and
a
lot
of
complexity
and
not
to
be
taken
lightly,
so
the
benefit
of
the
control
planes
like
sto
and
a
bunch
of
the
other
products
that
are
not
coming
out
around
envoy
is
that
they
make
some
of
these
common
case
configurations
easier,
but
they
don't
always
support
some
of
these
split
use
cases.
C
And
definitely
sto
has
it
has
a
certain
way,
as
as
Matt
was
pointed
out,
how
it
programs,
the
sidecars,
and
a
lot
of
that
is
to
keep
things
simple
right.
You
do
have
the
ability,
though,
if
you
want
to
roll
out
services
in
your
cluster,
you
can
enable
sidecar
injection
for
only
a
subset
of
the
namespaces
and
using
it
is
a
fairly
granular.
Well,
it's
not
it's
not
individual
services
at
this
point,
but
at
least
at
the
namespace.
C
D
Just
want
to
add
one
thing,
which
is
because
this
question
is
really
interesting:
I
think
we
haven't
really
spent
time
thinking
about.
Okay,
if
someone
has
a
kubernetes
cluster
is
their
way
to
create
a
helmet
art
that
sort
of
service
mesh
if
I'd
and
install
it
in
the
cluster
without
first
getting
the
cluster
as
part
of
a
service
mesh,
and
we
know
that's
kind
of
what
you're
asking
I
think
and
we
haven't.
We
haven't
spent
time
figuring
out
if
that's
possible
or
how
to
do
it,
but
it
is
really
interesting.
K
Thanks,
so
we're
using
Castillo
for
service
routing
cadena
like
a
cluster
and
we're
currently
getting
in
a
state
that
we're
not
only
getting
lambdas
executed
in
our
cube
lists
run
time
that
we
run
in
there.
But
you
get
more
and
more
demand
for
like
full
containers
to
be
executed,
and
since
we
treat
them
as
untrusted
code,
we
need
to
find
a
way
to
sandbox
them.
K
D
A
D
A
Right
I'll
try
the
summarize
to
tell
me
if
I
get
it
wrong.
So
the
question
was
in
his
scenario:
they
have
cases
where
they
need
to
be
able
to
run
untrusted
containers
they're
using
sto
or
using
using
STR
using
sto,
and
so
one
of
the
ideas
they
had
was
used
virtual
couplet
to
redirect
the
untrusted
containers
into
something
like
Azure
container
service,
or
something
like
that
and
his
question
is:
if
you
did
something
like
that,
how
would
I
steal
play
with
that?
Would
that
be
a
problem
or
not
be
a
problem?
C
D
C
D
You
have
a
cluster
of
your
local
cluster,
then
you
have
a
different
cluster
or
whatever
on
on
a
provider
running
okay,
so
well,
I,
don't
know
if
it
helps
or
not,
but
the
one
of
the
things
coming
out
actually
in
the
next
release.
Diversity
is
the
multi
cluster
support
so
being
able
to
connect
multiple
clusters
into
a
single
mesh
you
do
have
to
so.
The
earlier
point
be
able
to
install
sto
in
each
of
the
places,
but
then
once
you
do
that
absolutely
actually
SDO
gives
you
a
lot
of
benefits
in
that
model.
E
I'm
not
sure
so
two
relevant.
If
I
understand
your
question
correctly,
you
still
have
a
ingress.
It
has.
It
basically
has
a
great
way
in
the
SAP
traffic's
from
outside
of
the
mesh
and
also
allow
us
to
have
a
egress
and
the
directing
traffic
from
inside
a
mesh
to
outside
of
mesh.
So
and
if,
if
you
think
it's
worthwhile
to
go
through,
those
traffic
is
through
gateways
and
we
have
a
rich
settings
and
you
can
do
and
they
can
do,
is
like
security,
terminations
and
and
all
these
features.
E
A
B
So
I
I
can't
speak
for
Sto
I,
don't
know
what
sto
exposes
currently,
but
in
Envoy
we
have
two
types
of
consistent
load:
balancers
implemented.
We
have
a
Gotama
ring,
hash
load,
balancer,
and
then
we
have
a
maglev
float
balancer.
It's
also
a
consistent,
consistent,
hashing
algorithm,
and
then
we
have
a
way
of
hashing
based
on
cookies
or
like
IP,
addresses
and
stuff
like
that
and
it's
pretty
extensible.
So
we
can,
we
can
add
other
things.
B
I
think
Microsoft
is
actually
doing
some
work
around
I
like
there's
a
bunch
of
stateful
stuff
that
they
do
so
they
added
like
range
routing
from
headers,
so
I
mean
that
the
the
answer
is
yes,
in
fact,
like
we're
using
envoy
at
very
high
scale.
To
do
Redis
at
lift
I.
Think
I
need
to
know
a
little
more
about
your
specific
use
case
to
answer
yes
or
no
so
happy
to
talk
after
but
I
don't
know.
If
someone
wants
to
cover
the
the
sto
case,
I
mean.
C
From
the
from
the
sto
case
that
can
be
exposed,
I
mean
if
it's
supported
from
Envoy
that
can
be
exposed
through
the
routing
rules
to
make
available
as
part
of
the
decision.
When
you
set
up
your
routing
policies
and
the
routing
rules,
and
ultimately
it
comes
down
to
if
it
is
supported,
then
it's
something
we
can
expose
through.
Okay,.
N
B
My
personal
opinion
I
think
that
the
way
that
the
industry
is
going
is
that,
like
we're
in
this
middle
ground
right
now,
where
we
were
going
from
bare
metal
vm's,
now
we're
doing
containers.
But
containers
is
not
the
end
state
like
the
end
state
is
probably
serverless,
which
is
really
in
its
infancy
right
now.
B
The
reason
that
I
bring
that
up
is
that
in
the
long
run,
I
don't
think
you
configure
anything
I
mean
like
I,
think
it
just
basically
works,
we're
probably
10
years
away
from
that,
but
we're
we're
kind
of
in
we're
just
in
this
middle
ground,
where
people
are
building
these
kind
of
micro
services,
distributor,
architectures
and
it
is
really
complicated
and
I.
Think
that
I
think
that
there's
going
to
be,
you
know
a
set
of
vendors
and
services
and
all
these
things
that
will
grow
up
around
the
ecosystem.
B
That
will
make
it
simpler,
but
we're
not
we're
not
there
I
know
and
that's
why,
when
the
person
in
front
of
you
asked-
but
you
know
before
about
like
should
I
run
a
service
match,
it's
not
a
simple
question
right
now,
because
it's
very
complicated
and
I
think
every
what
I
tell
people.
You
know
I'm
somewhat
infamous
at
these
like
conferences
where
people
love
to
tell
you
about
all
the
new
things,
I'd
like
to
tell
you
to
stay
on
your
monolith,
because
it's
easier
so
I,
you
know
it's.
C
And
that
goes
back
to
the
one
thing
I
was
saying
earlier,
while
the
service
mesh
does
help
to
solve
complexity
and
and
bring
some
semblance
of
control
into
some
of
the
complexity
in
your
containers
and
micro
services,
it
introduces
its
own
set
of
complexities
and
I
agree
with
Matt
I.
Think
what
what
you'll
see
here
is
that
tools
are
gonna
evolve
to
help
with
that
complexity.
C
I'm,
a
strong
advocate
that
you're
see
icd
process
has
to
be
a
mature
process
for
handling
your
source
of
truth,
and
you
manage
those
changes
through
your
CI
CD
process
and
if
you've
got
a
stronghold
on
a
very
mature
CI
CD
process
that
helps
a
lot,
but
I'm
also
very
much
aware
that
I
failed
four
or
five
times
creating
one
of
those
types
of
pipeline
processes,
so
those
aren't
easy
to
build
either
and
do
it
properly
in
scale.
So
complex
problems
are
complex,
so
I
would
also
say,
be
cautious
about
trying
to
adopt
everything.
C
All
at
once,
I
mean
you
can
you
can
grow
into
it,
definitely
understand
what
you're
getting
into
learn
along
the
way
and
as
you're
learning
understand
what
those
pieces
are
doing,
so
that
you're
only
using
what
you
need.
Don't
don't
use
everything.
That's
there
just
because
it's
there,
because
that's
more
complexity
than
what
you
need
and
that's.
D
That's
one
of
the
things
we're
we're
actively
working
on
on
this
new
project
at
least
is
trying
to
make
it
make
that
base
install
smaller
and
easier
and
simpler,
so
that
you
don't
kind
of
get
over
overwhelmed
with
complexity
right
away
that
you
can,
just
you
know,
just
take
routing,
just
take
loop
balancing
and
just
take
little
pieces.
I
will
say
that
sort
of
talking
about
the
future
Google
actually
does
not
is
not
at
the
server
list
part,
but
in
terms
of
like
running
micro
services.
D
We've
been
doing
this
for
a
long
time
and
internally
I.
Don't
think
about
any
of
this
stuff
right,
I,
don't
think
about
security,
because
it's
taken
care
of
I,
don't
think
about
the
quota
system
other
than
having
to
configure
it,
because
it's
just
there
and
there's
a
team
that
runs
it
right.
There's
a
team
running
all
these
things.
It's
it's
like!
There's,
vendors
and
I
think
the
industry
will
get
there
to
where
there
are
vendors.
D
A
I
mean
that's
to
some
extent
the
the
motivation
here
so
take
the
practices
that
we've
been
using
and
turn
them
into
software
that
everyone
else
can
get
their
heads
around.
So
it
may
seem
complex,
but
it's
even
now
I
think
it's
less
complex
than
you
assembling
it
all
yourself
and
I.
Think
in
the
project.
As
we
work
to
make
it
kind
of
incrementally
consumable,
then
people
can
pick
up
the
pieces.
They
want
right.
You
guys
have
to
keep
you
know
we,
the
community,
have
to
keep
the
project
honest
as
we
go
that
you
know.
A
E
I
think
a
one
of
the
huge
benefit
is
if
you're
looking
at
the
perspective
from
developers
and
their
jobs
is
much
easier
and
they
can
be
more
focused
and
also
like
they
can
be
just
like
you
can
think
of
offering
works
developing
around
that
was
Easter
mesh
and
you
can
just
using
those
frameworks
to
writing
services
and
that's
aspect.
It's
very
scalable.
M
B
This
this
comes
up
at
every
conference.
It
is
the
thing
that
I
warn
people
about
the
the
most.
So
my
standard
disclaimer
is
you
know.
Service
message
is
great
rah-rah,
it's
not
totally
magic
and
mostly
around
trace
context
or
context
propagation,
and
you
know
won't
have
time
to
give
you
the
give
a
whole
talk
on
this.
B
It's
a
pretty
complex
subject,
but
the
industry
has
done
a
relatively
poor
job
of
helping
people
do
context
propagation,
it's
a
it's
a
hard
problem,
just
because
there's
no
standardized
way
of
doing
it
and,
in
fact,
in
certain
languages
it's
really
hard
like
NGO
makes
it
very
difficult
to
do.
I
am
hopeful
that
with
libraries
that
are
coming
out
like
open
census
and
also
you
know
some
of
the
open
tracing
work
and
stuff
like
that.
I
hope
that
that's
a
vehicle
for
making
this
process
easier
and
better.
B
It's
like
look
for
a
header
store
the
header
in
some
context
and
then
forward
the
header
out
the
other
side
when
you
make
outbound
calls,
but
given
for
a
larger
company
where
you
might
have
hundreds
of
services
and
you're
trying
to
get
people
to
upgrade,
it
may
take
you
six
months
or
more
to
actually
make
that
happen.
So
we
had
foresight
at
left
to
know
where
we
were
going
and
we
actually
started
the
context
propagation
process
very
early.
B
So
by
the
time
that
we
were
ready
to
do
tracing,
we
already
had
the
contact
propagation
code
in
place,
so
we
implemented
tracing,
we
flipped
the
switch
and
we
had
100%
coverage.
But
if
you
don't
think
about
the
context
propagation
now
you
you
won't
get
that
and
tracing
is
one
of
those
things
where
I
actually
think
that
one
of
the
reasons
that
tracing
I,
don't
want
to
say
has
a
bad
name
or
people
are
more
dubious
about
its
value.
C
It's
probably
worth
noting
that
in
is
do
well.
A
lot
of
things
are
magical.
You
just
turn
it
on
and
you
get
all
this
value
for
free.
That
is
one
of
the
areas
that
it
doesn't
come
for.
Free
you,
you
do
have
to
make
those
modifications
even
in
is
do
they.
We
can't
do
them
for
you,
the
mesh
can't
do
it
for
you.
You
have
to
do
this
in
a.
D
Second,
shout
out
to
open
census.
There
was
a
talk,
I
think
yesterday
about
it
to
definitely
look
into
open
census.
If
it
your
needs,
use
it
we're
putting
a
lot
of
effort
into
it.
We
Google
not,
we
is
do
the
other
thing
to
know.
Actually
yeah
do
context.
Propagation
context.
Propagation
is
for
more
than
just
tracing.
D
F
B
So
the
the
library
that
I'm
talking
about
is
in
each
language
that
lyft
uses,
we
have
a
thin
library
called
envoy
client.
So
we
have
one
for
PHP
and
go
and
Python,
and
that
library
is
not
very
large.
It's
like
100
or
200
lines
of
code,
but
basically,
what
it
does
is
it
guides
developers
into
simpler,
our
pcs,
so
instead
of
having
to
know
to
connect
to
envoy
on
port
foo
or
whatever,
like
it'll,
do
that
for
you
and
you'll
be
able
to
instantiate
an
envoy
client
say
I
want
to
talk
to
this
service.
B
It'll
set
up
sensible
defaults
for
retries
and
circuit
breaking,
and
things
like
that
and
allow
you
to
override
it
and
it'll
do
context
propagation.
So
that's
like
the
most
important
thing
at
that
that
library
does
so
from
a
developer
productivity
perspective.
I
would
I
would
recommend.
I
would
recommend
looking
into
that
just
because
I
think
it's
a
way
to
abstract
the
mesh
a
little
bit.
B
This
question
comes
up
a
lot
and
I
I'm
gonna
go
look
into
it
because
I
don't
I,
don't
want
to
say
that
we're
gonna
like
open
source
this
code
and
maintain
it,
but
is
the
kind
of
code
which
I
think
I
can
just
copy
somewhere
and
just
like
just
show
it
to
people
but
yeah,
basically
just
drop
it,
because
it's
not
that
miyoko,
but
I
think
it
would
be
very
instructive.
So
this
comes
up
a
lot
this
will.
This
will
be
my
next
reminder
to
go
and
and
think
about
that.
So.
D
I
think
that
the
I'm
gonna
have
a
different
take
on
what
I
think
the
question
was,
which
was
more
about
having
envoy
itself,
be
a
library
that
you
can.
So
if
your
application
is
C++,
then
you
would
be
able
to
just
sort
of
you
know,
import
the
Envoy
library
and
build
a
binary.
That's
both
on
the
way,
and
your
thing
know.
Is
that
not
your
question.
Your
question
was:
is.
D
D
You
don't
need
the
Envoy
stuff
you
can
actually
just
you
can
get
all
the
benefits
of
the
the
mesh
just
from
that,
and
it
already
has
some
of
those
parts
and
that's
what
Google
has
been
doing
internally,
but
Google
actually
is
switching
from
that
to
a
sidecar
model
where
we
actually
do
have
a
sidecar,
but
the
sidecar
doesn't
proxy
the
requests.
It's
just
used
for
all
that
extra
logic,
so
you
don't
have
to
write
it
in
all
the
languages.