Server side WebAssembly,
where versions range from 0.

3 to 3 to 25.

In this episode, we get
to chat with Mikkel about

WebAssembly then and now, Spin 3.

0, WASI 0.

3, and Spin moving into a
sandbox project for the CNCF.

And Laura took her shot.

She got us talking about
the enterprise, FML.

Of course I had to.

least we talked about Rust.

Enjoy this episode.

welcome Mikkel, thank you for joining us.

This is Cloud Native Compass,
and we're excited to pick your

brain on everything Cloud Native,
Fermion, WebAssembly, and Spin.

For anyone who is not familiar with
you, Fermion, or Spin, please feel

free to introduce yourself now.

Thank you, David.

And thanks for having me.

So my name is Miggel Mark Heinheit.

I am Danish, which is why
you would hear that surname.

I am the head of product and developer
relationships at Fermion, where I've

been for And now I actually don't
know whether it's two or three years,

so you pick whichever one you want.

I think it's actually three years.

at Fermil we are doing, um, WebAssembly.

We talk about it as the next wave of cloud
computing, which is, why it's so well

aligned with the topic of Cloud Native.

Hopefully you're going
to talk about today.

prior to being at Fermion, I spent
more than 10 years in Microsoft

building various cloud services and
developer tools there, which is also

where I met Matt Arrado, who are
the founders of Fermion and, how I

sort of got involved in all of this.

Excellent.

Awesome, thank you.

Now, of course I wanted to chat about
Spin, which as of November, only a

few months ago, released version 3.

So the pace at which that project
is evolving is fantastic to watch.

But I think we should set a little
bit of context and just talk about

WebAssembly and the evolution of that
over the last few years if you've seen it.

no surprise to anyone who's
listened to this podcast before

or seen any of my YouTube stuff.

I'm quite bullish on WebAssembly.

I think it's an enabler and
something that everyone needs to

start paying more attention to.

But I'd love to hear your version
of it as someone from the inside

who's actively trying to make this
possible for developers to adopt

and succeed with WebAssembly.

What have those last three years been like
for you and how is WebAssembly evolving?

the last few years, and I actually
think it's three years now

that I get to think about it.

It

Thank you, Laura, you're
confirming me, keeping me straight.

it actually says something about
how quick Time has passed, but

also how much have happened.

Like you have that weird paradox that
you feel like time just like snaps away.

But then on the other hand side,
there's so many things have happened.

And I just think that's a good
indication that, a lot has happened.

Like we moved, we really moved
forward and just, to think back to

even November when we did spin 3.

0 and where we are today,
even more has happened.

so yeah, so it's an interesting space.

I think over the last three years.

the whole ecosystem around WebAssembly
has, my first encounter with it when

I joined Fermion three years ago
was just, trying to figure out what,

what's even going on here, what's the
ecosystem trying to accomplish, lots

and lots of really great and promising
visionary stuff, but less practical

things that were usable and approachable
for people to actually do things with.

Where is over these three
years, that has really flipped.

I think, a lot of the
divisions has come to fruition.

And I hope we get to talk about
the upcoming Wasio 3 as well,

which is another big milestone in
what you can do with WebAssembly.

but also seeing Spin WebAssembly space.

Really bringing this in the hands of
developers, that it's easy to get to,

there's great developer experiences.

You can easily build applications,
manages, managed services popping up.

So it's easy for you to actually run them.

the ability to run things in Kubernetes
and, really try to get WebAssembly as.

That's a core primitive of cloud
computing in all those places

where you expect to, or where you
do cloud native computing today.

and I think that's, I used the
tagline, the next wave of cloud

computing when I introduced myself.

I think I did something along the lines.

but that's really what we
think about WebAssembly.

Here in on the progression that we've
seen from all the way back from physical

servers to virtual servers to containers
and then being WebAssembly the new kid on

the block in terms of that, core primitive
into how we do Cloud Native things.

Nice.

there's quite a lot I feel
we can dig into there.

And I'm going to try not to
go down, I love that, the

next wave of cloud computing.

And I think we'll just
We'll leave this here.

We're going to come back to this to
talk about how building WebAssembly

applications and operating WebAssembly
applications is different from traditional

container based or VM based applications.

We'll come back to that for sure.

But, you talked about WASI 0.

3 there, and I don't want to be
foolish, but I'm going to try and

say When WebAssembly first came out,
it was just a browser based sandbox.

