►
From YouTube: Who Knew Dogfood Could Taste This Good? A WebAssembly In Producti... Taylor Thomas & Brooks Townsend
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Who Knew Dogfood Could Taste This Good? A WebAssembly In Production Story - Taylor Thomas & Brooks Townsend, Cosmonic
One of the most common refrains we hear when we talk to people about WebAssembly (Wasm) is "well...I've seen tons of examples but it seems like it is just a toy and not ready for production." In this talk, we hope to prove the opposite! We will discuss how Cosmonic built almost its entire platform using Wasm and wasmCloud. To start, we will review what Wasm and wasmCloud are and how they work. Then, using what we built at Cosmonic as context, we will dive into concrete details of real databases, message queues, event sourcing, key-value stores, infrastructure provisioning, tracing, metrics, and security controls – all leveraging Wasm! With that knowledge, we will review the pros and cons of using Wasm, the gaps that need to be filled, the lessons we learned, and how it helped influence the Wasm community.
A
B
Yeah
Brooks
Townsend
lead
software
engineer
at
cosmonic
and
also
I'm
a
maintainer
of
the
cncf
open
source,
wasm
Cloud,
which
is
the
app
runtime.
We'll
talk
a
little
bit
about
today,
I'm
a
part
of
this
fun,
Venn
diagram
of
people
that
knows
Elixir
or
webassembly
and
rust
that
there's
a
very,
very
small
intersection
in
the
middle.
There
love
doing
demos
and
and
yeah
Taylor
yeah.
A
So
I
am
a
director
of
engineering
at
cosmonic.
I
am
a
restation.
Do
a
lot
of
rust
coding
came
from
doing
gopher
stuff
before
and
I
am
the
co-creator
of
cresslet
and
bindle.
If
you've
been
looking
at
anything
in
the
web
assembly,
space
you've,
probably
at
least
heard
of
creslit-
that
was
something
I
was
a
maintainer
of
our
creator
of
and
then
I'm
also
a
general
like
serial
open
source,
maintainer
I'm,
an
Emeritus
hell,
maintainer
I
was
a
core
Helm
maintainer
for
a
long
time.
A
A
First
off
we're
going
to
go
over
what
webassembly
is
and
just
out
of
curiosity
here,
how
many
people
have
heard
of
webassembly
how
many
people
have
used
it?
Okay,
there
we
go,
that's
what
I
thought
so
we're
going
to
talk
about
it
a
little
bit
in
like
what
what
web
assembly
is,
why
it's
important
and
then
what
is
this
whole
Wasim
cloud
and
cosmotic
thingy?
This
is
setting
kind
of
the
the
foundation
for
what
we're
going
to
show.
A
We
did
in
production
with
all
of
this
and
then
we'll
go
over
the
architecture
of
our
our
applications
and
how
everything
is
working,
the
Deep
dive
into
individual
things.
We
thought
would
be
most
important
to
share
the
lessons
on
and
then
Lessons
Learned
From
that
and
then
after
that,
we'll
talk
a
little
bit
about
what
we're
doing
next.
So
we
have
this
saying
if
any
of
you
have
talked
to
us
before
you've
probably
heard
us
say
this:
webassembly
is
neither
web
nor
assembly,
which
is
kind
of
funny,
given
its
name.
A
The
big
thing
is
that
it's
an
open,
w3c
standard
and
it
first
became
popular
for
the
web
when
it
came
out
and
because
it's
for
it
because
it
became
popular
in
the
web,
it
has
some
things
that
the
web
desires
and
that's,
namely,
that
it's
safe
and
secure,
efficient
and
fast.
It's
a
polyglot
thing.
You
can
write
in
any
language
and
it's
portable.
You
can
run
in
all
major
browsers.
A
A
You
also
want
this
to
be
a
thing
where
you
could
write
it
in
any
language
and
you
want
it
to
be
able
to
run
on
any
operating
system,
not
just
Linux,
not
just
a
specific
processor,
but
every
single
operating
system-
and
this
is
a
very
important
selling
point
for
webassembly
and
everything
that
we
build
on
with
it.
But
that's
just
remember
that
webassembly
is
a
compilation
Target,
it
isn't
a
language
I
mean
there's
we
can
nitpick.
But
essentially
that
is
true
like
it
is
a.
It
is
a
compilation.
A
Target,
you
don't
learn
to
write
webassembly
you
compile
to
webassembly.
Now
the
thing
with
webassembly
is:
there
are
still
some
gaps.
The
language
support,
especially
for
server
side,
is
still
limited,
but
it's
quickly
growing.
We
had
a
cloud
native
awesome
day
a
few
days
ago
and
we
heard
a
bunch
about
languages
that
are
that
are
getting
very
close
to
having
it
we're
talking
things
like.net
and
Python,
and
things
like
that.
So
those
are
coming
they're
not
here.
A
So
if
you
have
a
bunch
of
dependencies
in
there
from
that
you've
imported
they
get
compiled
in
and
we're
working
on
that
part
too,
it's
called
the
component
model
and
at
the
very
base
level,
webassembly
is
numbers
and
numbers
out,
and
so
that
kind
of
limits
how
effective
it
can
be
when
getting
big
adoption,
but
also
that's
being
improved.
There's
no
concrete
types
yet
so
we're
going
to
talk
a
little
bit
next
about
like.
A
B
Yeah,
so
when
you
look
at
the
Modern
Computing
environment,
there
we
go
and
kind
of
what
we
see
in
the
cloud
native
landscape
over
time.
We've
further
reduced
the
amount
of
responsibility
on
the
developer
and
compute
targets
are
getting
smaller
and
smaller,
so
going
from
pce
to
VMS
to
Containers
the
responsibility
is
getting
smaller
and
smaller
and
containers
were
abstracting
away.
The
kernel
so
you're
still
compiling
for
Linux
you're,
still
compiling
for
a
specific
architecture.
B
But
still
with
this,
even
though
we
have
deny
by
default
security,
people
are
still
baking
in
their
dependencies
into
the
the
final
binary,
so
they're
still
taking
code
that
they
don't
write
the
the
non-functional
requirements
and
compiling
it
all
together.
The
same
thing
that
we
do
now
and
that
that
works
really
well
for
some
use
cases,
but
it
gets
into
a
lot
of
pain
when
it
comes
down
to
the
maintenance
of
the
application
oftentimes.
You
are
recompiling
your
app
for
reasons.
B
That
is
not
because
your
actual
code
change,
but
because
you
need
to
update
some
dependency,
that's
open
source
and
resolved
a
vulnerability.
All
those
things
so
wasn't.
Cloud
takes
this
a
step
further
and
abstracts
the
capabilities
or
the
non-functional
requirements
away
from
the
application,
and
to
give
you
a
little
bit
of
a
concrete
example,
say
like
a
to-do,
app
the
functional
requirements
of
a
to-do
app.
Are
you
want
to
create?
B
Read,
update,
delete
to
Do's,
like
that's
the
code
that
you
as
a
developer,
are
wanting
to
write
like
you
have
an
idea,
and
you
want
to
implement
that
the
non-functional
requirements
are
I'm,
gonna
need
to
spin
up
a
web
server
and
listen
on
some
port
and
I
need
to
store
this
in
some
persistent
data
store
and
I
need
to
pick
which
one
I
need
exactly
to
compile
in.
All
of
that
is
abstracted
away
the
non-functional
requirements,
so
you
just
get
down
to
writing
your
business
logic
or
your
idea
and
so
to
explain
wasmcloud.
B
Now
the
wasn't
Cloud
application,
runtime,
like
I,
said
I'm
part
of
a
weird
Venn
diagram
is
written
in
Elixir,
OTP
and
rust.
So
we
get
the
security
and
speed
of
rust,
but
the
orchestration
of
processes
and
like
the
supervision
model
from
OTP,
which
is
really
good
at
running.
Small
lightweight
processes,
The
Elixir
processes,
kind
of
inspired
or
erlang
process
has
kind
of
inspired.
What
like
go
routines
and
green
threads
kind
of
are
today
way
back
in
the
day.
B
So
we
take
advantage
of
that
scalability,
not
just
many
different
web
assembly
modules,
but
running
them
across
a
different
wasm
Cloud
hosts
now
I
talked
about
capabilities
or
non-functional
requirements.
These
are
things
that
you
get
to
pick
at
runtime,
so
you
code
your
app
in
terms
of
an
abstract
contract,
something
like
a
key
value
store
and
you
can
do
all
those
things
with
the
interface,
the
key
value
interface
and
then
at
runtime.
You
say:
okay,
I'd
like
to
use
redis
or
okay
I'm,
deploying
to
my
organization's
Cloud,
environment
and
I'm,
going
to
use
AWS
dynamodb.
B
The
actors-
it's
not
quite
like
an
actor
model,
but
it's
the
webassembly
modules
that
is
implementing
your
business
logic,
and
these
are
stateless
reactive
pieces
of
compute
that
you
can
kind
of
deploy
anywhere
stitch
together
to
create
your
application
and
the
last
part
that
really
makes
this
all
feel
kind
of
like
magic
and
what
really
abstracts
a
lot
of
pain.
For
me
personally
is
the
lattice
Network.
It's
a
interconnected,
self-forming
self-healing
Network,
that's
kind
of
powered
by
gnats
under
the
hood
and
basically
no
matter
where
your
webassembly
modules
are
running.
B
That
only
means
so
much
for
a
distributed
system,
if
you
can't
actually
have
them
talk
to
each
other.
So
this
deals
with
the
connecting
RPC,
no
matter
where
the
actual
modules
are
running
and
then
cosmonic,
you
know.
So
that's
that's
wasn't
cloud
in
a
couple
of
different
layers:
cosmotic
company,
that
Taylor
and
I
work
for
we're
building
a
platform
for
hosting
webassembly
applications.
B
Our
whole
goal
is
to
make
it
a
painless
experience
to
make
distributed
apps
and
to
take
that
from
Dev
to
production,
and
the
reason
why
we're
talking
about
it
today
is
because,
even
though
all
of
this
power
is
in
the
open
source,
somebody
has
to
manage
this
at
some
point,
you
see
all
of
the
benefits
you
know.
Kubernetes
is
something
that
you
can
do
all
on
your
own,
but
managed
services
are
very
popular
because
taking
that
complexity
away
from
the
developer
again
just
reduces
pain
reduces
the
management
you
have
to
do
now.
B
The
real
thing
that
we're
here
to
talk
about
we're
here
to
talk
about
dog,
fooding
or
champagne,
drinking
whatever
your
you
know,
acronym
is
for
it,
but
everything
on
the
back
end
is
built
with
wasm
Cloud.
So
we
built
our
back
end
on
webassembly
modules,
hot
swappable
capabilities
in
an
effort
to
take
advantage
of
all
the
things
that
we
are
putting
out
as
benefits
and
prove
that
webassembly
can
be
used
on
the
server
side
now
to
run
a
platform,
and
we
are
running
our
platform
in
prod.
Now.
A
So
that
was
the
basic
stuff
to
just
understand,
so
keep
all
that
mind.
This
is
important
context
to
understand
these
points,
which
is
the
real
meat
of
what
we
want
to
talk
about.
So
let's
talk
about
our
architecture,
we're
just
going
to
show
this
to
you
actually
give
me
a
sec
to
swap
over
to
this
mirrored
mode.
So
I
can
show
you
hello
there
we
go
okay.
A
So
what
we
have
here
is
the
entire
back
end
for
cosmonic
running
in
cosmotic
yeah
that
this
this
is
it
right
here
you
can
see
the
whole
thing.
This
is
the
cosmotic
platform
running
on
the
cosmotic
platform,
and
you
can
zoom
in
and
see
how
everything
is
connected
one
to
another.
Now
these
lines
are
a
little
bit
crazy
yep,
but
you
can
see
like
we
have
all
these
applications
they're
written
in
webassembly,
connecting
to
these
capabilities
that
were
mentioned,
and
this
is
live
I'm
not.
This
is
not
some
demo
or
can
thing.
A
This
is
me
looking
at
our
actual
running
stuff,
that
is
running
cosmotic
right
now
on
on
this
canvas
that
we
have
that
lays
it
all
out
now.
I
know
that
all
of
this
looks
maybe
a
little
bit
as
soon
as
we
get
back
to
here.
This
is
this:
is
the
actual
architecture
diagram
that
happens
there
we
go
so
I
know
that
it
looks
a
little
bit
crazy.
I
mean
it
kind
of
looks
like
this
a
little
bit,
or
one
could
maybe
say
this,
but
actually
like
I,
know,
I
know.
A
That
seems
like
crazy
diagram
going
on
right
there,
but
this
is
actually
really
really
cool
underneath
the
hood,
and
we
just
wanted
to
show
you
that,
like
that's
the
final
thing,
but
let's
talk
the
details,
so
Dog
fooding
101,
we
always
like
Brooks,
mentioned
call
this
drinking
our
own
champagne,
but
most
people
call
it
dog
fooding.
So
when
we
started
this
product,
we
decided
that
we
wanted
to
be
customer
zero.
A
Now
we
could
have
whipped
this
all
up,
really
quick
with
go
or
rust
or
Elixir,
like
all
things
that
we
use.
We
could
have
just
whipped
this
all
out
and
said
here
you
go,
but
we
we
decided.
No,
we
need
to
actually
do
this
like
we
were
making
some
really
strong
claims
here
with
what
we're
able
to
do
and
we
needed
to
put
those
to
the
test
so
that
we
could
tell
people
no
like
we're
not
just
making
this
up,
we've
actually
done
it,
and
so
this
learning
for
us
has
served
two
purposes.
A
First
off
it
has
improved
our
open
core.
This
is
still
Watson
Cloud,
underneath
the
hood,
and
so
this
everything
that
we
discovered
goes
back
into
wasm
cloud
and
makes
it
better
for
anyone
using
it
from
an
open
source
perspective,
but
it
also
has
improved
the
customer
experience
for
us
because
we
were
our
own
customer.
We
had
to
go
through
a
lot
of
the
pain
points
before
our
customers
ever
had
to,
and
so
that's
why
we
why
we
did
this
now?
What
tech
do
we
actually
use?
A
Obviously
wasm,
but
beyond
that
we
also
use
open
Telemetry,
we
use
Nats
for
the
communication
layer.
We
have
various
data
stories,
namely
Vault
and
redis,
being
the
big
ones
we
use
AWS
as
well
as
a
bunch
of
other
Cloud
things
and
we're
not
limited
to
that,
and
we
also
for
our
infrastructure.
We
do
Nomad
with
our
own
custom
task
driver.
We
talked
about
that
hash
account
recently
and
it
actually
just
went,
live
on
YouTube
I
found
out
and
console.
A
B
Yeah,
so,
let's
start
out
with
one
of
the
media
benefits
that
we
saw
as
soon
as
we
started.
Thinking
about
customer
workloads,
everything
that
we
coded
for
the
the
back
end,
it
was
interacting
with
a
key
value.
Store,
was
interacting
with
a
key
in
abstract
key
value
store,
so
we
were
slotting
in
redis.
We
were
working
with
data
and
then
we
realized
that
we're
going
to
be
storing
some
secrets.
You
know
not
specific
customer
data,
but
we're
going
to
generate
secrets
for
customers.
B
We're
going
to
you
know
have
things
that
we
don't
want
to
just
be
sitting
in
some
plain
text:
key
value
store.
So,
instead
of
modifying
our
applications
that
interact
with
the
key
value
store,
we
simply
went
out.
We
wrote
a
vault
implementation,
a
hashcourt,
vault
implementation
and
then
this
little
line
that
you
saw
on
the
canvas
there
that
we
were
dragging
to
redis
just
drag
the
line
to
Vault.
B
Instead,
so
with
wasmcloud
all
of
our
actors
that
we
needed
to
store
secrets,
we
can
have
them
interact
with
Vault
and
none
of
that
code
actually
needed
to
change
when
we
were
going
from
developing
on
it
to
to
changing
default.
So
immediately.
The
abstraction
of
capabilities
is
something
that
we
saw
benefits.
B
It
takes
four
hours
to
figure
out
what's
going
on,
and
so
we
added
tracing
a
little
bit
into
the
development
of
cosmonic
and
all
of
that
again
went
into
the
open
core.
So
for
wasm
cloud,
even
if
you're
not
using
our
platform
at
all,
you
can
just
give
it
an
export
or
URL,
and
you
get
all
of
your
workloads
traced
automatically.
So
we
love
kind
of
contributing
that
back.
This
is
an
actual
example
of
one
of
the
things
that
we
like
one
of
the
traces
that
we
can
look
at.
It's
an
infrastructure
provision.
B
So
and
each
color
change
is
a
network
hop
a
change
in
service,
and
so
we
get
a
lot
of
mileage
out
of
doing
this
tracing
for
our
own
debugging
and
and
because
of
that
our
mean
time
to
resolution
has
dropped
a
lot
and
last
thing
that
I'll
talk
about
before
handing
over
to
Taylor
is
we
started
with
the
benefit
or
the
the
claim,
with
webassembly
that
it's
near
native
speed
and
can
rapidly
scale
and
yup
it's
fast.
Nowhere
in
our
performance
testing,
you
know
when
we're
looking
at
something
and
like.
B
Why
is
this
taking
a
second?
It
was
never
the
speed
of
webassembly
that
was
bottlenecking
our
system.
It
executes
in
Max
a
couple
of
milliseconds
couple
of
microseconds
and
nowhere
in
the
platform
you
know
we're
running
the
entire
platform.
I,
don't
know
if
you
saw
it
when
Taylor
pulled
it
up,
but
each
service
we
have
it
kind
of
distributed
for
high
availability,
but
we're
running
three
instances
of
these,
like
250
kilobyte
modules.
So
each
piece
of
our
platform
is
like
what
750
kilobytes
that's
how
math
works
very.
A
A
A
This
is
the
programming
model
that
a
lot
of
people
have
seen
in
serverless
right,
like
you,
do
an
HTTP
request
or
something
and
then
it
triggers
your
function
to
run,
and
then
your
function
does
something
that's
an
example
of
reactive
programming
and
wasmcloud
is
letting
you
do
like
plug
this
plugable
thing
of
putting
in
different
pieces
along
reactive
programming,
so
data
is
processed
and
sent
using
these
actors
we've
mentioned,
and
then,
when
I'm
talking
about
this.
This
is
this
is
stuff
like
config
data
and
policy
information.
A
All
of
these
different
things
can
be
sent
and
used
as
triggers
in
our
system,
so
we
use
like
we
use
a
messaging
bus
for
this.
In
our
case,
it's
Nats
and
the
wasn't
Cloud
actors
are
reactive
to
that
data.
That
comes
in
so
they
receive
the
data
they
need
from
the
message
do
something
with
it
and
then
move
on.
So
we
use
most
of
this
in
our
customer
facing
apis
our
configuration
and
as
the
entry
point
into
our
event,
sourcing
system
and
I
want
to
say.
A
Like
that's
the
first
bullet
point
here,
wasm
is
very
very
good
at
this,
I
mean
extremely
good
at
it,
and
wasmcloud
makes
the
whole
thing
easier
for
us
because,
like
I
mentioned,
Nats
is
the
the
thing
we're
using,
but
it
doesn't
matter.
If
you
wanted
to
use
Kafka
or
rabbitmq
or
any
type
of
messaging
system,
you
can
just
implement
the
contract
and
plug
it
in
and
so
then
the
actual
business
logic
of
handling
your
thing
does
not
change.
A
It
does
not
have
to
know
what
it's
connecting
to
or
any
of
that
stuff
that
you
normally
have
to
do
in
a
reactive
system.
So
then
we
also
do
all
this
with
event
sourcing,
so
event
sourcing
could
be
its
own
talk.
That's
why
I'm
going
to
once
again
give
it
a
description
of
this
that
may
trigger
anyone
who's
an
expert,
don't
worry
about
it.
This
is
so.
This
is
the
real
softball
definition,
but
basically
we
created
a
contract.
A
A
So
it's
really
really
flexible
and
the
value
that
we
demonstrated
before
with
shifting
from
redis
to
Vault
is
is
that
same
kind
of
idea.
We
like
to
we
first
tested
a
super
basic
implementation
of
it,
and
then
we
built
the
real
thing
that
does
it
like
multi-threaded,
locking
all
the
different
stuff
you
need
and
the
code
that
we
wrote
didn't
have
to
change
at
all.
We
just
swapped
it
out
and
boom
production
ready.
A
So
what
this
looks
like
in
practice-
and
this
is
the
crazy
diagram
here-
for
it
again-
sorry
I
like
putting
these
these
crazy
diagrams
up
here.
But
this
is
like
what
an
event
sourcing
works
for
a
wormhole.
A
wormhole
for
us
is
an
Ingress
into
our
system.
Space
theme,
Space
theme
yeah,
that's
me,
I
mean
you
got
it,
and
so
we
have
different
of
commands
that
come
in
they
go
to
these
different.
A
So
each
of
these
diamonds
is
a
piece
of
code
and
they
all
have
to
handle
tons
of
different
types
of
events,
and
some
of
these
events
go
eventually
get
stored
into
redis
and
some
get
stored.
Some
get
triggered
out
into
our
infrastructure,
but
what
the
so
all
of
this
crazy
stuff
that's
happening
is
handled
by
these
three
things,
so
this
is
just
screenshots
from
that
that
thing
I
was
showing
you
at
the
very
beginning
with
like
this.
A
We
have
the
this
Aggregate
and
it's
just
pointing
to
this
thing:
that's
receiving
its
events,
the
basically
an
event
sourcing
provider,
and
then
we
have
this
process
manager.
That
does
a
lot
of
the
logic
handling
and
it's
just
connected
as
well.
To
that,
then
we
have
something
that's
connected
to
redis
and
goes
at
like
this
is
It's
reduced
to
a
very
simple
diagram.
A
It
looks
like
you
sketched
it
and
then
put
it
into
the
cloud
and
that's
what
we
were
going
for
with
this
and
event
sourcing
is
has
been
a
powerful
model
for
us,
but
the
whole
point
is
just
that
it
is
a
nice.
These
abstractions
have
worked
really
well
for
us
because
you
can
plug
and
play
any
of
these
things.
We've
done,
we've
done
and
adapt
it
for
whatever
you're
doing
inside
of
your
your
infrastructure
and
your
systems.
A
So
the
other
thing
we
did
is
we
we
learned
here.
We
abstracted
over
infrastructure,
so
provisioning
was
on
Cloud
on
different
infrastructure.
Different
interests
and
on
different
infrastructure
is
like
very
it's
not
platform
agnostic
for
obvious
reasons,
so
the
Watson
Cloud's
very
good
at
scheduling
these
applications,
but
we
needed
functionality
to
schedule.
The
actual
was
on
cloud
processes
abstracting.
The
infrastructure
is
that
is
still
really
difficult.
That's
something
we
can't
do
very
well.
A
We
kept
it
to
a
minimum
and
probably
still
did
too
much
and
we
needed
the
functionality
of
a
scheduler,
and
so
we
came
up
with
the
our
custom
thing
for
nomad.
That
runs
all
these
all
these
things
we
use
Nomad
as
the
scheduler,
and
so
if
we
could
do
it
all
again
from
the
beginning,
we
would
say
that
this
is
something
where
you
can't
really
abstract
over
that
with
webassembly
or
even
some
of
the
providers,
so
we
would
just
probably
get
the
Nomad
scheduler
from
the
get-go
rather
than
doing
it.
A
So
that's
one
part
where
we
thought
it
could
work
out
well
and
it
and
it
didn't,
and
then
last
is
this
defense
in
depth.
This
has
been
a
popular
topic
as
of
late.
Let's
talk
about
so
we
run
untrusted
code.
That's
the
thing!
This
is
all
these.
These
things
you
write
for
your
business
logic,
they're,
entirely
interested,
and
so
because
of
this
we
need
multiple
tiers
of
Defense.
So
wasm
itself
gives
us
gives
us
massive
benefits
here,
because
it's
a
Sandbox
and
you
can't
do
anything
with
it.
Unless
you
explicitly
give
it
permission
to.
A
It
has
the
same
permission
model
that
you
see
on
like
a
phone
nowadays,
where
it
says,
can
I
use
the
microphone,
can
I
use
the
camera.
I
can
I
use
this,
and
so
you
still
have
to
do
that
with
webassembly,
and
then
we
have
besides
Watson
itself.
We
have
the
host
security
built
into
wasm
Cloud,
so
each
actor
and
provider
is
signed
and
they
have
to
have
those
specific
Keys
must
be
present
in
the
cluster
to
know
that
it
is
signed
properly
and
it's
completely
decentralized
checking.
A
We
don't
need
like
a
central
server,
but
they
have
to
have
explicit
access
granted
to
capabilities.
You
can't
just
all
of
a
sudden
access
a
database
if
you're
not
signed
to
be
used
as
a
database,
and
then
we
have
this
idea
of
the
net
Security
net
security
also
has
decentralized
authentication
that
use
that
uses
signed,
keys
and
jwts
to
actually
authenticate.
This
has
helped
us
to
segment
traffic
and
data,
but
it's
also
presented
a
lot
of
different
challenges
for
us.
A
We
need
to
figure
out
how
to
allow
the
right
things
across
the
different
information
boundaries,
because
this
is
a
multi-tenant
system,
but
it
was
very
powerful
once
we
had
figured
it
out
and
then
because
it
is
multi-tenant
as
well.
We
have
to
have
a
set
of
allow
and
deny
rules,
and
this
is
where
it
became
really
cool,
because
those
limit
checks
that
we
we
enforce,
depending
like
limits
on
the
platform,
are
actually
provided
using
an
actor
that's
written
in
webassembly,
and
then
we
have
at
the
very
end.
A
We
have
this
firecracker
thing
and
the
firecracker
was
one
example
where
the
limits
of
webassembly
show
through
4S
we
needed
firecracker,
which,
if
you're
not
familiar
with,
is
a
micro
VM
released
by
by
AWS
by
Amazon,
to
to
basically
provide
isolation
and
for
shared
processes
so
provide
like.
We
can't
do
everything
that
a
provider
needs
to
do
with
webassembly,
yet
we
will
soon
in
the
future.
But
right
now
we
can't-
and
so
these
are
untrusted
binaries
and
to
make
sure
people
can
run
them.
A
First
off
welcome
to
the
bleeding
edge
everybody.
That's
what
this
whole
thing
is.
The
bleeding
edge
is
real
and
I
I
understand
that
some
of
you
might
have
requirements
that
exclude
you
from
doing
some
of
this,
because
bleeding
edge
is
a
no-go
at
some
big
companies.
I
get
that,
but
you
get
a
really
large
list
of
very
nice
benefits
from
it.
A
Basically,
on
the
whole,
all
the
benefits
were
incredible
for
us
and
proved
that
this
new
technology
can
fit
really
nicely
next
to
existing
tools
and
Tech
Stacks,
like
I,
said
we're
using
Nomad
we're
using
things
that
there's
there's
pieces
of
our
system
that,
like
we're
not
going
to
run
like
we
use
Vector
for
logging
stuff,
we're
not
going
to
go
rewrite
vector
and
try
to
get
it
to
compile
to
watch
them.
It
runs
in
a
container
on
another
node
in
Nomad,
we're
still
using
Technologies.
A
Alongside
this,
isn't
like
a
hey,
kick
everything
out,
rewrite
everything
to
us,
and
that's
not
what
we're
saying
we're
saying
that
doing
this
as
webassembly
gave
us
some
huge
benefits
and
we
built
this
whole
platform
on
top
of
it.
One
of
the
other
motivations
for
us
submitting
this
talk
in
the
first
place.
Is
we
get
this?
We
have
this
constant
refrain
of.
Oh
well,
webassembly
looks
cool,
but,
like
you
can't
really
do
anything
with
it,
I
mean
we
just
showed
you
we're
doing
something
with
it.
A
The
whole
thing
is
running
on
top
of
webassembly
all
the
the
user
interactions.
Those
are
all
webassembly
things
that
are
handling
it,
and
so
we
just
want
to
say,
like
that,
should
Inspire
some
confidence
that
you
can
actually
do
something
real
right
now.
So
let's
talk
a
little
bit
more
about,
maybe
some
of
the
pros
and
cons
of
web
assembly
itself
to
kind
of
cover
this
yeah.
B
So
as
we're
going
through
we're
actively
proving
out
this
technology
on
the
server
side-
and
we
know
that
the
speed
and
the
size
and
the
scalability
is-
is
incredible:
we
we
had
great
gains
and
and
loved
watching
that
actually
come
together.
Being
able
to
compose
webassembly
modules
together
to
create
applications
is
really
important
and
something
that's
difficult,
depending
on
what
framework
are
you're
using
and
the
deny
by
default.
B
Security
gives
us
a
lot
of
confidence
in
our
own
platform
and
gives
us
kind
of
a
flexible
permissions
model
when
we're
making
our
own
platform
and
stuff
like.
Even
if
we're
writing
the
code.
The
deny
by
default
security,
gives
us
confidence
that
if
we
pull
in
some
open
source
Library
area
into
the
piece
of
logic
that
we're
doing,
we
know
that
it
can't
do
anything
unexpected.
B
We
don't
manage
crds
and
controllers,
we're
not
running
on
kubernetes
we're
running
with
webassembly
and
wasm
cloud
and
using
a
scheduler
to
actually
get
the
benefits
of
deploying
the
pieces
of
our
compute
on
different
parts
of
our
platform,
but
it
wasn't
all
sunshine,
sunshine
and
Roses:
we've
been
looking
at
something
that
Taylor
is
called
the
component
model,
it's
an
advancement
in
webassembly
and
that's
constantly
changing.
So
as
we're
developing
prototypes
and
looking
to
adopt
it.
You
know
our
prototypes
break
because
the
protocol
is
changing.
B
We
are
like
you
said
at
the
bleeding
edge
and
get
you
know
we're
prepared
to
bleed
now
some
of
the
things
don't
really
lend
itself
to
webassembly
Computing
very
well.
If
you're
looking
to
have
a
long
running
process
that
is
just
sitting
in
a
webassembly
module
to
sit
there
and
run
webassembly
is
still
single
threaded,
so
it
doesn't
really
work
very
well
to
sit
there
and
be
constantly
working
on
compute.
The
reactive
programming
and
fitting
to
that.
B
They
are
taking
a
lot
of
things
into
account,
trying
to
come
up
with
use
cases
and
standards
that
will
work
for
everyone,
and
this
is
actually
you
know.
This
is
a
good
and
a
bad
thing.
We
don't
want
to
rush.
This
webassembly
is
a
new
technology.
We
can
prove
these
things
out
and
then
publish
the
standard
we
don't
have
to
rush
through,
but
still
things
like
network
sockets
have
kind
of
come
long
over
years
and
years
and-
and
you
know
we're
building
things
kind
of
around
that.
A
And
I
want
to
point
out
here
that
the
breaking
changes
that
we're
talking
about
are
one
of
the
benefits
of
using
wasmcloud
is
that
we
try
to
paper
over
those
and
Bridge
the
gaps
for
you
right
now.
So
that's.
Why,
like
you,
can
there's
HTTP
servers
and
HTTP
clients
and
we're
bridging
over
that
Gap
right
now
and
there's
a
lot
of
these
things
that
we
kind
of
make
easier
for
you
by
doing
it
inside
of
wasm
cloud
to
to
make
this
something.
Like
I
said
you
can
do
something
real
right
now,.
B
Is
when
it
comes
to
wasm
Cloud
specific
lessons
developing
our
app
during
contracts
may
have
taken
like
a
little
bit
longer
in
the
beginning,
but
the
management
of
these
pieces
has
been
so
much
easier.
As
we've
developed
our
platform
like
a
literally
this
week,
we
updated
our
redis
implementation
and
instead
of
recompiling
all
of
our
little
services
that
use
redis.
B
We
just
updated
the
Reddit
service,
everything
re-links
everything
works
just
as
before,
which
is
a
really
attractive
story
for
the
management
of
an
application,
because
we
didn't
write
like
a
redis
library
like
we
got
all
of
that
from
open
source,
and
taking
advantage
of
that,
we
don't
have
to
recompile
our
whole
platform
to
ship
that
we
really
enjoy
the
reactive
programming
model
and
we
one
one
detail
that
we
may
have
not
dove
into
specifically.
Is
these
implementations?
B
The
providers
are
native
rust
or
native
go
binaries,
and
that's
because
the
ability
to
write
those
things
in
webassembly
isn't
quite
there
yet
like.
There
are
network
sockets
now,
but
they
weren't.
When
we
started
writing
the
platform,
multi-threaded
is
coming
along.
So
even
writing
like
an
HTTP
server.
If
you
use
the
new
sockets,
you
need
to
run
multiple
of
them
to
get
that
kind
of
multi-threaded
environment,
but
the
first
time
that
I
took
our
HTTP
server
and
deployed
it
to
like
Ubuntu,
22
or
whatever.
B
That
has
open
ssl3
and
it
goes-
and
this
was
built
with
opensl
1.1.1
just
makes
me
flip
the
computer
over
right,
I'm
sure
that
other
people
have
seen
that
before.
But
we
really
want
our
whole
platform
to
be
this
platform
agnostic
technology.
It
just
makes
it
easier
when
I'm
working
on
an
M1,
Mac
and
then
deploying
to
x86
Linux
that
binary,
not
changing
is
huge,
and
we
want
to
do
that
for
everything.
In
our
platform,
oh
yeah
and
and
last
I
think
Taylor
nailed
multi-tenancy
pretty
well.
We
we've
got
defense
in
depth.
A
So
that
leaves
us
with
this
question
of
well
what
what
happens
next?
Where
are
we
going
from
here?
First
off,
there's
some
Watson
clouds
or
cosmonic
specific
lessons
that
we
we
learned
here
and
that's
this
is
for
us
like
what
we
wanted
to
move
forward,
we're
going
to
keep
being
our
own
customer
zero.
Anything
you
tried
on
our
platform,
we'll
try
it
out.
A
We
also
plan
on
driving
work
forward
in
the
wasm
standards,
especially
the
the
stuff
that
allows
us
to
compile.
Providers
to
webassembly
we
want,
like
Brooks,
was
saying
webassembly
to
work
everywhere
for
everything
so
that
we
don't
have
to
to
keep
papering
it
over
with
some
of
the
stuff
we're
doing
for
webassembly
itself.
A
The
things
that
we're
going
to
be
contributing
to
are
the
component
model
I'm
not
going
to
go
into
that
here.
I
can
talk
your
ear
off
at
it.
You
can
come
by
the
cosmotic
or
Watson
Cloud
Booth
I'll,
be
there
pretty
much
the
whole
time,
and
you
can
chat
to
me
and
chat
with
me
about
that
or
or
Bailey
who's
also
sitting
up
here
in
the
front
and
we'll
we'll
go
over
we'll
go
over
that
with
you.
A
But
it's
a
really
cool
thing:
that's
coming
out
of
the
web
assembly
specifications
we're
also
going
to
be
working
on
Sig
registry
and
bindle.
This
is
a
part
of
the
bytecode
alliance.
That's
working
on.
How
do
we
store
complex
applications
that
are
our
webassembly
modules
and
then
we're
also
trying
to
make
make
networking
a
whole
lot
easier
to
use.
So
what
can
you
do
so
we
have
the
cosmotic
platform.
A
If
you
want
to
check
it
out,
there's
the
links,
that's
what
the
QR
code
links
to
our
our
platform
is,
is
open
in
a
developer
preview
right
now,
so
you
can
come
check
all
this
out,
build
your
own
crazy
diagram,
like
I,
did
There's
the
link
to
the
actual
watsoncloud
project
and
then
a
couple
other
things.
If
you're
doing
things
in
kubernetes,
which
is
very
likely,
we
have
something
that
we
wrote
called
the
kubernetes
supplier.
A
We
also
have
a
chart
for
wasm
cloud
and
you
can
connect
your
stuff
running
in
kubernetes
to
stuff
running
in
Wasim
Cloud.
So
it's
pretty
straightforward
and
easy,
and
it's
also
once
again
written
as
an
actor,
and
then
we
have
the
capability
providers
and
interfaces.
We've
been
mentioning
the
whole
time.
So
with
that,
let's
leave
a
little
bit
of
time
for
questions.
A
Yeah,
that's
that's
a
good
question
and
I
can
answer
this
one
very
clearly
having
done
another
so
at
the
in
the
beginning,
with
how
like
Watson
Cloud
started,
it
was
embeddable,
and
so
we
actually
put
it
into
crustlet
to
begin
with,
but
Crescent
has
become
kind
of
more
of
a
we've.
We
proved
what
it
was
supposed
to
do
and
people
have
moved
in
different
directions.
A
lot
of
us
are
working
on
these
new
things
like
wasm
Cloud.
A
Some
things
have
been
like
the
container
D
shim
stuff
that
Microsoft
has
been
doing,
but
creslet
doesn't
fit
into
this
directly
anymore.
There's
there's
easier
ways
that
we
think
we
can
integrate
with
existing
systems
like
the
kubernetes
supplier.
I
was
mentioning.
So
that's
that's
where
it
stands
with
kind
of
the
kubernetes
integration
part
we
have
one
over
here.
Oh
I'm,
sorry,
yeah,.
D
I
guess
first,
like
really
appreciate
all
the
work
you
guys
are
doing.
This
is
really
cool
and
enjoying
learning
about
this
project.
I'm
kind
of
curious.
It
sounds
like
there's
a
lot
of
effort
being
put
into
like
the
sandboxing
and
making
sure
that
there's
security
and
deploying
a
multi-tenant,
app
or
I
guess
onto
a
multi-term
platform.
D
Is
there
anything
in
terms
of
like
a
capability
for
tenants
to
be
able
to
host
the
I
guess,
walls
and
binaries
of
each
other's
execution
or
logic?
That
way,
instead
of
something
like
a
webhook
model,
where
you're
like
subscribing
to
events,
you
actually
are
able
to
just
host
or
I
guess,
produce
messages
directly
to
another
tenants,
I
guess
binaries.
B
So
you're
talking
about,
like
you
know
you,
you
have
a
webassembly
module,
that's
kind
of
executing
and
sending
messages
to
like
other
people
who
are
also
running
on
the
platform
yeah.
This
is
something
that
we've
talked
about
kind
of
from
our
roadmap.
From
the
beginning.
Like
we're
running
this
thing
on
our
platform,
everything
needs
to
be
denied
by
default,
like
none
of
that,
like
communicating
between,
we
call
it
a
constellation.
It's
a
segmented,
Network
space.
B
So
we
see
a
lot
of
benefits.
Coming
from
that,
because,
like
we
talk
about
separation
of
non-functional
requirements
into
capabilities,
that's
like
it's
exactly
I.
Think
log4j
is
a
good
example
of
this.
I
know
that
this
is
probably
overused
at
this
point,
but
everyone's
heard
of
it.
So
it's
kind
of
an
easy
analogy
that
one
library
is
kind
of
copied
across
thousands
of
different
applications.
The
idea
with
wasm
cloud
and
cosmonic
is
that
the
distributed
logging
capability
provider
would
be
managed
by
the
platform
team
used
by
every
application
team.