►
From YouTube: Living on the Edge: Using IoT Devices on Kuberne... Kate Goldenring, Rodrigo Farias Rodrigues Lemos,
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Living on the Edge: Using IoT Devices on Kubernetes WebAssembly Applications - Kate Goldenring, Microsoft; Rodrigo Farias Rodrigues Lemos, Federal University of Pernambuco
WebAssembly, Kubernetes, IoT, the “Edge”, and Rust. What happens when all of these are brought together? On the Edge, the smaller and more secure the application the better. Many of these optimizations come out of the box with WebAssembly. Akri is an open source project that discovers IoT devices – like sensors or cameras -- and represents them as requestable resources for Kubernetes clusters on the Edge. As compute resources for nodes on the edge are limited, Akri investigated converting its components to WebAssembly, reducing its footprint and opening a pathway for WebAssembly applications to leverage Akri to use IoT devices. Rodrigo and Kate will discuss the motivation behind the work, the collaboration with and use of Krustlet (a Rust kubelet that enables running WebAssembly applications on Kubernetes), limitations due to early WASI proposals and experiments, and a roadmap for what is to come. It will include a demo of Akri discovering demo devices and a Web Assembly Kubernetes application requesting and using them . This talk will show how the integration of Akri and Krustlet makes using IoT devices easy and simple on the Wasm environment.
A
A
We
also
hope
to
illustrate
the
delta
between
what
the
webassembly
systems
interface
supports
today
and
the
potential
of
what
it
can
support
in
the
future
as
it
matures
and
then.
Finally,
we
are
going
to
show
how
awkry
simplifies
iot
device
discovery
and
use
in
kubernetes
so
to
break
down
those
goals
into
an
agenda.
A
We'll
start
out
with
discussing
an
iot
scenario
that
we
hope
to
enable
and
then
we'll
talk
about
the
steps
that
we
went
to
enable
it
so
the
first
being
implementing
device
plugins
in
crestlet
and
the
second
being
porting
ocry
from
being
a
containerized
application
to
a
application
of
webassembly
modules
and
we'll
discuss
some
of
the
challenges
that
we
encountered
with
that.
Finally,
we'll
just
show
the
outcome
in
a
demo
and
discuss
next
steps.
A
So
let's
say
that
you're,
a
farmer
and
an
issue
you
have
is
that
you
have
a
bunch
of
chickens
and
there
are
some
coyotes
that
keep
coming
in
and
eating
your
chickens.
So
you
decide
that
you're
going
to
install
some
ip
cameras
and
set
up
a
web
set
up
a
machine
learning
application
in
order
to
identify
those
coyotes
and
alert
you
to
go
out
and
scare
them
and
get
them
to
go
away.
A
So
the
first
thing
you
do
is
you
set
up
your
ip
cameras
and
you're
going
to
go
ahead
and
do
this
in
the
cloud.
So
you
deploy
some
frame
server
pods
in
a
microservice
approach,
where
you're
deploying
one
pod
to
each
camera
and
that
frame
server
is
grabbing
the
frames
from
that
camera
and
passing
them
off
to
some
inferencing
pod,
which
then
does
the
work
with
with
the
gpu
and
some
ml
to
identify
those
coyotes
and
passes
that
output
to
a
final,
alerting
pod.
A
A
And
so
you
decide
to
follow
the
laws
of
data
gravity
and
process
data
closer
to
where
it
originates,
and
you
decide
to
install
a
server
on
the
edge
on
your
farm
and
you're
optimistic
about
your
farm
and
how
it's
going
to
grow
over
time.
So
you
go
ahead
and
add
it
as
a
node
to
a
kubernetes
cluster,
and
so
we
can
see
here
that
we're
doing
all
the
processing
locally
on
the
edge
and
we're
only
sending
up
the
final
alerting
data
to
the
cloud
on
the
side.
A
A
And
then
you
pass
the
output
from
that
inferencing
pod
to
the
learning
pod.
So
this
is
all
doable
today
with
kubernetes
on
the
edge.
However,
unlike
in
the
cloud
where
the
environment
is
very
homogeneous
on
the
edge,
the
environment's
heterogeneous
and
things
are
changing
all
the
time,
so
what
happens?
If
one
of
your
cameras
goes
down?
Well,
your
frame,
server,
pods,
idling
or
maybe
erroring
out.
You
have
to
go,
send
someone
out
to
either
fix
the
camera
or
you
have
to
bring
down
that
pod.
A
What
happens
if
you
scale
up
your
iot
deployment
and
add
more
ip
cameras?
Well,
you
need
to
manually,
go
install
and
pass
that
pre-configuring
and
pre-configure
each
one
of
those
frame
servers
to
connect
to
the
specific
camera.
Once
again,
what
happens?
If
you
add
a
node
to
your
cluster,
move
it
on
to
the
next
field?
Well,
you're
gonna
have
to
go
ahead
and
deploy
that
inferencing
pot
again
and
have
it
send
that
information
to
the
learning
pod
so
as
the
environment
continues
to
change.
A
A
So
in
this
case,
specifically,
you
specify
a
discovery
handler
and
ocari
supports
three
discovery:
handlers
onvif
for
discovering
ip
cameras,
uw
for
devices
in
the
local
linux
device
file
system
and
opcwa
for
industrial
machinery.
So
in
this
case
we're
discovering
ip
cameras
so
we're
specifying
the
onvif
discovery
handler.
A
A
So
once
you
have
applied
your
configuration
to
the
cluster,
you
can
see
that
aqui
automatically
discovered
the
cameras
and
deployed
those
frame,
server
pods
to
each
individual
camera,
and
it
injects
all
the
connectivity
information
into
each
of
those
pods
awkry
also
automates
the
creation
of
services.
So
you
can
see
here
that
it
created
one
service
to
provide
a
stable
endpoint
for
getting
access
to
to
the
frames
from
all
of
the
cameras.
A
So
now
that
we've
discovered
the
cameras,
let's
go
ahead
and
discover
our
gpu
with
ocry,
so
we're
going
to
apply
another
configuration
this
time,
we're
going
to
use
the
udev
discovery
handler
and
we're
going
to
specify
the
imprinting
pod
as
our
workload
after
deploying
that
we
can
see
that
we
discovered
our
gpu
so
we're
back
at
the
previous
first
stage
of
our
last
scenario.
But
now,
let's
see
what
happens
as
the
environment
changes,
so
we
scale
up
our
our
ip
camera
deployment.
Opry
automatically
discovers
those
cameras
and
deploys
more
frame
servers.
A
We
add
a
node
ocry
automatically
discovers
the
additional
gpu
and
deploys
another
inferencing
pod.
So
we
can
see
here
that,
as
the
environment
continues
to
change,
if
there's
intermittent
connectivity
of
devices
opry
will
bring
down
pods
when
they
come
back,
awkey
will
bring
them
back.
So
awkry
handles
these
unique
scenarios
on
the
edge.
A
So
the
first
question
when
exploring
this
is
first,
is
this
possible
and
the
second
is:
why
would
we
do
this?
So
for
the
first
question,
we
know
that
the
webassembly
systems
interface
provides
extensions
to
webassembly
that
enable
running
webassembly
applications
in
cloud
context
such
as
write
on
the
server.
A
So
we
know
we
can
run
our
webassembly
modules
on
servers
on
the
edge.
Furthermore,
we
know
we
can
run
webassembly
modules
on
kubernetes
due
to
a
lot
of
the
work
that
crestlet
has
done.
Crosslit
is
another
deus
labs,
open
source
project,
that
is
a
kubernetes
cubelet
written
in
rust,
and
it
allows
for
running
webassembly
modules
on
kubernetes,
just
as
you
would
containers
so
we
know
we
can
do
this
now.
The
question
is:
why
would
we
do
this
well
webassembly
modules?
A
Compare
and
contrast
grid
of
containers
versus
webassembly
modules
that
are
wazi
compliant,
and
you
can
see
here
that
some
of
the
red
on
the
wazi
side
are
the
fact
that
lossy
webassembly
modules
are
only
able
to
be
single
threaded
and
they
have
limited
network
access.
But
one
thing
to
note
here
is
that
all
this
red
is
due
to
the
fact
that
the
webassembly
systems
interface
was
only
created
two
years
ago
and
there's
work
underway
to
turn
these
red
blue
and
enable
these
features.
A
And
so
we
expect
that
over
time,
everything
on
the
swazi
side
will
be
blue,
while
all
the
downsides
on
the
containers
aren't
going
anywhere
and
so
really
excited
to
proceed
with
this
poc
of
making
this
happen,
and
we
know
that
any
of
the
challenges
that
we
encountered
will
go
away
over
time
as
the
webassembly
systems
interface
matures,
and
this
can
be
summarized
and
if
lawson
wazi
existed
in
2008,
we
wouldn't
have
needed
to
create
docker.
That's
how
important
it
is.
Webassembly
on
the
server
is
the
future
of
computing,
and
that's
a
quote
by
solomon
heights.
A
So
before
we
talk
about
how
we
implemented
the
device,
plug-in
manager
and
crestlet,
let's
first
talk
about
what
the
device
plug-in
framework
is
so
out
of
the
box.
Kubernetes
has
several
compute
resource
types,
namely
cpu
ram
and
huge
pages,
and
this
is
why
kubernetes
is
powerfully
declarative,
because
you
can
apply
a
pod
to
your
cluster
and
specify
that
it
needs
this
much
cpu
and
this
much
ram
in
order
on
the
node
to
be
reserved
for
it
in
order
to
run,
and
so
you
know
that
that
workload's
going
to
have
exactly
the
resources
it
needs.
A
The
device
plug-in
framework
takes
that
one
step
further
and
allows
you
to
advertise
other
node
level
resources
to
cubelet,
so
that
then
they
can
be
requested
in
a
pod.
Just
as
you
would
compute
resources-
and
this
was
really
motivated
by
gpu
access.
You
can
see
here
that
we
have
a
gpu
device
plugin,
that's
advertising
that
as
a
resource
to
the
node,
and
then
we
have
a
gpu
pod.
A
That
requests
that
resource,
and
so
this
means
that
now
we
have
just
with
this
work,
a
scenario
where
webassembly
modules
can
declaratively
request
devices
on
kubernetes
clusters
and
the
crestlet
will
mount
any
of
those
files
that
are
needed
environment
variables
into
the
webassembly
module
or
thereby
grant
access
to
the
webassembly
module.
For
those
files.
A
So
we
understand
now
the
how
we
went
about
implementing
the
first
of
our
two
steps,
so
we're
going
to
transition
and
talk
about
the
second
of
our
two
implements
implementation
steps
to
get
to
that
exciting
picture
that
we
saw
earlier.
But
before
we
talk
about
how
we
changed
ocari's
architecture
to
have
web
assembly
components.
Let's
talk
about
how
what
ocarie's
architecture
consists
of
so.
A
Once
you
apply
that
to
your
cluster,
the
ocry
agent,
which
runs
on
every
node
in
the
cluster,
will
see
that,
and
it
will
tell
the
appropriate
discovery
handler
to
start
looking
for
those
devices,
whether
locally
on
the
node
or
across
the
network,
for
every
device
that
the
discovery
handler
discovers
and
reports
back
to
the
awkry
agent.
The
agent
will
create
a
device
plugin
for
it,
thereby
advertising
that
device
to
the
cubelet
and
the
cluster
at
large
as
a
requestable
resource.
A
A
B
Thanks
so
much
kate,
so
yeah.
Now,
let's
go
a
little
bit
in
depth
on
what
does
some
of
the
changes
we
have
made.
We
have
made
to
make
bring
that
right
to
the
web
assembly
environment
and
you
can
see
right
there
on
the
design
on
the
operating
design.
Part.
The
upper
part
of
the
design
is
actually
100
the
same
as
kate
was
showing
off
showing
up
on
the
previous
slide,
so
we
didn't
change
anything
there,
so
you
can
still
have
the
configuration
on
the
instances.
B
The
correct
crds
and
the
apple
controller
is
still
there
so
that
the
card
changes
comes
on
the
node
level.
You
can
see
that
the
most
impactful
change
is
it's
now.
Every
node
will
be
across
that
node,
so
it's
not
running
on
a
normal
couplet
anymore,
and
what
this
means
is
this:
this
node
is
capable
of
running
webassembly
workloads.
So
this
is
what
we're
going
to
be
aiming
for
during
this
node.
B
So
we
have
web
assembly
applications
running
on
each
node
and
the
other
key
difference
is
right
there
on
the
aqua
agents,
not
that
they
are.
Creation
is
different,
but
it's
now
instead
of
running
a
little.
It's
not
sorry.
Instead
of
running
inside
kubernetes,
it's
not
running
locally,
and
this
is
because,
since
resolute
is
only
capable
of
running
webassembly
workloads
and
the
rpa
is
a
container
application,
it
was
required
to
be
removed
from
kubernetes,
but
still
they're
communicating
a
lot
with
the
rest
of
the
kubernetes
cluster.
B
It's
not
just
it's
not
applied
to
the
node
yet,
and
the
rest
is
of
course,
the
more
interesting
part
which
was
the
webassembly
application.
So
we
have
this
cover
handler
and
there
wasn't
brokers
so
for
this
poc
we
have
this
debug
scope
handler
and
debug.
Gecko
is
a
debugging,
accurate
discovery
handler
that
serves
as
a
test
for
our
discovery
process.
So
it's
discovering
fake
devices
and
start
using
them
on
their
applications.
So
you
can
see
that
the
acrylic
is
really
so.
B
B
So
now,
let's
go
to
the
next
slide,
where
we
see
some
of
the
technical
limitations
that
we
have
managed
to
overcome
for
doing
this,
this
design
and
right
down
the
left.
You
can
see
that
we,
this
was
the
like
our
ideal
design,
the
one
that
we
managed
to
the
one
we
wanted
to
do
like
if
there
was
no
limitations.
B
But
of
course,
katie
was
talking
before
how
web
assembly
has
is
single
thread
and
it
has
a
limited
network
access
and
turns
out
that
the
app
reagent
is
a
communicator
that
is
covering
headless
via
grpc
and
since
the
rpc
requires
sockets
and
http
2,
which
is
not
supported
by
web
assembly.
Yet
we
had
to
create
this
new
component
called
the
grpc
proxy
and
what
this
proxy
does
is.
B
It
mediates
the
communication
between
the
acquisition
and
the
discovery
handler,
and
it
does
that
by
using
the
file
system,
so
the
rp,
so
the
grpc
proxy
will
come
connect
to
their
creation
and
you'll,
send
everything
that
the
agent
sent
to
an
input
file
that
can
then
later
be
written
by
the
discovery
handler.
They
can
start
the
discovery
process
and,
as
soon
as
the
devices
has
been
discovered,
it
will
be
then
printed
to
an
output
file.
B
So
now
let's
go
for
the
for
the
demo
and
you
can
see
right
down
the
right.
We
have
our
updated
design
with
the
overcomes
we
have
to
deal
with
solar
demo
will
be
composed
of
four
steps
and
I'm
going
to
be
breaking
down
them
before
we
jump
to
the
video
first
we're
going
to
be
setting
up
our
cluster,
so
we're
going
to
be
making
sure
we
are
running
on
a
two
node
cluster,
one
being
a
normal
kubelet
and
the
other
one
being
chrysler.
B
B
So
this
being
the
grpc
proxy
and
the
agent
will
be
also
required
to
be
running
locally
there,
then
we're
going
to
be
applying
the
output
configuration
sorry,
the
actually
debug
echo
configuration,
so
we
can
make
sure
that
they,
their
creations,
already
know
which
device
to
look
for
and
also
configure
the
broker
position.
So
the
so
the
ip
controller
can
deploy
the
correct
brokers
as
soon
as
they
find
a
device
that
was
created
was
discovered.
B
Sorry
and
finally,
the
final
step
would
be
to
deploy
your
discovery
model
itself,
so
we
can
start
to
see
the
discovery
process
are
taking
place
in
full
action
during
the
during
the
during
the
demo
so
yeah.
Let's
now,
let's
go
for
that
video,
and
for
this
we
are
using
the
kubernetes
dashboard
to
better
visualize
the
pause
and
the
broker
and
the
cluster
situation
in
general.
So
let's
go.
B
Let's
start
and
first
we
are
going
to
be
setting
up
our
cluster,
so
you
can
see
that
right
now
we
only
have
one
node,
our
normal
kubernetes
couplet
one
and
that
will
be
serving
as
a
control
plane
for
us
and
so
now,
let's
deploy
our
clustered
node.
So
now,
let's
now,
let's
run
the
across
the
command
you
can
see.
This
is
really
similar
to
the
one
we
are
really
used
to
doing
crossfit.
B
Now,
let's
approve
the
certificate,
so
we
can
see
that
the
crosstalk
node
has
the
right
permission
to
handle
kubernetes
so
yeah
right
there
you
can
see.
We
are
now
with
a
two
node
cluster.
What
this
means
is
our
cluster
is
ready
for
receiving
webassembly
workloads
there.
So
now,
let's
go
for
the
for
the
deployment
of
acry.
B
So
for
this
we're
going
to
be
using
this
home
installation
right
there,
and
you
can
see
that
this
installation
is
really
simple,
there's
only
two
lines
and
it's
really
similar
to
the
one
we
are
always
used
to
during
installation
of
factory.
The
only
key
difference
right
there
is
on
the
last
line,
where
you
can
see
that
we
are
setting
the
agent
to
be
disabled.
So
what
this
means
is.
We
do
not
deploy
the
agent
to
any
pod
and
this
because,
as
I
said,
we're
going
to
be
using
our
local
running
agent
but
yeah.
B
Now,
let's
now,
let's
apply
it
so
the
the
correct,
cids
and
the
aquacontroller
should
already
be
deployed
during
this
during
this
installation.
So
now,
let's
go
back
to
the
dashboard
and
show
the
new
part
that
we
have
created
so
right.
There
we
have
the
acrylic
controller,
already
running
on
the
control,
plane
node,
and
we
have
the
two
crds
right
there.
So
the
configuration
on
the
instance
there
is
still
no
configuration.
Yet
it's
going
to
be
still
waiting
for
one.
So
now,
let's
go
back
to
the
terminal
and
deploy
our
local
programs.
B
The
first
one
I'm
going
to
be
using
is
their
creations,
and
nothing
really
is
stand
up
on
that
and
the
last
one
is
the
grpc
proxy.
So
this
grpc
proxy
is
where
we
start
to
see
something
interesting
and
different
than
aqua
itself
right
down
the
second
line,
you
can
see
that
we
are
specifying
this
copperhead
name
to
be
debugger,
and
what
this
is
doing
is,
since
this
proxy
was
designed
to
be
to
work
on
any
web
assemblies
cover
handler.
We
need
to
specify
which
device
this
grpc
proxy
is
responsible
to.
B
So
the
rp
agent
knows
that
this
proxy
is
able
to
find
debugging
devices.
So
as
soon
as
they
are
created,
it
knows
it
needs
to
find
this
type
of
device.
It's
know
exactly
where
to
look
for
so
now,
let's
run
it,
and
as
soon
as
we
run,
you
can
see
that,
of
course,
it's
not.
You
can
stay
right
there
on
the
creation
it's
already
registered,
so
they
are
creating
is
already
already
this
new.
B
This
new
discovery
handler
sorry,
this
new
gipc
proxy
is
there,
and
so
now
let's
apply
a
configuration,
and
this
is
where
we
start
to
see
things
interesting
and
a
little
bit
change
change
the
anchor
itself.
So
as
soon
as
we
run
this
configuration
we
go
back
to
the
dashboard
and
see
more
details
on
that.
You
can
see
that
it's
already
showing
up
there
and
the
things
we
deploy
into
this
configuration
is
is
the
same
format
as
k2
has
mentioned
it
before.
B
So,
the
after
configuration
is
composed
on
the
broker
pod
spec
and
the
the
configuration
for
the
discovery
handler
and
first
talking
about
the
broker
pod
spec.
This
is
where
we
start
to
see
things
different,
because
it's
now
deploying
to
the
it's,
not
a
website
application.
So
it's
not
a
container
application
anymore.
It's
still
going
to
be
deployed
automatically
by
the
aquacontroller,
but,
as
you
can
see,
right
down
the
node
selector
we
are
specifying
the
wasm.
B
32
was
the
architecture,
so
this
is
going
to
be
deployed
to
the
crescent
node
and
the
image
is
the
oci
normal
web
assembly
image.
So
now,
let's,
let's
go
right
there
on
the
on
the
bottom
part
of
the
of
the
configuration
where
you
can
select.
This
cover
handler
configuration
and
you'll
see
right
there.
We
are
specifying
the
debug
echo.
B
So
as
soon
as
we
apply
it,
the
agent
is
already
looking
for
the
blackjack
device,
but
since
we
haven't,
we
have
not
discovered
handler
yet
it
will
keep
waiting
for
one
so
now
this
is
where
we
what
we're
going
to
be
applying
now.
So
if
you
go
back
to
the
pod
section,
you
can
see
that
we
are.
We
have
our
idols
perpendicular
there.
So
at
any
moment
now
a
new
device
was
discovered
and
right
there
you
can
see.
The
device
was
discovered
and
the
apprehension,
sorry,
the
aqui
controller,
again
knowledge.
B
This
device
was
recovered
and
has
already
created
a
broker
path.
For
that,
and
you
know
what
right
there
on
the
aquarius
part,
you
can
see
that
we
have
a
debugging
echo
device.
So
now,
let's
go
back
to
the
terminal
and
we're
going
to
be
seeing
a
more
general
cluster
situation
for
our
components.
So
we're
going
to
be
seeing
the
aqua
instance
that
we
have
just
discovered
the
apple
configuration
that
we
have
applied
at
some
moments
before
and
write
down.
B
The
posts
on
the
on
the
pod
selection
is
where
we
get
to
see
the
more
interesting
thing,
because
right
now,
the
things
that
I'm
right
liking
right
there,
the
aqua
controller
deployed
this
broker
pod.
So
this
broker
prod
is
a
website
application,
that's
interacting
with
the
device-
and
it's
doing
this
using
this-
that
I'm
we're
going
to
be
showing
right
there.
B
This
is
requesting
that
this
pod
to
have
a
web
so
to
have
a
device
name
exactly
as
this
in
order
to
run,
and
what
this
is
doing
is
it's
using
the
the
it's
using
the
proper
device,
plugin
manager,
that
kate
was
showing
off
before,
and
this
is
what
we're
going
to
be.
This
is
what
we
did
to
link
the
web
assembly
application
to
the
device.
So
now,
let's
continue
on
and
as
now
that
we
have
showed
the
the
describe
of
the
code.
B
Now,
let's
check
the
logs
and
see
what's
doing
with
the
device
itself,
and
you
can
see
that
right
there,
the
pod
is
running
and
using
the
debug
activates
name
through
zero.
So
what
is
really
what
this
demo
really
shows
is
a
webassembly
application,
discovering
the
device
and
then,
after
controller,
deploying
automatically
application.
That's
used
in
this
device,
a
website
application,
that's
now
using
the
proper
device
that
was
covered
by
the
website
application.
B
So
now,
let's
continue
on
the
with
the
presentation,
with
some
takeaways
from
that
and,
of
course,
the
whole
point
of
this
of
this
experimentation,
and
this
is
a
study.
Whilst
you
reduce
the
acne
fingerprints,
so
we
can
work
on
even
more
constrained
environments
and,
as
you
can
see
right
now,
this
is
like
we
have
reduced.
The
oci
image
is
now
54
times
smaller
than
before,
went
in
from
103
megabits
to
1.9
megabits.
So
this
I
don't.
B
I
don't
know
about
you
guys,
but
this
is
a
really
domestic
decrease
there
and
really
shows
a
sense
of
how
web
assembly
is
on
a
completely
different
scale
than
the
normal
containers
in
terms
of
memory
usage
and
right
there
you
can
see,
we
have
a
a
more
in-depth
look
on
where
these
improvements
come
from,
so
web
assembly
binary
itself
is
way
smaller
than
ros,
and
ross
has
already
a
really
small
binary
itself.
So
web
assembly
is
even
better
than
that
and
we
have
also
reduced
the
container.
So
by
removing
the
container
we
are.
B
So
now,
let's
go
for
a
road
map
and
of
course,
the
first
part
and
the
more
immediate
one
that
we
can
start
working
on
right
now
is
to
create
a
real
discovery
handler.
So
we
can
make
sure
that
our
this
plc
work,
for
example,
on
a
scenario
that
kate
was
talking
before
with
the
cameras,
so
we
can
start
to
see
this
application
run
on
a
real
on
a
real
program,
a
real
environment.
So,
of
course,
acry
itself
has
some
already
some
discovery
handle
in
place.
So
maybe
this
task
will
be
to
convert
the
this.
B
These
across
copenhagen
should
be
a
web
assembly
application,
and
this,
of
course,
is
where
we
need
everyone's
help.
So
everyone's
watching
everyone
that
me,
kate,
everyone
that's
on
the
community,
we
can
start
doing
this
right
now,
so
we
can
make
even
more
powerful
environment
on
the
web
on
the
web
assembly
edge
community
and
the
next
few
bullet
points
is
something
that
we
as
a
community
is
still
working
on
hard.
B
That
is
trying
to
solve
some
of
the
limitations
of
web
assembly
right
now,
so
we're
going
to
be
adding
sockets
to
azi
and
the
multi-trading
support.
So
this
is
both
something
that
we
need.
There
is
still
a
lot
of
progress
already
going
on
with
the
community,
but
this
is
something
that
we
really
require
to
create
even
more
complex
applications
on
web
assembly
and
finally,
our
final
goal
would
be
the
kubernetes
first
plus
plus
part
where
we
want
everything
to
be
running
on
kubernetes,
so,
for
example,
even
the
accretion.
B
That
is
a
really
complex
application
that
has
a
lot
of
network
access.
A
lot
of
things
running
at
the
same
time
can
also
be
deployed
to
kubernetes
as
a
web
assembly
application
and
yeah.
So
to
conclude,
the
things
up,
if
you
want
to
get
involved,
there
are
plenty
of
ways
to
do
so.
This
plc
is
right
there
on
the
first
link
on
the
on
the
first
link
on
this
slide,
where
you
can
check
the
demos
and
everything
that
we
are.