Wazzy is what brought
WebAssembly to the server.

And I believe 0.

1, there was no such thing
as the component model.

The runtimes all implemented
their own interface things.

And then with 0.

2, the component model came along
and said, actually, let's have shared

interfaces to provide shared behaviors
with different implementations.

And I believe the Fermion team
was maybe not spearheading.

Maybe you were spearheading, but you
were definitely a major part of it.

As we progress to 0.

3, is this us leading to something
that is truly ubiquitous from a

WebAssembly and server side point
of view for people to adopt it now?

Because in my head, in one of the
conversations I have, sorry, I'm now

going to go on for ages and chat, when
I go to conferences, I'm always going

WebAssembly and waving my hands and
trying to get people to listen to me.

And one of the major concerns is, it's 0.

2 from the VASI, but isn't that?

Too early, and and on the opposite side of
this, we've got spend, which is on version

three, which is built on top of WA Z, zero
point X. So what is the stability here?

How do we get people to,
there's two questions here.

One, what is 0.3?

Where is this taking us?

And then is, are we at a stable
point for people to start

kicking the tires on this stuff?

Yes.

I like to think of these in
terms of, if you were to look

for stability, you should not.

So WASI is a specification.

Let's start there.

Like WASI is a specification, right?

and the specification typically has a long
time, to move from releases to releases.

in terms of there's a lot of,
alignment and agreement that

needs to happen in the ecosystem.

which I think is good because the
specification needs time to prove itself

before it, it stabilizes because that's
going to end up being the foundation

where, you know, the main promise of
longevity of what you end up building

comes in, promises of portability between
implementations and so on and so forth.

That's where you snap that to in
terms of what the specification is.

And there are definitely scenarios
where some of that has more impact and

is more important than other scenarios.

so you think about the runtime
implementation, so for instance,

wasmtime is one of the, most
popular, WASI runtimes that exist.

I think there's a nuance to this.

It's like, how do you even
apply your versioning concepts?

Because wasmtime is I think version 25
or something like that, because they

basically have a way of saying, Every time
we do a version, we do a major version

release, and that's, that's how you can
think about the runtime and what they do.

but what most people will end up taking
a direct dependency on would be those,

the tools and the implementations which
they as developers, would write against.

Spin being one of those, right?

which is a framework and a developer
tool that, that is where you

are going to meet WebAssembly.

in many cases, and there are other
examples of spinners, besides

spin as well, and more of these
come up in, in various scenarios.

and spin then across its major versions
that obviously has support for the

underlying specifications, Spin is, I
think, is where, that's at least been

our approach to that project, has been
like spin is where we're going to give

you the promises of Backbot And we have
across Spin 1 and 2 and 3, which we're

at right now as the major versions, kept
the Backbot compatibility for things

that we have been able to run previously.

Which means you can still run things
that are not, that is WASI 01.

with even with spin 3.

0. So if you wrote into that
specification, that's still

supported at that point.

so I think it's important for
people in terms of how they think

about this, what are the tools
they're going to implement against?

what is the direct dependency that
you have and do they rely on that

dependency to, do the long term support
across the specification revving?

yeah, at least that's
how I think about it.

and.

Knowing that we are early on with some
of the specification pieces, at least I

think it's important for the frameworks
that people use directly that they

help with the promise of, longer term
support and backbone compatibility.

Yeah.

you've just, you talking there for a
few minutes has given me a kind of a

eureka moment in my head and I think
I'm going to condense everything you've

just said until a single sentence.

And I hope you're not too offended, but,
I think from a developer standpoint,

exactly what I want is slow moving
specifications that I can trust to still

be there, but fast moving implementations
that can iterate and provide me what I

need to be successful as a developer.

And I never thought about it that way.

Yeah.

You can write it

I'll just say that next time around.

But yeah, I've never viewed it through
that lens before, but yeah, I want

my specifications to evolve slowly
with the implementations providing

that testbed to iterate, advance,
test things, kick the tires, and

all that, so I really like that.

And even though the WASI specification
is,what's your point moving 0.

2 moving on to 0.

3, these things have been in the works.

For a long time as well.

WebAssembly is not exactly a new concept.

It's been, around since, I don't
want to just throw out a year and

hope that I'm right, but I think it's
like 2016, 2017, maybe I'm wrong.

That's a great question.

It's actually a really good question.

should go Google it, but yeah,
no, but you're probably right.

So I was gonna say, now I'm not
as up on web assembly as David is.

