►
From YouTube: WASM in the Wild West: A Practical Application Tale - Matt Butche & Taylor Thomas, Microsoft
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
WASM in the Wild West: A Practical Application Tale - Matt Butche & Taylor Thomas, Microsoft
Almost one year ago, our team released Krustlet, a Kubernetes Kubelet implementation for running WASM modules. Since then, we’ve spent plenty of time out on the frontier, implementing full Kubernetes functionality for WASM as well as other experiments like WAGI. Along the way, we’ve seen all the rough edges and gaps when using WASM in the cloud. Using these project as a practical backdrop, we’ll discuss the lessons we’ve learned and the remaining gaps to be filled (and how you can participate!) in order for WASM to become more mainstream.
A
All
right
welcome
to
wassum
in
the
wild
west
a
practical
application
tale,
I'd
like
to
introduce
you
to
your
outlaws
for
the
day,
I'm
from
colorado,
and
we
are
definitely
cowboyish
here-
I'm
matt
butcher.
I
lead
an
open
source
team.
At
microsoft,
I
have
worked
on
helm,
kubernetes,
various
pads
systems
openstack
and
this
web
assembly
world
is
my
latest
foray
into
the
wide
world
of
cloud.
You
can
reach
me
at
any
of
these
social
media
handles.
B
And
I'm
taylor
thomas,
I
also
live
in
what
used
to
be
the
wild
west,
but
that's
not
why
we're
theming
it
this
way,
I'm
a
chrysler
and
helm
core
maintainer
emeritus
I've
been
doing
kubernetes
things
since
around
docker,
since
1.2
and
docker
around
0.7.
So
I've
been
doing
this
for
a
while
as
well
the
cloud
native
space
I
came
to
rust
by
way
of
go,
which
kind
of
makes
sense.
B
Given
the
kubernetes
background,
I
have
a
problem
with
consistency
with
my
social
media
handles
given
when
they
were
created
and
whatnot
and
I'm
always
afraid
to
change
them,
because
we
all
know
what
that
can
do
so.
Yeah,
that's
us!
So
let's
go
ahead
and
just
get
straight
on
into
things
and
talk
a
little
bit
about
just
kind
of
a
to
wet
your
whistle.
B
Just
like
you
would
a
normal
container,
it's
not
running
in
a
container.
It's
it's
running
actually,
just
as
a
straight
was
in
binary
and
then
bindle
is
an
aggregate
aggregate
object,
storage
engine
we've
given
another
talk
on
this
in
case
you
want
to
check
it
out.
This
allows
us
to
store
all
of
the
wasn't
things
together
and
then
last
is
waggy,
which
we
kind
of
took
from
all
of
our
dogs
on
our
team,
but
it
is
a
an
easy
way
to
write
cloud
side,
wasm
kind
of
as
a
http
handler.
B
A
A
We
all
got
together
in
vancouver
and
vancouver
island
rather
and
had
our
typical
on-site
off-site
meeting
but
somewhere
along
the
way.
Here
we
got
sort
of
sidetracked
from
our
usual
kubernetes
container
virtual
machine,
helm,
kinds
of
conversation
and
got
going
on
web
assembly,
and
we
were
talking
about
the
interesting
aspects
of
webassembly's
runtime
and
how,
while
it
was
intended
to
run
in
a
browser,
it
actually
had
a
lot
of
potential
for
running
on
a
cloud
side
and
creating
the
kind
of
isolated
runtime
that
we
need
in
multi-tenant
cloud
situations.
A
A
We
wrote
this
in
rust,
so
we
named
it
crestlit,
because
kubelet
rust
seemed
funny
to
us
and
it
turned
out
to
not
be
too
hard
to
basically
just
write
a
small
amount
of
code
that
could
connect
to
a
kubernetes
cluster
advertise
itself
as
a
kubernetes
node,
but
when
it
got
a
request,
instead
of
pulling
containers
and
executing
containers,
it
was
pulling
web
assembly
modules
and
executing
those.
So
this
is
sort
of
our
first
heist.
We
were
pretty
proud
of
ourselves.
A
We
got
got
enough
of
this
done
to
show
off
to
a
few
people
and
of
course
it
started,
peaking
more
and
more
people's
interests,
and
what
happens
is
that
your
cute
little
proof
of
concept
suddenly
runs
into
actual
production.
Use
cases
and
people
say:
can
it
do
this?
Well,
no,
can
it
do
that?
Well,
no,
so
then
we
had
to
sort
of
upgrade
from
a
heist
to
an
all
out
great
train
robbery,
style
thing,
and
we
went
from
a
proof
of
concept
to
an
mvp
and
anytime.
A
You
make
that
an
mvp
being
a
minimum
viable
product
right.
So
anytime
you
go
from
the
nice
little
demo
wear
to
something
that
can
actually
execute
production
workloads
on
it.
You're
gonna
encounter
some
growing
pains.
So
we'll
talk
a
little
bit
more
about
that
here
and
and
and
and
also
in
our
talk
about
crestlet
in
the
was
no
sorry
the
rest
day
event,
but
we
got
going
on
that.
It
was
very
exciting.
B
We
want
to
talk
about
what
we've
learned,
what
some
of
the
gaps
are,
because
what
we've
noticed
is
that
many
times
at
these
at
these
wasn't
conferences,
everyone
is
looking
into
the
clouds,
which
is
a
good
thing.
That's
what
we
want
here.
This
is
such
an
exciting
area,
but
we
sometimes
forget
about
the
people
actually
trying
to
implement
this
in
the
wild
west.
B
If
you
have
never
ridden
horses
before
you
have
a
a
saddle
that
sits
on
top,
which
is
obvious,
but
then
underneath
there's
a
cinch
that
runs
through,
and
you
always
want
to
check
it
for
two
reasons,
because
either
you'll
cinch
it
too
tight
and
your
horse
will
pass
out
on
top
of
you
or
you'll.
Have
it
too
loose
and
it'll
slide
right
to
the
side
or
off
and
you'll
fall
off
so
both
ways
you
end
up
under
a
horse
and
falling
off,
so
this
is
kind
of
our
well.
What
did
we
learn
in
this?
B
In
this
whole
experiment,
we've
done
and
first
off
is
our
horse
and
pony
show
we're
gonna
do
a
little
bit
of
comparison
here.
So
one
of
the
things
that
happens
is
when
people
talk
about
waz
and
they're
like
well,
and
they
always
hold
up
a
finger.
Haven't
we
tried
that
before
and
it's
like?
Yes,
I
mean
everything
kind
of
reinvents
things
just
every
every
10
years.
We
know
that,
but
let's
talk
about
some
of
the
most
common
ones
compared
to
we'll
start
off
with
the
java
vm.
B
The
java
vm
is
very
tried
and
true
and
infinitely
tweakable
and
configurable
people
have
careers
out
of
tweaking
the
jvm.
However,
it
is
very,
let's
just
put
it
nicely
bulky.
It
takes
a
lot
of
resources
and
it's
very
large.
So
it's
just
kind
of
bulky
and
also
it's
limited
to
a
single
language
ecosystem.
Now,
granted
you
have
java,
you
have
kotlin,
you
have
all
the
different
things
that
run
on
top
of
the
jvm,
which
is
great,
but
you're
still
limited
to
just
that
ecosystem.
A
That
we
were
fairly
passionate
about
we've
done
a
lot
of
work
in
the
container
container
ecosystem
container
system,
they're
more
lightweight
than
java,
in
a
sense
right,
particularly
a
single
well-made
sort
of
carefully
crafted
containers.
You
can
get
fairly
small
ones
and
you
can
run
things
written
in
just
about
any
programming
language,
provided
it
meets
the
operational
constraints.
You
need
to
execute
a
container
right,
but
cross-platform
is
hard
with
containers.
A
There
have
been
many
many
attempts
to
do
them
in
different
ways
with
you
know,
running
linux,
containers
on
windows,
running
windows,
containers
on
linux,
multi-architecture
containers
and
so
on,
but
a
lot
of
those
require
extra,
build
steps
or
other
specialized,
tooling
and
oftentimes
also
added
some
constraints
upon
what
the
developer
themselves
themselves
had
to
do.
In
order
to
make
this
run
in
the
expected
ecosystem.
B
We're
going
to
talk
a
little
bit
more
about
that
in
a
second,
but
the
binaries
can
be
very,
very
small,
especially
in
comparison
to
a
container,
even
well-made
containers.
I'm
not
talking
about
the
the
nightmare
containers
that
are
multiple
gigabytes.
I'm
talking
about
well-made
containers,
they're
still
smaller
than
that.
The
other
thing
is
that
it's
sandboxed
by
default,
and
so
for
for
that.
B
I
can
build
a
binary
on
my
mac.
Have
it
run
on
my
windows
machine?
Have
it
run
on
a
raspberry
pi?
Have
it
run
on
a
linux
server
in
the
cloud,
and
I
built
it
on
a
mac?
There's
no
changing,
there's
no
different
up
like
it's
just
the
same
binary
and
there's
also
this
idea
of
being
able
to
compile
from
any
language
without
additional
steps.
B
So
with
docker
it
made
developers
have
to
learn
the
intricacies
of
all
their
dependencies,
which
in
one
sense,
is
good
because
sometimes
in
in
the
old-fashioned
way
of
doing
things,
developers
would
just
kind
of
shovel
it
over
to
the
ops
people.
But
the
thing
is:
is
devs,
that's
not
their
specialty
and
sometimes
there's
little
nuances
that
that
people
don't
know
about
unless
they've
done
it
for
a
long
time
or
that's
their
their
specialty.
B
And
so
you
have
to
know
about
that
with
docker
files
and
building
a
docker
image.
But
with
the
wasn't
runtime
as
it
stands,
you
can
just
compile
into
a
wasm
binary,
there's
no
special
steps
except
specifying
a
target,
and
that
obviously
depends
on
the
language.
But
you
can
compile
straight
to
it.
Instead.
A
And
one
of
the
interesting
things
about
webassembly
is
that
it's
already
a
w3
standard
and
there
are
already
many
many
run
times
available
for
web
assembly
that
all
implement
consistently
the
same
spec
with
different
pros
and
cons
and
advantages
and
disadvantages
to
the
way
it
executes
it.
But
the
same
webassembly
module
will
run
on,
say,
wasm,
3,
wasmtime
and
scriptin,
and
so
on,
which
brought
us
to
our
first
choice.
Right.
Taylor.
B
Oh
yes,
the
language,
so
this
is
always
this.
We
all
know
as
developers
that
languages
generally
cause
flame
wars.
We
are
trying
to
avoid
that
here,
but
we're
just
trying
to
inform
like
why
why
we
decided
the
way
we
did
and
for
us
it
came
down
to
be
a
question
of
rust
or
javascript.
Now
that
doesn't
mean
other
languages
can't
do
it
we're
going
to
actually
talk
about
that
too.
But
the
idea
was
with
javascript.
B
It
was
the
first
language
to
do
wasm
in
a
real
quote,
unquote,
real
way,
it's
obviously
flexible
and
very
popular,
as
the
creator
of
javascript
has
said.
Like
bet
on
bet
on
javascript
I
mean
and
wasm
he
said
actually,
but
that,
like
there's,
there's
good
reasons
to
use
javascript
it's
very
accessible
to
people,
but
really
even
with
node.
It's
not
as
good
for
system
level
development
as
other
languages.
B
B
Most
of
the
tooling,
though,
on
the
bleeding
edge
of
the
wasm
space
is
written
in
rest
and
it's
amazing
for
systems
level
development
with
really
really
strict
and
good
safety
guarantees.
So
we
chose
rust
because
those,
even
though
it
was
less
popular
and
we'd,
have
a
little
bit
harder
time
getting
people
hooked
into
it.
It
was
much
better
for
choosing
how
we
did
our
building
things
for
how
we
were
going
to
do
and
use
wasm.
A
Yeah
and
sort
of
in
the
end
for
us,
even
though
we
chose
rust
and
we
use
it
in
our
major
projects,
we
do
still
do
a
lot
with
em,
scriptin
and
and
wasm
three
and
other
runtimes.
We
just
found
that
our
projects,
we
would
probably
stick
to
rust
for
the
main
ones,
but
in
the
end,
doesn't
represent
any
hard
feelings
or
anything
like
that
toward
any
of
those
other
runtimes.
A
You
know
when
you,
the
the
compiler,
is
going
to
mainly
just
try
and
transform
the
source
code
to
web
assemblies
to
bytecodes
right,
and
so
when
I
was
playing
around
with
swift.
My
first
swift
application
when
I
compiled
it
to
webassembly,
was
about
9.8
meg,
which
was
considerably
larger
than
most
of
the
other
languages
I
had
compiled
in.
A
There
are
fractions
of
of
the
amount
of
time
running
in
a
run
time
with
a
jit
optimizer
means
we
could
get
even
faster
run
times
and
we're
even
experimenting
now
with
ahead
of
time,
compilers
that
when
we
know,
for
example,
we're
running
in
a
pas
kind
of
circumstance
and
the
end
user
has
uploaded
a
web
assembly
binary.
We
know
that
the
user's
intent
is
to
execute
that
binary
on
the
platform
they
uploaded
it
to.
A
This
kind
of
leads
into
the
idea
that
there
are
many
different
ways
in
which
you
can
execute
a
webassembly
module.
So
it's
not
merely
a
matter
of
how
you
optimize
it
prior
to
starting
it
up,
but
webassembly
is
structured
in
such
a
way
that
you
can
run
it
in
a
flat
out
interpreter
which
will
execute,
as
it
reads,
through
the
webassembly
file.
A
I
think
26
now
includes
an
ahead
of
time
compiler,
so
you
can
even
pre-compile
some
of
this
stuff,
which
even
speeds
things
up
further
at
the
cost
of
having
to
have
storage
and
also
at
the
cost
of
sort
of
having
to
bind
it
to
one
particular
run
time
as
you're
executing
or
one
particular
family
of
run
times
right,
but
again,
if,
if
you're
willing
to
make
that
trade
off
for
speed
ahead
of
time,
compiling
might
be
the
the
fastest
object.
But
the
thing
that
we
really
appreciate
about
this
is
the
developer.
A
Never
has
to
be
concerned
with
whether
it's
running
in
an
interpreter,
a
jet
environment,
an
ahead
of
time,
compile
environment
or
whatnot.
The
developer
simply
writes
their
code
and
compiles
it
and
something
else
can
optimize.
Something
else
can
tweak
and
tune
and
something
else
can
run
it
and
the
developer
can
be
blissfully
unaware
of
that.
We
like
that,
because
that
tends
to
alleviate
the
kind
of
operational
decisions
from
the
developers
plate
while
at
the
same
time
giving
the
operations
staff
all
kinds
of
options
for
how
they'd
like
to
execute
something.
B
So
the
last
thing
in
our
learnings
section
is
around
the
wazi
spec,
so
this
is
really
important
to
us,
so
we
consider
wazi
to
be
the
future
of
wasm.
Now
that
isn't
meant
to
be
a
technical
declaration,
more
a
community
declaration
we'll
talk
about
that
a
little
bit,
but
it
gives
us
a
common
interface
that
any
wasm
project
can
then
build
on.
So
these
can
be
possible
posix-like
or
libsy-like
apis
common
abstractions
for
passing
data.
B
All
these
things
are
very
important,
but
for
us
the
most
important
thing
is
just
being
able
to
do
this
in
a
way
that
allows
people
to
extend
and
build
on
top
of
a
great
foundation
which
kind
of
leads
into
some
of
the
next
things
we're
going
to
talk
about.
So
our
next
topic.
We're
calling
keep
your
butt
in
the
saddle.
Now
that
is
a
phrase
that
I
hear
my
wife
does
horse
horsemanship
stuff
and
that's
a
phrase
you
hear
all
the
time.
B
It
sounds
like
something
stupid,
but
sometimes
you
forget
to
keep
yourself
in
the
saddle
and
if
you
get
out
of
the
saddle
or
out
of
place,
your
horse
will
ride
poorly
and
you
can
fall
out.
So
this
is
kind
of
our
discussion
of
how
we
can
avoid
the
gap
and
to
kick
it
off.
I
want
to
to
talk
about
something
that
is
very
close
to
what
the
last
thing
was
around.
B
The
wazi
spec
is
around
community
fracturing,
and
this
is
a
potential
gap
that
is
very
serious
for
us,
so
in
general,
there's
an
unevenness
across
all
these
different
wasm
implementations.
There's
various
run
times
and
protocols.
We
have
wasmtime
wasmer,
wapi-c
and
wasmcloud.
There's
witix
bindings.
There's
other
projects
like
suborbital
and
the
thing
is:
each
project
has
its
own
buy-in.
You
have
to
use
their
custom
libraries
and
their
custom
things
and
really
there's
no
major
community
found
community
or
foundation
to
use
as
a
gathering
place
or
a
watering
hole.
B
Shall
we
say,
given
the
theme
of
this
stock,
there
there's
no
community
place
for
us
to
just
talk
these
things
over
so
where
we
want
to
be
with
this
and
this.
This
is
meant
to
show
the
gap,
as
we
would
like
common
specifications
with
various
implementations
that
people
can
build
around
them.
We
would
like
to
have
less
lock-in
to
custom
libraries
and
we
want
a
better
community
collaboration
meeting
foundation
space.
To
do
this.
B
Our
opinion-
and
all
of
this
is
that
we're
better
together
is
if
we
can
work
together
like
we
know
that
there's
going
to
be
things,
there's,
there's
competitors
working
together
to
build
this,
but
we
don't
have
to
like
this
foundation,
doesn't
have
to
be
something
we
compete
over
or
to
create
competing
standards,
and
the
thing
we
worry
about
as
we've
observed
things,
we
worry.
The
community
is
trying
to
do
everything
right
now
in
fracture,
which
will
cause
lots
of
problems
in
the
future.
A
We
we
feel
like,
at
the
end
of
the
day
developers
are
going
to
use
the
tools
that
they
feel
the
most
comfortable
with
and
the
tools
that
we
use
as
developers
today
they
could
use
improvement.
Always
they
could
use
improvement
right.
So
we
want
to
be
part
of
that
story
of
how
we
improve
the
the
average
experience
of
creating
code
that
can
run
in
this
kind
of
cloud
native
ecosystem.
A
So
where
we
are
today,
we
see
a
lot
of
work
in
order
to
bootstrap
environments
and
in
order
to
get
objects
imported
into
assembly,
runtimes
and
so
on.
We
see
a
lot
of
work
with
custom
bindings
and
annotations,
each
of
which
matches
its
specific
little
platform
like
we
talked
about
on
the
last
slide,
a
lot
of
work
with
sort
of
like
bespoke
tool
chains
where
you've
got
to
line
up.
You
need
these
four
things.
A
A
One
of
one
of
my
call,
my
boss,
brandon
burns,
was
recently
saying
I
just
wanted
to
you
know,
create
my
first
webassembly
module
and
I
had
to
go
through
so
many
steps
just
to
create
hello
world
that
it
was
really
frustrating,
even
though
it
was
so
exciting.
To
then
have
this
binary
that
I
could
use
in
all
these
different
environments.
A
That's
the
kind
of
experience
that
we
want
to
alleviate
right
and
then
what
we're
seeing
is
the
very
beginning
of
an
emergence
of
set
of
sets
of
tools
that
will
be
able
to
do
this.
We've
worked
on
one
called
yowasum,
which
is
a
yeoman
generator
for
web
assembly,
where
it'll
walk
you
through
the
process
of
saying
yeah.
A
So
we
are
seeing
things
start
to
move
in
the
right
direction,
but
we
want
to
be
even
further
right.
We
want
this
kind
of
one
step
where
you
say
all
right,
build
and
deploy
this
thing,
and
it
builds
it
signs
it
pushes
it
and
then
the
next
thing
you
know,
you're,
you
know,
checking
out
the
results
of
your
work
to
see.
B
Now,
as
matt
mentioned,
we're
going
to
talk
a
little
bit
more
about
wazi.
So
where
do
we?
Where
are
we
at
with
wazi?
So
in
case
you
we
haven't
mentioned
it
yet
wazi
is
the
webassembly
systems
interface.
It's
kind
of
this
main
spec
that
we
were
mentioning
and
where
we're
at
right
now
is
that
networking
is
kind
of
a
mishmash
of
stopgap
solutions,
including
mission
one.
Something
in
that
mishmash
is
something
we
wrote.
That's
our
wazi
experimental
http
that
allows
us
to
get
some
sort
of
http
support.
B
B
There's
only
a
few
kind
of
very,
very
experimental
implementations
and
ideas
so
where
we
want
to
be-
and
this
is
kind
of
a
in
a
year,
because,
ideally,
we
want
everything
to
be
all
all
in
place
and
a
wonderful
1.0
spec,
but
where
we
want
to
be
in
a
year
is
a
working
stream
implementation
which
allows
for
flexible
extensions
on
top.
So
for
I
o
networking
all
those
things,
and
we
would
like
an
initial
nano
processors
implementation.
A
Streams,
the
I
o
streams,
I
o
array
work
that
that
is
happening
under
the
streams.
Kind
of
idea
is
what
really
opens
us
up
to
being
able
to
to
write
guest
modules
that
rely
on
resources
outside
of
them,
and
we
can
write
very
convenient
apis.
So
we
can
very
quickly
write
things
like
key
value,
storage,
drivers,
database
drivers,
file
system,
implementations
and
so
on.
A
So
if
we
can
get
there
in
a
year,
then
we
feel,
like
we've,
really
unblocked
kind
of
the
key
bit
of
potential
that
is
currently
sort
of
locked
up
in
the
webassembly
ecosystem,
and
is
that
is
accounting
for
a
lot
of
what
we're
currently
seeing
as
fracturing
in
the
ecosystem.
So
we're
optimistic
that
that
could
really
sort
of
re-level
the
playing
field
and
get
everybody
excited
about
building
together
instead
of
each
separate
project
having
to
kind
of
build
their
own
thing.
B
B
There's
really
only
five
and
of
those,
if
we're
being
honest,
like
the
ones
that
people
use
in
production,
there's
three
of
them
rust
c
and
swift
and
the
others
kind
of
have
they
can
build
wasm
for
the
web,
but
they
don't
really
build
wasm
for
like
wazi
compatible
things
so
where
we
would
like
to
be
in
a
year
again.
Is
that
we'd
like
to
have
first,
like
native
level,
support
in
c
sharp
python
go
and
java,
some
like
the
big
names
in
enterprise
development?
B
B
We
have
our
oci
distribution,
crate,
we've
written
in
rust,
there's
other
object
stores
people
have
used,
and
other
companies
like
glue
that
have
created
their
own
custom
registries,
but
really
where
we
want
to
be,
is
to
have
better
oc,
oci
support.
We
know
that
we
can
never
escape
like
having
oci
support
in
specific
places
in
the
cloud
native
ecosystem,
but
also
something
like
bindle.
Our
aggregate
object.
Storage
engine
we've
worked
on
now,
obviously
we're
biased
towards
that.
B
A
Yeah
the
reason
that
the
things
that
got
us
excited
about
this
when
we
first
looked
at
them
at
vancouver-
you
know
a
couple
of
years
ago-
are
still
the
things
that
we
are
really
excited
about.
We
see
here
the
the
potential
to
have
a
secure
lightweight,
vm
language
vm
that
is
portable
and
that,
ultimately,
with
just
a
little
more
work,
we'll
deliver
a
really
really
solid
developer
story.
A
We
feel
we
know
we
all
need
to
work
together
and
it's
exciting
to
see
the
community
sort
of
starting
to
form
ad
hoc
and
common
patterns
emerging,
largely
the
people
in
the
web
assembly
ecosystem.
We
all
know
we've
all
done
this
before
and
we're
all
going.
Okay.
We
know
that
if
we
start
working
together
and
sharing
information,
it's
going
to
make
everything
easier
for
us
everything
easier
for
our
users
and,
ultimately
you
know
that
kind
of
translates
to
an
ecosystem,
that's
inviting
and
approachable
for
new
developers
or
new
developers.
In
this
space.
B
Yeah
and
really
like
there's
a
gap
here
that
we
can
fill
because
there's
not
that
we
don't
have
this
nice
portability
with
a
very
small
footprint.
It
just
doesn't
exist
yet
and
that's
such
a
big
gap
in
the
cloud
native
ecosystem.
That
would
make
a
lot
of
people
very,
very
happy,
combined
with
that
developer
experience,
and
also
this
is
kind
of
our
call
to
action.
Just
help
us
gather
the
wagons.
This
conference
is
a
good
first
step.
A
As
we
see
this
ecosystem
go
from,
you
know
some
fancy
ideas
to
something
that
we
think
is
just
going
to
be
a
a
lovely
experience
for
developers
and
a
powerful
experience
for
operators.
So
thank
you
very
much
for
coming
today
and
please
again
reach
out
to
us.
If
you
have
questions
comments
or
just
want
to
get
connected
on
this
stuff.