►
From YouTube: Service Mesh Interface: Developer Friendly APIs for Service Mesh - Michelle Noorali, Microsoft
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
Service Mesh Interface: Developer Friendly APIs for Service Mesh - Michelle Noorali, Microsoft
The proliferation of service mesh technologies has led developers and operators alike wondering when and how to choose the right service mesh for their needs. It’s also hard to describe and build on top of the common features that service meshes provide. In this session we will introduce Service Mesh Interface (SMI), a common abstraction that allows service mesh users and operators the freedom to adopt service mesh concepts without being tied to a specific implementation, making the space more open and lowering the barrier for tools being built on top of these amazing technologies.
In this session, we will take a hands-on look at how SMI(https://smi-spec.io/) integrates into three different service mesh runtimes, Istio, Linkerd, and Consul, explore the SMI specification and it’s core components, and look at the future of what SMI can provide.
A
We'll
talk
a
little
bit
about
that
later
today,
I'm
pretty
involved
in
the
CNCs
I
serve
as
the
developer
representative
on
the
governing
board
and
on
the
technical,
Oversight
Committee
I
was
also
coop
kind,
2017
co-chair
and
anyone
who
knows
me
knows
that
I
am
very
passionate
about
Donuts,
okay,
so
I'm
going
to
talk
to
you
a
little
bit
today
about
pushing
to
production.
It
can
be
pretty
scary.
It
can
be
scary
for
the
developer
writing
the
application
code.
A
It
can
be
scary
for
the
person
who's
responsible
for
making
sure
the
application
is
up
and
running
and
those
credit
card
transactions
are
going
through.
It's
also
pretty
scary
for
the
CEO.
That's
hold
all
the
investors
that
this
was
the
next
uber
4x.
So
there's
a
lot
of
pressure
and
it's
justified
right
who
hasn't
actually
broken
production
before
raise
your
hand
if
you
have
broken
production,
ok,
cool
all
of
us
great
awesome
sounds
good.
Yeah
I.
Remember
my
first
time
breaking
production,
it's
a
beautiful
day
was
sunny.
It
was
an
it's
all
statement.
A
I,
just
I
just
switched
the
logic
for
no
reason
and
and
I
pushed
and
the
next
thing
you
know.
I
was
sitting
there
in
my
very
first
post-mortem
session,
but
I
think
that's.
Why
we're
all
here
this
week
right,
we
want
to
stop
breaking
production
and
building
and
running
distributed
systems
is
super
hard
and
we
got
a
little
bit
of
the
way
there
well
along
the
way
there.
To
be
honest,
talker
was
amazing,
so
we
got
to
you
know
finally
isolate
our
applications
and
these
consistent
environments
and
our
docker
containers.
We
now
have
kubernetes.
A
We
can
orchestrate
those
containers,
that's
awesome
and
the
cloud
native
computing
foundation
became
this
home
for
all
of
the
tools
and
technologies
you
might
possibly
need
to
build
and
run
and
democratize
distributed.
Applications
and
I.
Remember
that
it
was
khoob,
khun,
north
america,
in
austin
and
2017
december.
I
think
oh
yeah,
the
dates
there.
It
was
December,
it
was
cold
and
rainy,
and
that's
that
those
few
days
were
when
service
mesh
just
completely
exploded,
and
so
we
saw
this
explosion
of
the
service
smash,
and
you
know
it
was.
A
It
was
a
really
good
time
for
it.
You
know
we
had
the
packaging
done.
We
had
the
orchestration
system
John.
We
had
really
good
tools
for
monitoring
and
logging,
and
this
next
evolution
for
for
figuring
out
how
to
make
sure
your
service
to
service
communication
is
reliable.
That
just
seems
like
it
would
flow
and
also
the
analysts
were
really
hungry
for
the
next
big
thing.
Everybody
was
blogging
about
this
stuff.
A
It
was
excellent,
and
you
know,
link
Rd
I
believe
was
the
first
service
mesh
to
be
drawn
into
the
CNC
F,
but
more
meshes
came
to
the
party
and
everyone
was
super
excited,
especially
our
customers.
Right,
like
customers,
would
come
to
us
and
be
like.
We
really
want
to
use
a
service
mash
and
and
with
any
good
thing
there
are
costs
associated
to
it,
so
the
cost
of
I'm
we've
talked
about
I'm
sure
we've
talked
about
this
earlier,
but
there
are
infrastructure.
Costs
are
running
the
service
mash.
A
There
are
there's
the
idea
or
there's
the
cost
of
figuring
out
which
mash
to
use
you
need
dedicate.
You
need
to
dedicate
time
and
experience
you
might
be
fixing
bugs
as
an
early
adopter,
so
you
might
want
to
or
have
to
upstream
those
contributions
and
we're
all
in
new
and
uncertain
chartered
territory
in
terms
of
tooling
and
UX,
and
so
that
left
our
customers
with
an
end
users
that
we
were
talking
to
with
this
particular
question
and
it
was
to
mesh
or
not
to
mash,
but
we
believe
that
is
not
actually
the
question
right.
A
We
we
were
in
this
like
search
of
figuring
out
what
it
is,
if
it's
not
just
the
generic
like
service
smash
super
hyper
term.
What
is
the
thing
that
people
are
looking
for,
that
end-users
are
looking
for,
and
you
know
we
talked
to
a
lot
of
customers
conducted
a
lot
of
interviews
and
it
really
came
back
down
to
like
three
particular
things.
A
One
was
they
wanted
to
be
able
to
execute
certain
deployment
strategies.
So
canary
is
like
the
first
thing
that
people
talk
about.
They
wanted
to
be
able
to
control
which
services
communicate
with
each
other
and
how
and
they
wanted
insight
into
what
is
happening
in
their
micro
services,
environment,
and
this
may
not
be
new
information
because
I'm
sure
a
lot
of
you
already
used
a
service
smash
or
are
familiar
with
it.
So
raise
your
hand
if
you're
running
a
service
master
in
production
Oh.
Actually,
that's
not
everyone.
A
That's
like
10%,
who
heard
who
has
played
with
service
meshes
before
today.
Oh
awesome,
great
great,
okay.
This
is
a
great
piece
all
right,
so
we
wanted
to
do
something
in
this
space
and
and
we
wanted
to
figure
out
how
to
meet
our
customers
needs
but
also
lower
the
barrier
to
entry
and
and
risk
of
using
a
service
mash,
and
we
did
this
in
collaboration
with
the
service
master
community,
so
folks
from
linker
key
from
measure
E
from
solo
and
the
list
goes
on.
A
I've
had
the
pleasure
of
working
with
a
lot
of
really
good
people
in
the
community
for
the
last
few
months,
so
anyways.
We
also
wanted
to
create
a
consistent
experience
for
end
users
and
tooling.
So
if
you
want
to
carry
out
a
particular
deployments,
it's
different
in
every
mesh
and
we
also
wanted
to
bring
different
parties
together
to
create
an
ecosystem.
A
If
you
look
at
the
things
that
are
in
common
of
the
projects
that
are
in
the
CNC,
F
you'll
find
that
ciencia
projects
are
generally
interoperable
and
flexible
and
extensible,
and
so
this
is
the
kind
of
feel
that
we
wanted
to
bring
to
the
service
mesh
community.
Okay,
so
going
into
service
match
interface
SMI.
This
is
a
standard.
It's
a
document.
It's
a
spec,
it's
documents
and
standardizes
key
functionalities.
A
A
So
the
spec
is
in
the
form
of
kubernetes
custom
resource
definitions,
so
each
part
of
the
spec
is
a
CRD.
This,
for
example,
is
the
traffic
splits
back
and
you'll,
see,
there's
a
route
service
and
there's
some
backends
and
there's
this
thing
called
weight
and
weight
is
correlated
to
how
much
traffic
you
want
to
send
to
a
particular
service.
A
So
you
may
want
to
start
sending
like
10%
of
your
traffic
to
a
service
and
then
you
know
carry
forward
and
progress
and
you
in
reality
are
probably
doing
this
with
a
tool
or
want
to
do
with
this
with
a
tool.
But
you
can
do
this
by
hand
if
you
want
with
us
my
traffic
split
resources
and
we'll
go
into
a
little
bit
about
that
too.
A
So
we
have
a
few
different,
CR
DS
I'm
not
going
to
go
to
in
to
detail
in
each
of
them,
because
I
want
to
show
you
like
how
it
works,
but
there
is
an
estimate
s
mi
SDK.
So
in
this
back
we
define
these
CR
DS.
This
specification
for
how
you
define
certain
behaviors
and
certain
things
you
can
do
with
the
mesh,
but
in
the
SDK
we
have
these
Sierra
T's
implemented
these
api's
implemented
so
that
you
can
just
import
them
into
your
project
and
use
them
yourself.
A
For
example,
if
you
wanted
to
build
an
operator
that
watches
these
Sierra
T's
and
then
does
something
to
your
data
plane.
This
is
the
traffic
policy
example,
so
I
will
kind
of
give
you
a
high-level
overview.
What
this
looks,
what
this
is
actually
saying.
So,
if
you
start
from
the
bottom,
it
says
in
the
traffic
target
section:
basically,
we
have
an
API
service
and
we
only
want
to
allow
Prometheus
to
be
able
to
hit
the
metrics
URL.
A
A
So
we
are
in
a
alias
cube,
CTL
to
K,
because
I
don't
spell
cube,
C
tail
correctly,
ever
so
I'm
on
a
cluster,
that's
running
sto,
we're
gonna,
see
what's
running
here.
I'm
just
gonna
delete
this
v2
version
and
we'll
go
into
that
a
little
later,
but
basically
I
have
a
node
app
and
all
it
does
is
it
calls
a
greeting
service
and
then
the
greeting
service.
A
Is
a
go
app
and
all
it
does
is
send
back
a
greeting
and
a
color,
and
then
we
use
that
in
the
node
apps
like
view
okay,
so
we
are
going
to
go
ahead
and
see
what
that
looks
like
I
could
have
shown
you
like
a
lot
of
different
services
like
running
together.
There's
like
lots
of
demos
like
that,
but
for
this
demo,
I
just
have
two
services
here,
because
I
wanted
to
show
you
everything
in
a
very
simple
context,
and
then
you
can
also
use
this
code
base
to
build
more
complex
demos
or
examples.
A
A
And
these
are
traffic
split
manifests,
so
I
have
version
1
of
my
grading
service
running,
but
what
I
want
to
do
is
control
the
control
and
manage
traffic
shifting
so
I'm
going
to
show
you
what
my
traffic
split
looks
like
and
basically
it
just
says
that
I'm
gonna
give
a
hundred
percent
of
my
all
the
traffic
to
version
1
and
nothing
to
be
too
to
start
with,
and
so
I'm
going
to
go
back
to
this.
Greeting
service
and
I
also
have
to
manifest
here
and
so
v2
breeding
service.
A
A
Okay
cool,
so
now
we
have
this
greeting
service
and
if
we
go
back
and
also
SEO
injection
is
enabled,
so
it's
going
to
take
a
second
to
get
this
running.
Okay,
all
right!
So,
if
I
go
back
to
my
app
I
should
only
see
good
morning,
we're
still
good.
Now
we're
going
to
do
the
fun
part,
which
is
which
is
shift
some
traffic.
A
A
A
A
Don't
actually,
when
you
make
changes
to
your
service
like
five
minutes
before
the
talk,
so
okay,
so
alright,
so
just
to
recap
and
bring
us
back
and
bring
me
back
so
I
have
two
versions
of
the
greeting
service:
running
v1
and
v2
I
have
my
node
app
running
up
and
running
and
I
just
applied
this
traffic
split
object,
which
should
start
shifting
traffic
for
us
and
so
we're
gonna
go
back
to
our
browser
and
okay
cool.
So
now
it's
like
half
the
time
it
works,
which
is
good.
A
A
A
A
A
Okay,
so
with
with
linker
D,
they
have
this.
They
just
added
this
traffic
split
section
to
the
dashboard,
which
I
think
is
pretty
cool.
So
you
can
see
like
the
latest
traffic
split
and
you
can
make
requests
and
kind
of
see
metrics
around
that
just
pretty
sweet,
but
it's
the
same,
but
it's
the
same
like
actual
CR
D.
So
let's
just
switch
it
up
a
little
bit
to.
A
And
I
want
everything
to
go
to
version
1
because
something
happened.
There
are
tools
that
will
detect
you
know
and
analyze
like
metrics,
around
success
rates
and
then
roll
back
for
you,
but
I'm
just
doing
this
manually
just
to
kind
of
get.
You
know
how
help
us
understand
everything:
okay,
so
I
want
100%
of
my
traffic
to
go
to
v1
and
I,
see
that
it's
correct,
linker
D
is
supporting
the
old
version
of
traffic
split
because
because
I
just
changed
it
recently
so
and.
A
Okay
cool,
so
now
we
should
go
back
and
we're
seeing
that
100%
of
the
traffic
is
going
back
to
the
version,
one
of
the
grading
service,
and
you
can
see
information
about
that
in
the
actual
dashboard.
So
this
is
just
to
show
you
that
you
can
have
the
same
experience
on
different
clusters.
Running
different
service
meshes.
A
A
There
are
some
really
really
cool
things
that
are
coming
out
and
a
lot
of
them
use,
SMI
already
and
even
newer
meshes
that
are
coming
out,
are
starting
to
use
SMI
as
like
a
first-class
thing,
and
so
I
think
this
is
the
thing
that's
most
exciting.
It's
not
necessarily
that
you
as
an
end
user
or
a
developer,
are
gonna.
Try
to
do
your
own
canary
deployments,
like
that's,
not
really
the
goal
here.
A
The
goal
here
is
to
build
developer
friendly,
api's,
in
which
we
can
build
tooling
on
top
of
SMI
and
others
and
service
meshes
and
create
this
consistent
experience
and
really
grow.
What
kind
of
workflows
we
can
we
can
have?
So
flagger
is
amazing.
It's
this
Cabrini's
operator
that
helps
you
do
Canaries.
It
uses
Prometheus
to
check
metrics
and
through
rollbacks
you
can
even
hook
in
like
load,
testing
and
other
things
in
that.
A
So
there
is
a
flagger
demo
and
the
sto
adapter
project
and
I
didn't
explain
that
yet
so
linker
D
has
like
first-class
support
for
SMI.
We
created
sto
adapter,
which
is
basically
an
operator.
It
just
watches
the
CRTs,
the
traffic
split
and
all
the
SMI
CR
DS,
and
then
it
informs
sto
about
what
changes
it
needs
to
make
so
but
anyways,
there's
some
really
cool
stuff
coming
out
or
has
come
out.
A
Flagger
service,
mesh,
visualization
tools
like
key
ollie
and
benchmarking
tools
like
ma
cherie,
so
just
things
to
kind
of
give
you
an
idea
of
like
if
you're
trying
to
build
tooling.
That's
we'd,
really
love
to
talk
to
you
about
how
you
can
use
SMI
and
and
and
leverage
those
api's
mention
the
SCO
adapter.
It
has
really
good
example.
Demos
so
check
this
repo
out.
If
you
want
to
play
with
SMI
some
more
and
if
you
want
to
get
involved,
we
have
a
pretty
active
community.
A
We
have
a
slack
Channel,
it's
all
on
the
SMI
spec
website
and
we
have
zoom
meetings
every
other
week.
So
if
you're,
even
thinking
about
using
SMI,
please
hop
in
tell
us
where
you're
from
we'd
love
to
hear
from
you,
and
this
slide
was
originally
called
synergy.
But
I
took
that
off.
But
basically,
just
to
reiterate
SMI
is
something
that
allows
people
some
flexibility
and,
and
you
know,
takes
away
a
little
bit
of
the
edge
about
getting
locked
into
a
particular
service
smash.
It
helps
people
with
interoperability.