Uh, kind of that person in the call.

but last I remember there was a move from.

Building on top of, I think it
was Nomad, and now it mostly

builds on top of Kubernetes.

So from like an operator standpoint,
I'm curious from that perspective

of, that move been a significant
throw this out there, as you

start thinking for like spin 4.

0 and whatever's next for WebAssembly,
are you thinking that you'll

probably stay on Kubernetes or do
you think you might branch out to

try to encourage even more adoption

I'm pretty sure Kubernetes is
the path to get adoption I think.

If anything, you will find in most,
companies that run thing is that you can

be pretty certain as a developer, if you
hand over a container to your operations

department, they know how to run it.

Right.

they probably will use
Kubernetes in most cases.

95 percent of the cases
or something like that.

so I think that's a given for
sort of like the mass adoption.

it's true that at Fermion, we did create
something we call the Fermion platform

on Nomad to begin with, mainly because
we didn't have, we didn't see a good

solution to run, other types of work
inside Kubernetes than containers.

And that was really the main thing, why
we picked up Nomad at that point in time,

because Nomad are able to run even just
processes along with containers and other

things, and that's how we packaged that.

So the big invention that happened
there, which was together with, well,

actually Microsoft did a concept
called RunWASI, which was a way to

provide a, we evolved into a way of
providing a shim for ContainerD, the

runtime, to not only be able to run
containers, but also to run WebAssembly.

natively, so to speak, right?

So you don't wrap a
WebAssembly in a container.

You basically run the
WebAssembly directly.

And with that component, it sort of
saw like what we, what we didn't take

on at that point in time is you now
have native Native WebAssembly support

in Kubernetes by using Containerd
and using that shim, which means

that, it makes so much more sense to
start running inside of Kubernetes.

So if you take that compared with,
birth of adoption of, of Kubernetes, I

think that's definitely the way forward.

That makes sense.

Yeah.

To add on more context there, just because
like this is now my dream situation.

We're talking about WebAssembly
and Kubernetes side by side.

So if we bring in some rust
and I'm just, I'm on fire,

in here?

Let's go.

the reason, The serverless workloads
on top of Kubernetes sometimes have a

bad time and get a bad reputation is
because in order to actually start.

A container or a pod inside of Kubernetes.

There's a whole bunch of
assumptions that needs to be made.

One is it needs to speak to
the CNI and get an IP address.

It needs to speak to the Linux
kernel and get c groups and

namespaces and all this stuff.

Meaning that the base or the
bottom line for starting a

container is actually measured in
usually hundreds of milliseconds.

Those are ways to improve that,
but hundreds of milliseconds.

Yeah.

and for WebAssembly, I don't
think that makes sense.

I believe it's Radu, Fermion, who's always
talking about the invocation and startup

time for a WebAssembly binary is measured
in nanoseconds and not milliseconds.

Yeah.

And when you realize, yeah, why would
you take all of that performance

improvements and throw it away
just to run it on Kubernetes?

There's a lot of things that need
to be challenged and changed there.

And I love what the Microsoft team
are doing with RunWasy to enable this,

because it provides that new bedrock,
that new framework, that allows these

WebAssembly applications to maintain.

to that velocity without
sacrificing the runtime environment.

Because Michael just said, everyone
has Kubernetes, I don't even think

HashiCorp are running Nomada anymore.

They're at Kubecon too,
taling about Kubernetes.

So

that

is,

yeah,

I know.

the fact that we can have Our
stateful container based databases

running side by side with a future of
hopefully web assembly and vocations

I think is a powerful future that we
should all be aspiring to eventually

and it's just how do we get there?

How do we onboard more developers?

And I'm sure Mikkel's got
all these answers in his back

pocket we can dive into that.

But how do we go from,
okay, we've got WASI 0.

3 coming up, hot on our heels.

We've got SpendCube now, which is
open source and release that allows

people to run these WebAssembly
workloads natively on Kubernetes,

side by side with everything else.

We now need to get them right in
Kubernetes application, WebAssembly

applications and voila, now we're onto
Spend3, like why don't you give us the

TLDR, why should people start paying
more attention to Spend and what did

the v3 release bring to the table?

so I think, I just want to make a
small remark on what you said on the

performance thing, because the way that
I think about that in my head is that I

think what we've done with RunWASI and
SpinQube, so SpinQube being the project

that pulls all these things together
with, easy Helm challenge installs,

