►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Disrupting the Downtime Continuum - Taylor Thomas & Brooks Townsend, Cosmonic
At this point in Cloud Native development, many people run headlong into the “day 2” operational headaches that come with running containers at scale. One of the most frustrating is handling dependency patching and version migration. We’ve all been there. A vulnerability is released and thus begins a frantic scramble to patch hundreds of container images and release them everywhere. WebAssembly and wasmCloud offer a better way! This demo-heavy talk will start with a brief introduction to WebAssembly and what it can enable. Then we will discuss how wasmCloud leverages WebAssembly to make creating and running an application at scale a breeze. We’ll then demonstrate downtime-free migration, patching, and failover between clouds live on stage with no changes to configuration or code.
A
B
A
And
I'm
taylor
thomas
I'm,
the
director
of
customer
engineering
at
cosmonic,
I'm
a
restation,
so
I've
done
a
lot
of
rust
for
a
long
time
now,
and
I'm
also
the
co-creator
of
crestlit
and
bindle.
If
you've
looked
into
the
web
assembly
space
at
all,
you've
probably
seen
one
of
these
two
projects,
I'm
an
open
source
maintainer
in
general,
I
was
I'm
an
emeritus
maintainer
of
helm.
I
was
one
of
the
core
maintainers
there
for
a
long
time
and
since
we're
at
kubecon,
most
of
you
at
least
probably
know
what
helm
is.
A
So
there
is
some
some
at
least
here's
our
background.
We
know
a
little
bit
about
what
we're
talking
about
as
we
do
this
today.
So
let's
go
over.
What's
the
agenda
going
to
look
like
what
are
we
going
to
talk
about
here
so
first
off
we're
going
to
talk
about
what
is
web
assembly
and
I
want
to
know
this
is
my
favorite
thing
about
being
back
in
person
by
raise
of
hand?
How
many
people
know
what
web
assembly
is?
Okay,
good!
A
So
that's
a
good
chunk
that
was
more
than
I
was
expecting,
which
is
great,
so
we're
going
to
cover
a
little
bit
about
what
web
assembly
is
and
then
and
also
explain
like.
What's
this
whole
like
wasm
cloud
and
cosmonic
like,
why
are
we
wearing
these
cosmonautic
shirts,
then
we're
going
to
do
a
bunch
of
demos
there's?
This
is
a
very
demo
heavy
session
and
it's
going
to
be
live
as
long
as
we
haven't
angered
the
demo
gods.
A
A
Well,
what's
web
assembly,
we
like
to
say
it's
neither
web
nor
assembly,
which
is
kind
of
funny,
given
its
name
now,
it
was
primarily
used
first
in
the
on
the
web,
and
if
you
look
at
it,
these
are
the
characteristics
that
make
it
very
good
for
the
web.
It
is
an
open,
w3c
standard,
it's
very
safe
and
secure.
It's
a
completely
default
like
nothing's
allowed
it's
in
a
sandbox
because
you're
in
a
browser
right
and
the
browser's,
the
wild
west,
so
everything
needs
to
be
sandboxed.
A
It
has
capability
driven
permissions
capability.
Driven
permissions
is
like
what
you
have
on
your
phone
when
you
go
like
oh,
would
you
allow
this
app
to
access
your
microphone
and
your
notifications
and
all
those
things
it's
very
efficient
and
fast,
which
is
important
because
the
small
sizes
you
are
able
to
download
it
quickly
over
an
internet
connection
and
use
it?
It's
also
polyglot,
so
you're
able
to
use
multiple
languages
to
compile
to
webassembly
it's
just
a
compilation
target
and
it's
very
portable.
It
runs
in
all
major
browsers.
Imagine
if
someone
said.
A
Oh
sorry,
this
only
runs
on
linux
that
wouldn't
go
over
very
well
in
a
browser
world.
Now
those
things
right,
there
are
actually
the
exact
same
kind
of
things
we
want
to
see
in
the
cloud
we
like
having
open
standards.
Most
of
the
world
is
transitioned
to
using
open
standards
for
these
things.
We
want
something
that
is
completely
secure
and
locked
down.
That's
why
we
started
using
things
in
containers.
A
It's
very
efficient
and
fast,
that's
also
important.
We
want
to
be
able
to
pack
these
things
tighter
and
have
good
utilization,
any
any
language
that
can
compile
to
webassembly
same
thing,
that's
a
benefit
and
once
again
portable,
it
truly
runs
everywhere,
not
just
on
linux.
So,
let's
cover
a
little
bit
about
the
gaps
here.
There
are
some
gaps
to
just
be
aware
of
one
of
the
things
that
language
support
for
webassembly
outside
of
the
browser
is
still
limited.
A
It's
quickly
growing,
but
it's
still
limited,
and
so
you
have
to
know
that
that
is
one
of
the
things
that's
happening
right
now
in
the
in
the
industry.
Networking
is
generally
rudimentary
or
non-existent.
They're
just
starting
to
add,
socket
support.
It's
really
great
that
it's
there,
but
networking
support
is
very
limited,
so
you
have
to
find
ways
around
that
and
you
still
have
to
compile
a
lot
of
your
dependencies
into
a
final
binary.
The
final
web
assembly
module
and,
ultimately
everything
is
still
numbers
in
numbers
out.
A
You
get
a
vector
of
bytes
and
you
have
to
return
a
vector
of
bytes.
There's
no
types,
there's
work
being
done
on
that,
but
right
now
you're
pretty
much
just
raw
bytes
when
you
work
with
it.
So
that's
that's
where
we
are
with
with
webassembly.
Now,
let's
talk
about
like
where
we've
been
and
where
we're
going
with
this-
and
I
promise
all
this
is
important
to
understand
why
what
we're
going
to
show
you
is
important.
A
So,
first
off
we
started
with
what
we
jokingly
called
the
pc
time
right,
like
everyone
had
their
own
towers
or
you
had
blades
or
one
two:
three:
u
units
that
you
had
in
a
rack
and
you
owned
that
entire
thing
you
own
the
operating
system
you
installed
on
it,
the
libraries
for
that
operating
system
and
then
the
libraries
for
your
applications
and
an
application
that
you'd
run
on
top.
Then
we
moved
on
to
clouds
we're
like
hey.
Can
we
like
vm
this?
A
We
can
put
in
a
vm
everything's
running
and
we
abstracted
away
the
hardware,
but
we
still
were
installing
full
stacks
of
libraries
and
applications
on
top.
Then
we
came
into
containers
and
kubernetes,
and
containers
gave
us
this
real
nice
way
to
keep
everything
all
together
and
secure
and
reusable,
but
you're
still
talking
about
everything
being
coupled
together.
A
So
we're
talking
like
all
these
non-functional
requirements
that
happen,
the
example
I'm
going
to
point
out
here,
because
it's
the
most
recent
fresh
is
the
log
4j
vulnerability
that
happened.
We
have
all
written
vulnerabilities.
I
have
written
security
vulnerabilities,
we've
all
written
bugs
that
turn
into
bad,
like
sev1
incidents
and
other
things
that
happen.
So
it's
not
a
criticism
of
that.
A
But,
like
those
happen
in
software
and
when
that
happened,
everyone
we
talked
to
there
are
people
who
had
to
deploy
to
rebuild
and
redeploy
tens
of
thousands
of
containers
because
you're
bringing
along
95
of
your
code
being
just
non-functional
requirements
things
you
don't
care
about
and
anytime
an
upgrade
happens.
That
has
to
happen.
A
So
that's
what
happened
with
containers,
everything's
still
coupled
and
even
webassembly,
to
an
extent
is
still
you
have
to
you
have
to
couple
in
a
library
when
you
run
your
your
final
artifact,
even
with
some
of
the
new
proposals
that
are
coming
out
around
the
components
model.
So
all
those
things
it's
still
better,
because
now
it's
completely
separate
it
can
run
on
different
hosts.
A
But
you
still
have
this
non-functional
requirements
that
are
that
are
very
important
and
still
bound
to
that
thing
that
you
compile
the
last
one
over
here
is
web
is
wasn't
cloud
where
we've
taken
it.
We've
turned
into
a
platform
and
we've
abstracted
away
the
libraries
that
you
need
and
they're
called
capabilities.
You
now
code
against
a
contract
and
we'll
talk
a
little
bit
more
about
that
as
we
go
into
what
wasm
cloud
is.
B
We're
not
just
locked
into
one
single
thing,
but
where
the
disadvantages
is
where
we're
not
fully
there
yet
is
where
the
wasmcloud
application
runtime
comes
in.
This
is
where
you
get
your
removed
boilerplate
code,
the
access
to
capabilities,
you
know
outside
of
the
webassembly
sandbox
and
the
wasm
cloud
runtime
facilitates
the
passing
of
bytes
back
and
forth.
So
when
you're
writing
your
app
with
wasmcloud,
you
get
to
write
it
against
the
contract.
B
B
This
is
the
part
that
you
need
to
make
your
app
run,
but
that
you
don't
write
either
you
copy
and
paste
it
from
a
previous
project,
so
you're
setting
up
the
http
server
in
the
right
way
or
you're,
bringing
in
open
source
libraries,
which
is
great
but
you're,
not
reading.
All
of
the
code
from
your
open
source,
libraries
you're,
not
making
sure
that
everything
is
fine,
and
this
is
this-
makes
up
up
to
95
of
the
application
code
that
you
end
up
deploying
with
this
capabilities
model.
You
choose
it
at
runtime.
B
B
This
is
what
you
write,
your
your
business
logic
in
what
we
like
to
say,
write
the
right
code,
you're
writing,
just
the
code
that
you
want
in
order
to
make
your
business
logic,
work,
you're,
not
copying
and
pasting
a
bunch
of
code
or
re-implementing,
open
source
libraries,
especially
not
compiling
it
into
your
application.
Logic,
these
are
stateless
reactive
modules
and
because
they're
webassembly,
you
get
all
the
advantages
as
a
developer
of
being
able
to
deploy
anywhere
after
you've
built
a
webassembly
binary
and
the
last
step.
What
really
makes
wasm
cloud
work
is
a
distributed.
B
Application
runtime
is
the
lattice
network.
This
is
running
with
nats
under
the
hood.
You
know
they
have
a
project
booth
over
at
the
project.
Pavilion
go
see
them
they're
great,
but
what
this
does
is
it
represents
the
resources
in
a
wasm
cloud
application
at
a
flattened
layer,
everything
no
matter
where
it's
running
in
the
cloud
on
the
edge
on
my
laptop
here
in
the
conference.
A
A
B
All
right
enough,
with
the
slides
for
now,
we
can
actually
get
started
with
the
fun
stuff.
Let
me
get
out
of
this
okay,
so
I
want
to
paint
the
stage
for
you
right.
You
come
into
work
on
a
monday
and
your
boss,
or
your
pm
comes
to
you
and
they
say
you
know
we
have
this
really
important
business
application
to
code
up.
We
need
a
web
app
that
can
display
a
random
comic
from
xkcd.
B
Do
you
think
you
can
get
that
done
by
the
end
of
the
week
and
you
say
yeah?
I
think
I
can
do
that.
You
know
this
is
everyone's
monday
right
yeah.
This
is
what
you
guys
are
doing.
So
when
we
you
know
we
sit
down.
We
start
writing
this
application.
When
we're
thinking
about
how
we're
going
to
design
it
right,
we
need
a
web
app.
So
it
needs
to
be
a
web
server
respond
with
an
http
response
and
then
show
something
in
the
browser
right.
B
So
I'm
going
to
start
with
the
finished
product,
because
that's
the
that's
the
most
fun
part
you've
got
this
little
app
and
if
you
you
refresh,
you
know
you
get
you
get
just
random,
xkcd
comics,
it's
completely
random,
so
you
can
get
really
anything
and-
and
this
is
it
right,
you
did
it.
Thankfully
you
wrote
this
with
wasmcloud,
so
they
asked
if
you
could
finish
it
by
the
end
of
the
week,
and
you
finished
in
the
first
15
minutes
on
a
monday,
so
you
had
a
pretty
chill
week.
B
So
this
is
the
the
finished
app.
This
is
our
business
logic
kind
of
introduce
the
stage.
Let's
look
at
what
the
code
looks
like,
so
we
can
actually
zoom
in
a
little
bit
more
here.
This
is
going
to
be
our
xkcd
actor.
This
is
an
actor
and
a
capability
pair.
The
the
actor
is
where
you're
writing
again
your
business
logic,
and
even
if
you
haven't
seen
rust
before
that
you'll
you'll
be
able
to
grok
this
pretty
well,
you
know
we
found
out
that
the
one
of
the
newer
xkcd
comics
was
like
number
2600.
B
So
that's
the
max
we're
going
to
generate,
and
in
order
to
make
this
app
it's
very
simple.
We
have
a
trait
called
http
server
and
the
contract
that
comes
with
this
trait
is
a
single
function.
Handle
request
receives
an
http
request,
returns
an
http
response,
very
common
level,
abstraction
of
an
http
server.
B
Now
the
business
logic,
how
we
actually
implement
this
first
thing
generate
a
random
number.
We
use
the
number
generator
capability
since
webassembly
actually
can't
use
random
like
crypto
stuff,
because
it's
on
the
the
system,
so
we
generate
a
random
number
and
then
we
actually
found
this
great
open
source
capability
provider
that
implements
a
function
that
you
can
get
a
comic
by
a
number.
So
great,
we'll
call
our
git
comic
function
and
then
return
it
as
an
http
response.
That's
it!
You
know
three
lines
of
code
minus
little
nice
formatting.
B
In
order
to
do
that,
business
app,
you
get
right
down
to
writing
the
logic
right
there.
Now.
That's
all
fine
and
good.
It
works
great.
You
know
you're
running
this
in
production,
your
your
management
team
is
really
happy.
Now,
let's
take
a
look
at
the
provider,
the
open
source
library
or
the
capability
provider
that
actually
implements
that
git
comic
function.
B
You'll
see
a
lot
of
similar
things
here.
You
know
git
comic
handler.
We
we
take
in
a
number.
We
request
that
url.
We
make
sure
that
it
was
successful
and
then
return
that
as
a
little
byte
vector
of
an
html
page.
That's
how
we're
actually
implementing
this
on
the
provider
side
so
someday
you
get
a
little
notification
that
your
provider
or
the
open
source
library
has
updated.
You're
like
great
I'll
pull
in
the
new
version.
B
It's
going
to
be
even
more
even
more
secure
and
you
go
to
deploy
the
next
version
of
this
provider.
So
this
is
actually
the
wasm
cloud
dashboard
we
haven't
hit
it
yet
so
I'll
just
explain
it
really
quick.
We
have
up
in
the
top
left.
Our
xkcd
actor
is
running
on
the
right.
We
have
our
http
server
provider,
that's
what's
actually
you
know
getting
the
http
requests
and
and
forwarding
it
off
to
the
actor
and
then
in
just
a
moment
we'll
have
our
newly
deployed
updated
version
of
our
xkcd
provider.
B
B
A
sub
one
we
can
see
our
new
updated
version,
while
it
still
works,
has
a
very
critical
vulnerability
in
it.
So
this
is
pretty
unfortunate.
I
didn't
mean
for
this
to
happen
during
the
talk,
so
we
can
actually
look.
You
know
you
can
go
back
as
as
the
deployer
of
this,
you
can
go
back
and
see
that
this
sub
one
is
recognized
everywhere.
B
The
maintainers
caught
on
to
it
released
a
patch
version,
that's
great,
but
instead
of
having
to
go
and
recompile
our
entire
app,
you
know
the
part
where
we
wrote
the
business
logic.
Recompile
run
it
through
our
our
testing
platform
make
sure
that
nothing
broke.
Maybe
this
is
a
minor
version
bump,
because
I
already
included
something
else.
We
can
just
go
straight
back
to
the
straight
back
to
the
url
and
load
up.
B
Another
xkcd
comic,
this
one's
nice
and
wholesome
I'm
not
going
to
tempt
fate
anymore
because
I
you
know,
I've
looked
at
a
lot
of
xkcd
comics
and
we
got
there's
some
there's
some
that
you
don't
want
to
show,
but
that
covers
the
first
part
of
our
talk.
We
want
to
talk
about
downtime,
free
migration
patching
and
what
was
the
last
one
failover
fan
failover,
so
that
was
the
first
part
of
our
our
talk
or
of
our
demos.
So
hopefully
that
speaks
to
how
easy
it
is.
B
When
you
can
separate
the
non-functional
requirements
into
a
separate
unit
that
you
can
deploy,
you
don't
have
to
spend
a
ton
of
time,
redeploying
your
app
and
for
a
log4j
type
of
vulnerability.
That's
the
one
place
that
it
updates
in
an
enterprise.
It's
not
every
single
app
that
depends
on
that.
Common
library
needs
to
update.
A
You
have
an
api
that
goes
out
an
api
gateway
that
forwards
requests
to
specific
services
that
respond
to
that
there's:
a
visit
service,
a
vet
service,
a
customer
service
and
all
these
things
are
in
there,
but
you'll
also
notice
that
this
diagram,
it's
very
enterprise.
Looking
I
did
not
make
it
to
look
enterprisey
looking.
This
is
literally
from
the
spring
boot
examples
and
look
at
all
the
stuff
that
goes
on
around
it.
You
have
to
have
the
spring
boot.
A
Sorry,
the
spring
cloud,
config
server,
the
like
service,
discovery
elements,
the
logging
things
all
these
different
requirements,
and
then
the
http
stuff,
and
to
talk
between
the
different
services,
all
of
that
extra
baggage,
and
you
have
to
have
that
in
your
actual
code.
So
what
this
actually
looks
like,
if
we
do
it
in
wasmcloud,
is
something
a
lot
cleaner.
So
you'll
see
that
you
have
the
user,
that's
on
top
that's
connecting
to
an
http
server.
It
can
literally
be
any
type
of
http
server,
because
it's
just
a
contract,
and
that
has
the
clinic
api.
A
It
returns
ui
assets
through
there
and
it
also
forwards
requests
on
which
then
talk
to
a
sql
database
contract.
It
doesn't
even
know
what
sql
database
it's
talking
to
in
this
case
we're
talking
to
postgres
and
all
of
these
things
are
just
done
and
configured
at
runtime
and
it's
a
lot
more
simple.
There's.
No
other
logging
servers
that
are
set
up.
There's
no
service
discovery,
you're
just
able
to
connect
between
these
different
things,
and
so
we're
going
to
actually
show
you
what
this
looks
like
and
what
you
can
do
with
it.
Yep.
B
So
demo
time
around
two,
so
we
walked
through
the
the
architecture
of
the
pet
clinic.
Let's
take
a
look
at
the
pec
clinic
right,
so
we've
got
this.
I've
got
this
running
on
my
local.
You
know
a
little
little
dummy
user,
I'm
running
in
dev,
so
I
just
have
some
test
data
in
here
we
could
add
in
a
pet
if
we
wanted
to,
but
really
we
can
look
at
what
kind
of
vets
we
have.
B
We
encourage
you
to
try
it
out
just
a
little
bit
easier
to
visualize
here.
So
there's
two
main
views:
we're
going
to
take
a
look
at
in
cosmonic.
The
first
one
is
the
infrastructure
view.
This
is
where
you
can
see
all
of
your
different
infrastructure,
your
your
virtual
host,
no
matter
where
they
are
on
a
flattened
canvas.
So
taking
a
look
here,
we
actually
have
our
first
host
is
the
cosmonic
application
running
all
the
actors
and
capability
providers
that
power
what
we're
going
to
do
in
the
demo.
B
Today
we
have
a
wasm
cloud
host
running
in
azure,
that's
an
x86
processor,
it's
on
linux
and
it's
in
south
central
us.
I
think
that's
texas.
We
have
our
paclinic
application.
This
one
is
running
all
on
my
local
machine.
It's
got
the
api
visits,
vets
and
customers.
You
know
our
http
server.
All
of
that
and
you
know
what
we
want
to
do,
especially
with
these
other
hosts,
this
azure
host
and
on
the
right
this
aws
host.
That's
an
arm
processor
running
in
california.
B
We
want
to
take
this
application,
that's
just
running
on
our
local
and
let's
deploy
it
to
prod.
Let's
push
it
up
to
the
cloud.
Take
these
webassembly
modules
there
now
the
second
view,
which
is
where
we're
going
to
be
doing
some
more
interaction,
is
the
logic
view.
This
is
where
you
can
see
again:
flattened
topology
view
of
all
your
application
components.
B
So
again,
everything
running
in
my
local
not
super
fun
for
a
distributed
application
framework,
so
we'll
just
go
ahead,
terminate
all
the
actors
from
from
the
lattice
here
from
the
wasmcloud
network
and
we'll
take
them
instead
of
running
my
laptop,
let's
put
them
in
the
cloud,
so
our
clinic
api,
the
api
gateway.
We
can
find
a
wasm
cloud
host,
that's
running
in
aws
to
host
that
actor.
B
B
It
is
actually
running
in
aws,
the
second
thing,
our
customers
actor.
We
can
find
a
host
there
go
ahead
and
start
up
our
customers
actor
in
azure.
Our
let's
see.
What's
next,
our
vets
actor
say
instead
of
cloud
specifically
more
have
a
region
requirement.
So
we
can
run
this
in
the
us
west.
One
region
which
we
know
is
our
you
know
our
california
host
that's
running
in
aws
and
then
also
you
know.
B
Last
but
not
least,
we
can
run
our
visit
service
in
the
region,
south
central
u.s,
so
great,
we've
taken
all
of
our
application
components,
the
same
web
assembly
modules
and
we're
running
them
from
an
m1.
You
know
an
arm
macbook
pro
put
them
up
in
a
cloud
provider
on
an
x86
linux
arm
linux,
all
the
exact
same
webassembly
module
from
an
oci
registry.
B
If
we
check
our
infrastructure
view,
we
can
see
visits
and
customers
are
on
azure.
Api
and
vets
are
on
aws
and
if
we
hit
our
little
refresh
here,
look
at
that
we
still
get
the
same,
still
get
the
same
data,
and
that's
because
all
of
the
configuration
that
we
set
up
at
runtime
is
automatically
re-established
when
we
push
our
business
logic
up
to
the
cloud,
so
it
has
no
bearing
on
the
actual
location.
We
just
immediately
redirect
the
request
over
to
the
cloud
host.
B
B
B
We
can
redraw
this
and
then
tell
the
runtime
whenever
this
customer's
actor
makes
a
request
to
an
http
or
to
a
sql
database
we're
instead
going
to
access
this
one,
and
once
we
draw
that
link
again,
we
hit
refresh
on
the
the
wasm
cloud
pet
clinic
and
look
at
that
some
real
data,
some
cosmonic
employees.
If
we
we
click
in
here
to
taylor,
we
can
see
his
beautiful
dog
checks,
which
I've
seen
a
ton
of
pictures
of
this
weekend
and
and
my
dog
archie
all
coming
from
from
our
azure
cosmos
database.
B
So
you
know
when
you're
in
production,
you
wouldn't
like
live
swap
from
databases
without
a
perfect
strategy,
but
this
is
to
show
that
you
can
move
from
dev
to
production
in
a
completely
seamless
way.
That's
configured
at
runtime.
You
know
our
actors,
our
pet
clinic
actors,
didn't
have
to
change
or
do
anything
to
make
this
happen.
Yeah.
A
It's
kind
of
we
like
to
call
this,
the
knob
that
turn
you
can
turn
the
knob
from
monolith
to
distributed.
You
didn't,
we
didn't
have
to
do
anything
else,
except
move
it
around
and
we're
adding
more
utilities
to
the
actual
open
source,
wasm
cloud
tooling.
That
will
allow
you
to
just
automatically
do
this
and
automatically
redistribute
based
on
certain
characteristics.
B
Right
so
last
part
of
our
talk
is
before
a
little
bit
more
slides
is
failover,
so
we
have
these
actors
running
in
different
clouds,
but
they're
kind
of
spread
out
across
clouds.
It's
not
really
a
resilient
application.
There's
no
replication,
there's
no
different,
there's
no
scaling
in
different
clouds.
So
let's
go
ahead
and
set
up
a
little
bit
more
of
a
resilient
architecture.
So
we
have.
We
have
visits
and
customers
running
in
azure
right
now.
Let's
go
ahead
and
take
some
instances
of
both
of
those
and
run
it
in
aws.
B
So
we'll
start
an
instance
of
visits
and
an
instance
of
customers
in
aws
great,
so
we
come
down.
We
take
a
look
at
our
application
components
you
can
see.
We
have
two
replicas
of
visits,
two
replicas
of
customers
from
this
view
doesn't
matter
where
they're
actually
running.
We
just
know
we
have
two
of
them
because
it's
all
going
to
route
they're
the
same
now
we
can
actually
come
back
to
our
host.
We
can
look
at
our
azure
host
and
we
can
just
terminate
it
entirely,
get
rid
of
it.
Those
actors
are
gone.
B
We
come
back
to
our
pet
clinic.
We
hit
refresh.
We
navigate
around
immediate,
live
failover
to
the
other
cloud
that
we
have
set
up
so
using
wasmcloud
with
this
interconnected
lattice
network,
wherever
the
available
compute
is,
is
immediately
where
your
request
is
going
to
be
routed
and
through
some
nats
and
gs
things
that
also
has
a
preference
on
location,
choosing
a
closer
location,
but
just
to
note
this
is
still
hitting
our
cosmos
database.
So
if
you
trace
this
request,
that's
happening
right
now.
B
It's
going
from
my
laptop
to
aws
in
california
previously
to
azure
the
other
actor
in
texas,
but
now
all
in
california
and
then
over
to
new
york,
wherever
the
azure
east
region
is
for
our
database
and
then
coming
back.
That's
the
that's
the
request
that
you're
watching
you
know
our
pet
clinic
resources
coming
back
with.
B
All
right
so
just
to
just
to
kind
of
nail,
this
demo
home
or
wrap
up
kind
of
what
we
did.
This
is
the
application
diagram
what
we
started
with
when
we
decided.
Oh,
let's
write
a
pet
clinic
app,
we'll
sketch
this
out,
and
this
is
the
architecture
diagram
that
we
ended
up
with
like
what
we
were
actually
running
in
production.
So
you
know
we
took
all
of
our
actors.
A
So
that
leads
us
to
this
question.
Well,
how
are
you
going
to
use
it
right
like
let's,
so,
let's
talk
about
what
can
you
do
right
now?
If
you
want
to
try
this
out,
the
first
thing
is:
you
can
write
a
very
basic
service.
These
are
generally
data
processing,
image,
processing,
those
kind
of
things,
they're
standalone
services
in
most
cases
or
part
of
a
pipeline,
and
you
can
try
rewriting
one
of
those
we've
seen
quite
a
bit
of
success,
of
people
trying
that
out
and
being
able
to
at
least
give
little
examples.
A
If
you
watched,
if
any
of
you
were
at
the
wasabi,
you
may
have
seen
collins
talk
where
he
showed
some
things.
They
did
adobe
like
this
or
just
little
tiny
services
that
they
could
do
and
then
another
one
is
just
a
small
part
of
a
service
that
you
can
that
you
were
planning
on
rewriting
anyway.
So
we
have
this
this
concept
we
like
to
call
the
bridge
to
the
future.
A
We
consider
wasm
to
be
the
future,
but
we
also
know
everybody
is
running
things
on
kubernetes
and
other
platforms
right
now,
but
we've
open
sourced
as
cosmonic
something
called
kubernetes
supplier
that
allows
you
to
automatically
hook
in
anything,
that's
running
in
kubernetes
to
be
able
to
connect
to
services
running
in
wasmcloud
automagically,
and
it's
actually
all
built
using
actors
and
receiving
events
from
from
that
and
then
publishing
things
into
kubernetes.
It's
actually
really
cool
and
interesting.
A
If
you
like
some
of
the
more
advanced
kubernetes
stuff,
but
that's
just
one
small
part
of
a
service
you
can
rewrite,
try
it
out,
see
how
it
works
and
still
connect
it
back
to
everything
you
have
and
the
last
thing
is
a
full
stateful
application.
This
is
where
you
could
use
all
the
different
providers.
We
have
or
write
your
own
to
connect
to
the
different
data
sources
you
need.
This
is
for
greenfield
application.
A
Obviously,
but,
like
I
said
we're
doing
that
all
that
stuff
you
saw
running
with
the
cosmonautic
dashboard,
that's
all
running
on
top
of
webassembly.
So
that's
just
what
you
can
do
now.
So
with
that
we
have
some
references
of
things.
You
can
go
check
out
if
you
want
to
get
involved
and
that's
it
for
now
and
we're
welcome
to
have
any
questions.
A
B
B
A
B
So
what
we
found
with
with
github,
I
personally
am
a
huge
fan
of
github
actions.
I
think
it
made
ci
cd,
a
ton
simpler,
there's,
a
ton
of
open
examples
for
that
and
when
you
get
to
you
know
part
of
our
demo,
we
started
actors
in
different
locations
from
an
oci
url
and
in
generally
some
registries
don't
end
up
implementing
the
the
oci
spec,
but
github
cr
actually
does,
and
so
part
of
the
thing
that
we're
really
trying
to
do
with
github
is
create
a
nice
seamless
flow.
B
Where,
with
our
tooling,
you
generate
a
little
actor
project,
you
get
started,
you
write
your
hello
world,
you
push
it
up
to
github
and
then
what
comes
with
that
is
a
build
pipeline
and
a
release
pipeline.
So
you
know,
as
you're
working
automatically
get
you
know,
tests
and
making
sure
you're
following
best
practices
as
soon
as
you
push
a
tag
or
push
to
main
that
actor
is
automatically
pushed
to
github
container
registry
github
packages.
B
A
So
how
do
I
run
this
in
my
ide?
How
do
I
run
tests
and
get
the
providers
and
so
on
yeah
good
question
so
right
now,
like
we
mentioned
in
the
beginning,
there's
still
limited
language
support
in
general.
For
for
some
of
these
web
assembly
things,
the
main
language
we
have
the
best
support
for
is
rust.
We
have
other
ones
coming
on
down
the
line
and
the
nice
thing
about
webassembly.
Why
I
mention
it
being
polyglot?
Is
you
can
just
use
the
tool
chain?
A
You
already
have
no
matter
what
the
language
so,
for
example,
all
the
rest
definition.
We
still
use
cargo
test.
We
still
use
cargo
build.
All
of
those
things
are
still
the
same
when
you
do
it
in
another
language
like
go,
which
is
one
of
the
ones
we're
looking
at
hopefully
doing
soon.
You'll
just
do
go,
build,
there's
nothing
different,
and
so
you
get
to
use
all
the
same
ide
tools.