►
From YouTube: Lightning Talk: Storing WebAssembly Modules with Bindle - Matt Butcher & Taylor Thomas, Microsoft
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.
Lightning Talk: Storing WebAssembly Modules with Bindle - Matt Butcher & Taylor Thomas, Microsoft
In this presentation we introduce Bindle, a technology for distributing collections of WebAssembly modules. We will talk about supply chain security, distributing nanoprocess-based applications (including wasmCloud), secure proxying, and dynamically assembling applications based on host capabilities. Bindle is designed to move beyond plain object storage. It can describe applications as graphs, where the application can be assembled at runtime based on the constraints and capabilities of the host. An embedded device may favor performance and speed of thoroughness. A server may run an application with a web frontend, while a phone may render it using a native windowing solution. Bindle provides a way to describe these characteristics so that the client can assemble the right collection of WebAssembly binaries to execute optimally.
A
Hi
welcome
to
storing
webassembly
modules
with
bindle,
I'm
matt
butcher,
and
this
I'm
joined
by
taylor
thomas
and
we
are
going
to
very
quickly
go
through
an
overview
of
bindle,
an
aggregate
object,
storage
system.
So
what
do
we
mean
when
we
talk
about
aggregate
object?
Storage?
Well,
the
idea
here
is
that
we
want
to
store
a
collection
of
related
objects
under
a
named
entry
and
with
a
single
shared
piece
of
metadata.
A
So
we
want
to
be
able
to
represent
a
group
of
objects
as
a
single
thing
and
represent
the
relationships
between
those
objects
in
that
group,
as
sort
of
an
added
bonus,
we
want
to
be
able
to
share
when,
when
an
aggregate
has
you
know,
five
objects
and
another
aggregate
has
three
objects
and
there's
overlap.
We
want
to
be
able
to
share
the
objects
in
between,
so
we're
not
constantly
copying
up
the
same
things
and
that
allows
us
to
optimize
for
transmission
for
caching
and
for
reuse.
A
So
I
put
together
a
little
diagram
to
sort
of
explain
this
idea
when
we
talk
about
object,
storage
like
azure,
blob,
storage
or
amazon,
s3
or
mineo,
or
something
like
that.
We're
typically
thinking
of
this
mod
model,
where
there's
a
single
piece
of
metadata,
that
has
the
name
the
size,
other
attributes
of
that
object,
and
then
a
single
binary
object
and
the
two
of
them
are
tightly
related.
A
The
idea
there
is
you
have
one
piece
of
metadata
and
then
you
have
several
different
layers
that
can
all
be
pulled
down
together
and
reassembled
into
one
docker
container
on
the
other
side,
bindle
sort
of
one
step
beyond
that
where
the
idea
is
that
we
should
be
able
to
express
more
complicated
relationships
between
objects,
so
it
can
represent
things
in
a
more
tree-like
structure
where
we
might
have
nine
or
11
or
50
different
objects.
But
those
objects
could
be
related
in
different
ways
and
later
on.
A
In
this
presentation,
we'll
talk
about
grouping
and
feature
flags
as
way
of
in
ways
of
indicating
which
particular
objects
within
an
aggregate
object,
storage
system
we
want
to
pull
and
how
we
want
to
configure
them.
When
we
do
so,
I'm
going
to
pass
on
now
to
taylor
to
talk
us
through
the
parts
of
bindle,
so.
B
How
does
all
of
this
get
expressed
so
that
it
looked
like
a
kind
of
complex
graph
in
our
in
our
fun
little
clip
art
there
in
the
beginning,
and
so
what
are
the
different
parts
of
a
bundle?
So
let's
go
ahead
and
talk
about
the
bindle
itself,
so
a
bundle
which
we
refer
to
with
the
lowercase
b
to
differentiate
from
the
name
of
the
project
is
an
is
the
name
for
the
package
inside
of
the
bundle
system,
so
we're
talking
the
the
whole
thing.
This
is
part.
B
This
consists
of
two
parts:
first,
the
invoice
which
is
the
description
of
the
bindle,
and
that
includes
the
metadata
for
it
and
a
list
of
everything
that
should
be
attached
to
it
and
the
parcels
which
are
the
objects
related
to
that
invoice
and
that
together
makes
a
bindle.
So
what's
the
invoice,
an
invoice
is
a
description
of
the
whole
thing
altogether,
so
it
first
has
the
top-level
metadata.
So
we're
talking
the
thing
you
normally
expect
name
version
the
authors
of
it
any
additional,
there's,
also
additional
annotations
that
are
that
are
allowed.
B
Then
you
have
a
parcels
list,
and
this
is
the
list
of
each
attached
parcel
which
we'll
talk
about
what
makes
a
part
what
makes
up
a
parcel
and
then
each
each
invoice
can
have
a
set
of
groups.
That
gives
you
a
way
to
organize
different
parts
of
the
bindle
together
and
there's
also
a
section
for
signatures
which
we'll
talk
a
little
bit
more
about
in
a
second
now,
as
for
a
parcel,
a
parcel
in
and
of
itself
is
just
data.
B
It
can
be
anything
it's
just
it's
just
bytes
of
some
kind,
and
so
the
invoice
actually
lists
all
those
parcels
and
how
they're
connected
using
a
shot
and
then
that
shot
contains
them
and
then
there's
also
other
information
like
what
kind
of
type
it
is.
What
you'd
expect
in
in
most
object
storage
systems
now
what's
interesting.
B
Is
that
because
it
can
be
an
arbitrary,
any
arbitrary
types
of
data,
a
bundle
could
be
used
to
represent
something
like
a
web
page
and
it
would
have
a
parcel
for
the
html
file,
a
parcel
for
the
css
file,
a
parcel
for
each
image
file,
probably
a
parcel
for
the
javascript
file.
All
those
things
together.
A
So,
in
addition
to
this,
we
have
this
notion
of
features
and
groups
as
way
of
ways
of
describing
the
relationships
between
different
objects
inside
of
an
invoice.
So
you
might
think
of
it.
This
way
imagine
we
had
an
application
that
had
both
a
web
ui
and
a
potential
ui
that
could
run
on
the
desktop
right.
A
A
lot
of
the
logic
is,
is
the
same,
so
you've
got
some
sort
of
core
resources
that
are
in
one
group,
and
then
you
might
have
a
group
that
has
a
a
web
ui
with
the
same
kind
of
index,
dot,
html
and
css
files,
and
things
like
that
groups
allow
you
ways
to
say:
okay,
these
objects.
These
parcels
belong
here.
These
parcels
belong
here
and
and
when
you
pull
this
one,
these
are
the
required
relationships
between
this
and
when
you
pull
that
these
are
the
required
relationships
between
those
features
are
a
little
more
special.
A
Imagine
like.
If
you
have
a
system
where
there's
a
gpu,
you
might
want
to
turn
on
a
feature
to
take
advantage
of
that
gpu,
whereas
on
a
platform
without
one,
you
might
not
want
to
turn
on
that
feature.
So
features
and
groups
together
are
tools
to
indicate
a
parcel's
relationship
to
the
bindle
itself
and
to
the
other
parcels
inside
of
that
bindle
now
quickly,
I'll
also
talk
about
signatures.
A
One
of
the
important
things
that
we
wanted
to
make
sure
we
could
accomplish
in
this
system
was
a
cryptographic
provenance
trail
so
that
you
would
always
be
able
to
say.
Okay
when
I
pull
this
assembly
of
objects,
these
are
exactly
the
objects
that
the
creator
in
that
the
creator
of
this
bindle
intended
to
be
pulled
together
right
and-
and
we
wanted
to
do
that,
a
little
more
elaborately.
A
So
we
created
a
signature
model
that
allows
you
to
express
relatively
complicated
signing
chains
and
provenance
chains
so
that
in
those
cases
where
software
supply
chain
security
matters
to
you,
there
are
a
plethora
of
different
ways
that
you
can
use
this
signature
data
to
verify
that
things
are,
as
the
original
creators
hosts
and
verifiers
intended
them
to
be.
So
now
we're
going
to
switch
over
to
some
examples,
and
taylor
is
going
to
kick
us
off
with
the
first
one
here.
Yeah.
B
So
the
examples
part
is
really
just
you
might
have
gotten
lost
in
that
big
fire
hose
of
information.
We
just
gave
you
so
let's
go
ahead
and
talk
about
some
very
specific
examples.
So
each
example,
starting
with
this
basic
bundle
example
we'll
have
a
link
here
at
the
top.
You
can
click
on
that
when
you,
if
you
download
the
slides
and
you'll,
be
able
to
see
the
what
the
invoice
actually
looks
like
so
this
first
one
is
a
very
simple
basic
bundle
with
none
of
the
the
bells
and
whistles.
B
B
B
Now
these
are
all
technically
by
default
part
of
the
default
group.
Hence
the
name,
and
so
I
put
a
little
box
around
to
show
there's
a
group
but
there's
no
requirements
here
that
are
expressed.
This
is
just
there's
a
bundle
and
there's
three
files
in
the
spindle.
There's
no
relationships
defined
or
anything
like
that.
A
This
is
a
slightly
more
complicated
example
that
that
illustrates
how
groups
might
be
used
so
now
in
taylor's
example,
when
an
end
user
agent
pulled
that
that
bindle,
the
assumption
is
that
it
would
pull
all
three
parcels
because
they
were
part
of
the
default
group.
Well,
what
if
we
have
a
situation
where
a
particular
bindle
maps
a
more
sophisticated
array
of
objects?
A
So
here's
an
example:
my
bindle
is
actually
has
both
a
client
application
in
it
and
a
server
application
in
it,
and
we
can
represent
these
as
separate
groups
right
then
we
might
also
even
have
a
third
group
that
has
some
utilities
that
could
be
used
that
are
additional
command
line
tools
that
might
be
necessary
in
some
situations,
but
not
in
others.
So
we've
got
some
red
bright,
bold
red
arrows
here
to
indicate
when
a
relationship
is
required
and
and
then
we've
got
some
pale
arrows
to
indicate
when
it's
not
when
it's
optional
right.
A
So
the
idea
here
is:
we've
got
a
group
called
a
cli
group.
It
has
two
objects
in
it.
So,
by
default,
when
I
pull
this
invoice
and
and
activate
the
cli
group,
I
will
get
those
two
first
and
second
objects
and
they
will
be
pulled
down
along
with
my
with
my
bundle,
so
those
are
two
parcels
that
are
going
to
come
in
the
bundle.
A
Now,
if
I
want
to
run
a
server,
I
might
also
want
to
turn
on
the
server
group
and
turning
that
on
will
give
me
a
daemon
that
I
can
run
in
the
background
right.
So
if
I
turn
on
that
group,
then,
when
my
bundle
client
pulls
it's
going
to
pull
the
server,
but
it
is
also
going
to
pull
the
utility
group,
because
we
can
see
that
there's
a
requirement
relationship
between
the
daemon
process
and
the
blue
box
there
at
the
bottom,
with
the
third
item
located
inside
of
it.
A
So
what
what's
illustrated
here
is
this
idea
that
you
can
have
a
single
bindle
that
encapsulates
a
more
sophisticated
application
and
you
can
model
the
relationship
so
that
the
agent
can
really
pull
a
bundle
and
pass
in
the
configuration
and
be
sure
that
the
the
configuration
it
passes
in.
I
need
this
group.
B
Yeah,
so
last
just
to
finish
this
off
as
an
example
of
using
was
and
nano
processes,
which
is
a
thing
that
still
in
products
we're
not
going
to
talk
about
here.
But
the
idea
is
what,
if
you
had
a
heavy
and
light
example.
So
if
you
wanted
to
run,
if
you
were
on
a
more
powerful
device
or
a
something
else
like
a
raspberry
pi,
you
could
run
two
different
versions
of
something
so
in
this
example
weather
app.
B
So
if
you
need
that
heavier
thing,
it's
going
to
give
you
more
accurate
results
and
you
have
the
processing
power
to
do
it.
It'll
select,
you
can
select
one
of
the
almanac
group
members
or,
if
you're
running
on
a
raspberry
pi,
you
could
run
the
lib
almanac
lite,
and
so
that's
what
these
they're
both
required
in
this
case,
but
you're
allowed
to
select
from
each
group
to
be
able
to
satisfy
the
requirements.
So,
hopefully
you've
enjoyed
this
overview
of
bindle
very
fast.