and then you just deploy the Spin app.

But basically it's all the
underlying technology stacked up and

operators and so on and so forth.

Is we've ensured that Kubernetes is
sort of a, that a spin application,

WebAssembly can become a first class
citizen inside of Kubernetes, right?

So you, when you operate these in
Kubernetes, You operate them the

same way you would operate container
there, which also gives you the huge

benefits that the whole ecosystem
around Kubernetes worked with this.

Last week, I did a recording of
an introduction to SpinCube that

involves showing how you can
just apply a KEDA scaler to your

WebAssembly workloads, right?

The same way you do to your container
workloads, which is a really good

example Of, just fitting into the broader
ecosystem, which I think is part of the

answer to getting the adoption, right?

Like the same way that operations teams
or platform engineering teams provide

platforms that support containers,
it's really easy for them to enable

now just supporting WebAssembly
inside of the same platform that way.

I think the missing piece there to
your point about performance is work

to be done to have Kubernetes being
a first class host for WebAssembly.

meaning that you actually get the full
benefits of, for instance, the scaling

to zero and starting from zero, the lack
of, the, not the lack of cold start, but

the fact that there hardly is any cold
start going from not having a WebAssembly

component loaded and then loading it.

we've done runtimes in that, around
that as a commercial project for

Fermion, where basically we can host
10, 000 applications, WebAssembly

applications on a single Kubernetes node.

But we can't do that in the.

Kubernetes model because of pod
limits and those type of things,

which means we have to break out of
that being the first class citizen.

So there is that trade off there, right?

That sort of speaks to that.

but I think being a first
class citizen in Kubernetes is

part of the road to adoption.

So back to your question, David,
about what we've done in Spin 3.

0. the main things that we have
been focusing on in Spin 3.

0 is this idea of WebAssembly components.

it's actually also a good sort of, there's
a tie back to when we talked about Wasi

03 and that being sort of the next release
of the specification, the major, the

sort of the marquee feature that Wasi
03 will bring in the specification is

to be able to do a combination of async
and sync programming between components.

So we might want to talk a little bit
about what WebAssembly components are,

so that we get an idea of what this is.

so WASI stands for the
WebAssembly System Interface.

So it's basically a set of APIs that
you need to implement if you create

a WASI compliant runtime, which
means that it's a virtual machine,

it's like an operating system.

So if you write a WebAssembly and
using these APIs, you expect that

WebAssembly to be able to run
inside of Wasi compliant runtime.

But Wasi is also just, so together
with Wasi, a way of describing those

APIs and interfaces, called WIT.

which is the WebAssembly interface
type language, was developed.

But it actually enables you
to define your own set of

interfaces and APIs through WIT.

And what's interesting about
WIT is that WIT operates BOP.

WIT is meant to bridge same way that a
WebAssembly, you can say, is portable

or runtime, because it's a bytecode
format and you have this virtual machine.

What Wit enables us to do, it has
a definition that the programming

languages now can understand.

So you can have a definition of
an interface that you can provide

in a Rust implementation and use
in a JavaScript implementation.

Which means that you can actually
have libraries, which is what we

would normally call them when we're
in a single programming language.

from other programming languages that you
use in whatever code you're writing today.

And in the WebAssembly world,
we call these, when they're

compiled, we call them components.

So you can implement a WebAssembly
component in a given programming

language you can now go and use in
another WebAssembly component written

in another programming language.

there's a path of this, which
is, just polyglot development.

And then it's like, well, I don't want
to, Breakdown my libraries in different

programming languages, I just, because
I use one programming language, it's

already right, but there's another
path of this, there's another way of

telling the story, which is, maybe it's
the package managers and all package

managers, like, you know, if someone
wrote a really secure and fast Postgres

driver in WordPress, and Given language,
we don't have to write a Postgres drive

in all these other languages when we're
using the WebAssembly world, because we

can basically just use that component
from other programming languages.

So the component model is a core focus
in O3O where now between these libraries,

we're actually able to combine synchronous
and asynchronous functions that work

inside of each of these components,
unlocking a whole breadth of scenarios,

particularly around streams and other
things where you want to stream data.

I think it's one of the typical use
cases that, that will light up there.

yeah.

So this means.

I I haven't been keeping up with 0.

3, so this is new to me, but I'm
loving where this is going already.

This is essentially like a distributed
promise across any language, where,

again, if I've got an async function in
JavaScript, it does a fetch request to a

