Spinkube: Running WASM in Kubernetes
fermyon.com
fermyon.com
Ae you saying this is bigger than AIs that are so smart that they can do software development?
There's been huge huge strides in low-profile elegant serverless platforms built around v8 isolates. We can get all those wins and more - in an way more scaled out more multi-tenant way - with wasm. If it lives up to it's aspirations, which it seems on target to do.
Luke Wagner's WasmCon talk iterated through the core attributes of what makes wasm wasm and what those attributes unlock. The ability to host much much much more with a muchower profile, with extremely short-lived sandboxed runtimes, is incredibly enticing. The app-server model could finally be disrupted.
I have no patience for "bigger than AI" apples to oranges comparisons. Wasm is orthogonal, has it's own features & distinctions. The direct run off comparison shirks both of their value.
Eh, fair. At the time I thought it was actually a fairly reasonably and pithy way to compare an hype-inflated technology that is being mindlessly applied to every possible target (while also, I concede, being thoughtfully, practically, and usefully applied in some cases, too), to an under-hyped and (AFAICT) almost unheard-of technology which seems on-track to provide an unshowy-but-significant optimization to basically any web technology ever, everywhere - but you're right that they are, indeed, trying to do different things, and comparing their impact is somewhat reductive. WASM is certainly not better than AI at the things that AI is trying to do.
* Far better isolation than a normal Linux container
* If WASM takes off, maybe architecture-independent artifact distribution
* If WASM takes off, maybe improved ability to call from one language into another
As a Kubernetes container runtime WASM today is probably most comparable to gVisor, with the somewhat huge caveat that it prevents you from just running normal Linux software.Have you never had to deal with java and .net installs across various platforms? It's a mess.
There are tons of languages that target CLR and JVM bytecode to chose from, CLR was even designed with C and C++ into acocunt.
Have you never had to deal with java and .net installs across various platforms? It's a mess.
There are tons of languages that target CLR and JVM bytecode to chose from, CLR was even designed with C and C++ into acocunt.
Is there any specific language or framework I could learn to stay competitive?
I haven't played with it enough to know which one provide the best experience at the moment, so I'd be interested to hear suggestions from others who have used it more extensively, especially with newer parts of the ecosystem like the component model, interface types, WASI, and generating ergonomic bindings to other languages (e.g. JS <> WASM)
Example, the WASM GC design doesn't support all use cases of .NET GC with interior pointers.
There is really no reason to use this instead of packaging higher level languages with garbage collectors into a regular Kubernetes container.
edit: Seems to be this: https://developer.fermyon.com/spin/v2/index
Great talk, highly recommend watching it on YouTube if you're into this kind of thing. No link but I imagine it'll be up pretty soon.
Why is this so?
https://www.spinkube.dev/blog/2024/03/13/introducing-spinkub... is a really good blog post on Spin that talks about this.
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.
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.
Thanks!
Progress is wonderfull! /s