►
From YouTube: Keynote: A Simplified Service Mesh With gRPC - Srini Polavarapu, Engineering Manager, Google
Description
Keynote: A Simplified Service Mesh With gRPC - Srini Polavarapu, Engineering Manager, Google
gRPC is a popular choice for building microservices based applications but it does not have any native service mesh features such as service discovery, load balancing, application security and observability. A service mesh typically provides such features via sidecar proxies deployed alongside the microservices. In this session, we will introduce the new exciting development of service mesh features in gRPC and show how to bring the benefits of a service mesh to your gRPC applications without the complexity of managing sidecar proxies. We will also talk about the architecture and show how you can go from a proxy based service mesh to a proxy-less service mesh with gRPC.
A
A
A
A
A
Now
I
will
also
say
that
service
meshes
are
cool.
As
you
know,
microservices
is
the
name
of
the
game
when
you
want
to
build
scalable
and
highly
available
applications,
so
it
is
also
known
as
service
oriented
architecture,
where
a
large
application
is
divided
into
many
small
services
that
talk
to
each
other
over
the
network.
A
A
So
these
are
common
problems
on
which
an
application
developer
should
not
be
wasting
their
time
and
that's
where
a
service
mesh
is
very
useful
to
solve
these
issues
seamlessly
so
as
an
example
check
out
istio,
which
is
an
open
source
service
mesh
solution,
and
that
is
gaining
a
lot
of
popularity.
These
days.
A
A
A
The
sidecar
proxy
gets
service,
mesh
policies
from
the
control
plane
and
apply
them
on
the
intercepted
requests.
So
there
is
one
sidecar
proxy
on
each
end
of
the
connection
providing
client-side
and
server-side
mesh
functionality
right
so,
like
any
other
application,
a
grpc
app
client
would
do
a
dns
lookup
of
the
service.
It
is
trying
to
connect
to
and
open
one
connection
to
the
virtual
ip
of
the
service.
A
A
A
Now
this
looks
similar
to
the
look
aside,
grpc
lb
solution
that
I
showed
earlier,
but
here
grpc
would
be
talking
a
much
broader
set
of
data
plane
apis
that
enable
supporting
a
large
number
of
features
available
in
a
service
mesh
right.
So
the
key
thing
to
note
here
is
that
we
won't
need
a
sidecar
proxy
in
the
middle.
A
A
The
lessons
we
learned
from
clb
protocol
showed
us
that
picking
the
right
data
plane,
api
is
the
most
important
thing,
so
data
plane
apis
are
used
to
exchange
configuration
data
between
the
control
plane
and
the
data
plane.
Components
like
the
proxies,
in
contrast,
control,
plane
apis,
are
used
to
program
the
control
plane
itself
with
information
like
what
are
the
services
in
the
mesh.
A
A
Also
it
should
fit
the
current
grpc
architecture
and
align
with
our
vision
of
no
vendor
lock-in
right,
so
xts
apis
fit
the
bill
perfectly,
and
these
apis
were
developed
for
onboard
proxy,
which
is
a
very
popular
proxy
used
in
many
service.
Mesh
solutions
like
istio
and
because
of
that
xts
apis
have
become
a
defect
to
standard
for
data
plane
apis,
and
there
is
also
an
effort
going
on
to
evolve
these
apis
into
universal
data
plane
apis
for
layer,
4
to
7
data,
plane
configuration.
A
A
A
A
A
The
country
may
include
various
rules
like
match
on
header
values
or
a
path
and
then
route
to
a
particular
cluster
and
apply
a
particular
timeout
or
maybe
insert
a
header
right,
so
once
the
proxy
knows
which
cluster
the
request
needs
to
be
sent
to.
It
then
uses
cluster
discovery
service
to
get
cluster
information
like
what
is
the
load
balancing
policies
and
what
are
the
security
policies
if
any
right?
So
a
cluster
is
basically
the
implementation
of
your
service
in
the
form
of
end
points
right.
A
A
A
So
when
you
create
a
client
channel
in
grpc
to
connect
to
a
service,
you
need
to
use
the
xds
scheme
instead
of
the
default
dns
scheme,
and
this
scheme
tells
the
client
channel
that
an
xts
resolver
needs
to
be
created
in
order
to
resolve
the
service
name
and
and
then
it
sends
an
lds
request
to
resolve
the
name.
So
if
the
service
exists,
then
it
uses
rds
to
get
the
routing
rules
associated
with
that
service.
A
So
a
routing
lb
policy
is
then
created
to
match
the
rpcs
against
the
match.
Rules
right
so
so,
based
on
the
route,
action
of
the
match,
rule
a
traffic
splitting
policy
or
a
a
single
cluster
load.
Balancing
policy
is
created
and,
as
I
said
earlier,
a
cluster
is
made
of
end
points
in
different
localities.
A
A
A
Okay.
So
how
do
you
enable
xts
in
your
grpc
applications
and
go
proxy
less?
It
is
quite
easy,
instead
of
using
the
default
scheme
when
you
create
a
channel
just
use
the
new
xds
scheme
that
tells
the
client
channel
to
start
an
xts
resolver
instead
of
a
dns
resolver
right.
So
in
this
example,
you
can
see
how
xds
scheme
is
used
to
connect
to
a
service
called
foo
dot
my
service
right.
A
But
then
how
does
a
grpc
application
know
which
xts
server
to
talk
to
so
the
address
and
the
credentials
of
the
xts
server
needs
to
be
provided
via
a
bootstrap
file
in
the
local
file
system
and
the
location
of
the
file
is
provided
via
an
environment.
Variable
called
grpc,
xts
bootstrap,
so
the
bootstrap
can
contain
some
other
information,
such
as
a
unique
client
id
its
locality
and
any
other
data
that
is
relevant
to
a
particular
xds
server.
Implementation,
such
as
a
project
number
or
a
or
a
network
number.
A
A
A
A
So
you
could
have
a
fast
application
bottlenecked
by
a
slow
proxy
right
so
and
also
a
sidecar
proxy
requires
a
complex
set
of
ip
filter
rules
for
intercepting
traffic
that
are
not
needed
in
a
proxy
list
deployment
and
because
the
grpc
uses
xts
to
resolve
a
service
name,
you
can
even
get
away
without
configuring.
Dns
entries
for
the
services
also
proxies
are
additional
binaries
running
in
your
service
mesh.
A
A
So
so
what
are
the
downsides?
So
mature
proxies
like
envoy
are
very
feature
rich
and
there
is
a
large
ecosystem
of
third-party
filters
and
tools,
especially
in
the
area
of
observability,
but
we
are
actively
working
on
adding
more
features
in
grpc
to
close
the
feature
gap
so
note
that
grpc
provides
extensibility
with
interceptors
and
there
is
a
good,
open,
sensors
and
open
tracing
integration
for
observability.
A
A
A
A
We
are
also
making
good
progress
on
adding
route
matching
based
on
path
and
header
values
and
splitting
traffic
to
multiple
clusters.
There
are
several
other
features
in
the
design
phase
and
we
are
migrating
from
xts
version
2
to
version
3
sometime
this
year.
So
you
can
watch
the
progress
on
github
and
you
are
very
welcome
to
contribute.