►
From YouTube: Service Mesh Specifications and Why They Matter in Your Deployment - Lee Calcote & Kush Trivedi
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Service Mesh Specifications and Why They Matter in Your Deployment - Lee Calcote & Kush Trivedi, Layer5
As the ubiquity of service meshes unfolds so does the need for vendor and technology-agnostic interfaces to interact with them. The Service Mesh Interface (SMI), the Service Mesh Performance Specification (SMPS), and Multi-Vendor Service Mesh Interoperation (Hamlet) are three open specifications solving the challenge of interoperability, workload and performance management between service meshes. Learn what makes each of these specifications unique and why they are very much needed. See each of these three specifications in-action as we use Meshery, the open source service mesh management plane to demonstrate the value and functionality of each service mesh abstraction, and the adherence of these specifications by Istio, Linkerd, Consul and other popular service meshes.
https://sched.co/ekEz
A
A
B
A
A
I
do
have
a
full-time
focus
within
the
layer.
5
community
layer,
5
community's
service
mesh
dedicated
to
service
meshes
and
helping
people
adopt
them
and
operate
them.
Do
so
confidently.
We're
gonna
talk
about
some
of
the
projects
that
the
open
source
contributors
work
on
within
that
community.
It's
warm
and
welcoming
sign
in
join
up.
Another
slack
workspace
is
just
what
you
need
this
one
isn't
quite
like
the
others.
C
C
A
A
A
I
think
the
further
you
step
back
from
it,
the
more
the
journeys.
Look,
the
same
for
a
lot
of
us
that
has
been
with
sort
of
the
advent
of
cloud
native
has
been
with
the
popularization
of
containers.
Thank
you
docker,
which
you
know.
Docker
was
first
announced
a
little
over
about
seven
and
a
half.
Years
ago
now
we
saw
a
number
of
container
run
times
come
and
a
number
of
container
run
times
still
here
from
there
containers
took
off
like
wildfire.
We
got
a
lot
of
them
turns
out.
A
A
I
don't
remember
know
if
it
was
today
or
yesterday,
but
hashicorp's
nomad,
1.0
was
just
announced,
and
so
so
can.
Orchestrators
are
a
thing,
and
so
are
service
meshes
the
if
you
measure
by
the
when
linker
dv1
was
announced.
That
was
about
a
little
over
four
years
ago,
and
I
was
sort
of
generally
available
three
years
three
years
ago.
So
service
meshes
have
been
a
hot
topic
for
the
last
few
years
and
they
still
continue
to
be
rightfully
so
they're,
quite
a
powerful
piece
of
technology.
A
From
my
perspective,
not
everyone
quite
understands
the
capabilities
of
meshes
as
they
are
promoted
and
spoken
about
today,
and
for
my
part,
I
believe
that
there's
a
tomorrow
in
which
data
plane,
intelligence,
really
matters
and
matters
about
how
people
write
cloud
native
applications
so
so
come
along
on
the
journey,
I
suppose,
is
the
thing
there
are
any
number
of
service
meshes
out
there
and,
as
a
matter
of
fact,
one
of
the
community
projects
is
to
track
a
landscape
of
all
of
the
meshes
there
are.
This
landscape
was
just
updated
today.
A
Actually
it's
been
a
busy
day.
It's
kind
of
late
here
at
landscape
was
updated
with
the
nginx
service
mesh
if
you're
not
familiar
with
it
or
missed
the
announcement
a
week
or
a
couple
weeks
ago,
go
get
familiar,
there's
a
lot
to
say
about
each
of
these
service
meshes
and
how
they
work
their
architecture.
A
A
A
True,
we
did
pull
out
a
a
few
strengths,
just
as
a
sampling
of
some
of
the
surface
meshes
that
are
available
network
service
mesh.
On
the
right
hand,
side
is
sort
of
the
service
meshes
surface
mesh.
If
you
will,
it
has
a
lower
layer
and
by
layer
I
mean
osi
model
layer
focus,
it's
a
highly
performant
mesh,
it
layer.
Seven
players
like
five
through
seven,
tend
to
be
more
of
the
focus
of
the
rest
of
the
service
meshes,
so
nsm
offers
some
unique
value
in
that
regard.
A
A
Again
fortunate
in
many
regards,
I
think
in
this
space,
but
I
am
a
maintainer
of
of
smi
and
will
tell
you
that
it
will
describe
smi
more
deeply
here
in
a
couple
of
slides,
but
it's
focused
on
lowest
common
denominator.
Functionality
across
service
meshes
smp
service
mesh
performance
focused
on
describing
and
capturing
the
performance
of
a
surface
mesh.
The
overhead.
A
A
So
everybody
gets
a
piece
of
power,
I
guess
when
they
deploy
a
mesh
because
of
well
the
fact
that
there
are
many
meshes
by
the
way.
I
didn't
say
that
there's
a
little
over
20
of
them
that
are
being
tracked
on
that
landscape,
the
the
those
abstractions
have
come
along
and
there's
a
need
for
abstractions,
because
it's
not
necessarily
the
case
that
that
most
it's
not
the
case
that
most
organizations
are
running
multiple
service
meshes
at
the
same
time.
A
A
Certainly,
just
like
any
other
market
we'll
have
some
that
enjoy
much
more
adoption
than
others,
but
we've
been
as
a
community
out
answering
a
lot
of
questions
about
which
mesh
is
best
for
me.
How
do
I
get
started?
How
do
I
operate
these
with
confidence?
How
do
I,
how
do
I
ensure,
if
I'm,
should
I
be
adopting
one
of
these
specifications?
A
So
let's
take
a
moment
to
look
at
the
architecture
of
measuring
if
you
hail
from
a
network
engineering
background,
some
of
these
next
terms
are
going
to
be
quite
familiar
to
you.
If
you
don't,
then,
as
long
as
you've
spent
some
time
around
kubernetes
the
the
data
plane
and
control
plane
terms
are
probably
conceptually
somewhat
familiar
to
you
and
are
certainly
two
of
the
logical
planes
that
generically
comprise
a
service
mesh.
A
There's
a
third
one
that
meshery
lands
into
and
that's
the
management
plane,
there's
a
lot
of
comparatives
and
an
analogy
to
be
made
here
to
how
physical
networks
run
and
these
data
plane
control
and
management
planes
that
are
represented
there.
As
we
collectively
sort
of
at
least
part
of
us
or
half
of
us
live
in
the
cloud
native
ecosystem.
A
A
A
A
A
Its
focus
is
on
lowest.
I
said
this
before,
but
lowest
common
denominator
functionality
or
a
different
way
of
saying
that
is
kind
of
focusing
on
bringing
forth
apis
that
highlight
and
reinforce
the
most
common
use
cases
that
service
meshes
are
being
used
for
currently,
while
leaving
space
and
providing
extensibility
room
for
additional
apis
to
address
other
service
mesh
functionality.
A
That's
used
to
identify
whether
or
not
a
kubernetes
distribution
of
which,
at
one
point
there
was
near
100,
maybe
there's
over
100
now,
but
whether
or
not
that
distribution
is
in
fact
kubernetes,
whether
or
not
that
piece
of
software
that
is
labeled
with
kubernetes
in
fact
adheres
to
the
kubernetes
apis
and
and
like
I
said
it
is
kubernetes,
so
sonaboy
runs
some
conformance
tests.
The
same
thing
is
needed
for
smi
as
a
standard
specification.
A
A
There's
been
a
community
effort,
open
source
effort
to
create
service
mesh
conformance
tests
to
assert
whether
or
not
a
given
surface
mesh
is
compatible
with
smi
and
in
order
to
facilitate
those
types
of
tests,
you've
got
to
have
a
tool
to
well
provision.
Those
seven
service
meshes
to
provision
a
sample
application
on
those
service
meshes
to
then
generate
load
and
test
out
whether
or
not
traffic
splitting
behaves
like
it
should
or
or
works
with
that
service.
A
Mesh's
implementation,
traffic
splitting
as
an
example,
and
so
and
then
you
need
to
be
able
to
collect
the
results,
guarantee
the
provenance
of
those
results
and
publish
them,
and
so,
as
a
community,
we
turned
to
mesherie
as
the
tool
to
implement
smi
conformance
and
we've
been
working
with
the
individual
service
meshes
to
validate
their
conformance,
and
so,
let's
take
a
moment
to
do
a
demo.
Let's
take
a
moment
to
look
at
what
that
looks
like
to
validate
conformance
in
smi
using
meshri.
A
So
what
I'm
going
to
do
here
is
use
mestre
as
the
tool
to
validate
that
conformance,
we'll
come
over
and
spin
up
mesherie
locally,
so
we'll
use
measuring
ctl
as
the
command
line
interface
to
work
with
measuring
that
command
line
interface.
We'll
do
a
mystery.
Ctl
system
start
it'll
update
the
latest
and
greatest
meshery
start
that
up
open
up
your
browser
and
drop
us
in
here
we
can
interact
with
a
number
of
different
service
meshes
the
service
mesh
that
we're
going
to
work
with
today
is
open
service
mesh.
A
A
B
A
A
The
test
assertions
that
are
being
used
are
not
a
complete
spec,
so
they
will
address
all
four
of
smi's
apis,
but
the
conformance
tests
are
a
work
in
progress,
and
so
as
such,
we
will
show
on
the
current
set,
so
so
right
now
that
those
are
being
run,
I'm
going
to
go
ahead
and
take
a
look
at
some
prior
tests
that
were
run
just
a
bit
ago.
So
these
were
run
earlier
on
open
service
mesh.
A
These
tests
go
and
and
do
assertions
across
these
different,
the
same
specifications.
We
were
looking
at
traffic
access,
traffic
split
traffic
spec,
we
don't
have
looks
like
we
don't
have
traffic
metrics
being
tested
here
just
yet,
but
there
are
a
number
of
assertions
things
that
osm
should
do
and
behave
to
be
conformant,
and
I
wouldn't
reflect
on
osm
in
a
negative
way
here.
A
B
A
You
know
it's.
It's
very
frequently
been
the
case
that,
as
I
engage
and
speak
with
people
about
service
meshes,
they
are
concerned
about
overhead
of
a
mesh,
and
you
know
rightfully
so.
Service
meshes
can
do
a
lot
and
the
more
that
you
ask
any
particular
pieces
of
infrastructure
to
do
the
more
cpu
and
memory
that
you
would
expect
that
it
consumes.
A
But
what
you'll
find
is
that
they're,
probably
using
an
environment
that
isn't
necessarily
like
yours
and
they're,
also
using
different
statistics
and
metrics
to
measure
themselves
and
it's
kind
of
doesn't
help,
and
so
smp.
It
was
born
in
combination
with
in
engaging
with
a
few
of
those
different
service,
mesh
maintainers
and
creating
a
standard
way
of
articulate
capturing
articulating
a
performance
of
a
mesh
in
a
future
discussion.
We'll
talk
about
meshmark.
A
If
you
want
to
learn
about
what
meshmark
is
visit,
the
specifications
website,
you'll
you'll,
see
the
it
gets
kind
of,
maybe
more
interesting
than
you
might
think.
It's
first
of
all,
really
rather
challenging
and
somewhat
intriguing,
how
many
things
you
need
to
measure
and
keep
track
of?
It's
not
just
the
mesh,
it's
not
just
the
meshes
version
or
its
workloads
or
how
many
clusters
you
have
the
size
of
the
clusters,
the
type
of
nodes.
All
these
things,
it's
all
of
that.
A
These
are
all
open
questions
that
s
p,
assists
in
answering
and
assists
in
answering
in
your
in
your
environment,
maybe
you're
using
webassembly
and
filters
there
well
what's
more
efficient,
should
you
implement
retries
as
an
example
or
authorization
in
one
versus
the
next?
Is
one
more
powerful?
What's
the
overhead
of
using
one?
A
So
there's
a
lot
of
approaches
here
to
to
how
you
derive
that
value
and
how
you
put
that
value
to
work
so,
for
example,
yeah!
So
there's
a
few
examples
here
about
path-based
routing
and
context-based
run
like
just
different
load,
balancing
algorithms.
What
are
those
going
to
cost
you
and
the
speed
by
which
you
can
enable
that
in
the
mesh
is
pretty
fantastic
you'd,
be
surprised
by
some
of
the
results
of
some
tests
that
we've
done
and
that
the
community
has
done
in
combination
with
a
couple
of
universities
and
graduate
students.
A
C
Okay,
so
I'm
going
to
demonstrate
service,
mesh
performance
or,
more
specifically,
I'm
going
to
show
you
the
implementation
of
server
switch
performance.
As
me
told
you
that
measuring
the
service
mesh
management
plane
is
the
canonical
implementation
of
the
service
mesh
performance.
So,
on
my
terminal,
I
have
a
local
deployment
of
mystery
running.
C
C
C
B
C
C
While
doing
the
test,
let's
see
what
other
options
we
can
expose
in
machine.
So
in
the
advanced
options
you
can,
even
you
can
even
tell
what
header
should
be
passed
by
testing
your
services
or
service
mesh.
You
can
tell
them
the
cookies.
You
can
tell
the
content
type
and
you
can
tell
the
request
body
which
should
be
passed
while
doing
the
performance
test
and
then
yep.
This
should
be
completed.
C
So
nighthawk
is
the
load
generator
which
is
maintained
by
online
community
and
it
is
relatively
new
and
it
still
hasn't
got
its
one
point
or
at
least
but
right
now,
nighthawk
has
sufficient
features
to
come
to
compete
with
different
load
generators
which
are
still
in
the
play
like
it
can
generate
a
grpc
server.
It
can
generate
a
grpc
service
on
its
own
and
it
has
some
more
attributes
which
you
can
expose
using
their
cli
tool.
B
C
C
In
the
yaml,
you
see
that
start
time
load
time
the
performance
latencies,
the
metrics,
the
environment,
are
being
captured.
We
plan
to
capture
more
details.
According
to
the
specification
we
have
specified
in
the
service
mesh
performance
repo,
you
can
just
go
into
the
depo
and
see
what
all
attributes
we
are
planning
to
capture.
C
One
more
interesting
thing
which
we
have
about
machine
over
here
is:
if
you
see
the
following
result,
and
what
I
can
do
is,
I
can
just
select
the
results
and
I
can
just
compare
them
so
over
here.
If
you
see
the
graph
a
the
blue
line,
this
is
the
loader
which
was
using
the
four
dialog
generator
and
if
you
see
b
the
orange
one,
this
was
the
load
test
which
was
10
using
my
talk.
A
A
We
mentioned
hamlet
earlier.
We
talked
about
briefly
about
hamlet's
focus
on
service,
mesh
federation
hamlet's,
an
important
specification
I
consider
in
and
like
I
said
before,
in
a
lot
of
respects,
I
consider
that
you,
you
might
think
of
it
as
service
catalog
federation,
like
the
other
specifications.
Hamlet,
is
defines
api
interfaces,
two
apis
in
hamlet.
At
the
moment,
one
is
the
federated
resource
discovery
api,
the
other
one,
is
the
federated
service
discovery
api.
A
There
is
much
discovery,
that's
happening
in
these
apis,
that's
intentional.
The
intention
here
is
to
marry
up
and
connect
to
disparate
service
mesh
deployments.
Those
deployments
might
be
of
the
same
type.
They
might
be
of
two
different
types:
hamlet,
takes
on
a
client
server
architecture
in
which
resources
and
services
of
one
service
mesh
are
discovered,
registered
and
using
a
common
format.
A
Information
about
them
is
exchanged
between
different
service
meshes
part
of
the
real
power
here
or
I
consider
in
hamlet,
is
the
ability
to
overcome
what
are
likely
to
be
separate
administrative
domains.
There's
likely
one
team
that
controls
this
service
mesh
over
here
and
the
services
that
it's
running
another
team
that
controls
this
one,
the
ability
to
identify
rules
around
authentication
and
authorization
rules
around
which
services
get
exposed
and
to
whom
and
who
can
who
can
communicate
with
them
and
whether
or
not
they
can
do
it
securely.
A
You
know,
surface
meshes,
we've
seen
have
been
around
for
you
know
four
years
now
part
of
the
work
that
we're
doing
inside
of
the
cncf's
sig
network.
There's
a
service
mesh
working
group
that
working
group
is
well
helping,
identify
those
patterns
of
which
there's
a
list
right
now,
unbeknownst
to
you.
This
is
a
clickable
hyperlink
that
when
you
have
access
to
the
slides,
you
can
click
on.
A
If
you
don't
find
the
slides
reach
out
to
cush
reach
out
to
myself
or
better
yet
reach
out
and
join
into
the
service
mesh
working
group
all
are
welcome.
You
don't
have
to
be
a
member
of
the
cncf
to
participate
but
come
join
in
and
help
us
work
through
the
60
patterns
that
are
defined
right
now.
30
of
those
are
going
into
an
o'reilly
book
called
service
mesh
patterns.
A
Thank
you
for
your
time,
cush
and
I
will
be
in
the
chat
ready
to
field
your
questions.
If
we
are
out
of
time
and
we
don't
get
to
them,
come
join
the
layer
five
community
come
join.
The
slack
there
are
each
of
the
service
meshes
that
we've
discussed
today.
There
are
representatives
of
those
in
the
community
and
there
are
many
people
who
have
adopted
and
are
operating
service
meshes
in
that
community
as
well,
so
a
lot
to
be
shared
and
to
share
okay
thanks
a
lot
we'll
see
you
in
the
chat.