►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Panel Discussion: Ask Us Anything: Microservices and Service Mesh - Lin Sun, IBM; Jason McGee, IBM; William Morgan, Buoyant; Zack Butcher, Tetrate; and Louis Ryan, Google
Have you heard the buzz around microservices and service mesh lately? With containers becoming the new standard to building microservice based applications for production, users are leveraging 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, Lyft, Linkerd will address your most challenging inquiries around microservice and service mesh!
https://sched.co/MPfD
A
A
So
my
name
is
Lin
Chang
I
work
on
the
sto
project,
I'm
a
maintainer
on
the
project
I'm
also
serve
on
the
technical,
Oversight
Committee
I'm,
the
new
release
manager
for
one
that
you
release
and
also
I
work
for
IBM
and,
along
with
me,
we
have
four
great
panelists.
So
the
first
one
is
louie,
louie
ryan
he's
a
principal
engineer
at
Google.
I
would
call
away,
is
also
a
co-creator
of
the
Israel
project.
Back
then
at
Cuba
in
Seattle
about
three
years
ago.
That's
when
Israel
was
born
sounds.
A
On
the
very
next
person
I'd
like
to
introduce
is
Jason.
Mcgee
JC
is
the
VP
and
IBM
fellow
for
the
IBM
cloud
developer
services.
Only
in
Cuban,
IT
services
function,
services,
I,
think,
I
lost
track
of
all
the
services
are
Jason
owns,
Jason
is
also
a
co-creator
of
Sto,
and
one
thing
that
Jason
is
very
special
to
me
is
Jason
has
been
a
mentor
for
me
and
being
helped
me
working
on
containers,
and
it
still
else-
I
probably
wouldn't
be
here
today.
A
The
very
last,
but
not
the
least
I
would
like
to
introduce,
is
Zack
but
sure.
So.
To
me,
odd,
Zack
is
a
moving
target.
I
could
never
keep
track
of
him.
I
remember
when
I
met
him,
he
was
working
a
mixer.
He
was
introducing
mixer
adapter
to
everybody,
and
then
he
moved
to
work
on
pilot
and
network
him
component,
who
is
CEO
and
then
now
he's
working
as
a
funding
engineer
at
Petri,
so
not
sure
where
you
are
going
to
be
next
but
very
exciting
to
have
all
of
you
be
on
a
panel.
A
So
the
way
we
are
going
to
run
this
panel
is
I'm
going
to
get
started
with
a
few
questions
and
then,
after
that,
I'd
like
to
have
you
guys
engaged
because
this
panel
is
really
for
you
to
allow
you
guys
to
bring
the
questions.
So
we
can
ask
the
panelists.
So
the
first
question
I'd
like
to
kick
started
is
why
do
we
need
a
service
match
with
that
I'd
like
to
invite
the
panelists
to
jumpy?
A
B
Obviously,
I
think
they're.
The
service
meshes
come
out
of
a
variety
of
iterations
of
you
know
what
people
have
been
doing
in
the
networking
layer
for
a
number
of
years,
like
I,
would
imagine.
Most
people
here
had
probably
been
using
something
roughly
termed
an
API
gateway
right
for
a
long
time,
and
also
using
API
gateways,
not
just
for
kind
of
traffic
coming
in
from
outside
your
network,
but
also
for
things
moving
around
inside
the
network.
E
So
I
guess
for
me:
I
come
at
it
from
a
slightly
different
angle,
because
my
background
was
at
Twitter,
which
did
not
have
a
whole
lot
of
like
security
policy
kind
of
things
to
it,
mostly
Twitter
was
just
trying
to
stay
up
the
entire
time.
So
a
lot
of
the
focus
of
of
linker
D,
especially
early
on,
was
less
on
the
security
side
and
more
on
the
reliability
side
and
getting
deep
into
things
like
well.
How
are
we
gonna
do
retries
and,
and
how
are
we
gonna
do
request
balancing?
E
And
you
know
how
are
we
gonna
deal
with?
You
know
the
fact
that
under
crazy
load,
all
these
things,
you
know,
tend
to
die
in
all
sorts
of
horrible
ways,
and
we
need
to
have
these
mechanisms
for
for
preventing
that
over
time.
That's
that's
shifted.
Certainly,
if
you
look
at
kind
of
the
modern
incarnation
of
linker
D,
it
doesn't
really
share
any
code.
With
is
what
we
were
doing
it
at
Twitter
and-
and
we
have
you
know
things
like
docker
and
Cooper
Nettie's-
that
titter
didn't
have
so.
E
E
Think
a
lot
of
the
value
that
we
see
is
not
in
reinventing
that
stuff,
but
in
moving
it
down
to
the
platform
layer
and
out
of
the
application
layer
where
it
kind
of
fits
more
naturally
for
for
a
couple
reasons,
and
that
I
think
is,
is
a
lot
of
that's.
What
I
think
the
core
value
has
been,
because
it
allows
a
platform
team.
A
So
next
question
I'm
going
to
do
a
quick
show,
handing
our
audience
how
many
of
you
are
using
service
machine
production
wow.
That's
totally
surprising,
okay,
very
good
good
job.
So
the
question
I
have
for
the
panelist
is
what
other
scenario
any?
What
are
the
production
usages
you
see
of
service
match.
Attax.
Do
you
mind?
Go
first
yeah.
F
Sure
I
mean
so
when
we
talk
about
service
bonus,
we
kind
of
talk
about
these
three
pillars.
Right
so
rides
visibility,
observability
apps
are
observable:
the
traffic
management,
security
right
and
so
we've
seen
real
use
cases
that
focus
on
each
of
those
right,
the
the
best
way
or
the
most
successful
way.
We
see
people
adopt
a
service
specialist
to
pick
a
specific
pain
points,
pick
a
specific
use
case
and
use
the
best
to
solve
that.
F
And
then
once
you
have
that
piece
of
infrastructure
there,
it
tends
a
blown
out
right,
because
you
now
have
this
centralized
control.
You
can
now
start
to
impart
these
other
teams
to
interact
right,
so
we've
seen
it
so
I've
seen
people
adopt
them
as
for
each
of
those,
those
use
cases
right
and
it's
more
just
what
hurts
most
in
the
particular
organization
today
right
and
then
part
of
that
which
of
the
teams
is
the
one
funding
this
exercise
as
well
right,
because
your
central
platform
team
has
different
panes
than
your
security
team.
D
Mean
a
couple,
maybe
a
couple
of
concrete
examples.
So,
like
one
of
the
teams
using
sto
n
IBM
is
our
API
management
team.
They
built
a
product
called
API
Connect
and
you
know
their
use
cases
more.
You
know
to
kind
of
build
on
what
you
said
they
serve
with
observability.
You
know
they
have
a
hundred
and
seventy
ish
micro
services
that
they're
running,
and
they
put
the
surfers
mesh
in
place
to
say,
give
us
some
better
view
of
how
these
things
interacting
how
they're
behaving,
and
so
you
know
it's
interesting
scale,
a
couple
hundred
services.
D
You
know
that's
hard
to
hard
to
manage
and
and
it
still
helped
them
get
that
view
and
then
they're
kind
of
next
step
was
alright.
Now
we
want
to
turn
on
security.
You
know
we
want
to
turn
on
automatic
encryption
of
all
the
communications
and
services
service,
authentication
authorization
I
mean
another
example.
We
have
a
client
called
steel
house,
they
do
digital
advertising
they're
using
Sto
they're
more
like
thirtyish,
my
career
services
that
they're
running
in
the
mesh.
So
not
huge.
You
know
not,
you
know
not
two,
but
not
a
giant
number
I.
D
Think
for
them
is
more
about
control
of
traffic
performance
and
resiliency,
like
maybe
a
third
of
those
services
are
internet
facing,
so
you
know
they're
in
advertising,
so
latency
and
performance
they're
super
important
in
their
business
and
so
they're,
using
its
do
to
help
them
have
better
resiliency
and
control
over
those
things.
Just
two
examples:
that's.
E
E
So
Leo
Lang
is
going
to
talk
about
meshing
from
monolith
to
micro-services,
with
Lincoln
II
I
believe
that
was
that
offer
up
and
then
there's
a
really
interesting
talk
from
salt
at
VT
T,
which
is
which
is
a
finished
technology
organization,
building
cloud
native
GDP,
our
friendly
safe
systems
for
data
collection.
So
there's
like
a
wide
variety
of
uses
and
I.
Think,
like
you
know,
to
Zacks
point,
it
really
depends
on
what
the
starting
approach
is
and
what
that
immediate
pain
point
is
and
then
from
there.
G
B
B
B
I
would
certainly
recommend
that
people
try
write
the
the
various
service
mesh
implementations
and
see
which
one
they
feel
comfortable
with.
Obviously,
you
know
think
about
your
use
cases
and
look
at
the
features
that
the
products
present
and
you
know,
make
your
own
assessments
and
go
talk
to
people
I.
Don't
I
wouldn't
get
a
bearing
claim,
but
you
know
SEO
solves
world
hunger
and
you
know
I,
like
you
shouldn't.
Do
that
and
you
know
linker
T
is
a
good
product.
Look
like
good
people,
and
you
should.
You
know,
evaluate
their
stuff.
I
causes
world
hunger.
B
D
So
I
did
not
like
one
mash
implementation
versus
the
other,
but
I
do
think
you
know
the
architectures
that
were
putting
in
place
with
service
meshes
and
with
sidecar.
Architectures
do
add
a
small
amount
of
path
latency
for
most
applications
like
in
completely
insignificant
amount,
but
if
the
application
you're
gonna
run
on
a
mesh
is
incredibly
sensitive
to
path,
latency
and
extra
hops,
that
might
be
a
place
where
you
at
least
test
whether
the
surface
mesh
is
the
right
architecture,
because
you're
adding
you
know,
eight
millisecond,
ish
hops
in
between
services.
B
Probably
also
worth
pointing
out
that
there
are
kind
of
soft
landings
in
between
service
mesh
and
not
service
mesh.
You
know,
for
instance,
one
of
the
things
on
the
G
RPC
roadmap
is
to
support
some
of
the
same
control,
plane
api's,
so
that
they
can.
You
know,
use
that
for
service
discovery
and
load,
balancing
and
credential
loading
and
interoperate
with
other
things
that
are
in
a
service
mesh
or
behind
a
proxy
right.
That
is
conforming
to
the
same
set
of
standards.
So.
F
Another
example
is
just
deploying
a
sidecar
employee
with
a
static
set
of
configuration
right.
You
can
actually
wire
up
an
envoy
to
do
pass-through
things.
You
need
a
lot
of
visibility.
You
can
get
some
of
the
resiliency,
you
don't
have
the
active
control,
but
you
know
that's
like
a
reasonable
path.
That
gets
you
again.
It
depends
on
what
your
penis
right.
A
E
Louise
point
like
the
beauty
of
open
sources
that
you
can
try
these
things
and
you
can
come
up
with
very
concrete
answer
for
what
exactly
you're
gonna
get
and
what
exactly
you're
gonna
you
know
you're
gonna
have
to
give
in
order
to
do
this,
so
you
know
read
the
blog
post.
If
you
want
to
read
the
blog
post,
but
nothing
beats
actually
trying
to
get
it
working
and
from
the
linker
Deeside.
You
know
the
stuff
that
we
have
focused
on
primarily
has
been
I.
E
Think
on
operational
overhead
on
minimizing
that
at
the
expense
of
features,
so
there's
a
whole
set
of
features
that
link
turkey
doesn't
have
at
least
not
now
at
some
point,
and
you
know,
will
have
every
possible
feature
in
the
world.
But
you
know
if
you
need
something
today,
you
you're
making
it
a
trade-off
between.
You
know
what
what
are
the
feature
sets
and
what
am
I
gonna
pay
to
get
there
and
I.
Think
if
you
actually
start
experimenting,
you
know
you'll
get
a
pretty
concrete
sense
of
what
that
trade-off
is
like.
H
Thank
you.
So
my
question
is
I
know
a
link.
Tea
is
a
new
service,
mesh
implementation
and
well
Easter
is
some
some
longer
than
it,
and
the
Google
had
invested
unique
the
posting
tea
and
easier.
You
know
for
easier.
It's
a
funder
together
with
IBM,
and
the
Dinkley
is
also
the
university
allowed.
So
I
want
to
know
from
about
pound
how
you
what
your
bad
42
assessment
technology,
which
we
are
focus
in
in
the
future,
for
these
two
different
service,
meant
technology
between.
J
B
B
I
A
Think
her
question
was
many
around
Google
is
a
heavy
investor
in
sto.
As
everybody
knows,
Google
is
the
co-founder
of
SEO
major
contributor
to
the
project,
and
then
her
question
was
also.
There
was
a
blog
about
link
D
Sakura
$10,000,000
from
Google.
Venture
capital
is
Google,
which
horse
is
Google
vetting,
yeah.
E
Okay,
I
got
it
yeah
yeah,
so
I
can
I
can
talk
about
that.
So
the
let's
see
where
do
I
start
okay,
so
link
rudy
is
a
cnc
f
project.
One
of
the
I'd
say:
probably
the
primary
contributor
to
linker
t
at
this
point
as
a
company
called
poignant,
which
I'm
also
the
CEO
of
so
I
happened
to
know
kind
of
both
sides
and
I.
Wear
both
hats
I.
E
Wear
that
like
Lincoln,
do
you
maintain
her
hat
and
the
and
the
buoyant
CEO
hat
so
now,
I'm
gonna
take
off
my
linker
D
maintainer
hat
and
I'm
gonna.
Put
on
my
buoyant
CEO
hat
buoyant,
raised
some
money.
I
think
you
said,
10
million,
which
is
right
from
Google
Ventures
in
order
to
continue
developing
linker
T
Google
Ventures
is
not
a
strategic
investment
arm
of
Google
they're
a
separate
entity.
They
happen
to
have
the
letter
G
in
their
name
there
now
GV
they're,
not
Google,
Ventures
anymore,
they're
GV.
E
I
F
So
I
think
one
of
the
things
that
whoa
so
yeah,
so
it's
like
our
performances,
is
critical
right
and
Louis
mentions.
You
know
there
are
for
many
applications,
the
the
latency
overhead
that
a
sidecar
ads
or
the
performance
you
know,
costs
of
a
sidecar
is
pretty
irrelevant
compared
to
the
application
itself
right.
If
I'm.
E
A
F
But
yeah,
so
the
quick
answer
here
is
that
yeah.
So
it
adds
overhead
for
a
lot
of
large
class
of
applications
that
doesn't
matter
for
applications
where
it
does.
A
variety
of
options
are
being
developed
right.
So
we'll
see
the
side,
car
move
into
user
space
right,
we'll
see,
user
space,
IP
sex
and
long
jump
more
generally
speaking,
I
I
believe
that
we'll
see
heterogeneous
data
planes
in
mesh
deployments
over
time
right
and
that's
looking
quite
a
bit
further
ahead.
F
D
I
guess
what
I
would
add
is
I
think
we're
at
the
stage
where
we
spend
a
lot
of
time
looking
at
primitive
performance
of
the
componentry
of
the
mesh
itself,
because
obviously,
as
people
building
meshes
we're
trying
to
make
that
overhead
as
small
as
possible,
both
latency
and
CPU
and
memory
demand.
But
if
you
look
more
realistically
at
your
application
like
it
really
is
irrelevant
in
most
cases
and.
F
As
an
example
book
info,
when
you
run
it
without
a
service
mesh
and
when
you
run
it
with
SEO
and
when
you
run
with
linker
D,
the
Boren's
gets
better
with
both
of
the
service
meshes
versus
not
running
it
right
and
that's
because
of
the
connection
management
that
both
of
the
proxies
implement
that
for
a
variety
of
reasons
right
and
so
it's
another
one
of
those.
You
kind
of
need
to
see
with
your
with
your
applications.
It's
just
some
extent
as
well.
Yeah.
D
So
I
think
in
that
way
you
know,
we've
been
doing
psych
architecture
as
part
of
meshes
for
a
while.
Now
we
all
feel
pretty
confident
that
that's
a
good
approach,
it's
the
right
trade-off
on
what
you
were
after
William
I
think
would
just
get
it
out
of
the
application
space
and
get
it
into
the
platform
and
sidecars
are
really
nice
way
to
do
that
and
I
think
for
the
majority
of
applications.
The
performance
impacts
not
meaningful.
Yeah.
E
But
but
thinking
about
it
as
a
trade-off
is
exactly
right.
Like
we've
had
we've
had
folks,
who've
brought
linker
D
into
production
and
not
even
the
the
new
one,
but
like
the
old
one.
That
was
on
the
JVM
that
had
non-trivial
latency
and
they
did
it
and
they
didn't
care
about
that.
They
didn't
care
about
and
they
did
it
as
a
sidecar.
They
didn't
care
the
memory
consumption
because
in
this
case
it
allowed
them
to
get.
E
You
know
a
consistent
layer
of
mutual
TLS
and
between
all
their
applications
and
the
alternative
to
doing
that
was
having
to
talk
to
every
developer
team
of
every
service
and
get
a
you
know,
TLS
like
work
item
on
their
roadmap,
and
that
was
basically
an
impossible
task,
and
so
you
know
in
that
case
that
trade-off
made
sense
to
them.
You
know,
and
it
was
a
trade-off.
They
were
exchanging
kind
of
computers
having
to
do
more
work
with
the
organization
as
a
whole
being
more
efficient
and
I.
Think
that's!
E
What's
to
me,
that's
what
is
really
interesting
about
the
adoption
of
the
service
mesh
is
yes,
you're
paying
a
computational
cost
for
doing
stuff
right.
The
sidecar
model
you
know
by
its
very
nature
is
like
we're,
gonna,
add
proxies
everywhere,
and
then
we
have
to
talk,
you
know
and
and
and
it's
going
through,
the
network
stack
and
like
maybe
we
can
do
cool
stuff
and
like
reduce
the
cost,
and
you
should
try
and
reduce
the
cost.
But
you're
always
gonna
pay
a
price
right.
So
it's
it's.
E
A
C
So
I
was
wondering
about
patterns
or
tips.
You
might
have
for
people
who
are
moving
services
subsequently
onto
kubernetes,
but
you
might
still
have
some
legacy
services
running
on
premise,
because
the
features
you
might
look
at
in
a
service
match
are
very
different
when
you
only
compare
them
for
services
running
on
kubernetes,
as
if
you
want
to
take
others
into
account-
and
maybe
there
are
certain
patterns
that
you
encountered
in
the
world
that
might
help
with
this
endeavor,
even
just
completely
rolling
out
on
Prem.
B
Yes,
I
mean
you
know,
I
think
clinker
D
provides
support,
for
you
know,
making
sure
that
workloads
can
that
run
on
VMs,
not
just
in
kubernetes
can
be
involved
in
the
mesh
and
history
does
the
same
thing.
Obviously,
kubernetes
simplifies
the
kind
of
operational
aspects
of
kind
of
enrolling
workloads
into
the
mesh.
Obviously,
there's
a
lot
more
diversity
out
there
when
you're
talking
about
arbitrary
workloads,
running
on
VMs
or
bare
metal.
But
that
said,
you
know
the
there's
kind
of
two
classes
of
issues
that
go
along
with
bringing
these
things
into
the
mesh.
B
Mt
LS,
like
Williams
example,
deployed
into
that
infrastructure.
Right
you
had
no
other
way
of
doing
it.
You
couldn't
get
the
application
team
to
go
and
change
their
code.
The
other
thing
that
mess
provides
is
because
it
provides
a
higher
level
abstraction.
It
also
provides
a
mechanism
to
kind
of
bridge
networking
issues
across
these
types
of
deployments.
Right
because
you
know,
let's
say
your
VM
is
running
on
a
private
IP
space
on-premise
and
you
have
all
your
modern,
shiny,
kubernetes,
stuff
running
in
a
cloud
and
they're
not
on
the
same
network.
B
You
need
to
be
able
to
route
traffic
all
right
and
the
mesh
provides
abstractions
and
mechanisms
that
help
you
do
that
type
of
routing
right
with
security
end-to-end
all
the
way
through
that
system,
even
when
it
transits
over
the
public
internet
or
something
like
that
right.
Well,
that's
one
of
the
you
know
one
of
the
key
advantages
of
MPLS
is:
you
can
use
it
not
just
as
a
well
as
they
as
a
means
to
achieve
a
kind
of
point-to-point
micro.
B
You
know
VPN
right
and
get
all
the
security
properties,
but
it
can
also
act
as
a
routing
mechanism.
Right
because
sni
is
available
at
our
edge
points
in
that
network,
and
these
proxies
can
use
that
to
do
load
balancing
and
make
routing
decisions
without
introspecting
deeply
into
the
traffic,
which
is
a
nice
property.
A
D
Mean
I
would
add,
maybe
just
two
other
thoughts.
I
mean
I,
think
we
talked
about
the
idea
of
kind
of
taking
the
mesh
and
extending
it
into
the
existing
workloads,
which
both
meshes
do
I.
Think
sto
is
also
Duns
and
interesting
work
with
ingress/egress
gateways
and
kind
of
having
a
structured
way
in
and
out
of
the
mesh.
D
D
You
know
integration
patterns
with
existing
systems,
the
other
thing
which
I've
seen
happen
a
few
times,
which
I
think
is
quite
interesting
as
people
are
starting
to
put
in
systems
like
sto
in
place
to
get
visibility
into
the
existing
applications
to
help
them
understand
the
existing
world
and
how
it
talks
to
itself
and
use
that
information
to
help
them
refactor
applications
in
de
kubernetes
or
into
micro
services
or
whatever
they're
trying
to
do,
and
so
to
me.
That's
a
non
obvious
thing
like
when
we
started
this
service
mixture.
A
B
Well,
we
were
walking
around.
There
was
an
example
in
a
we
had
a
meet-up
yesterday,
and
somebody
had
written
a
plugin
for
is
do
that,
captured
DNS
requests
and
converted
those
DNS
requests
into
entries
in
our
service
registry,
so
that
you
kind
of
had
this
kind
of
adaptive
documentation
of
the
dependencies
of
workloads
that
you
didn't
really
know
what
they
were
consuming,
which
is
a
kind
of
interesting
taking
it.
L
For
William,
what's
the
difference
between
link
it,
not
just
sorry
I'll,
leave
that
one
alone
on
the
observability
side,
observability
in
a
cluster
of
many
micro
services,
can
obviously
create
a
really
large
stream
of
data.
That's
basically
impossible.
You
can't
have
someone
sitting
there
watching
it,
and
observability
is
going
to
also
mean
different
things
to
different
parts
of
your
organization.
What
sort
of
thoughts
around
that
do
you
have
about
making
the
observability
useful
to
those
different
parts
of
your
organized?
You
know
why
that's
not
overwhelming.
Oh.
E
E
What
I
think
is
interesting
about
the
the
visibility
that
the
service
mesh
can
give
you
in
terms
of
like
telemetry
data
or
observer
ability,
kind
of,
and
it's
a
similar
story
actually
for
reliability
and
for
security
of
the
three
pillars
that
Zack
talked
about.
Is
it's
not
a
complete
solution?
None
of
these
it's
a
complete
solution
right.
The
service
mesh
is
not
gonna
solve
all
your
security
problems.
It
can
be
a
part
of
it
and
it's
not
going
to
solve
all
of
your
visibility
problems
and,
in
particular,
because
of
the
way
that
it
it
works.
L
F
Business
metrics
tend
to
be
not
necessarily
directly
related
to
the
operational
metrics
that
a
mesh
typically
generates
and
in
two
ways
point
that
is
one
of
the
key
gaps
right
and
it
could
be
very,
very
challenging
to
try
and
and
deduce
the
correct
business
behavior
from
these
operational
metrics
right
so
to
some
degree,
that's
not
necessarily
the
the
problem
that
these
particular
metrics
are
trying
to
solve
right.
There
they're
incredibly
valuable.
F
They
can
do
things
like
build
these
graphs
and
give
you
deeper
insight
that
is
very
valuable
to
to
more
of
the
organization,
but
in
terms
of
just
the
raw
data
itself,
you
know
the
goal
is:
is
that
it
be
operational,
big
kind
of
because
of
the
nature
of
how
the
mesh
operates
right,
because
it's
a
black
box?
That's.
D
Would
add
maybe
one
other
thing
which
is
you
know,
I
think
service
meshes
are
kind
of
a
new
collection
of
primitives.
You
know
like
a
new
source
of
really
interesting
data
that
we
didn't
have
before
and
a
new
source
source
of
kind
of
controls
over
the
environment
we
didn't
have
before,
but
there's
a
tremendous
opportunity
and
space
for
tools
above
the
mesh
to
leverage
that
right
and
and
lots
of
monitoring
tools
are
gonna.
D
Take
this
new
source
of
data
and
give
you
those
different
views
and
insights
I
think
to
see
ICD
tools,
there's
a
huge
space
for
them
to
take
some
of
the
route
controls
that
exist
in
meshes
and
leverage
it
to
do
a/b
testing
and
to
do
canary
and
to
make
the
richer
and
so
like
part
of,
is
just
building
the
ecosystem.
On
top
and.
F
I'll
go
so
far
as
to
say,
because
we're
we've
been
implementing
messages
to
me
at
least.
Actually,
the
mesh
now
is
kind
of
the
boring
part,
and
the
things
you
can
do
on
top
is
really
the
the
interesting
piece,
because
you
have
this,
this
common
set
of
data,
and
in
this
touch
point
you
can
start
to
do
really
incredible
things.
Over
top
there's.
E
Which
will
drive
a
see
I
Drive,
a
canary
or
a
Bluegreen
deployment?
Look
at
the
success
rate
of
the
new
code,
and
if
it
you
know,
the
success
rate
is
dropping
that
it'll
like
roll
it
back
and
that's
like
a
perfect
example
of
you
know
how
you
can
take
these
primitives
provided
by
the
service
mesh.
There's
another
really
cool
project.
Ida
stumbled
across
called
coop
cost.
We'll
give
you
a
breakdown
of
like
what
the
cost.
You
know.
E
You
know
when
you're
running
your
stuff
on
gcp
and
you're,
getting
these
big
bills
it'll
break
down
exactly
what
the
costs
are,
and
you
can
any
can
tie
into
the
surface
mission.
They
can
say:
hey
here's
a
cost
per
request.
You
know
here's
how
much
it
actually
cost
you
to
serve
each
API,
endpoint
and
I.
Think
that
kind
of
stuff
is
super.
Super
cool
that.
F
E
A
J
B
I
J
B
Certainly
have
a
roadmap
that
is
aggressively
trying
to
squeeze
the
CPU
footprint
down
and
the
latency
footprint
down.
Some
pretty
largest
changes
went
into
the
1.1
release
and
we
turned
off
policy
checking
by
default
through
the
mixer
pipeline,
because
most
people
weren't
using
it
they
were
using
the
arbok
feature
which
was
implemented
in
the
data
plane
directly.
We
have
some
stuff
in
the
works
to
squeeze
down
the
cost
of
our
Prometheus
integration,
which
is
being
used
by
most
the
end
users,
and
there
were
some
that
made
a
couple
of
talks.
B
There
was
a
talk
today
about
envoy,
extensibility
and
use
of
webassembly
as
part
of
that,
and
that's
something
that
we'll
probably
aggressively
leverage
to
kind
of
put
more
features
directly
in
the
data
plane
and
control
them
with
the
control
plane
and
use
that
to
squeeze
down
resource
custom.
So
there's
just
quite
a
large
amount
of
stuff
coming
on.
E
The
linker
decide
we're
pretty
happy
at
this
point,
with
the
memory
footprint
and
overall
with
latency,
but
I
also
think
link
Rd
CPU
is
is
too
high,
so
there's
and
that
is
I
think
mostly
just
a
matter
of
like
we
need
to
sit
down
and
do
some
profiling
and
tuning
we've
been
so
focused
on
like
building
out
the
core
functionality.
You
know
that
you
know
now
now
find
the
squeeze.
You
know,
squeeze
the
grapefruit
and
get
the
juice
out
or
whatever
the
analogy
is,
and.
B
You
know
what,
while
we
have
all
told
you
that
you
know
when
you
should
look
at
the
relative
cost
of
the
match
to
your
applications.
I
see
benchmark.
Think
that
meshes
are
an
order
of
magnitude
more
expensive
than
they
can
be,
and
that
that
optimization
work
just
hasn't
happened
yet,
and
that's
not
speculation
right
because
of
based
on
work
that
we've
done
internally
at
Google
with
our
internal
mesh.
We
have
a
very
good
idea.
What
the
costing
an
overhead
should
be
in
certain
circumstances,
and
it's
just
it's
an
engineering
grind
right.
B
F
D
About
just
everything,
I
mean
know
what
the
only
thing
to
add
is
make
sure
you
look
at
it
in
context,
though,
like
remember
part
of
the
reason
we
were
started
to
build
meshes
was
to
take
functionality
out
of
the
applications
that
was
getting
built
into
every
service
and
put
it
in
the
platform
so
like.
How
much
would
it
cost
you
to
do
all
that
stuff
in
your
application?
D
L
E
Mean
that
that
company,
that
deployed
like
JVM
linker
D
as
a
sidecar,
like
tens
of
thousands
of
on
tens
of
thousands
of
servers
like
they
were
really
happy
with
the
result
right
and
like,
and
it
was
not
because
it
was
particularly
faster
or
low
latency
it's
because
of
what
it
allowed
them
to
do.
Yeah.