remote host, but I call that from Rust.

It's able to handle the promise in
JavaScript for a shorter response,

but it's handled at the WebAssembly
world point of view, rather than

each individual component itself.

Is that correct?

yes.

That's like a yes and no,
rather than just a yes, but

yeah.

Yeah.

I don't know what the no would be.

Yes.

that's really cool.

I like where that's going and I can, I,

the main thing here that we've discovered
is that are certain frameworks and

programming languages that like
makes, such heavy use of async.

so one of the things that people may
have stumbled upon when they'd be looking

into WebAssembly is like, but there are
all these things you can't do, right?

Like, there's probably still like garbage
collection, multi threading or things

that, people used to take on to in this.

There's definitely things because,
because it's not a full operating system,

like it's not a full VIP C compatible
thing like people expect other places.

A lot of these frameworks just take
assumptions that are not, we're not

able to honor in WebAssembly yet, right?

So it's just yet another step on
this ladder of, Making more, think

the, really the effect of this will
be that more stock libraries you get

from your NPMs and your Cargo or your,
NuGets or wherever will actually just

work at WebAssembly once we have 0.

3. 0, working.

that's really the net effect of this.

The people

just compile down to one layer
and everything can work together.

it makes sense.

Yeah.

it's preaching.

To myself here.

I'm a polyglot developer.

I don't, as much as I would like
to write most things in Rust, I

definitely appreciate having that
option to jump out to writing

some goal where it's appropriate.

I like writing Elixir.

I like playing with Pony Lang.

I like playing with Z. if there's a
language, there's of an interest isn't,

I generally like to play with it and I
feel like web assembly and especially

wazi and server side stuff just allows
me to sit down and experiment with all

these things and, Having spent the first
10 years of my life writing nothing but

C and Perl, you get locked in to how
things are done in those ecosystems.

And it's not until you start experimenting
and playing with more languages that I,

I feel that I broadened as a developer
and began to pick up new patterns

and, new paradigms and I think made
me a better and stronger developer.

I encourage people to
look at it from that lens.

don't just sit and write Go because the
entire Cloud Native ecosystem is in Go.

There's a lot to learn from Lust
and Elixir and Zig and all these

other really cool languages.

just this week, I seen a language,
library shared on GitHub.

Someone starred it and it was an
actor framework written in Swift.

And I like distributed systems.

I like actor based systems and
I've never played with Swift.

So I went and lost three hours of my day
just playing and getting tired of that.

But it's fun.

You've got to find moments of joy as
well when you're doing this stuff, right?

That's what stops you, hopefully,
from burning out and just

have a smile on our face we do

I mean, just the diversity

of ideas that are implemented and
concepts that are implemented, just

like, I think enables you to reasoning
about things in a different way, it's

like hearing other people's opinions,
which is also always inspiring, right?

Definitely I just hear that
you're enabling David's o shiny

syndrome, is what I'm hearing.

so that's very classic.

very

Yeah.

It is.

sang some for it.

there's actually, there's a very,
there's a very specific scenario

that we did end up writing the other
for a few weeks back because someone

requested it, which was like, Hey, I'm
a JavaScript developer and I want to do

something really easy that I can employ
into, low compute environment, but I

actually want to do image manipulation.

What's a great way of doing
image manipulation in JavaScript?

It's we can just implement a component in
Rust over here and use a really efficient

Rust library to do image manipulation.

Expose the features to an interface
defined in VIT and now you just wrap, the

HTTP request in your JavaScript and you
call into the Rust component that actually

does some of the heavy lifting, right?

So there, I think there's another
thing, which is, you know, using

some of these programming languages
appropriately where they are.

they're really easy.

JavaScript is easy with HTTP and JSON.

Rust is not necessarily easy
with HTTP and JSON, but it can

do other things as well, right?

So I think that's a good, sort of
more, down to earth practical use

case for this type of polyglot.

Right?

Yeah.

And if we also expand the scope a little
bit, people write servers, people write

applications that run server side,
some people write applications that run

front end, there's desktop applications,
there's mobile applications, there's

a lot of opportunity for interop.

Okay.

But they require you to use different
languages, yes, sure, you can use Electron

for desktop and mobile and all right,
but we all like native feeling apps

that work well within each ecosystem
and WebAssembly gives us this wonderful

integration point as well where you can
have shared type definitions that can be

consumed across the entire stack, which

Yeah.

I mean I spend a lot of time doing
this with  JSON GraphQL and a whole

