From what I've read, it seems much more complicated then it has to be. I've been running crun with wasmtime enabled since about 1 year in my private test clusters. No shim, no operator, no runtime class manager. I just have to set one extra annotation to the pod.
Only problem is that most k8s distros ship with runc. So there is no out of the box experiance yet, but it is a super efficient setup.
Your approach seems more managed/enterprise ready, but also a more complicated. I don't want to be rude, I just want to get what additional value I would get from this since there a so many small differences in the WASM runtime world and I'm not super familiar with most of them
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.
Why is anything special or unique required to run WASM on kube? A container is a container, no? Serious question. To me the benefit of kube is that the api is a container and allows for any container to run there.
With WASM, you get better isolation than a regular virtual machine, you can be more granular with scheduling and the attack surface is far smaller than a regular VM. When compared to namespaces containers, you don’t need to rely on the kernel attack surface being tight for security. And you get to intercept all syacalls ala gvisor with less complexity. The downside is interaction with specialty hardware and performance.
A container can be a VM, this provides a container with similar isolation characteristics to a VM with less complexity on the orchestrator/runc side of things.
Hey SpinKube maintainer here. You're right that you could just run your Wasm (or Spin app) directly in a container and there often are reasons you might want to do that. But, SpinKube executes WebAssembly using a containerd-shim which means we avoid the overhead of starting a container and rather just directly execute the Wasm.
The project is focused on supporting Spin. But Spin supports a large amount of the WASI API surface and is headed in the direction of using WASI in place of Spin specific APIs wherever possible.
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.
Question how did you come up with your the languages you support. Obviously how well the language compiles to Wasi is a factor, but how did you end up picking C# for instance?
Additionally how does Javascript support work? Are you embedding QuickJS?
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.
I'm impressed you're already leveraging the component model. I thought it wasn't quite ready for primetime yet, but it seems you're proving that wrong... I'll have to dig in more here, as I'm working embedding WebAssembly in a high performance storage engine.
Thanks for the notes! I hear you on QuickJS - I've seen approaches of folks trying to build more node compatibility on top of quickjs (ala https://github.com/second-state/wasmedge-quickjs), but have recently heard about spidermonkey in wasmtime. Do you have intuition for nodejs vs browser in terms of what people want in terms of compatibility?
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!
While you advertise it as portable in the introduction the install guide only mentions "Linux (amd64 and arm64), macOS (Intel and Apple Silicon), and Windows (amd64)".
What are your plans on supporting more operating systems and architectures?
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.
Hi Matei_Radu,
Is it possible for spin to support actor-model pattern for eg. can it run long running process to execute trading strategies which will accept tick data every second
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.
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!
> 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.
Yes, "shifting" was a terrible choice of words on my side, sorry about that :)W hat I meant was, it gives developers more ways to manage outbound traffic -- which is both great but I wonder how the intersection of Ops and Devs handle this going forward because these things often become contention points at organizations (remember the enterprise proxies, etc.); let's see how this all plays out, but I'm glad devs now have more ways to [express and] manage these aspects of their apps.
Web apps always had a chance to decide who to talk to.
This is trivial when they are clients of some other APIs, so about server side choices:
- domains, if reverse proxies / firewalls give them the IP of the client
- routes, by servicing the good URIs and 404 the bad ones (attacks more than honest mistakes)
- users, with many different authentication systems
- data, with validations.
The former points are traditionally more in the domain of the network infrastructure, the latter ones are for the application. I've seen all the possible combinations in the last 30 years.
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.)
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).
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.
Sure, I suppose that's one way to put it. It has a lot of real, practical benefits over the JVM though (locked down by default, small surface area, simpler, buy in from major platforms, compilation target for multiple major languages), and this feels like a dismissal you could put on anything that follows in the footsteps of something else. One could dismiss Rust as hipster C++, but that wouldn't really engage with the issues of compile-time memory safety or concurrency or ADTs. Or JSON as the hipster XML! These are all true in a sense, but it doesn't address the actual advantages and disadvantages (both of which exist for all of these examples).
