►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Cloud Native & WebAssembly: Better Together - Liam Randall, Founder, Cosmonic & Co-Founder, Wasmcloud & Ralph Squillace, Principal PM, Azure Core Upstream, Microsoft Azure
A
I'm
liam
randall
and
I'm
the
co-founder
of
an
open
source
framework
for
microservices
called
wasmcloud.
My
co-speaker
ralph
is
the
principal
program
manager
for
azure
core.
Together
we
collaborate
on
a
number
of
cloud
native
projects
leveraging
webassembly
today
ralph
and
I
are
going
to
take
a
few
minutes
to
explain
why
cloud
native
and
webassembly
are
simply
just
better
together
for
the
uninitiated.
Webassembly
abbreviated,
wasm
or
wasm
is
on
the
path
to
becoming
as
important
to
the
enterprise
and
as
ubiquitous
as
the
container,
whether
you
realize
it
or
not.
A
You
are
likely
already
adopting
webassembly
in
your
environment
today.
The
security
portability
and
embed
ability
has
developers
throughout
the
cloud
native
ecosystem,
adopting
both
its
power
and
potential.
We'll
take
you
there,
but
let
us
first
set
the
stage
over
the
last
30
years.
Each
wave
of
innovation
has
built
upon
and
further
scaled
the
previous
generation's
wave
of
technology.
A
We
can
observe
that
each
new
epoch
of
technology
has
been
dominated
by
two
dimensions.
The
first
dimension
is
its
format.
The
format
is
how
we
store
our
applications,
the
what
we
deliver,
what
we
run
and
the
what
we
move
around
the
second
critical
dimension
is
the
technology
we
use
to
orchestrate
those
formats
to
create
delete,
scale
and
connect
them
together
with
the
format
and
dimension
in
mind.
A
Let
me
explain
the
parts
of
the
picture
in
green
are
responses,
are
the
responsibility
of
the
application
builder
and
the
parts
of
the
picture
that
are
in
blue
are
the
responsibility
of
the
orchestration
layer
on
the
left.
The
standalone
pc
started
with
an
image
and
was
manually
orchestrated
by
the
data
center.
This
gave
way
to
the
virtual
machine
and
the
virtual
machine
was
orchestrated
by
the
public
cloud
and
we've
segmented
our
formats
even
further,
with
the
rise
of
containers
and
portable
pluggable
multi-cloud
orchestration
with
kubernetes.
A
Now,
let's
observe
a
few
general
trends
and
patterns
first,
each
epic
is
solved
for
the
emerging
challenges
of
the
waves
that
came
before
it.
Second,
in
each
progressive
wave,
we
increased
the
coupling
of
applications
from
their
specific
underlying
environments,
the
format
itself
embeds
fewer
assumptions
than
the
format
that
came
before
it
think
back
to
the
data
center
computers,
for
example,
specific
applications
were
tuned
for
specific
hardware
on
which
they
resided
with
specific
drivers.
A
A
A
A
So
what's
next
the
jobs
to
be
done
of
the
previous
epic
shaped
the
next
epic's
design,
the
need
for
horizontally
and
skillable
compute
led
to
the
rise
of
the
public
cloud.
The
need
for
shippable
environments
led
to
the
creation
of
the
container
in
the
design
of
everyday
things.
We
would
recognize
that
we
can
use
the
clues
in
our
environment
to
identify
what
we
need
next,
a
well-designed
product,
something
that
has
real
fit,
would
have
these
intentions,
these
intuitive
cues
that
make
it
obvious
how
to
use
it
and
the
solution.
A
Today's
to
today's
broad
challenges
will
be
less
of
a
wow
experience
and
feel
more
like
a
boring
of
course.
So
here
we
are
15
years
into
the
launch
of
the
public
cloud.
Eight
years
since
the
dawning
of
docker
and
seven
years
since
the
launch
of
kubernetes,
now
the
linux
foundation
edge,
has
helpfully
provided
us
with
this
wonderful
continuum.
For
what
the
coming
world
looks
like
and
at
first
glance
it
feels
pretty
straightforward.
The
next
epic
of
technology
therefore,
may
account
for
the
world
from
big
to
small,
from
centralized
to
distributed.
A
Now,
this
broad
summary
can
hardly
show
everything.
Themes
of
infrastructure
are
bundled
on
the
far
right.
We
have
not
a
cloud
we
have
multi-cloud
and
in
the
middle
we
have
not
just
an
edge
but
a
multi-edge
and
at
the
user
we
have
not
just
browsers
but
multi-browsers,
and
it
is
clear
that
the
world
of
tomorrow
accelerates
an
existing
challenge:
the
incredible
diversity
in
cpu
architectures.
A
Now
let
us
take
this
world
view
and
envision
the
great
epics
of
technology
laid
over
it.
If
we
consider
the
cloud
native
landscape,
as
we
understand
it
today,
we
have
so
many
great
fits
kubernetes
on
the
edge
and
increasingly
on
the
edges,
containers
riding
along
with
them
into
parts
of
the
consumer
edge.
We
have
service
meshes
like
envoy.
We
have
policy
engines
like
opa
and
dozens
of
other
related
projects,
so
where,
in
this
view,
do
we
see
those
three
tenets
emerging?
A
Where
is
the
progressive
decoupling?
Where
is
the
plugability?
Where
is
the
freedom
from
the
broad
assumptions
that
we
embrace
in
today's
models
as
we've
accumulated
these
design
criteria?
Where
might
this
happen
in
the
cloud
at
the
edge?
It
is,
in
fact
not
just
one
place:
webassembly
builds
upon
the
entire
ecosystem
and
not
just
on
the
ecosystem.
Web
assembly
is
inside
the
ecosystem
and
in
some
places
it
is
the
ecosystem.
A
A
Now,
if
you
haven't
heard
of
webassembly,
let
me
start
with
what
may
seem
to
be
an
all
too
familiar
promise.
Webassembly
was
begun
as
a
portable
polygon
compilation
target
for
the
web,
an
idea
like
java,
silverlight
or
flash
that
promises
right
once
and
run
everywhere.
Execution
and
wasm
difference
differs
both
open
source
and
free.
It's
a
community
driven
w3c
standard
created
in
close
collaboration
with
browser
engine,
vendors
and
shipping
in
all
major
browsers,
since
2017.
A
webassembly
is
a
compilation
target
and
not
a
programming
language.
This
is
a
technology
that
enables
developers
and
organizations
to
choose
their
languages,
their
libraries
and
to
deliver
them
with
a
consistent
set
of
tenants
and
like
many
great
technologies
designed
for
the
web
before
it,
such
as
javascript
webassembly
2
has
found
a
home
outside
the
browser
on
the
server
on
applications
on
the
devices
and
even
embedded
in
other
platforms
themselves,
and
while
the
future
of
webassembly
is
simply
dazzling
today,
it
already
brings
much
to
the
table
it's
efficient
and
fast.
It
runs
at
near
native
speed.
A
A
So
today
we
already
find
webassembly
runs
in
runs
on
and
runs
around
cloud
native
as
applications
executing
on
our
big
servers
as
plugable
engines
embedded
within
our
applications
as
platforms
in
their
own
right
on
the
edge
it's
inside
our
browsers
and
yes,
it's
even
inside
the
iot
webassembly
is
already
showing
up
in
our
applications
it's
running
in
and
around
the
cloud
native
ecosystem.
Certainly
most
of
us
use
webassembly
on
a
regular
basis,
whether
we
realize
it
or
not.
It's
speed
and
efficiency
is
part
of
the
magic
behind
both
google
earth
and
microsoft.
A
Both
leverage
wasm-
and
these
are
just
two
of
the
hundreds
of
cloud
native
applications
building
on
webassembly
today
and
webassembly-
is
being
incorporated
inside
of
existing
cncf
projects
as
an
embedded
engine
webassembly's
key
value
proposition
around
speed,
efficient
size
and
security,
make
it
an
attractive
choice
as
an
embedded
engine
where
we
might
execute
code
from
third
parties
where
once
you
may
have
turned
to
lua
or
javascript.
We
are
now
starting
to
find
wasm.
A
Webassembly
is
not
only
one
of
the
core
technologies
leveraged
by
companies
like
shopify
and
fastly,
but
it's
also
showing
up
with
the
kubernetes
rust,
kubelet
or
crustlet
as
a
native
payload,
and
so
it
is
as
an
application
as
an
embedded
engine
as
a
platform
in
the
browser
or
on
the
edge.
A
new
epoch
of
technology
has
emerged
that
decouples
us
further
from
the
limitations
of
our
previous
world
view.
Webassembly
security,
portability
and
decoupling
of
concerns
transcend
and
are
part
of
our
cloud
native
landscape,
and
both
cloud
native
and
web
assembly
are
better
together.
B
Thanks
liam,
as
you
just
heard
liam
outline,
webassembly
is
perhaps
surprisingly
already
here-
you
may
not
have
noticed
it
in
envoy
or
istio
or
glue
in
cube,
warden
or
crustlet,
but
it
could
already
be
running
in
your
kubernetes.
Clusters
may
not
know
that
flight
simulator
or
shopify
uses
it
or
that
it's
the
way
fastly
does
their
compute
at
the
edge
already
cloud
native
and
like
any
good
technology,
it's
boring
because
it
works.
B
It's
the
coming
future.
That
might
add
a
little
spice
to
the
boredom,
have
a
seat
I'll
be
talking
about.
What's
coming
for
a
moment,
do
a
demo
and
tell
you
how
you
can
get
involved.
Webassembly
is
already
sandbox
by
default,
the
first
step
to
untrusted
code,
but
we
want
to
take
more
steps
in
that
direction.
B
In
containerland,
we
continue
to
apply
all
the
best
pod
identity
practices
we
use
our
back.
We
prevent
privileged
containers,
among
other
things,
and
these
best
practices
are
essentially
continuing
to
find
the
holes
and
plug
them.
Web
assembly
has
taken
the
next
steps
too,
and
it's
happening
right
now.
B
The
objective
is
secured
shareability.
This
is
the
genius
of
open
source
and
containers
without
sacrificing
performance
or
a
native
developer
experience.
If
containers
are
the
big
gears
in
cloud
native,
webassembly,
components
like
this
are
like
smaller
gears
in
between
the
larger
ones,
so
that
the
entire
mechanism
can
do
more
work.
B
B
This
default
stance
is
a
great
foundation.
The
isolated
memory
model
means
that
modules
get
their
own
memory.
They
have
no
access
to
anyone
else's
memory,
and
this
is
great
third
interface
types,
bring
two
main
features.
First,
they
ensure
that
complex
types
can
be
passed
into
and
received
out
of
modules
and
that
the
languages
will
do
this
work.
For
you
not
a
complex
manual
chain
of
tools.
B
Now
some
things
are
done.
We
can
mostly
pass
complex
types
in
and
out,
that's
really
great,
but
there
are
some
things
that
are
still
in
flight
like
handles
to
files
and
buffers.
These
will
likely
appear
very
soon
and
I
absolutely
can't
wait
because
there
are
some
things
that
you
want
to
do
with
files
and
networks.
B
This
is
part
of
the
webassembly
system,
interface
work,
which
is
commonly
called
wazi.
Now
wazi
does
several
things,
including
enabling
languages
to
target
a
single
binary
specification,
giving
developers
their
current
native
dev
iteration
experience
and
ensuring
that
they
just
create
their
code.
The
way
they
do
now
and
securing
memory
internally
and
ensuring
that
modules
can
export
and
import
things
is
great,
but
code
also
does
things
against
shared
resources
like
files
and
networks
and
like
processes
and
operating
systems.
Lozi
ensures
that
calls
have
a
fine,
green
set
of
permissions
or
capabilities
that
they
must
have.
B
In
order
to
use
those
resources,
it
becomes
possible
to
deny
to
code
any
outbound
network
permission,
for
example,
and
do
it
with
the
application
rather
than
modifying
the
entire
platform.
Let's
go
to
a
demo.
First,
let's
establish
the
environment,
as
this
is
a
deliberately
simple
example
to
ensure
what
is
happening
is
clear.
B
Let's
have
a
quick
look
at
the
ammo
for
our
web
assembly.
If
we've
done
things
well,
it
should
be
immediately
understandable.
Note
two
important
things.
First,
the
image
is
a
web
assembly
module
stored
in
azure
container
registry.
A
project
called
wisem
to
oci
makes
this
possible
and
it
works
for
pretty
much
any
oci
registry,
but
for
kubernetes
users
this
is
irrelevant
as
it's
just
the
image
you
want
to
run.
B
Second,
the
node
selector
is
asking
for
a
wasm
cloud:
node,
not
in
linux
or
windows,
or
anything
else
operations
just
got
simpler,
no
multi-arch
images
os
based
images,
it's
always
the
same
webassembly
binary,
even
if
you
change
the
wasm
runtime.
Let's
start
a
simple
file
server
just
to
watch
it
work,
cute
control
apply
and
we
ensure
the
pod
is
running
and
then
curl
to
the
service
to
create
a
new
file
on
the
server
and
because
we're
running
locally.
We
can
list
the
directory
and
see
the
file.
B
B
Now
that
application
was
a
simple
wasmcloud
file
server
hosted
on
a
crestlet
node
running
in
kubernetes.
Not
only
were
no
oci
containers
involved.
We
didn't
even
touch
the
advanced
messaging
and
capabilities-based
security
of
wasn't
cloud.
Nonetheless,
it
should
be
clear
that
whether
you're
working
inside
kubernetes
or
building
applications
that
communicate
with
it
webassembly
is
likely
to
be
a
part
of
your
cloud-native
future.
B
B
Webassembly
stands
out
as
an
important
open
source
addition
to
kubernetes
and,
as
the
webassembly
component
features
begin
to
emerge,
its
ability
to
run
on
multiple
architectures
and
operating
systems
and
in
constrained
environments
means
that
you
can
start
thinking
how
you're
going
to
use
it
right
now.
Only
you
really
know
how
to
fill
the
webassembly
landscape
posted.