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.
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.
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!
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.
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.
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.