►
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.
From Napkin to the Cloud: A WebAssembly Journey - Kevin Hoffman, Capital One
WebAssembly is not only changing the way we build and deploy software, but it can improve every aspect of the developer experience from napkin sketch to deployment. In this session, Kevin takes you on a trip from application concept (the "napkin") all the way to production in the cloud (and beyond!). He will illustrate the process of building a full-featured, cloud-native application composed of polyglot actors (Rust and Go!) using the open source project wasmCloud. You'll learn how this journey changes for the better in so many ways simply by embracing the power and--even the limitations--of WebAssembly. You'll see how what you build in isolation on your workstation can grow in scale, performance, and resiliency, all without ever having to re-architect components, consume hard-to-use remote services, or recompile a complex chain of dependencies. Ship your napkin to production!
A
So
what
I
want
to
talk
about
today
is
a
journey
from
design
to
production,
and
I
want
to
comment
on
how
that's
different,
when
using
webassembly
as
the
underlying
technology.
To
do
that.
First,
I
want
to
start
off
with
a
real,
quick,
two-minute
tour
of
what
webassembly
is
and
what
asmcloud
is
and
I'll
talk
about
the
application
that
we're
going
to
build
and
that
I
have
built
for
this
demo.
A
A
A
A
So
in
the
case
of
a
web
browser,
the
host
runtime
is
some
kind
of
javascript
engine,
so
in
chrome
it
might
be
v8
and
so
on,
but
in
the
browser
your
host
runtime
is
done
through
javascript
when
you're
outside
the
browser.
There
are
a
number
of
different
web
assembly
host
runtimes
available
to
us.
We
have
wasmtime
from
the
vitacone
alliance.
A
A
A
Wisemcloud
supports
a
rapid
feedback
loop.
We
have
a
rebel
in
one
of
our
command
line
tools.
Wasmcloud
also
provides
a
self-healing
self-forming
mesh
called
the
lattice
that
connects
your
host
runtimes
in
clouds,
iot
devices
edges
and
more.
It
provides
a
single
flat,
topology
network
that
you
can
use
to
manage
and
observe
your
active
workloads.
A
So
let's
take
a
look
at
the
combination
of
webassembly
and
wasm
cloud,
and
we
saw
earlier
that
webassembly
provides
security.
Most
of
the
security
from
webassembly
at
the
core
comes
from
just
the
fact
that
it
contains
no
bytecode
operations
for
interacting
with
the
operating
system.
It
can't
do
things
that
the
host
runtime
doesn't
allow
it
to
do
it's
portable.
A
A
By
giving
us
access
to
loosely
coupled
capabilities
and
those
capabilities
might
be
web
servers,
database
clients
message,
brokers,
those
types
of
things
blob
stores,
seamless
distributed
compute
that
runs
anywhere
is
a
feature
that
we
add
through
wisem
cloud.
You
can
horizontally
scale
your
actors
and
your
capability
providers.
A
Again,
I
mentioned
the
actor
model
earlier
and
we
also
do
contract
driven
design.
So
when
you
build
a
wisdom,
cloud
actor
you're
writing
against
an
abstract
contract,
so
you
might
be
writing
against
the
key
value,
contract
or
abstraction
or
the
web
server
abstraction
or
some
database
client
abstraction
and
not
the
actual
database
itself,
which
means
all
of
those
things
can
change
at
runtime
without
you
having
to
rebuild
or
redeploy
your
code.
A
So
the
application
that
we're
building
is
called
wisem
cloud
chat
and
it's
a
multi-channel,
real-time
messaging
application.
So,
instead
of
a
simple
hello
world
app,
this
chat
application
has
a
full
backend.
It
records
all
of
the
messages
that
go
through
it
and
it
has
multiple
inbound
and
outbound
channels,
including
message
broker,
and
for
our
demo
we're
going
to
use
telnet.
A
So
this
is
essentially
the
napkin
sketch
or
the
blueprint
for
what
we
wanted
to
build
for
the
sample
application,
and
so
you
can
see
that
we
have
some
users
coming
into
the
back
end
through
the
telnet
channel
and
someone
coming
in
through
the
broker
channel
and
in
the
back
in
the
the
true
back
end.
We
have
functionality
lumped
together
in
categories
called
presence
which
is
who's
online,
and
how
long
have
they
been
on
line
for
messages
which
is
essentially
the
message,
processing
and
storage
rooms?
A
A
A
But
this
iteration
of
experimentation
and
redesign
is
pretty
common,
including
another
round
of
refactoring
and
redesign,
and
during
that
process
we
might
actually
get
something
out
into
production
and
deployed.
But
it's
certainly
in
many
cases
nothing
like
what
we
wanted
to
to
build
back
when
we
had
our
amazing
idea-
and
this
of
course
leads
to
despair.
A
So
we
start
off
again
with
our
amazing
idea,
and
then
we
get
to
an
initial
design,
our
napkin,
drawing
which
I
drew
on
a
slide
earlier
and
then
again
we
go
to
early
experimentation,
and
I
think
this
is
where
the
paths
diverge.
The
results
of
the
early
experimentation
is
going
to
be
different
this
time
and
that's
where
we're
able
to
quickly
and
easily
deploy
and
test
our
experiments
in
different
environments,
including
production
and
production,
simulated
environments
and
then
the
iterative
process.
After
these
successfully
deployed
experiments
is
now
instead
of
complete,
refactors
and
redesigns.
A
A
So
back
on
the
original
journey
path
of
microservices,
when
we
build
our
services
with
hard
service
boundaries,
I
think
work
if
you've
built
any
microservices.
This
pattern
should
look
pretty
familiar
each
one
of
these
represents
one
of
the
potential
units
of
deployment
that
we
might
want
to
build
and
if
we're
building
this
as
regular
microservices,
a
small
fraction
of
each
one
of
these
services
on
the
screen
is
our
business
logic.
But
then
we
now
have
all
of
these
embedded
dependencies.
A
A
And
so
hopefully
we
can
do
better,
and
so
with
webassembly
and
using
wisem
cloud
actors
and
a
bunch
of
beneficial
open
source
runtimes,
we
can
get
flexible
service
boundaries.
So
one
deployment
option
here
would
be
to
have
a
single
runtime
process
that
has
all
of
our
actors
in
it.
So
we
can
choose
on
our
laptop
during
early
development
to
have
a
monolith,
because
it's
the
most
convenient
and
it's
the
easiest
to
work
with
for
that
time.
A
And
I'm
going
to
go
through
some
rust
fairly
quickly,
but
the
main
thing
that
I
want
to
show
that
I
want
you
to
keep
in
mind
as
I
go
through.
This
code
is
not
what
the
code
looks
like,
but
what's
missing
from
the
code,
and
so
in
this
one,
the
first
thing
that
an
actor
does.
Is
it
righteous
areas,
the
message
handlers,
actors
are
reactive
and
they
they
receive
messages
and
they
emit
a
reply
to
those
messages.
A
But
what's
missing
is
actual
communication
with
a
tightly
coupled
broker
that
publish
function
just
takes
the
topic,
a
reply
topic
and
the
payload
to
publish
the
choice
of
which
broker
is
doing
the
publishing.
How
that
broker
does
the
publishing
and
what
configuration
we
use
in
order
to
enable
that
publisher
that
broker
to
publish
that's
all
done
at
runtime,
we
could
completely
swap
out
rabbitmq
for
kafka
for
gnats
without
having
to
recompile
this
actor
or
even
redeploy.
We
could
swap
those
at
runtime.
A
Similar
scenario
here
with
data
services,
so
in
this
one
we
are
adding
a
room
to
the
chat
back
end
and
in
order
to
do
that,
we
need
to
communicate
with
a
database
and
in
this
case
we're
communicating
with
a
key
value
store.
But
the
again,
what's
missing
from
here
is
that
the
key
value
store
isn't
actually
defined
here,
we're
referring
to
the
key
value
abstraction,
but
we're
not
talking
explicitly
to
redis
or
to
cassandra
or
memcached
or
etcd.
A
All
right,
so,
let's
get
started
with
the
demo.
I've
got
a
couple
of
terminal
windows
open
here,
because
in
general
my
demos
are
I'm
pretty
devoid
of
graphics.
I'm
going
to
be
going
through
some
console
stuff
and
we'll
be
using
the
telnet
channel
on
the
chat
example.
So
the
first
thing
I
want
to
go
through
is
looking
at
some
of
the
actors.
A
A
So,
if
I
inspect
the
claims
on
this
module,
you'll
see
that
what
I've
got
here
is
the
name
of
the
actor
which
is
called
a
telnet
channel
and
the
actor
has
an
account.
A
module
expires
can
be
used
and
so
on,
and
if
you're,
paying
close
attention
and
you've
seen
jason
webb
token
before
you'll
recognize
that
these
are
similar
fields
where
we
have
an
issuer
a
subject
and
then
some
other
fields
for
how
that
certificate
or
how
that
token
can
be
used.
A
But,
more
importantly,
this
telnet
channel
is
capable
of
using
the
key
value
store,
messaging
broker,
logging
extras
for
random
number
generation
and
the
telnet
capability,
and
it's
it's
worth
pointing
out
that.
Nowhere
in
that
list
of
capabilities
is
there
a
specific
mention
of
a
vendor
project,
so
we
don't
mention
redis.
We
say
that
you
can
use
the
a
key
value
store
and
so
on.
A
So
that
was
that's
the
telnet
channel
and
we
also
have
in
the
actor
list.
We
have
authorization,
a
broker
channel.
So
anything
that
is
using,
let's
say
gnats
can
use
gnats
as
a
gateway
into
the
chat
system.
We
have
the
messages,
actor,
a
presence,
actor
for
determining
who's
online
rooms
and
then
again
the
telnet
channel.
So.
A
What
I'd
like
to
do
next
is
start
up
a
wisdom
cloud
host,
and
I
want
to
start
all
of
the
important
actors.
I
want
to
start
all
of
the
capability
providers
and
then
I
want
to
configure
those
and
we
do
that
through
a
manifest
file
and
first
looking
at
this
manifest
file
may
seem
a
little
bit
overwhelming
I'm
only
using
yaml
here
for
an
example,
you
can
also
use
json,
there's
no
no
requirement
there.
A
So
the
first
thing
we
have
on
lines:
five
through
seven,
is
a
list
of
actors
that
we
want
to
start
up
in
the
asm
cloud
host
and
then
on
lines.
9,
11,
13,
15
and
17
you'll
see
we're
actually
using
a
thing
called
an
image
ref
for
a
capability,
and
what
that
means
is
we're
actually
able
to
load
a
capability
provider
from
an
oci
registry.
That
means
that
we
can
store
them
the
same
way.
You
store
document
niches
and
we
can
retrieve
them
the
same
way.
A
You
you
retrieve
docker
images,
and
so
we
have
a
number
of
our
first
party
capability
providers
sitting
in
our
wasm
cloud,
oci
registry
in
azure
and
then
starting
on
line.
18
we
have
links
and
link
definitions
essentially
consists
of
the
actor,
the
provider
that
we're
linking
to
and
then
the
name
of
the
link
and
then
a
set
of
parameters.
So
we
think
environment
variables,
and
so,
if
you
see
here,
we've
got
the
broker.
A
Channel
actor
is
being
linked
to
the
front-end
version
of
the
broker,
the
wasmcloud
messaging,
and
so
by
using
these
two
different
link
names,
we
can
actually
have
two
different
instances
of
the
same
capability
provider,
but
with
different
configuration
parameters.
And
so
in
this
case
we
have
a
mats
broker
configured
with
a
front
end
connection
string
and
one
configured
with
the
back
end
connection
string.
A
A
A
Ascii
art
welcome
message
so
we'll
log
in
here
I
shall
those
are
the
list
of
the
commands
that
we
support,
and
I
mentioned
earlier,
the
back-end
system
deals
with
things
like
storing
and
retrieving
messages
as
a
stream
creating
and
deleting
rooms,
joining
rooms
and
all
of
that
sort
of
thing,
and
then
the
channels
are
responsible
for
the
actual
communication.
So
right
now
I'm
using
the
telnet
channel.
A
And
I
typed
a
message
there
and
since
there
was
no
one
listening,
if
there's
no
one
listening
to
a
real-time
chat
message
in
the
forest,
did
it
actually
happen
and
if
we
go
into
our
redis
cli
we'll
see
that
in
it
indeed
did
still
happen.
So
I'll
take
a
look
at
the
stream
for
the
general
room
and
don't
worry
if
the
rate
of
syntax
isn't
familiar?
It's
not
all
that
important
right
now,
but
you
can
see.
What's
what's
what
happened
here?
A
A
The
moral
of
the
story
is
that
we've
been
able
to
build
the
chat
application
by
composing
tiny
units
of
compute
and
distribution
that
literally
consume
no
more
than
one
meg
each
that
are
cryptographically
signed
that
have
a
verifiable,
secure
prominence
that
can
be
deployed
anywhere
and
can
connect
to
capabilities
that
are
also
deployed
anywhere.
I
can
choose
to
run
this
entire
thing
as
a
monolith,
which
is
what
I'm
doing
in
this
one
terminal
window
or
I
could
choose
to
run
it
as
any
number
of
processes.
A
A
This
chat
application
was
that
thinking
about
the
the
problem
that
we
were
trying
to
solve
was
almost
directly
in
line
with
how
we
solved
it
when
we
went
with
building
actors
and
connecting
them
to
capabilities
versus
other
avenues
that
might
have
been
higher
friction
had
we
decided
to
go
with
the
traditional
microservices
route.
So
if
I
could
ask
one
thing,
it
would
just
be
to
take
a
look
at
the
tutorials
and
kick
the
tires
and
see.