bunch of other Arvo type languages.

And then you're always compiling the
language specific assets for this.

And it's cumbersome, it's
painful, especially when you go

across multiple repositories and
multiple projects and you've got

versioning and distribution, right?

It sure I could throw all
in MPM, but I wanna do that.

No.

and I think there's better ways now and
Web assembly is front and center with

that regard, at least in my opinion.

So again, I said I'm bullish.

I'm not gonna be shy away from saying that
I really like where web assembly is going,

and more people need to be doing this.

From an enterprise standpoint, though,
it's actually very useful because

you're not really having to deal
with a lot of the, how do I chase

the new thing that I need to do and
get more developers to work on that?

But I still need to maintain all
of these tools and things that I've

built that are running in older
development systems and older languages.

so you can't staff up for everything.

if you have to constantly move around,
whereas if you only had to have one person

be able to build in this, one person be
able to build in that, and they can build

different components and put it together,
or one team, I should say, an enterprise

is going to find that very useful.

So I can definitely see the value
there, especially if you're building

on what is the de facto operation
system, which is Kubernetes right now.

So that makes perfect sense.

There's a, and so a lot of, we talked
about a lot of the component stuff in

terms of, benefits it gives to developers.

There are fun parts that you can do
on the runtime side of things as well.

and part of 3.

0, we actually released a feature
we call selected deployments,

means that you can define.

so considering the scenarios, when
you write a spin application, You

can expose, individual components.

It's typically HTTP endpoints, right?

Because these are serverless
function models, so you create

an HTTP event, an HTTP handler.

Within that handler, you can take
dependencies and other components that

you bring in, but you can also split up
the applications in multiple handlers.

with selected deployments, what you
can do is now, if you go and deploy

this into Kubernetes, for instance, you
can actually define which components

you want to deploy on various, node
types or node pools inside of your

Kubernetes cluster, even if there's
some of them you don't want to deploy.

so there's, there are lots of benefits
you can get on the runtime side, once you

have things broken out into components.

One of those being this,
breaking up the application.

another thing we've done as
experiments and other runtimes

is deduplicating components.

if you've, if you know Windows and NET,
there's a global assembly cache concept

in I think it's actually NET content.

It must be outside of Windows as well.

Anyways, I used to, about it from
Windows back in the days, but

basically at runtime, what you
can do is let's go back to the

example of the image transformation.

Let's say a hundred people deploys
applications into your system

that all makes use of that same
image transformation component.

We only need to host it one time
and we actually unend the system

and all of these applications and
other components that make use of it.

we'll just, run that.

so there are lots of great things you
can do there, both in terms of, less

footprint at deployment time, but going
back to your enterprise scenario, Laura,

again, there's things like, how can you
actually patch things, in, in the system?

but you can just, upgrade that one
component if there's a security thing

that needs to come in, and now all the
applications are using the updated, right?

Even if it's in a distributed system
and not necessarily on a single machine.

That makes sense.

It's a good model.

Useful model.

I'm just thinking in terms of massive
enterprises with lots of things going on

and just only having to fix it once and
having to stay up once to do a deployment

in the middle of the night is a very nice.

yes

Instead of having to have four
deployment windows that I have to go

deal with over the course of a week
to handle a security vulnerability.

Let's get away from the enterprise
chat because, we don't want to offend

the Cloud Native folks, of course.

And no, what I'm thinking is,

they work in its process?

yeah, small ones.

okay.

Little ones.

It's not

no, I don't know, maybe it's just
my cloudy judgment, but enterprises,

I hear Java, Tomcat, scatty stuff,
virtual machines, custom data centers.

could work on here, right?

Maybe?

What?

Sorry?

Chava, I'm just kidding.

Oh.

Yeah.

and

I think she's trying to convince
you to build the WebAssembly Tomcat.

That's what it is.

good.

I'm more just trying to horrify
you, David, so it's all good.

Anyway, what was your question?

no, I was thinking, I think we've said
lots of nice things about WebAssembly.

We're seeing momentum, there's
pace, there's velocity, all

these wonderful things we want
from a budding new ecosystem.

The next wave of cloud
computing, if you will, right?

how are Fermion approaching the idea of
getting individual developers to say,

OK, I want to write my next thing in
WebAssembly, because I imagine that is.

A challenge, right?

if people are still setting their
ways with ready to go and shipping

containers and sticking them onto
Kubernetes, what does it look like?

