spin-trigger-mqtt VS containerd-shim-spin

The MQTT trigger is a feature of the Spin framework that allows a Spin application to subscribe to a specific MQTT address. Individual components within that application can then be configured to monitor particular topics at the address. When messages are detected on these topics, the corresponding component functions are triggered.

Let’s start by looking at the implementation of our first component, which is triggered by messages published to an MQTT topic and persists the data in a SQLite database. It is implemented in Rust and was scaffolded using the MQTT template. In the Spin application manifest (spin.toml), we are using a Spin application variable to dynamically configure the address for the MQTT broker. This will enable us to set Spin to connect to a broker at "mqtt://localhost:1883" when running locally and at "mqtt://emqx.default.svc.cluster.local:1883" when running in SpinKube. We also set the keep alive interval (secs) for connections with the broker and username and password authentication credentials. In this example application, the broker does not require authentication, so the credentials are left empty.

With our Spin application completed, we can now deploy it to Kubernetes by configuring the cluster with SpinKube. SpinKube is an open source project that enables running Spin applications on Kubernetes alongside containers. The project consists of 4 sub-projects, the Spin Operator, the spin kube plugin, the runtime class manager, and the Spin containerd shim. The latter is what contains the Spin runtime and executes the Spin applications on your nodes. The v0.16.0 release of the shim added support for the MQTT trigger, enabling us to run our application on SpinKube! You can use one of SpinKube’s installation guides to install SpinKube on your distribution of Kubernetes.

containerd-shim-spin

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!

Containerd Shim Spin - the containerd shim implementation for Spin