Announcing Spin 2.4
Kate Goldenring
spin
webassembly
wasi
component model
release
wasmtime
Today we’re happy to announce the release of Spin 2.4, which includes several enhancements to Spin:
- Spin now supports application-internal service chaining, removing the overhead of network requests when making requests to other components of the same application
- Apps can emit traces with experimental support for OpenTelemetry (OTEL) observability
- The Spin Redis trigger can listen to events from multiple Redis servers
- Spin now supports an experimental MQTT interface, which allows you to publish messages from your Spin application using MQTT protocol
Let’s dive into a couple of these new features.
Installing Spin
If you haven’t already, please go ahead and install Spin.
Upgrading Spin: If you already have Spin installed, please see the Spin upgrade page in the developer documentation.
First-Class Support for Application-Internal Service Chaining
Spin applications have always been able to make requests to other components in the same application (“self-requests”). This effectively makes Spin applications a set of connected microservices. In Spin 2.2, we streamlined this by adding support for sending self-requests by route, avoiding the need to specify a hostname, port, or protocol. With Spin 2.4, we’re introducing support for application-internal service chaining. Now, if you opt-in, applications will enforce that requests between components within the application are handled in the same process. This removes some key sources of complexity for distributed applications, namely infrastructure-induced partial failures and unpredictable latency.
What Spin 2.4 adds is the ability to ensure - at deploy time - that the runtime environment will handle these self-requests internally, turning it into something that the developer can rely on as part of the application’s architecture. This means that developers can benefit from microservice patterns, language flexibility, and smaller components without accidentally building a distributed application and all of the complexity that comes with it.
Application-internal service chaining is guaranteed for requests that make use of the special <component-id>.spin.internal hostname. For example, to ensure that a request from component-a to component-b is handled internally, the request must use the hostname component-b.spin.internal. And to enable this request, as well as explicitly opt in to this behavior, component-a’s allowed_outbound_hosts field must include that hostname.
You can learn more about the feature in the Spin HTTP requests documentation. To dive into the implementation, see the Spin Improvement Proposal introducing it.
Experimental Support for OpenTelemetry Observability
Spin now has experimental support for the OpenTelemetry (OTEL) observability standard. When configured, Spin will now emit traces of your Spin App as an OTEL signal. Here is a teaser of how to configure it.
First, run an OTEL compliant collector to collect the traces. Jaeger is an open source distributed tracing platform that can act as an OTEL collector and enables viewing taces. You can run Jaeger using Docker:
docker run -d -p16686:16686 -p4317:4317 -p4318:4318 -e COLLECTOR_OTLP_ENABLED=true jaegertracing/all-in-one:latest
Now, you can start your Spin app, setting the endpoint of the OTEL collector in the OTEL_EXPORTER_OTLP_ENDPOINT environment variable:
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 spin up
After sending some requests to your Spin app, navigate to Jaeger (http://localhost:16686) to view the traces.
Spin supports both inbound and outbound trace context propagation. This allows you to include Spin in your distributed traces that span all your services.
This observability support in Spin is still experimental. Only the HTTP trigger, the LLM host component, and outbound HTTP requests are instrumented at this time. Going forward we will be adding tracing to the remainder of Spin triggers and host components. We also hope to add support for the OTEL metrics signal in the future. Try it out, let us know what you think and help us improve the observability experience in Spin!
Experimental Support for Outbound MQTT Messaging
As of v2.4.2, Spin supports an experimental interface for you to publish messages using the MQTT protocol. This is a common protocol used for machine-to-machine communications, typically in resource-constrained devices. With this experimental interface, you can use Spin applications to establish a connection with an MQTT server and publish a payload for a specific topic. Let’s take a look at what this might look like in practice.
First grant your Spin application access to make network calls to the particular host for your desired MQTT server by specifying the host and allowed port:
[component.uses-mqtt]
allowed_outbound_hosts = ["mqtt://messaging.example.com:1883"]
From within your application’s source code, you can then establish a connection:
let connection = spin_sdk::mqtt::Connection::open(&address, &username, &password, keep_alive_secs)?;
And then implement your business logic to publish the appropriate payload to your host as an outbound MQTT message:
let cat_picture: Vec<u8> = request.body().to_vec();
connection.publish("pets", &cat_picture, spin_sdk::mqtt::Qos::AtLeastOnce)?;
For a more detailed review, please visit the Spin SDK reference documentation, or get started with this Rust code example on GitHub.
Thank You!
We would like to thank the over 75 contributors to the Spin project and especially our new contributor @thesuhas. We hope to see you again in the commit history soon! Thank you to everyone in our growing community. Every comment, issue, and pull request helps us to make Spin better!
A special mention goes out to the maintainers of the Bytecode Alliance projects, particularly the Wasmtime project and the developers working on WASI and the WebAssembly component model. Their work is instrumental in supporting Spin.
Stay In Touch
If you are interested in Spin, Fermyon Cloud, or other Fermyon projects, join the chat in the Fermyon Discord server and follow us on X (formerly Twitter) @fermyontech and @spinframework!
If you want to get involved in the Spin project, join us at our Spin Community Developers Meeting on the fourth Monday of every month at 11 a.m. Eastern US Time (5 p.m. Berlin Time). Our next one is on April 22. You can watch recordings of the previous meetings on our YouTube Channel.