How I'm assuming you go to
conferences, you speak to people,

they have the aha moment, but
they're like, this is really cool.

How do you deliver that to
the individual developer?

But then I'm sure they eventually go
down enterprise, but I don't care.

But how do you put that
smile on a developer's face?

We showed them the thing, right?

it is, it, no, but that is actually,
this is a, it's hard to do in a podcast

like this, we, I think one of our
taglines is like 66 seconds from LinkedIn

cursor to deploy the application, like
the light weight ness, I don't even

know if that's a word, but it, Yeah,
of the whole thing, just it had been

a, I think it's enabled us to able to
create like one of the best developers

experience I've been part of creating.

Um, to give you some of those
examples, there's a simple CLI tool

that you download and by the way,
we didn't talk about this yet, but

both spin and spin cube, the project
to get things into Kubernetes.

are becoming CNCF sandbox projects.

At the moment they're in
the process of onboarding.

So this is now a CNCF based project.

There are other CNCF projects
around WebAssembly as well that

people should go and check out.

So it's not a, It's been open source
all along, but it's not a Fermion

owned thing anymore, it's now in
the CNCF, which is super nice.

You download a CLI, and that's
really all you have to do.

You don't, you need your programming
language toolchains, and there

aren't like heavy dependencies.

Container runtimes are probably
almost everywhere again.

So whether that's a heavy dependency
or not, but you still need it if

you want to run containers, right?

And even if you want to do Kubernetes
stuff, you either want k3d or micro k8s

or whatever you do locally and all of
these things, none of this is needed here.

So being able to go through that
experience of having just a CLI, writing

a simple function handler, running it
locally, Where you get, building key

value stores and other things that we
can do again because of this whole WASI

model, like we can plug in underlying
data store implementation through those,

those interfaces and being able to
deploy that either into a Kubernetes

cluster and spin cube or into a managed
service like Fermion Cloud, which is,

run these serverless functions at scale.

Um, that is 66 seconds to have things
in the cloud, which find it super, super

hard to get to anywhere, elsewhere.

I know when people talk a lot about,
typically when people talk about

PaaS, they always end up referring
back to Heroku as being sort of the

golden standard of how you want to
build a good developer platform.

And I think we've actually come
super, super close to that without

having to lock people into particular
programming languages or frameworks or

other things that they can do, because
it's all based off WebAssembly and

the standards that are behind that.

I hope some of those things are the things
that would put, a developer's smile on.

which I felt was part of your question
as well, David, definitely SpinCube

is one of those, like making it
super, super easy to have a way,

place to run these things, right?

Starting to see some enterprises
experimenting with lighting up SpinCube

as part of their Kubernetes base based
platforms, really just gives developers

the deployment endpoint that they
need to start running these things.

Yeah, I was really hoping that you went
down the developer experience angle and

you totally did, so that's fantastic
because you mentioned Heroku there, and

I'm old enough that I remember when Heroku
deployed or launched and I shipped my

first thing and I didn't write a single
config, I just did a git push to a remote

that wasn't mine, it was the Heroku
cloud, And all of a sudden it knew what

type of application I had, it put it
into production and it spat out a URL.

And that was a moment, that was, that's
a eureka moment, that's wow, like

deploying has never been this easy before.

And I think for spin for me, and I can't
remember when this was or whatever, but

it was when the spin add command was
added and I was able to just add new multi

language polyglot, whatever you want to
say, components to a single application

where all the routing was handled for me
and I could invoke each different thing.

easily.

That was oh wow, like this changes
the game because it just gets rid

of so many different challenges with
writing applications in this way.

we look at Kubernetes and can you be
successful with Kubernetes on its own?

But really you need service meshes
and you need, observability tools and

you need GitOps and you need platform
engineering and all this stuff.

And then you get spin coming along
and you just do spin deploy and spin

build and spin up and it doesn't
matter how many components are it

just handles that for you and it like

show me a better developer experience
anyone like that's an open challenge

like I just don't think what exists
okay I feel like we're doing a nice

journey here and we're getting close
to wrapping up But let's, let's

put smiles on developers faces.

They see the magic.

And now we're talking
about productionization.

There was something that caught
my eye with Spin V3, which was

the open telemetry integration.

Maybe you can shed a little bit of
light on, as we move to pushing more

WebAssembly into production, how
important that is and what's coming next.

Yeah.

the main thing we did in spin 3.

