►
From YouTube: Service Meshing with Docker Desktop & WebAssembly
Description
--
Too lazy to implement multi-tenancy? Don't have time to implement per user rate limiting in your application's endpoints? In this talk, we will examine how to let application infrastructure concerns melt off your Dockerized workloads and have your infrastructure implement multi-tenancy on your behalf.
Learn how to use Docker Desktop and Kubernetes as your development platforms of choice in combination with Meshery, the service mesh management plane, to easily deploy a service mesh. Using Consul and Envoy's latest capabilities, see how WASM can be used to move user authentication and authorization from your application to the infrastructure.
Speaker: Lee Calcote, Layer5
Twitter: @lcalcote
Speaker: Kanishkar J, Layer5
Twitter: @_kanishkarj
A
A
Well,
this
incident
is
relevant
to
our
topic
at
hand.
It's
rather
unfortunate.
Well,
it's
it's
a
bit
messed
up
really!
Well,
let's
press
forward
and
get
started.
I'm
Lee
Cal
coat
I'm
coming
to
you
today
from
Austin
Texas
I
am
also
coming
to
you
today
over
a
brand-new
cable
modem,
I'm,
a
docker
captain
I
focus
in
the
cloud
native
ecosystem.
Much
of
my
time,
having
been
spent
on
service
meshes
these
past
couple
of
years.
A
If
you
enjoy
this
talk,
want
to
see
the
slides
or
other
talks
that
I've
given
visit
the
URL
in
yellow
and
you
will
have
your
fill.
Can
each
car
jaye
my
co-presenter
he's
an
open-source
maintainer
in
the
layer?
5,
a
service
mesh
community
he's
been
focused
on
rust,
wasum
web
assembly
on
well
management
projects
that
help
people
adopt
service
meshes
and
run
them
well.
So
he
would
love
to
have
your
feedback
go.
Go,
join
the
slack
that's
listed
here.
A
It's
a
warm
and
welcoming
community
I'd,
be
sure
to
say
hi
to
Kanishka
when
you
do
so
service
meshes.
What
are
they?
These
have
been
described
in
a
number
of
different
ways,
I
like
to
describe
them
as
a
services,
first
network
as
a
layer
of
cloud
native
infrastructure
in
between
kind
of
a
me,
but
you
know
kind
of
laying
down
it
at
layer.
Five,
if
you
will
in
between
your
Orchestrator
and
your
applications,
they
fulfill.
A
Some
unmet
needs
that
applications
have
occasionally
those
needs
are
being
met
in
other
places,
but
service
meshes
bring
together
administrative
control
over
some
of
the
some
of
these
needs
that
are
being
disparately
delivered
today.
We'll
talk
about
those
needs
before
we
do.
I'll
say
that
if
you're
new
to
service
meshes
there's
a
great
resource
here,
there's
a
free
report
from
O'reilly
that
gives
you
an
introduction
to
the
space
lets.
You
know
what
a
service
mesh
is
and
in
context
of
other
technologies
that
you
might
be
familiar
with
and
so
I
recommend
giving
it
a
read.
A
A
That
docker
is
a
project
that
it's
here
about
five
and
a
half
years
ago,
really,
like
six
years
ago
now,
docker
wondered
or
became
generally
available
ready
for
production
use,
as
people
picked
up
well
like
wildfire
docker,
they
found
the
need
for
orchestration
of
all
of
their
containers.
All
of
that
sprawl.
A
So
about
five
and
a
half
years
ago,
orchestrators
came
onto
the
scene
and
they've
been
production
ready
for
some
time
and
now
about
four
years
ago,
the
first
service
mesh
project
was
announced,
and
they
too
have
become
production,
ready
kind
of
interesting
to
see
the
cadence
by
which
the
technologies
are
adopted.
Here
the
time
of
the
mesh
is
upon
us
I
suppose
we
are,
many
of
us
have
adopted
containers
and
docker
in
significant
ways.
A
We're
gonna
put
my
demo
where
my
mouth
is
later
and
show
you.
This
service
meshes
are
like
every
other
technology,
not
the
end-all,
be-all.
There's
a
much
value
that
that
are
promised
by
them
and
much
delivered.
Part
of
that
value
is
to
help
with
modernizing
existing
applications.
Existing
workloads
that
you
might
have
they
can
help
uplift,
your
existing
apps
you
can,
you
can
bring
those
on
to
the
mesh
they
aren't.
Service
meshes
aren't
confined
to
the
land
of
micro
services
and
containers.
A
Some
service
meshes
allow
you
to
on
board
your
existing
applications,
so
you
call
those
legacy
or
call
those
monoliths
or
maybe
just
things
are
non
containerized
and
so
they'll
help
modernize
your
infrastructure
modernize,
your
applications,
which
is
kind
of
reminiscent
of
docker
and
part
of
the
value
that
it
provides
so
another
way
of
articulating.
This
is
to
say
that
you
would
deploy
a
service
mash
to
avoid
well
bloating
your
application
code
with
infrastructure
concerns,
if
today,
you're
writing
a
retry
logic
into
your
application
code.
A
Maybe
you
shouldn't
be:
maybe
that's
something
you
don't
need
to
bother
with
that.
You
could.
Maybe
you
can
trust
your
infrastructure
to
take
care
of
that,
for
you
trust
your
service
mash
to
do
it
if
you
were
building
in
rate
limiting
logic
or
circuit,
breaking
or
path
based
routing
or
any
number
of
things.
You
can
look
to
your
mesh
for
this.
You
don't
need
to
put
that
into
code.
You
can
define
that
in
yamo
in
config
and
have
your
mesh
do
those
things.
So
you
can,
you
know,
avoid
doing
duplicative
work.
A
You
can
make
the
behavior
of
those
network
services.
You
know
the
the
retries
that
I
was
just
talking
about
make
that
consistent
across
your
services,
irrespective
of
what
language
your
services
are
written
in,
maybe
irrespective
of
some
disparate
infrastructure
that
you're
using
bring
some
consistency
here.
A
The
another
thing
that
you
might
use
a
service
mesh
to
do
is
to
avoid
diffusing
the
responsibility
of
managing
your
services.
Things
like
defining
the
number
of
retries
that
a
given
service
should
make
if
it
fails
to
make
a
connection
whose
responsibility
is
that
so
that
developers,
the
operators,
the
service
owner
the
product
manager
of
times
you
find
some
of
these
questions
fall
between
the
cracks
that
that
responsibility
is
diffused.
A
All
of
these
roles
are
empowered
by
the
presence
of
a
service
mesh
and
because
of
this,
because
developers
don't
have
to
be
burdened
with
as
many
infrastructure
concerns
they
can
move
a
bit
faster
because
operators
don't
necessarily
have
to
go
back
to
the
development
teams,
to
ask
for
some
additional
telemetry
or
to
enforce
a
rate
limit
or
or
change
the
the
behavior
of
the
circuit
breaker.
They
too
are
empowered.
As
a
matter
of
fact,
the
product
owner
is
empowered
and
I
won't
describe
how
I
will
show
you
in
the
demo
I'm
how
they
are.
A
They,
too
are
empowered,
so
this
phenomenon
of
helping
separate
and
developers
and
operators
and
letting
them
iterate
a
bit
independently
means
that
they
can
move
more
quickly
and
also
means
that
the
responsibility
of
who's
defining
the
behavior
of
these
network
services
is
no
longer
diffused
between
the
teams
so
on
to
the
architectures
of
service
measures.
If
you're
a
network
engineer
these
three
components
to
a
service,
mesh
architecture
are
probably
pretty
familiar
to
you.
If
you've
been
dealing
with
the
container
Orchestrator,
then
a
few
of
these
terms
are
probably
familiar
to
you
as
well.
A
Generically
speaking
you'll
find
a
couple
of
networking
planes
prevalent
within
any
service
mesh
to
its
core
to
the
architecture
of
any
service
mesh.
One
of
those
is
the
data
plane.
This
is
really
where
the
heavy
lifting
is
done.
This
is
the
calm.
The
grouping
and
combination
of
a
bunch
of
network
proxies
intelligent,
intelligent
proxies
that
are
brought
together
to
form
a
data
plane.
A
They
intercept
every
request
that
goes
to
your
services
to
your
workloads
and
they
provide
any
number
of
the
the
network
services
that
I
was
just
speaking
about
another
component
to
the
architecture
of
a
service.
Mesh
is
the
control
plane,
and
this
is
where
you,
as
an
operator
may
interface
with
your
particular
service
mesh
and
I'm,
configure
it
and
integrated
with
your
underlying
platform
integrated
with
the
container
Orchestrator.
A
It
was
the
case
that
that
there
were
some
that
were
projects
that
were
announced
as
a
service
mash
button,
but
really
didn't
really
only
had
a
data
plane
and
we're
kind
of
missing
the
control
plane.
So
you
need
the
combination
of
those
two
to
kind
of
fit
into
the
category
of
a
project
being
a
service
mesh.
There's
also
this
a
third
plane
here
and
that
is
of
a
management
layer,
management
plane.
A
management
plane
provides
well
any
number
of
things
advanced
policy.
Additional
governance
really
helps
you
interface,
integrate
your
business
logic.
A
Your
back-end
systems
with
your
infrastructure,
we'll
give
an
example
of
this
later.
In
the
talk,
the
that
we're
gonna
focus
on
today
is
console.
Console
is
from
Hoshi
Corp
consoles.
Well,
component
architecture
looks
a
bit
like
this.
In
the
control
plane,
there
are
there's
usually
a
quorum
of
console
servers
that
that
get
together
gossip
and
raft
among
each
other.
They
do
any
number
of
functions,
service,
discovery
and
things
they
end
up.
A
Interacting
with
a
console
agent.
That's
typically
deployed
one
agent
per
node,
I've
been
a
kubernetes
environment,
sort
of
as
a
daemon
set.
If
you
will,
the
data
plane
ends
up.
Looking
like
this
I'm
specific
to
consoles
architecture
is
the
use
of
envoy
as
its
as
the
data
plane
proxy
that
it's
using
the
architecture
of
console
is
also
such
that
console
will
sidecar
Envoy
to
your
application.
Containers
will
will
insert
Envoy
as
a
sidecar
proxy
inside
of
your
kubernetes
pods.
A
As
I
was
saying
before
there
are
a
number
of
other
service
meshes.
Not
all
of
them
adhere
to
this
style
of
data
plane
design,
but
we've
seen
this
style
be
popular
as
well
as
more
of
a
one
node
one
agent
per
node
style,
because
console
has
chosen
envoy
as
its
data
plane,
proxy
and
because
of
some
recent
developments
with
an
envoy
console
is
now
able
to
take
advantage
of
web
assembly
and
run
wasum
modules
as
network
filters.
We'll
talk
more
about
this
and
so
web
assembly
web
assembly
is
an
open
standard.
A
It
defines
a
binary
format
for
executable
programs.
It's
fast
portable,
secure
kind
of
reminiscent
of
docker
in
some
respects
it
that
standard
defines
interfaces
for
facilitating
interaction
with
host
environments
that
wasum
programs
are
running
within.
So
the
initial
focus
of
these
host
environments
was
web
browsers
and
large
web
applications
and
speeding
them
up
as
an
open
standard
is
maintained
by
the
w3c
has
been
adopted
by
all
major
browsers,
and
you
know
as
such,
after
HTML
CSS
JavaScript,
it's
the
fourth
language
to
run
natively
in
web
browsers,
it's
exciting
in
general
because
of
its
performance
characteristics.
A
It's
been
noted
to
have
about
20%
overhead
if
you're
familiar
with
Java
and
the
JVM
wasum
has
a
virtual
stack
machine,
that's
becoming
something
of
a
war.
Ax
write
once
run
anywhere
again.
We've
kind
of
seen
this
before
with
docker
that
level
of
portability
rather
so
wasum
executables
are
precompiled,
there's
a
variety
of
languages
that
are
supporting
wasum
as
a
compilation
target
about
40
in
total,
and
so
as
wasum
and
envoy
come
together.
The
two
of
these
are
really
the
the
workhorses
of
the
service
mesh
both
sitting
in
the
data
plane.
A
Now,
Google
and
envoy,
maintainer
z--
have
worked
to
bring
wasum
to
envoy
and
they've
done
this
by
embedding
the
v8
JavaScript
engine
into
envoy,
the
v8
JavaScript
engine,
that's
used
in
chrome
now
through
the
Wasi
or
the
web
assembly
system.
Interface
envoy
exposes
an
application,
binary
interface,
an
ABI
to
lost
some
modules
so
that
they
can
operate
as
envoy
filters,
which
is
pretty
exciting.
A
Now
the
way
that
Wasi
works
is
relatively
straightforward.
You
write
your
application
in
rust,
C
C++,
you
know
one
of
those
languages,
then
you
build
it
and
compile
it
into
the
web
assembly.
Binary
I'm,
targeting
that
particular
Wasi
environment
and
then
the
binary
that's
generated,
requires
a
special
runtime
to
execute
that
runtime
that
that's
the
virtual
stack
machine.
A
It
then
provides
the
interface
is
necessary
to
make
those
system
calls
those
calls
into
that
host
environment,
and
so
we
talked
earlier
about
how
there
are
any
number
of
service
meshes
and
those
that
run
on
voi
are
bringing
forth
support
for
awesome
and
there
are
any
number
of
others,
maybe
about
20
in
total.
There's
a
landscape
that
tracks
these.
It's
essentially
a
multi
mesh
world.
It's
a
bit
messy
out
there
actually,
because
of
that
there
are
service
mesh
abstractions
that
have
come
forth
about
three
in
total
and
that
are
worth
noting.
A
A
Lastly,
there's
the
service
measure
performance
specification
or
SMPS:
it's
a
format
for
describing
and
capturing
the
performance
of
a
service
mesh
in
context
of
its
environment
and
in
context
of
the
functionality
that
it's
performing.
You
know
in
context
of
its
configuration
because
of
this,
and
because,
though
it
is
a
multi
mesh
world
and
because
some
service
meshes
are
more
difficult
to
adopt
than
others,
and
really
because
the
world
needs
a
management
plain
of
the
open
source
project
measure
II
has
been
created
as
a
multi
mesh
manager
and
is
SMI
compatible.
A
It's
also
compatible
with
the
service
mesh
performance
specification.
It's
an
implementation
of
that
as
an
open
source
project.
It's
been
participating
in
google
Summer
of
Code
through
the
CNC
F,
it's
participating
in
the
community
bridge
and
major
league
hacking,
so
lots
of
people
cutting
their
teeth
for
the
first
time
in
that
project.
This
multi
mesh
manager
does
a
few
things.
It
does
lifecycle
management
of
service
meshes,
but
it
also
offers
configuration
best
practices
for
the
operations
of
any
given
mesh.
A
It
also
does
performance
management
and,
like
I,
was
saying
it
helps.
You
understand
that
the
value
vs.
the
overhead
of
a
mesh
so
that
it
does
there
is
a
cost
associated
with
running
a
service
mesh.
There's
a
lot
of
value
gleaned
for
morning
one
and
whether
or
not
you're
doing
it
well
is
something
to
be
managed
ongoing.
It's
something
to
help.
You
choose
your:
what
which
mesh
to
deploy
and
then
ongoing,
which
mesh
to
or
whether
or
not
you're
you're
doing
it
well,
whether
or
not
you're
getting
enough
value
out
of
it.
A
So
the
architecture
of
this
particular
management
claim
is
looks
like
this.
So
we've
got
a
generic
is
set
up
for
a
data
plane
in
a
control
plane
and
some
of
their
common
components.
Measure
e
as
a
management
playing
lays
down.
On
top
it
has
a
built
in
load,
generators,
w
RK,
4
IO.
It
has
a
set
of
docker
compose
or
docker
containers
that
run
as
a
either
docker
compose
application
or
kubernetes
application
is
able
to
interface
with
six
different
service
meshes
to
date,
and
so
we'll
show
it
in
action.
A
It
is
also
capable
of
interfacing,
with
and
well
with
web
assembly
modules
to
demonstrate
that
we'll
use
a
sample
application
called
image
hub.
It's
a
lot
like
docker
hub,
except
it's
really
simple
and
doesn't
have
much
built
into
it.
It's
just
two
containers,
the
functionality
of
which
is
really
small
as
an
application.
It
allows
users
to
sign
up
sign
in
get
a
token
and
choose
what
subscription
plan
they
want.
A
Behavior
we're
going
to
demonstrate
that
by
way
of
subscription
plans
today,
something
that
every
SAS
offering
has
so
this
application
very
simple,
a
web-based
front-end
written
with
using
view
GS
and
back-end
written
and
go
and
we're
gonna
take
that
application
and
deploy
it
on
console
and
slightly
in
advance
of
where
console
is.
Today.
A
We
will
benefit
from
the
fact
that
console
uses
envoy
as
its
data
plane
proxy
and
we
will
insert
in
wasum
module
to
function
as
an
envoy
filter
and
thanks
to
some
advanced
work
that
Nick
Jackson
of
hashey
Corp
has
done,
will
demonstrate
this
to
you
now
we'll
go
ahead
and
head
on
into
the
demo.
Ok,
here
we
are
in
our
demo
environment.
We
are
running
docker
desktop
which
we're
going
to
heavily
leveraged
for
running
kubernetes.
A
As
well
as
docker
compose
applications,
we
can
see
here
that
we
don't
have
any
workloads
running
other
than
just
the
default.
Let's
go
ahead
and
get
a
docker
compose
app
measure,
II
the
service
mesh
management
plane
up
and
running
so
do
a
measure.
E
CTL
system
start
that
will
load
up
our
devices
default
web
browser
to
connect,
Auto
connect
us
to
the
kubernetes
environment
so
to
docker
desktop
in
this
case,
which
is
great
measure.
You
manages
currently
six
different
service
meshes
and
does
a
variety
of
actions
on
them.
A
The
surface
mesh
we're
going
to
use
today
is
console,
so
measure
e
is
connected
to
its
console
adapter.
We
can
go
over
to
console
and
go
ahead
and
get
it
deployed,
as
we
do.
Let's
come
back
here
and
begin
to
watch
what's
going
on
in
our
system,
and
so
what
we'll
want
to
do
is
get
go
ahead
and
deploy
console.
This
console,
though,
is
not.
It
is
the
latest
version
of
console,
but
it's
a
little
bit
in
advance
of
the
latest
release
of
console.
A
Remember
this
console
has
the
wasum
runtime
available
to
it
so
that
we
can
begin
to
deploy
our
sample
app
the
image
hub,
both
with
that
wasum
module
that
that
runs
as
an
envoy,
filter
and
without
and
we'll
just
want
to
make
sure
that
our
console
is
fully
up
before
we
go
ahead
and
deploy
these
image
hubs.
The
first
one
will
deploy
will
be
without
the
wasum
filter.
It
looks
like
it's
up
now,
so
we'll
go
ahead
and
get
that
deployed.
A
We
will
notice
that
as
the
image
hub
without
the
wasum
filter
gets
deployed,
it
begins
to
receive
envoy
sidecars
and
we
can
go
ahead
and
visit
that
application
very
simple,
app,
a
reminiscent
of
docker
hub
you
go
to
it
and
by
default
you
can't
download
any
can't
make
any
polls
of
docker
images.
That's
because
you
need
to
sign
up
and
you
need
to
sign
up
under
a
plan
now
there
are
very,
very
simple
app
again,
but
the
plans
that
it
has
our
personal,
a
team
and
an
enterprise.
A
A
A
The
service,
the
power
of
the
service
mash
for
the
product
owner
to
be
able
to
well
enforce
a
subscription
plan
and
let
people
change
subscription
plans
so
that
we've
got
the
width,
the
width,
the
filter
version
coming
up
and
without
the
filter
going
down
great.
Now
that
that
new
version,
our
new
instance
rather
with
the
filter,
is
at
this
on
this
port,
go
ahead
and
go
to
this
version
so
again
and
we're
not
able
to
make
any
pulls.
A
Let's
go
ahead
and
sign
up
Bob
again
under
the
personal
plan,
and
last
time
we
saw
that,
even
though
bob
was
signed
up
under
the
personal
plan,
there
was
no
filter
rate
limiting
him.
So
now
he's
signed
up
again
this
time
again
under
the
personal
plan,
but
with
the
filter
running.
So
let's
go
back
to
my
Cherie.
Oh,
let's
go
back
to
my
show:
let's
grab
our
new
port
number.