►
Description
Service Mesh use cases for Telco and Edge - Kunal Shukla & Prajakta Joshi, Google
Service Mesh is a key paradigm for Telco, 5G and Edge. In this session, the speakers deep dive into how Service Mesh delivers technical and business value for use cases like: - Service Mesh for modern service ops for Telco - Service Mesh for managing heterogeneous environments with container and openstack/VM services - Service Mesh for 5G Core service based architecture - Telco Security - Consistent service management across multi-cloud and Edge - Extending the experience of Cloud to the Edge The speakers also describe some of the new capabilities that are needed in service mesh for these use cases and the road ahead.
A
B
A
To
talk
to
you
about
some
of
the
key
industry
trends,
drivers,
opportunities
and
challenges
within
the
telco
and
edge
industry,
let's
start
with
a
closer
look
at
key
industry
trends
that
are
driving
the
edge
and
telco
model.
I
have
summarized
them
in
three
areas:
our
lives
are
changing
the
way
we
work
the
way
we
live.
The
way
we
play.
We
live
in
a
world
of
connected
everything,
ericsson
predicts
25
billion
connected
devices
by
2025,
and
these
devices
will
generate
huge
amounts
of
data.
A
This
has
led
to
a
strong
focus,
around
edge
initiatives
and
edge
as
a
business
service
platform
to
deliver
new
business
outcomes
and
solutions
for
enterprises
next
is
telco
transformation.
The
telco
industry
has
gone
through
tremendous
transformation
in
the
last
five
years
to
build
the
foundation
of
next
generation
networks
for
consumers
and
enterprises.
A
A
Third
is
5g:
5g
is
not
just
another
ge.
Historically
2g
3g
4g
has
focused
on
wireless
technologies,
spectrum
utilization
and
getting
bandwidth
to
consumers
like
you
and
me,
5g
bring
forwards
a
paradigm
shift
and
promises
to
deliver
service
based
architecture
focused
on
end
user
experience
and
services
through
concepts
such
as
network
slicing,
better
control
management.
A
A
A
B
A
With
the
drivers
discussed
in
the
earlier
slide.
The
industry
is
seeing
a
left
shift
in
moving
cloud
environments
towards
the
edges
at
google.
We
already
are
extending
our
good
gcp
google
cloud
into
our
pops,
but
are
extending
our
partnership
with
telco
to
bring
our
cloud
environments
to
the
telco
edges,
which
are
in
thousands.
A
A
A
For
example,
retail
is
looking
at
edge
and
5g
to
drive
consumer
experiences,
such
as
queue
management,
heat
maps
for
product
placement,
dress,
your
look
using
arm
vr
and
no
contact
checkouts.
In
addition,
they
are
looking
at
self
cleaning
and
self.
Storing
robots
for
manufacturing
manufacturing
is
looking
at
driving
operational
efficiencies
in
connected
factory,
by
reducing
the
faults
found
using
ai
and
ml
based
solutions.
A
A
Telcos
are
providing
5g
connectivity
that
is
dedicated
to
the
enterprise
customers,
to
which
all
the
devices
in
the
enterprise
locations
are
connected.
In
this
example,
all
traffic
coming
from
video
cameras
in
the
warehouse
location
would
be
kept
on
the
enterprise
location
based
on
enterprise
policies.
A
A
A
You
being
able
to
browse
the
high
speed
data
on
your
phone
or
home.
These
are
the
applications
which
make
it
happen
so
number
one
is
a
multi-vendor
cloud
native
network
function.
Environment
number
two
is
service
based
architecture,
5g
networks,
leverage
service
based
architecture,
with
the
applications
built
using
microservice
methodology
with
the
micro
services
based
architecture
in
5g.
It
will
ultimately
evolve
into
a
complete
service
mesh
with
service
discovery,
load,
balancing
encryption,
authentication
and
employing
sidecar
for
inter-service
communication
taking
the
cloud
native
and
micro
services
based
application.
A
You
have
j5g
core,
where
you
will
have
rest
of
the
control,
plane,
applications
and
data
management
application,
and
you
will
have
the
public
cloud
where
you
are
bringing
in
new
differentiated
applications
on
the
5g
network.
Essentially,
this
will
enable
a
distributed
cloud
deployment
model.
The
last
thing
is
dynamic.
Network
slicing
5g
introduces
a
concept
of
network
slicing
by
which
telcos
can
provide
you
a
dedicated
network
slice
based
on
different
traffic
types.
A
You
could
be
an
enterprise
asking
for
a
network
slice,
you
could
be
a
manufacturing
entity,
you
could
be
connected
cars
or
you
could
be
an
iot
service
provider.
Each
of
these
solutions
can
be
provided.
A
network
slides
based
on
the
network
on
based
on
the
traffic
type
overall
5g
telco
network
is
more
than
just
speed.
A
It's
about
how
you
enable
consumers
and
enterprise
experience,
enable
machine
to
machine
communication
at
scale,
deliver
ultra
reliable
low
latency
use
cases
such
as
autonomous
vehicles
drones
ar
vr,
which
will
truly
transform
the
consumer
and
businesses,
while
the
promise
of
edge
and
5g
with
telcos
is
appealing.
There
are
multiple
challenges
that
need
to
be
addressed
in
order
to
truly
realize
this
at
scale.
A
B
A
It
at
scale
the
second
is
the
focus
of
enterprise
and
consumer
services.
The
resources
needs
to
be
scaled
dynamically
without
any
business
impact.
So
that's
where
dynamic
service,
scalability
and
performance
comes
in.
The
third
area
is
around
service
definition
and
orchestration
across
vm
and
containers
in
a
distributed
cloud.
Environment
applications
will
be
running
on
vms
and
containers.
How
do
you
manage
them
both
and
using
that?
How
do
you
provide
end-to-end,
slas
and
availability
across
the
business
critical
systems
residing
in
these
distributed
cloud
environments?
A
The
next
one
is
with
network
slicing
ability
to
imperatively,
deploy
manage
measure,
and
this
network
slices
at
service
level
becomes
extremely
important,
and
the
last
part
is
around
harmonization
of
service
control,
service
mesh
across
multi-vendor
application
and
network
functions.
So
how
do
you
provide
that
multi-vendor
service
control?
A
A
B
Thank
you,
kunal
hello,
everyone,
I'm
prajaptha,
I'm
the
product
lead
for
cloud.
Networking,
telco
and
edge
in
google
cloud
as
canal
described.
Service
mesh
is
a
key
paradigm
for
solving
many
challenges
for
cloud
telco
and
edge
use
cases
as
discussed
as
an
industry.
We
have
three
big
opportunities
to
tap
into
for
telco
and
edge.
First
is
working
with
telcos
to
transform
their
it
network
and
services.
B
This
is
going
to
be
fueled
by
leveraging
the
best
of
technologies,
experience
and
talent
that
telcos
public
cloud
providers
isps
and
others
have
with
all
of
us
becoming
better
in
the
process.
The
second
major
opportunity
is
around
delivering
value
to
enterprises
with
edge
computing
solutions
and
5g
as
a
business
services
platform.
This
will
create
new
revenue
streams
for
the
broader
ecosystem.
B
The
third
one
is
as
much
an
opportunity
as
a
necessity
to
enable
the
first
two
opportunities.
It's
about
breaking
down
the
silos
that
have
existed
between
the
network
and
services,
platforms,
paradigms
service,
orchestration
automation
and
more
use
by
telcos
and
public
cloud
providers.
It's
also
about
jointly
jointly
building
pieces
that
don't
exist.
Yet
that's
how
we
can
unlock
seamless
delivery
of
services
across
a
global
distributed
agent
cloud
now
to
do
this.
We
need
open,
scalable,
resilient
network
and
services
platforms
that
can
work
across
telco
cloud
and
edge.
B
Now
here's
how
I
generally
explain
service
mesh
to
networking
and
telco
folks
think
a
few
years
back,
you
had
all
of
these
complex
network
appliances
and
then
came
software
defined,
networking
or
sdn
and
it
disaggregated
these
closed,
complex
appliances
into
a
control
plane
and
a
data
plane.
The
data
planes
were
simple
and
forwarded
traffic.
These
data
planes
were
controlled
by
sophisticated,
often
logically,
centralized
control,
plane,
think
of
service
mesh.
As
software
defined
networking
for
services.
You
take
a
complex
application.
B
B
One
of
the
biggest
benefits
of
service
mesh
is
that
it
decouples
development
from
operations,
which
means
developers
no
longer
need
to
write
and
maintain
policies
and
networking
code
inside
their
applications.
Service
mesh
does
not
make
any
assumptions
about
where
your
service
is
or
whether
it
is
instantiated
on
vms
or
containers
or
bare
metal.
That's
why
it
provides
a
framework
that
can
be
used
consistently
across
multi-cloud
deployments
across
heterogeneous
vm
and
container
environments
and
for
telco
and
edge.
B
What
are
the
benefits
of
service
mesh
so
first
of
all
is
to
simplify
networking
architecture
and
deploy
advanced
traffic
management
capabilities
easily.
The
second
is
to
enhance
security
and
encrypt
all
data
in
transit
by
automatically
using
mtls
on
all
calls
within
the
mesh
use
policy.
To
allow
only
explicitly
permitted
calls
third
is
to
ensure
more
uptime,
safer,
rollouts
and
lower
time
to
resolution
with
logs
telemetry
and
traces
gathered
for
every
service
in
the
mesh.
B
Let's
take
a
closer
look
at
the
service
mesh.
Basically,
a
mesh
abstracts,
the
notion
of
a
distributed
system
network
from
the
application,
because
the
individual
services
are
not
aware
of
the
network
at
large.
They
only
know
about
their
local
proxy
in
this
model
and
each
proxy
is
configured
and
administered
separately.
Service.
Mesh
control
plane
takes
these
onboard
data
planes
or
these
whichever
the
service
proxy
is
and
configures
them
into
something
larger
by
providing
unified
configuration
and
management
and
then,
depending
on
the
implementation
added
intelligence
to
these
service
proxies.
B
One
of
the
most
popular
ways
to
implement
a
service
mesh
is
using
what
I
just
referred
to,
which
is
the
open
source
envoy
proxy
deployed
next
to
the
application
logic,
and
then
the
data
plane
of
the
envoy
is
managed
by
a
service
mesh
control,
plane.
The
service,
mesh
control
and
data
plane
speak
the
open,
xds
protocol.
This
is
also
evolving
and
envoy
makes
the
data
plane
highly
programmable
and
extensible,
and
it's
one
of
the
most
popular
proxies
on
the
market.
B
There
are
many
implementations
of
service
mesh
today.
Some
of
these
are
also
aiming
to
solve
new
problems
with
mesh
constructs
or
to
bring
mesh
constructs
to
solve
layer,
two
three
issues
or
provide
a
platform
for
building
new
service
control
planes
or
to
provide
an
abstraction
layer
that
can
help
you
plug
in
one
or
more
meshes.
Under
this
layer,
personal
favorite
is
high
tower
service
mesh.
B
B
Let's
take
the
example
kunal
described,
we
want
to
build
a
smart
retail
solution
for
a
retail
store,
but
the
solution
is
going
to
be
hosted
across
the
retail
store,
telco
network
edge
and
cloud.
What
are
the
capabilities
of
service
mesh?
We
can
leverage
here,
first
of
all,
according
to
gartner,
very
small
percentage,
so
about
five
percent
of
enterprise.
Apps
worldwide
are
containerized.
B
B
B
You
can
also
steer
traffic
to
services
based
on
http
headers.
When
there
is
a
match,
you
can
configure
a
variety
of
actions,
traffic,
splitting
redirects,
url,
rewrites
and
much
more
fault
injection
helps
you
test
the
resiliency
of
services
to
different
forms
of
failures,
like
delays,
aborted
requests,
etc.
By
simulating
various
service
failure,
scenarios
like
high
latency,
partial
availability,
overloads
and
so
on.
B
As
a
part
of
fault
injection,
when
the
client
sends
request
to
back-end
service,
delays
can
be
introduced
by
the
service
mesh
control
plane,
in
this
case
traffic
director
on
a
percentage
of
requests
before
sending
those
requests
to
the
backend
service.
Similarly,
requests
from
clients
to
a
backend
service
can
be
aborted
by
traffic
director
for
a
percentage
of
requests.
B
One
feature
I
personally
love
is
traffic
mirroring.
This
feature
allows
a
shadow
application
to
receive
real
traffic,
which
is
processed
by
the
main
version
of
the
app
it's
fire
and
forget,
which
means
responses
received
by
the
shadow
service,
are
discarded
a
fire
and
forget
traffic
mirroring
can
be
a
powerful
test
to
test
binaries
with
production
traffic,
and
it
can
also
help
you
debug
errors
happening
in
production
using
the
shadow
service.
B
One
of
the
key
considerations
in
telco
and
edge
use
cases
is
the
ability
to
provide
end-to-end
visibility
and
slash
in
a
service
mesh.
Every
service
is
inherently
observable
and
it
emits
signals
you
can
easily
set
up
metrics
emission
collection
tracing
and
then
build
out
closed
loop
automation
to
act
on
the
gathered
insights.
B
Antho
service
mesh,
for
example,
from
google,
has
comprehensive,
sli,
slo
sla
management
capabilities.
Many
other
service
mesh
implementations
provide
related
capabilities
as
well
service
in
mesh
aims
to
make
granular
and
service
level
policy
driven
security
and
enforcement.
Easy
to
deploy
the
service
mesh
traffic
can
be
automatically
encrypted
using
mtls
configuration,
configurable,
authentication
policies
and
secure
naming
information,
ensure
authorization.
B
You
can
have
fine-grained
role-based
access
control
at
the
application
layer
for
micro
segmentation,
and
then
you
can
combine
service,
mesh
security
and
observability
to
perform
security
auditing,
as
well
as
for
detecting
and
investigating
anomalies
service
mesh
enables
you
to
specify
traffic
management,
security
and
observability
policies
at
the
service
level
in
a
compute
agnostic
manner
for
telco
and
edge.
One
key
requirement
is
to
manage
a
mixed
environment
of
vmn
container
services.
The
other
use
case
is
to
migrate.
B
Vm
based
services
to
container
services
using
cap
grow
drain
strategy
in
the
past,
telcos
had
mpls
networks
and
they
wanted
to
migrate
to
optical.
They
started
doing
this
using
a
strategy
called
cap
grow
dream
the
first
time
I
heard
this
term.
It
was
from
atnj
and
onf.
So
you
cap
your
mpls
networks,
you
grow
optical
and
you
drain
existing
mpls
to
optical.
B
The
same
applies
to
transition
from
vm
to
container
services,
continue
to
support
existing
deployments
with
vm
orchestration,
introduce
a
container
platform
like
google
cloud's
answers
for
all
new
containerized
deployments
and
then
slowly
drain
vm-based
services
to
container
services
in
the
interim
period,
when
telcos
have
both
vm-based
services
and
containerized
services,
these
can
co-access
seamlessly
and
interact
with
each
other
at
the
service
mesh
layer.
Since
the
service
mesh
is
compute,
agnostic,
telco
and
edge
environments
will
often
have
legacy
appliances
or
clients
alongside
cloud
native
services
and
clients.
B
Imagine
you
have
a
legacy
client,
where
you
cannot
insert
an
unwipe
proxy
now,
since
load
balancing
in
a
mesh
is
client-side,
then
how
do
you
split
the
traffic
from
legacy
client
to
say,
v1
and
v2
of
the
prediction
service,
as
you
did
before?
You
can
do
this
by
inserting
a
managed
middle
proxy
based
on
envoy.
You
can
think
of
this
as
an
envoy
based
layer.
7
internal
load
balancer,
and
then
you
can
specify
traffic
splitting
or
any
policy
on
the
l7
ilb,
which
you
cannot
perform
on
the
legacy.
Client.
B
This
was
one
of
the
reasons
we
built
out
a
new
flavor
of
services
in
the
mesh,
the
proxy
list
service
traffic
detective
support
for
proxy-less
grpc
services
is
based
on
a
simple
idea.
If
traffic
director
can
configure
site
car
proxies
to
do
load
balancing
on
behalf
of
a
grpc
client,
why
not
just
have
it
configure
the
grpc
client
directly
to
make
jr
proxy
list
jrpc
possible?
We
continued
to
adhere
to
the
open
xds
api
and
we
added
this
xds
api
support
to
the
most
recent
version
of
grpc.
B
The
xts
api
is
the
same
open
source
apis
you
use
for
envoy
proxy,
which
means
you
get
a
level
of
consistency
for
telco
and
edge.
We
see
three
main
use
cases
for
the
proxy
list:
grpc
approach,
simplified
grpc,
adoption,
high
performance
services
in
a
service
mesh
and
bringing
service
mesh
to
environments
where
you
cannot
add
a
sidecar
proxy.
B
In
this
example,
the
service
is
deployed
at
the
telco
edge
approximate
grpc
services,
actually
there's
one
more
interesting
innovation
to
keep
an
eye
on
which
is
bringing
programmability
to
the
client
and
endpoint
through
envoy,
mobile
and
grpc
web.
This
will
help
create
a
true
end
to
end
stretching
from
the
client
to
the
edge
to
the
cloud
and,
and
we
continue
to
go
and
do
more
stuff
in
this
area.
B
One
more
key
use
case
of
service
mesh
is
cross
cluster
cross
region
and
cross
edge
failover
for
tel
point
edge
use
cases
now.
Typically,
if
you
did
this
on
your
own,
this
involves
a
lot
of
toil
and
setting
this
up
to
solve.
For
this
use
case,
we
built
cross
cluster
cross
region,
overflow
and
failover
capabilities,
inherently
into
our
service
mesh
through
a
service
mesh
control
plane,
which
is
traffic
director.
With
these
capabilities,
you
can
easily
deploy
a
service
with
vm
or
container
instances
in
multiple
regions
and
also
with
endpoints
in
non-gcp
locations.
B
Now
the
front
end
service
instances
in
the
closest
region
to
the
end
user
have
no
capacity
traffic
will
automatically
shift
over
to
the
other
region.
If,
for
some
reason,
if
any
of
the
services
say
like
the
payment
micro
service
goes
down,
then
traffic
automatically
shifts
to
the
other
reason
region.
To
avoid
outage.
B
This
capability
will
be
key
to
managing
capacity
at
the
edge,
because
it's
not
as
much
capacity
as
say
you
have
in
the
cloud,
and
you
have
to
be
able
to
do
these
types
of
failovers
as
well
as
overflows,
and
this
is
also
very
critical
to
guaranteeing
the
slas
in
the
world
of
telco
and
edge
now
moving
on
from
edge
use
cases
to
the
core
telco
network.
The
goal
here
is
to
help
deliver
capex
and
opex
efficient
network
and
make
it
ready
for
5g
by
bringing
in
cloud
native
technologies,
including
service
mesh
service.
B
Mesh
is
a
key
paradigm
for
5g
core
service
based
architecture.
Service
based
architecture
provides
a
modular
framework
from
which
common
applications
can
be
deployed
using
components
from
one
or
more
providers.
So,
let's
take
it
back
to
english
speak.
One
of
the
key
components
for
deploying
5g
is
the
5g
packet
core.
This
is
comprised
of
a
5g
core
control,
plane
and
data
plate.
So
what
you
see
on
the
top
is
the
control
plane.
B
The
5g
control
plane
itself
is
a
set
of
network
functions
like
amf
and
smf
that
communicate
with
each
other
through
well-defined
interfaces.
While
we
don't
have
enough
time
to
get
into
the
details
of
each
service
at
a
high
level,
this
control
plane
will,
with
all
of
the
alphabet.
Super
services
can
be
deployed
as
a
service
mesh.
Think
of
the
network
functions
as
services
and
the
service
based
interface
between
them
as
service
to
service
communication.
B
Another
key
benefit
for
telco
use
cases
is
that
envoy
at
its
core
is
extensible.
You
can
basically
write
your
very
own
extensions.
The
envoy
architecture
makes
its
fairly
easily
extensible.
We
have
a
variety
of
different
extension
types.
These
include
access,
loggers
access,
block
filters,
clusters,
listener
filters,
network
filters,
http
filters,
grpc,
credential
providers,
health
checkers,
there's
also,
more
recently,
all
of
the
work
around
wasm
and
so
on
so
forth.
B
So
as
an
example,
one
of
our
partners,
which
is
tetrad,
has
an
offering
called
get
envoy
which
has
a
build
pipeline
accessible
to
do
extensions
building.
So
what
this
pipeline
does
is
it
allows
you
to
cherry
pick,
the
extension
that
really
matters
to
you.
While
you
go
build
out
the
envoy
build,
so
this
extensibility
of
envoy
is
really
going
to
drive
its
adoption
in
telco
and
edge
use
cases.
B
If
you
take
a
broader
view
of
where
we
are
as
an
industry,
we're
just
getting
started,
and
we
have
many
things
to
solve
together,
especially
in
the
area
of
telco
and
edge.
While
we
are
making
great
headway
on
creating
consistent
cloud
native
network
and
services
platforms
and
evolving
them
for
enterprise
telco
and
edge,
we
need
to
do
much
more
to
abstract
our
complexity
and
manage
heterogeneity
better
for
telco.
We
need
to
get
to
the
point
where
network
services
and
slices
automatically
scale
and
optimize
are
proactively
secure
and
effortless
to
administer
and
use.
B
B
I
should
also
be
able
to
move
my
service
from
an
edge.
It
is
deployed
at
to
another
edge,
say
to
bring
it
closer
to
the
end
user
or
to
lower
cost.
I
should
also
be
able
to
deploy
a
service
that
spans
multiple
edges,
so
take
the
case
of
machine
learning.
Where,
for
my
services,
I
may
do
small
amounts
of
processing
on
the
user's
device,
which
then
connects
up
to
a
telco
edge
for
scrubbing,
which
then
connects
up
to
google
cloud
to
do
machine
learning
at
the
google's
edge.
B
So
we
have
bits
and
pieces
that
can
actually
help
deliver
a
solution
for
this,
but
we
haven't
really
put
together
a
full-blown
solution
as
an
industry
which
solves
all
of
this
problem,
so
to
make
this
happen,
for
example,
I'll
describe
one
example
of
what's
needed.
We
need
a
layer
above
the
service
mesh
that
allows
users
to
specify
desired
outcomes
for
the
end-to-end
application
or
service
chains.
B
If
you
want
to
go
a
little
bit
lower
in
abstraction
or
workflows,
if
your
company
is
workflow
oriented
as
well
as
placement
policy,
so,
for
example,
optimize
for
latency
or
optimize
for
cost,
and
then
this
layer
also
orchestrates
and
connects
the
services
and
underlying
infrastructure
using
service
mesh
and
other
open
apis.
So
we
have
a
lot
of
work
to
do
here,
but
it's
one
of
the
most
interesting
areas
to
partner
as
an
industry
on
another
interesting
problem
to
partner
on
is
effortless
network
slicing
at
scale
for
telcos.
B
So
you
will
hear
a
lot
of
talk
around
network
slicing,
very
simply
from
the
end
user.
All
the
way
to
the
end
of
the
application.
You
want
to
create
a
slice
at
every
layer,
whether
it's
the
physical
infrastructure,
all
the
way
to
the
service
layer
where
you're
guaranteeing
a
certain
set
of
parameters
to
that
slice.
If
you
will
that
was
created
for
that
end,
user
and
that
entire
flow,
so
network
slicing
is
actually
happening
in
experimental
setups
and
at
small
limited
scale.
B
But
if
you
really
want
to
monetize
this
infrastructure,
whether
say,
let's
say
you're
a
telco
or
you're
somebody
who's
monetizing
network
slicing,
we
are
missing
a
few
abstraction
layers
and
I'll
just
describe
one
such
capability
there
more.
It
is
the
ability
to
treat
everything
as
a
service.
The
absence
of
this
is
what
is
making
network
slicing
more
complicated
than
it
needs
to
be,
so
you
can
think
of
this
almost
as
an
evolution
of
the
service
mesh
concept.
B
We
discussed
a
few
of
the
use
cases
today,
including
traffic
control,
pervasive
security
and
observability,
a
cross
region
failover
and
overflow,
multi-cluster
multi-region
multi-cloud
and
multi-year
services.
We
also
discussed
the
cap
crow
drain
for
vm
container
migration,
and
then
we
also
took
a
quick
look
at
the
5g
core
service
based
architecture.
B
Obviously
these
are
very,
very
deep
topics
and
we
could
essentially
do
a
talk
on
each
one
of
them
and
there
are
many
many
other
use
cases
as
well,
but
the
key
thing
I
think
is
we
need
to
remember
that
service
mesh
itself
is
and
will
need
to
continue
to
evolve
as
a
paradigm
to
support
telco
edge
and
other
new
use
cases,
and
so
in
that
we
look
forward
to
collaborating
with
all
of
you
on
service,
mesh
evolution
and
innovation
as
well.
Thank
you.
Everyone.