1, 3. 0 is actually to have the
runtime being, instrumenting the

path to invoking your components.

So think about it as a runtime, your app
is like the guests running on top of the

runtime, which means that, of the box, and
there's actually a, we have called them

plugins to the Spin CLI, the developer
experience, so you could run a command

called spin plugin install otel, and then
when you do the local running of your

spin application, which obviously is the
command spin hub, you do spin otel hub,

And if you do those commands, what you
get is a local Jaeger instance that just

immediately shows you the spans when you
call into your WebAssembly components.

And you can start imagining how you
can see a span of, a request came

in, one component was loaded, that
component called another component,

may have called a third component.

And when we get async,
you can start doing that.

Seeing those things coming
back and you just get all these

spans and things out of the box.

that also is translated into SpinCube.

So when you deploy things into
SpinCube, you can either have a global

or a namespace scope or whatever
your scope is, OTIL configuration.

So all the spin applications just start.

pushing traces and, and spans
into your OTAL instances.

So I think the main thing
there is just going where the

ecosystem already are, right?

Or is, where it's just, if you build
a platform based on Kubernetes,

there is a high likelihood that
you have some OTAL based monitoring

system, observability system already.

So obviously these workloads
just need to, fit into that

ecosystem as easy as possible.

And again, Taking it back to the
developer experience is let's just

take some of those concerns away.

Because why, if we have a good enough
solution that, solves for the 80, if

not even more, use cases, why even, make
it your concern from the get go, right?

you get stuff out of the box and obviously
you could be able to start implementing

your own spans and so on and so forth.

in the code that you write, but really
out of the box, you get all these things

where you can start just measuring
the execution time off your component

and so on and so forth, and have that
as, you know, a thing you don't have

to think about, but it's just there.

Makes sense.

Awesome.

Yeah.

Alright.

Last question.

What's next for Spin?

Main thing right now is actually
the whole CNCF onboarding.

It's quite a piece of work getting it
in and it will probably resolve in a 4.

0, main reason being we have to do
breaking changes of a bunch of namespaces

and things in there that were previously
assigned with, or subject with, Fermion

as a company, which will now be,
think either spin or spin framework.

I don't know.

I think the GitHub is
called spin framework now.

for both spin and spin kubeland.

So there's a whole bunch of
work that we actually have

to do to wrap all of that up.

but obviously spin, sorry WASI 0.

3. 0, is a little bit of a way
out in terms of timeline for the

specification, but I, our hope is
that we'll be able to contribute 3.

0 in the next release of spin and.

Other than that, I think we've
spent a lot of time on really

improving the JavaScript experience.

it would actually have been more
interesting to talk about the

JavaScript SDK version 3 and the
upcoming version JavaScript SDK, but

that could maybe be another episode.

but a lot has happened on the JavaScript
side, to make that more interesting.

A much more pleasant
experience around spin.

Other than that, given it's a CNCS
project, now everyone is able to come

and contribute to what the roadmap should
look like and their ideas and what they

would like to see from the framework.

I highly encourage everyone to
seek that out and, be part of it.

good luck with that transition.

Thank you.

good, it's a good road to be on.

It's a long road, but it's a good one.

it definitely is.

mean, are we casting bets on when
the Linux Foundation launches

the WebAssembly Foundation?

Because surely that's
right around the corner.

there's a DevRel Foundation now,
so why not a WebAssembly one?

That makes more sense.

That's fair.

That's fair.

Dora, I'll cut that out.

I'm not going to moan about
the Linux Foundation on this.

I could.

all right.

Any last questions, Laura?

no, it's just always good to hear a
little bit more about WebAssembly.

And I know, just itching David's oh,
shiny itch is always a good thing, too.

All right, then we'll give
Michael a chance to say goodbye.

do you have any parting words or anything
you'd like to share with our audience?

Oh, thanks.

Thanks for having me here.

Thanks for inviting me to
come talk about WebAssembly.

It's, it's always good to
see you guys in person.

thank you for coming on.

It's been good

KubeCon is right around the corner, right?

So I'm sure.

true.

That's true.

I will definitely be there.

Also, there's Wasm.

io just a week before, so if you'd
rather go to Barcelona Thursday, Friday,

and maybe stay over the weekend, I'll
definitely recommend coming to Wasm.

io.

There you go.

We'll include the links
and the show notes.

I see you in London and to everyone
who listened, thank you for joining us.

Thanks.

Thanks, folks.