►
From YouTube: Keynote: WASI - A new kind of system interface & what it means for cloud native - Lin Clark, Fastly
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.
Keynote: WASI - A new kind of system interface and what it means for cloud native - Lin Clark, Senior Principal Engineer, Fastly
The system interfaces we use today were designed in the 70s and 80s to power the systems that were prevalent at that time. But increasingly what a "system" even is, is much more open-ended. They include distributed applications spanning the cloud and edge networks, tiny IoT devices scattered throughout our homes, or platforms that embed sandboxes to run untrusted code.
With the WebAssembly System Interface, we’re building a new kind of system interface to better support these kinds of systems. And with this shift, new opportunities are opening up.
In this talk, I’ll explain what all of this means for Cloud Native and some of the opportunities that could be unlocked.
A
A
For
example,
one
problem
we've
been
thinking
through
is
how
do
you
deal
with
code?
That
depends
on
the
concept
of
a
file
system
in
places
where
you
don't
actually
have
a
file
system
available
or
another
problem?
How
do
you
create
a
clear
separation
between
the
business
logic
of
an
app
and
the
orchestration
of
that
app?
A
So
why
was
webassembly
created
the
browsers,
wanted
developers
to
be
able
to
compile
code
bases
that
were
written
in
languages
like
c
plus
and
rust
to
a
single
file
and
then
have
that
code
run
at
near
native
speeds
in
the
browser
and
they
wanted
it
to
run
in
a
very
secure
way
in
a
well
isolated
sandbox?
Because
you
need
that
when
you're
running
code
that
you
just
downloaded
from
the
internet,
that
you
don't
trust
to
get
that
near
native
speed.
A
A
But
as
these
developers
started
bringing
web
assembly
to
the
server
and
to
other
places,
they
left
some
of
the
key
properties
of
webassembly
behind
they
were
giving
these
web
assemblies
of
webassembly
binaries.
Full
access
to
the
operating
system
system
call
library
that
compromised
security
and
it
also
compromised
the
portability.
Since
now,
the
binary
was
tied
to
a
particular
operating
system.
A
A
A
A
Files
are
like
these
swiss
army
knives
that
are
used
for
all
of
these
different
tasks,
but,
as
we
were
thinking
about
all
the
places
where
we
wanted
to
run
wazzy,
we
started
wondering
whether
or
not
this
was
the
right
abstraction
to
use
the
file
achieved
its
central
position
in
system
interfaces.
During
a
very
different
time.
In
software
development,
there
were
a
few
operating
systems
that
really
entrenched
the
file
in
this
privileged
position,
and
these
operating
systems
were
first
being
developed
in
the
1970s
and
80s.
A
A
A
A
For
what
a
program
is
trying
to
do,
my
colleague
and
the
architect
of
much
of
wazzy
dan
gilman
has
called
this
distinction,
the
difference
between
compute
and
meta
compute,
and
he
had
the
thought
that
what
if
we
were
to
push
as
much
of
the
meta
compute
out
to
the
edges
of
the
system
as
possible,
either
up
to
an
orchestrating
module
or
even
better
out
to
the
host
itself
to
see
exactly
what
this
means?
Let's
walk
through
an
example.
A
A
The
operating
system
would
hand
it
back
a
handle
and
then
the
wasm
module
would
read
the
bytes
from
that
file
using
the
handle
with
this
we're
requiring
the
module
to
think
about
the
file
system,
we're
requiring
it
to
think
about
the
concept.
The
context
that
it's
running
in,
but
this
module
wouldn't
really
need
to
know
about
these
details.
All
it
really
needs
is
the
stream
of
bytes
to
come
in
so
that
it
can
operate
on
that
stream.
A
A
This
makes
the
code
more
portable
and
this
architecture
also
makes
things
more
secure.
Because
this
way
we
didn't
actually
need
to
give
the
open
syst
call
to
the
wasm
module
either,
and
so,
if
this
wasm
module
were
to
get
exploited
or
were
subject
to
a
supply
chain
attack,
it
wouldn't
have
access
to
open
files.
Willy-Nilly
on
your
machine.
A
A
A
So
your
code
can
act
like
it
has
direct
access
to
a
file
system
which
it
might
in
some
cases
or
the
host
might
provide
a
virtualized
file
system
either
way.
This
looks
pretty
much
like
the
run-of-the-mill
file
system
apis,
so
your
code
would
not
have
to
actually
make
any
changes.
You
wouldn't
have
to
make
any
changes
to
your
code.
A
A
A
A
The
developer
doesn't
think
I
have
a
file
with
this
name
in
this
directory
I'll,
open
the
file
and
read
the
bytes
from
the
file.
They
just
think
I
have
a
stream
of
bytes,
so
this
means
that
the
code
really
can
run
anywhere.
It
doesn't
matter
what
the
host
system
all
systems
can
represent,
these
basic
primitive
types
and
we've
completely
gotten
rid
of
the
potential
for
the
global
shared
mutable
state,
while
also
eliminating
the
overhead
of
the
per
module
virtualized
file
system.
A
Now,
when
talking
about
these
three
options,
there's
something
I
want
to
be
clear
about-
you
don't
need
to
make
the
same
choice
for
all
of
the
different
modules
in
your
app
part
of
this.
Gradual
adoption
path
is
having
the
ability
to
convert
certain
modules
before
others,
with
both
the
second
and
the
third
option
that
I
just
talked
about:
you're
using
the
wazi
io
types,
either
explicitly
or
implicitly,
and
in
both
cases
you're
not
expecting
to
share
the
file
system
between
these
two
modules.
A
A
And
it's
one
of
these
potential
host
optimizations
that
I
want
to
end
with
just
to
get
everybody's
minds
start
to
start.
Turning
on
what
this
paradigm
could
potentially
open
up
for
cloud
native-
and
this
is
just
one
opportunity
that
we
see,
but
I'm
sure
that
there
are
more,
that
others
who
are
more
familiar
with
cloud
native
will
also
be
able
to
see
and
we're
excited
to
explore
those
more
now.
This
opportunity
has
to
do
with
requests
between
containers
and
how
to
make
those
faster.
A
So
let's
walk
through
what
happens
when
you
make
a
request,
so
I
want
to
be
clear
here.
This
is
just
based
on
conversations
I've
had.
I
haven't
actually
set
this
up
myself
and
step
through
it.
So
there's
a
chance.
I've
gotten
some
of
the
details
wrong
here,
but
I
think
that
this
is
at
least
directionally
correct.
A
A
The
data
that
you're
sending
over
gets
serialized
using
a
format
like
protobufs,
and
this
is
saved
into
memory
in
user
space,
and
then
the
system
makes
a
syscall.
The
memory
is
copied
over
into
kernel
space
memory.
So
that's
two
copies
already
and
now.
Let's
say
that
you're
using
a
sidecar
for
something
like
a
service
mesh,
so
that
sidecar
is
another
container
in
the
same
pod.
A
A
The
data
is
then
copied
into
user
space
of
the
sidecar
proxy
and
then
the
system
deserializes
the
data
into
objects
that
it
can
use,
and
only
then
does
the
service
mesh
policy
actually
run
on
this
data.
We
haven't
even
gotten
the
data
out
of
the
pod,
yet
we
still
have
to
go
through
steps,
one
through
four
again
to
get
the
data
out
to
the
network
and
then
when
it
gets
to
the
other
side,
this
whole
process
happens
in
reverse.
A
They
were
to
pipe
the
data
into
that
sidecar
and
you'll
see
that
the
documentation
about
the
sidecar
sidecar
pattern
calls
this
out
as
a
trade-off.
These
docs
suggest
that
you
ask
yourself
whether
the
isolation
is
really
worth
the
additional
overhead
that
your
the
sidecar
is
going
to
introduce
in
your
use
case.
A
But
this
overhead
isn't
inherent
to
the
problem.
We
can
actually
eliminate
this
as
a
trade-off,
since
we
can
do
fine-grained,
sandboxing
and
wasm.
We
can
actually
make
this
relationship
between
the
container
and
the
sidecar
much
more
efficient,
even
running
them
in
the
same
process,
but
we
still
get
all
the
isolation
between
the
two
and
possibly
more
depending
on
how
they
were
using
a
file
system
or
volume,
and
because
of
this
we
don't
need
the
socket
to
be
our
interface
between
the
isolated
units
of
code.
A
A
A
However,
sometimes
you
actually
do
need
things
to
be
on
different
machines
across
the
network
and
it
would
be
inconvenient
to
have
different
apis
for
representing
that
and
to
have
to
change
which
api
you're
using
in
your
source
code
based
on
whether
or
not
the
other
container
is
on
the
same
machine
or
not,
but
we
don't
have
to
do
that
in
this
paradigm.
We've
moved
all
of
the
decision
making
related
to
where
the
code
is
running
out
to
the
edges,
so
the
module
that
you'd
write
would
import
the
callee
specifying
a
function.
A
But
if
a
service
mesh
is
being
used,
the
host
would
instead
supply
a
proxy
module.
That's
on
the
same
machine
using
the
much
cheaper
calling
convention
described
before
now.
The
important
thing
is
that
it's
the
host
that
handles
this
distinction,
not
your
code,
and
so
in
this
way
you
can
get
the
optimal
performance
when
you're
talking
to
a
container
on
the
same
machine,
while
not
sacrificing
the
ability
to
communicate
with
a
container
that's
across
the
network.