matei_radu

Hey, one of the SpinKube maintainers here!

You are correct that there is nothing extra required if what you want is to run Wasm inside a container.

However, that comes with a few disadvantages, primarily stemming from bundling your wasm runtime with each container image — and while your wasm workload is portable, the runtime itself needs to be compiled for the specific OS and architecture you need to execute on.

SpinKube comes with a containerd shim (or plugin) that executes Wasm workloads directly, so you can continue to integrate with the Kubernetes API (either by using regular pods with a runtime class, or the Spin application manifest), but not get the overhead of a full Linux container for your lightweight wasm component.

Thanks for the question!

For context, the shim is just an implementation detail of how containerd runs workloads; some come pre-built by default on some systems (like runc), and others you configure (like kata-containers, or in this case, the Spin shim); and some Kubernetes distros already have built-in shims (or will have soon), like k3s.

Your setup seems to work really well for you (and as a side note, I'm curious to learn more about the kinds of workloads you are running) — I'll note that you can also set the runtime class on a regular Kubernetes deployment / pod spec and you can run the workload like this with the Spin shim (for reference https://github.com/spinkube/containerd-shim-spin/blob/main/d...).

For Spin, we focused on the end-to-end developer experience, and on building a set of tools that take advantage of the benefits you get from Wasm, while integrating with a lot of cloud native tools — while allowing you to more easily build APIs and event-driven functions.

Our goal with SpinKube is to integrate with how organizations run workloads on in their infrastructure, and to make building, distributing, and running Wasm as seamless as possible.

Happy to dive into details for any of the points above, and would love to learn more about what you are running as Wasm.

Thanks!

Hi, everyone! I'm one of the maintainers, I'd love to chat about the project and about how and why we built it.

Thanks for the question!

Spin could definitely run in more places than what we have pre-built binaries for. Specifically, we could run on all platforms Wasmtime supports today (https://github.com/bytecodealliance/wasmtime/releases/tag/v1...), including RISC and S390X, for example.

And while we have been experimenting a bit with running Spin on RISC, we haven't really had the bandwidth or requirement to build a production build for those yet.

Are you interested in a specific operating system or CPU architecture? Would love to understand your scenario.

Joel from our team worked on the initial prototype for WASI support in TeaVM (https://github.com/konsoletyper/teavm/pull/610), and we temporarily forked before the WASI support made it to the official repo.

Good reminder to deprecate that now, and thanks for the amazing work on the project!

Hey, thanks for the question!

The short answer right now is no. The behavior of the default (and most popular) trigger in Spin (the HTTP trigger) is to create a new instance for handling each incoming request. We made that choice primarily because we want to leverage the really good startup times for Wasm (and in particular for Wasmtime), and not running any guest code (in this case, business logic) until there is an actual incoming request means the server can execute other applications while idle.

Now, HTTP workloads are not the only type of workloads that Spin can handle — because of the way it's built, it's entirely pluggable and you can build your own trigger (for example https://github.com/fermyon/spin-trigger-sqs), and potentially have long-running processes, but that is not currently possible with Spin today.

Thank you!

(disclaimer: I work at Fermyon, the company that created Spin.)

All of Fermyon's websites are powered by Spin, and there are quite a few users who are deploying their Spin applications to Fermyon Cloud.

Thank you for the kind words!

Hey, jesdict1!

Check out this community project that adds support for Zig — https://github.com/tensorush/zig-spin.

Thank you!

To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular.

Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support.

For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK. (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have significant experience) and JCO (https://github.com/bytecodealliance/jco), and the web platform compatibility makes it a significantly better proposition for things like 3rd party dependencies).

C# is an interesting one — the .NET team at Microsoft (and in particular Steve Sanderson from that team) has been making tremendous progress in ahead-of-time compilation for .NET and generating Wasm and WASI compatible binaries (as opposed to their initial approach on Blazor), and experimenting with that led us to build support for Spin as well.

Finally, we do a lot to support other popular languages and their Wasm support — two examples: Python (https://github.com/bytecodealliance/componentize-py) and Java / TeaVM (https://github.com/fermyon/teavm-wasi), for which we haven't fully integrated Spin support, but we hope to get there soon.

I hope this explains a bit our process on language support, happy to expand on any point here. Enjoy your weekend!

Hi, everyone, I'm one of the Spin maintainers.

We're really excited about the new release, happy to answer questions about it!

Hi, everyone! One of the platform maintainers here, happy to chat about WebAssembly, our platform, and Spin!

(one of the Spin authors here.)

This is not shifting the security responsibility from the firewall entirely — it's just an additional guard rail to ensure only allowed domains can be accessed. It does not mean setting proper firewall rules is no longer a concern, but just continuing WebAssembly's "deny by default" stance on accessing anything outside the sandbox.

We have not explored exactly how large scale apps will look like with Spin and WebAssembly — our initial target, at least in the beginning, is making sure building and running function-as-a-service(-like) applications is a great experience.

That's a great call-out regarding configuration and templates — we do have previous experience with "config template hell" from working in Kubernetes, Helm, CNAB, and other distributed systems platforms, so hopefully we can try to make things better!

(one of the Spin authors here.)

I'm not all that familiar with the Java ecosystem, but I seem to recall the CheerpJ people having examples for running Swing applications in the browser. (I don't know much about how their solution works, or whether it's open source.)

https://cheerpjdemos.leaningtech.com/SwingDemo.html

(one of the Spin authors here.)

This is so cool! The Spin documentation website (https://spin.fermyon.dev) is also served by Spin itself, running on a Nomad cluster, with the same blogging engine mentioned here.

We're really looking forward to improving the rolling deployments, but it's really great seeing something like this live!

(one of the authors of Spin here, and a WebAssembly enthusiast.)

There are, of course, a lot of similarities between the Java or .NET runtimes and WebAssembly, and other comments made excellent points about the lower level nature of Wasm, or the isolation sandbox.

I would also point out that there are significantly more languages that either have support for compiling to WebAssembly today, or that have started adding support (in the last month alone there were initial announcements for Python, Ruby, and .NET, for example).

(one of the authors of Spin here.)

Your intuition is mostly correct. Before anything, I strongly suggest you read this article on server-side WebAssembly — https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...

In short, when compiling to Wasm, you are building a binary that is agnostic of the operating system and CPU architecture it is going to run on, so it can be executed in lots of very different places (microcontrollers, Raspbery Pis, in the cloud). You can also use several VERY different programming languages, and interoperate between them (write a component in Rust, import it in a new component in JavaScript, and use those two from C# — this is an example for how the component model will (hopefully soon) enable cross-langauge interop in WebAssembly).

Among other benefits, the compact binary format (which makes it easy to distribute modules), the isolation sandbox, common compilation target.

Hope this is helpful!

(one of the authors of Spin here.)

I think this is an excellent point — while we do try to give acknowledgement to the previous technology that paved the way for what we are doing (there are a few articles that treat microservices, containers, serverless https://fermyon.com/blog/index), I agree that we could do a better job at talking about programming languages and language runtimes.

Thanks for the suggestion!

Thanks for your comment! (one of the authors of Spin here, working at Fermyon.)

You are correct, a lot of our team worked in the DeisLabs R&D team at Microsoft before joining Fermyon!

(one of the authors of Spin here.)

WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/):

- the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/...

- the "cold" startup time — https://fermyon.github.io/spin-benchmarks/criterion/reports/...

Another disclaimer is that we have not focused on optimization work at all, so we expect to make significant improvements over the next few months.

Hi, and thanks for your comment! (one of the authors of Spin here.)

First, both Spin and the component model are in their early stages, but there are a few things I'd mention here:

- as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/)

- we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment.

- all "platform features" we want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165)

- we are closely following the tooling in the component model (https://github.com/bytecodealliance/wit-bindgen/pull/183) and will add support for natively executing actual components once that is available upstream.

Hope this is helpful!

Hi! (one of the authors of Spin here) Interesting to hear your thoughts on this, why do you think that?

We believe that the things that make WebAssembly attractive in the browser (compact binary, near-native speed, the sandbox isolation model) make it really compelling outside the browser, on the server.

Hi! (one of the authors of Spin here.)

As you can assume, we are just as excited about all the places where we can run WebAssembly! That's a pretty intriguing idea, looking forward to seeing it evolve!

Microservices are serving us well in many ways. But in some ways, we can do better. Having learned a bit from Functions as a Service, containers, and now WebAssembly, we can rethink some of our assumptions and perhaps devise a better way for creating microservices.

By default, a WebAssembly module has no access to any host APIs — particularized for the web platform, a running module will have no way of accessing the DOM by default.

When instantiating a module, it can use module imports [1], which can be used to access the DOM through JavaScript calls.

[1] https://webassembly.github.io/spec/core/syntax/modules.html#...

This is an excellent collection of SOM/COM resources, thanks a lot for that!

Perhaps not surprising, but COM/DCOM has been a recurring reference when talking about the WebAssembly component model. Another useful resource from the past that influenced quite a few Wasm component discussions (h/t to Luke Wagner for sharing it) is one about Knit [1], which as intended as a _component definition and linking language_ for C.

[1] https://www.cs.utah.edu/flux/papers/knit-osdi00/

I think that is a really valid observation, and I would like to point out a couple of things:

- the WIT language decisions will end up impacting people writing WIT syntax by hand. I am not sure how large that audience is right now (and I am not dismissing the initial comment), but I really hope we could get good enough tooling that could directly generate WIT (in its eventual binary format) based on annotated source code.

- an equally valid observation here is that we need people from multiple programming languages looking at generating _idiomatic bindings_ based on the WIT format, which is what end users will interact with when using components. (Currently there are binding generators for Rust and C/C++, with hopefully Grain following soon enough.)

Hi, author of the article here. Happy to have a discussion about the WebAssembly component model and current implementations.

Hi, one of the maintainers here. We don’t have a WebSockets implementation for WASI yet (the WebAssembly System Interface), and in fact, WASI doesn’t have a networking implementation at all yet.

This is why we have been experimenting with the outbound HTTP implementation [1], which is available in WAGI. In theory, you could take the same approach as here, with the difference that a WebSockets connection is persistent and long-running.

[1] https://github.com/deislabs/wasi-experimental-http

Hi, one of the maintainers here. It does support outbound HTTP, the runtime we are currently using enables that -- see https://github.com/deislabs/wagi/blob/main/docs/writing_modu...

Good point on the docs, I will open an issue and add some information about it, thanks!