►
Description
Join us for Kubernetes Forums 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
Navigating the Service Mesh Landscape - Paul Bouwer, Microsoft
Service meshes offer a number of capabilities around security, traffic management and observability. They provide a compelling approach to shift the requirements related to these capabilities out of our code bases.
Istio, Linkerd and Consul are all really capable options within this space. But how do you decide between them?
What scenarios are each of them best suited for? Which one best delivers the capabilities both your business and workloads require? And what are the overheads and implications of running them within your environment?
In this talk, Paul will help you make sense of this landscape and leave you with the tools to make the decision that is best for you.
A
A
A
So,
hopefully,
by
the
end
of
this
talk,
you'll
have
a
better
idea
of
what
a
mesh
is,
the
options
you
have,
what
you
should
be
looking
out
for
and
how
to
pick
the
right
one
for
for
what
you're
interested
in
doing
so,
my
name's
Paul
Bauer
I'm,
a
software
engineer
at
Microsoft
and
I've
spent
the
last
year
working
with
a
lot
of
our
customers
around
the
world,
looking
at
service
meshes
and
producing
guidance.
So
a
lot
of
what
we're
going
to
see
today
has
come
out
of
that
work.
A
A
So
let's
start
off
with
why?
Why
should
you
be?
Why
should
you
be
looking
at
service
Misha's?
Why
is
there
such
a
lot
of
hype
around
service
measures
so
so
to
dig
into
this
I'm
going
to
cover
off
three
broad
scenarios?
First
of
all,
I'm
going
to
start
around
security,
so
typically
not
too
long
ago,
and
potentially
for
some
of
you.
This
is
still
what
your
security
looks
like
the
firewall
is
the
security
boundary.
A
So
with
the
advent
of
micro
services
and
distributed
systems,
that
is
no
longer
what
the
picture
looks
like.
Typically,
this
is
what
your
security
model
looks
like
I've
got:
zero
trust
networks,
so
nothing
on
your
network
is
trusted.
There's
a
requirement
for
strong
identity,
secure
communication
between
each
of
your,
your
marked
services
or
each
of
your
workloads.
Your
IP
addresses
are
dynamic.
So
in
the
cube
Nettie's
world,
your
pod
may
have
one
IP
address
today
or
this
minute
and
a
different
one
in
the
next
minute,
and
all
your
workloads
are
dynamic.
A
People
would
be
able
to
name
the
servers
or
I
understand
where
things
were.
Potentially
your
releases
were
monolithic.
There
was
one
release
that
happened
every
so
often
that
again
in
the
mark,
services
and
the
distributed
world
has
now
moved
to
a
picture
that
looks
like
this.
We've
got
dynamic,
workloads
and
versions.
You
may
have
multiple
versions
of
an
application
running
in
your
cluster
or
in
your
compute
nodes.
A
There's
a
requirement
for
progressive
rollouts.
You
may
want
to
to
deploy
a
version
at
10
percent
20
percent
test
if
it's
working
in
production
and
then
roll
it
out
further,
there's
a
be
testing.
Canaria
releases
people
want
to
understand
from
an
observability
point
of
view,
what's
going
on
in
your
cluster,
what's
going
on,
it's
your
workloads
and
then
there's
also
a
requirement
for
traffic
policies
so
being
able
to
dynamically
all
through
configurations
set
up
the
policy.
A
What
workloads
should
allow
be
allowed
to
talk
to
what
other
workloads
and
how
those
should
be
accessing
each
other,
whether
it
is
rate
limiting
whether
there's
strategies
all
that
type
of
thing
and
then
finally,
there's
a
section
around
resiliency
and
observability.
So,
typically,
most
you're
probably
doing
this
in
your
code
in
your
workloads,
they're,
probably
an
approved
set
of
libraries
that
you're
using
the
sting
retries
back
offs
or
all
that
type
of
stuff.
So.
A
That
works
well,
if,
if
you're
in
a
monolithic
environment
or
your
development
environment,
is
a
single
language
and
there's
an
approved
library
that
you
can
use
we're
moving
fast
to
a
world
where
different
workloads
can
be
written
in
different
languages
and
often
the
libraries
that
cater
for
all
of
these
things
are
not
consistent
across
those.
So
workloads
are
in
different
languages
and
frameworks
and
there's
requirements
for
consistent,
observability
and
policy
across
all
those
types
of
workloads.
A
So
we've
spoken
a
little
bit
about
why
people
think
there's
a
need
for
service
mesh
and
I'm,
probably
alluding
to
the
fact
that
maybe
a
service
mesh
will
solve
some
of
those
things.
But
what
what
does
a
service
mesh
offer?
That's
going
to
help
us
with
that.
So
what
I'd
like
to
start
off
with
is
maybe
a
definition
looking
at
what
is
a
service
mission.
A
This
is
why
I
asked
your
friend,
so
the
the
first
paragraph
in
this
quote
by
Christian
and
burr
from
their
book
talks
around
what
a
service
mesh
is,
rather
than
the
value
that
it's
delivering
its
delivering
a
bunch
of
capabilities,
but
that's
not
really
what
makes
it
special.
The
second
sentence
is
starting
to
get
very
much
crisper
on
the
message
and
you
can
see
there.
It
allows
applications
to
offload
capabilities
from
your
application
down
to
the
infrastructure,
and
you
can
see
this.
A
This
crisping
of
the
Smasher
message
is
starting
to
become
apparent
from
quotes
from
other
people,
so
this
is
Eric
Brewer
VP
of
infrastructure
at
Google.
It's
DoD
couples
operational
aspects
of
the
services
from
the
implementations
again
we're
moving
stuff
out
of
our
application
into
the
infrastructure
level
and
again
William
from
link
D
from
buoyant
link.
D
moves
for
ability,
reliability,
security
constraints
down
to
the
infrastructure
level
out
of
the
application
they
will
out
of
the
application
there.
A
This
means
that
all
of
those
requirements
that
we
saw
a
little
while
ago
no
longer
need
to
be
managed
within
your
code.
The
service
mesh
can
deliver
those
capabilities
for
you.
So
what
are
those
capabilities?
Typically,
look
like
in
a
typical
mesh.
You'll
have
a
whole
bunch
of
traffic
management
capabilities.
This
is
it
all
operates
at
layer.
Seven,
which
is
your
application
layer
within
the
networking
stack.
You've
got
HTTP
NG,
RPC
management
of
traffic,
there's
dynamic
routing,
so
you
can
do
conditional
routing
weighted
routing.
You
can
do
mirroring
of
traffic
resiliency.
A
A
So
this
is,
maybe
you
only
want
if
the
service
calls
the
service,
it
can
only
call
it
a
maximum
ten
times
a
second
and
then
some
of
the
measures
also
support
this
testing
capability,
where
you
can
actually
use
the
mesh
in
QA
or
or
dev
to
actually
inject
faults
into
your
system
and
that
tests.
Your
is
a
resiliency,
then,
from
a
security
point
of
view,
in
terms
of
capabilities,
meshes
automatically
give
you
encryption,
so
you
can
automatically
encrypt
all
the
traffic
between
your
workloads.
Even
if
your
application
doesn't
understand
what
encryption
is.
A
This
is
managed
by
a
mutual
TLS
and
certificate
exchanges,
the
strong
identity,
the
the
talk
before
me,
you
mentioned
spiffy
and
that's
an
important
aspect
of
a
lot
of
the
measures.
So
spiffy
is
a
it's
a
specification
that
gives
you
strong
identity
and
a
way
to
attest
that
identity
and
also
gives
you
certificate
bundles,
which
allows
for
all
the
encryption
and
then
there's
also
authentication
and
authorization
that
the
mesh
can
do
transparently
for
you
and
then
in
a
ability.
A
Typically,
all
these
measures
will
give
you
a
bunch
of
stuff
around
matrix
tracing
and
traffic,
so
typical
architectures
broken
into
two
components:
the
control
plane-
and
this
is
where
all
the
configuration
and
the
management
happens.
You'll
have
components
that
you
can
see
there.
It's
around
a
management,
UI
or
API
that
controls
how
the
configuration
goes
in
your
to
rules
and
your
policies.
You've
got
security
which
manages
the
certificates
and
the
identities,
and
then
you've
got
the
metrics
which
allows
you
to
collect
all
that
observability
and
then
typically
in
the
data
plan.
A
That's
where
your
compute
nodes
are.
They
will
either
have
side
cars
in
suicide
cars,
a
pattern
in
cuba,
Nettie's,
and
this
injects
a
proxy
that
will
hijack
all
of
the
traffic
in
and
out
of
your
workload
and
apply
the
rules
and
policies
to
that
on
virtual
machines.
This
may
be
running
as
a
separate
process.
Next
to
your
workload,.
A
So
I
also
mentioned
where
upfront
that
features
are
not
the
only
consideration
that
you
should
be
taking
into
account
there,
multiple
things
that
you
should
be
looking
at
when
you
decide
on
a
mesh,
we've
covered
some
of
the
technical
stuff
around
traffic
management
policy,
security
and
observability,
but
there
are
other
things
that
may
be
important
to
you
in
your
organization.
So
from
a
business
point
of
view,
you
may
be
looking
at.
Does
this
mesh
is
someone
offering
commercial
support
around
the
smash?
Is
their
foundation
behind
it,
like
the
CNC
F?
What
is
the
OSS
license?
A
Is
there
some
sort
of
governance
that
allows
my
voice
to
be
heard
in
terms
of
the
feature
sets
and
then,
from
an
operational
point
of
view?
How
difficult
is
it
to
install?
How
difficult
is
it
to
maintain?
There
are
a
lot
of
considerations
when
you
add
a
mesh
in
into
your
cluster
and
then
some
people
may
also
look
at
it
from
a
security
point
of
view.
They
may
have
compliance
considerations
around
stiff
Achatz
and
management
of
certificates
and
route
cas.
A
Now
often
when
people
ask
me,
do
I
need
a
mesh.
My
first
response
is
no
and
typically
once
you
ask
some
of
these
questions.
They
don't
need
a
mesh.
I
would
say
once
you
once
you
reach
a
certain
level
of
maturity
and
you're.
Confident
was
running
committees
then
start
gradually
exploring
a
mesh
if
you're
in
the
the
keynote
this
morning
from
zero,
they
are
not
implementing
a
mesh
it
it's
on
their
roadmap,
but
they
understand
that
it's
a
gradual
journey.
A
So
we'll
start
off
with
sto,
so
sto
is
the
one
that
most
people
are
most
familiar
with:
it's
full-featured,
customizable
and
extensible.
So
it
has
a
ton
of
features
and
see
some
of
the
project
details
there,
there's
commercial
support
from
Aspen
mesh
and
then
there's
also
managed
offerings
in
Google
and
IBM's
clouds.
A
So
when
you
look
at
a
mesh,
it's
often
crucial
to
understand
the
design
goals
of
their
project
and
that
will
guide
you
around
what
what
is
important
to
you
and
whether
that
aligns
with
what
is
important
to
the
project,
so
STS
design
goals
around
maximizing
transparency.
This
means
you
install
sto,
and
your
workload
should
just
work.
You
shouldn't
have
to
do
too
many
other
things.
The
one
that's
super
important
around
is
there's
extensibility.
A
You
can
extend
sto
in
multiple
ways
to
do
things
that
it
wasn't
designed
to
do,
or
it
wasn't
initially,
it's
extending
the
system
pretty
much
like
kubernetes
works,
and
that
comes
with
some
trade-offs
portability.
It
should
be
able
to
work
across
VMs
and
kubernetes
or
any
other
future
workload
that
that
the
project
may
decide
to
support,
and
then
policy
uniformity
talks
to.
If
you
create
policies,
those
need
to
be
able
to
be
translated
in
the
language
across
anything
that
may
not
actually
be
cube
nearly
so.
A
They
need
to
make
sense
in
virtual
machines,
less
Cuban
eighties.
So
this
is
a
list
of
the
sto
capabilities.
So
there's
a
time
they're
not
going
to
go
through.
All
of
them
just
understand
that
they're
a
lot-
and
this
is
a
full-featured
full-featured
service
mesh.
You
may
not
always
need
all
of
these
features,
which
is
also
often,
why
will
suggest
to
customers
to
look
at
what
scenarios
I
want
to
support
and
then
work
from
there
back
to
which
one
of
the
meshes
makes
more
sense
for
them
at
that
point
in
their
life
cycle.
A
So
this
is
what
a
typical
architecture
for
sto
looks
like
at
the
top.
You've
got
pilots
and
galley,
so
Gallia's
configuration
pilot
is
the
thing
that
controls
all
the
configurations
and
sending
them
down
to
the
proxies.
You
can
see
at
the
bottom
here,
there's
a
virtual
machine
on
the
right
and
communities
on
the
on
the
left
and
Cuban
Eddie's
on
the
right,
so
I'm,
showing
here
is
that
sto
can
extend
its
mesh
across
both
communities,
clusters
and
virtual
machines.
A
A
A
So
if
you're
looking
at
sto.
Typically,
if
you
have
these
types
of
scenarios,
then
sto
is
probably
a
good
fit
for
you.
If
you
require
a
number
of
those
capabilities
that
are
listed,
it's
good
for
you
if
you
require
routing
and
access
controls
based
on
earth
or
JWT
or
claims.
Sto
is
really
good
option
all
right,
also,
if
you're
looking,
if
you
or
service
mesh,
if
you
want
to
extend
it
across
Cuba
Nettie's
clusters
and
virtual
machines
is
also
a
very
good
option,
and
then
they
also
support
multi
cluster
out
the
box.
A
So
you
can
actually
span
the
mesh
across
multiple
clusters,
so
linker
D
is
the
next
one
we're
going
to
look
at.
So
this
is
an
easy-to-use
and
lightweight
service
mesh
and
see
there
it's
under
the
CNC,
F
and
commercial
support
is
through
buoyant,
which
is
the
creators
of
linker
D,
so
linker
D
that
we're
talking
about
now
is
actually
linked
to
D
2.
It
was
a
complete
rewrite.
Link.
D
1
was
based
on
Java,
so
it
was
a
little
bit
heavy.
A
So
the
design
goals
of
link
at
the
end,
this
is
crucial
to
understand,
is
keep
it
simple,
minimize
resource
requirements
and
just
work.
So
if
you've
tried
sto
and
link
D
next
to
each
other,
you'll
actually
understand
these
design
principles,
but
it
also
comes
with
some
trade-offs,
so
their
capability
list
is
not
as
extensive
because
they're
focusing
on
simplicity
and
reducing
the
latency
within
within
the
pipeline.
A
If
you,
if
you
have
a
look
at
their
their
architecture,
you'll
see
that
so
it's
really
simple,
there's
no
central
components
that
everything
has
to
go
through,
so
the
bottlenecks
are
moved
and
it
at
the
moment
only
works
on
Cuban
Eddie's,
so
they're
not
focusing
on
virtual
machines
or
anything
from
an
operational
point
of
view.
It's
a
very
nice
user
experience.
It
does
pre
and
post
checks
when
you
install
everything's
done
through
the
CLI,
and
it
comes
built
in
with
web
dashboards
with
sto.
A
So
just
a
heads
up
here,
as
I
mentioned,
it's
a
smaller
set
of
features
that
linka
D
will
implement.
Some
of
the
features
are
not
built
in
in
the
philosophical
opinions
point.
At
the
end,
there
was
because
of
their
design
principles.
They
typically
will
not
put
things
into
mesh
features
that
Cubans
can
provide
natively.
So
it's
just
trying
to
understand
how
you
would
do
this
versus
in
ST
or
one
of
the
other
meshes.
So
it's
just
something
to
to
consider.
A
The
scenarios
that
you
should
look
out
for,
if
you
want
to
use
link
addy
if
you
have
a
simple
use
case,
if
all
you're
interested
in
is
mutual
TLS
between
your
workloads,
then
I
would
start
with
link
addy,
because
it
will
get
you
up
off
the
ground
quickly.
You
understand
how
how
to
to
leverage
a
mesh
as
your
capabilities
change.
If
link
D
doesn't
support
them,
maybe
move
to
sto,
then.
A
So,
if
you
have
super
low,
latency
and
low
overhead
requirements,
then
mrs.
Dabney,
the
mesh
for
you
to
and
finally
let's
this
look,
a
console
so
console
from
hashey
Corp
comes
from
a
non
service
mesh
background.
It
was
I
mean
it
has
been
around
for
a
while
they've
added
capabilities
to
it
now
where
it
can
behave
like
a
service
mesh.
So
this
commercial
support
through
her
she
caught
their
design
goals.
Api
driven
running
connect
anywhere
extended
integrates,
so
they
want
to
also
be
able
to
run
across
any
workload.
A
This
capability
list
looks
pretty
much
like
sto.
They
do
a
lot.
A
lot
of
things
they
also
do
multi
multi
data
center
or
multi
cluster
or
multi
VM
gateways.
They
can
span
across
VMs
yeah
that
there's
a
ton
of
stuff
and
also
around
security
because
they
have
Hershey
called
vault
you.
You
can
have
a
little
bit
more
control
over
your
certificates
and
your
identities.
A
They
run
an
extra
component
in
the
control
plane,
so
it's
the
client
and
that
talks
to
the
quorum
of
console
service
at
the
top
there.
But
once
once
you
pass
that
everything
on
the
bottom
looks
very
very
similar
to
the
others
and
again,
you've
got
communities
MVM,
so
it
can
span
those
types
of
workloads.
A
A
You
also
need
to
understand
some
of
the
console
concepts.
So
if
you're
not
familiar
with
console,
you'll
also
need
to
upskill
on
and
today
in
some
of
the
core
console
concepts
before
a
lot
of
this
will
make
sense.
It
doesn't
have
tracing
support
and,
unlike
the
other
two,
it
doesn't
use
communities
dns.
It
runs
its
own
concept
of
services,
which
is
again
something
you'll.
Don't
need
to
become
familiar
with
the
bottom.
A
A
So
the
scenario
is
that
this
is
useful
for
the
extending
existing
console
connected
environment.
So
if
you,
if
you're
using
console,
ready
or
other
hashable
project
products,
this
is
very
good
and
then,
if
you
have
requirements
around
certificate
or
compliance,
this
is
also
a
good
option
to
have
a
look
at
and
then
it
can
do
multi,
cluster
and
service
mesh
expansion
across
VMs
and
clusters.
A
A
A
So
there's
a
project
called
service
mesh
interface,
and
this
is
looking
at
a
standard
way
to
describe
some
of
the
core.
The
basic
interfaces
that
each
of
these
service
measures
will
be
providing
so
there's
a
bunch
of
companies
that
have
contributed
to
this,
and
these
are
these
the
four
areas
that
that
they're
looking
into
at
the
moment.
A
A
So
if
you
doing
canary
releases
flagger
from
where
he
works
as
definitely
something
you
should
look
at
they're
actually
using
SMA
and
that
has
allowed
them
to
support
multiple
measures
now,
the
flagger
will
actually
allow
you
to
do
canary
releases
and
multiple
rollouts
and
progressive
rollouts
Solo
has
a
service
mesh
hub.
This
is
also
really
interesting
if
you
want
to
start
playing
with
these
different
measures,
you
install
this
in
your
cluster
and
it
will
allow
you
to
install
each
of
those
meshes
really
easily
and
and
get
to
play
with
them
mesh
asure.