[Sandbox] Spin

[michelleN]

Application contact emails

[email protected], [email protected]

Project Summary

Spin is an open source framework for building and running fast, secure, and composable cloud microservices with WebAssembly

Project Description

Spin is an open-source framework designed to facilitate the development and deployment of event-driven, serverless applications using WebAssembly (Wasm). Spin provides a lightweight runtime environment for running fast and secure applications. Spin supports multiple programming languages including Rust, Go and others, allowing developers to use their preferred languages while targeting WebAssembly as the execution environment.

WebAssembly provides some key benefits over container based environments including better portability, significantly faster cold-start times, smaller size, minimal overhead, secure sandboxing and strict deny-all by default security model. These characteristics enable a broader range of use cases to benefit from cloud native environments and using existing infrastructure and resources in a more cost-effective and efficient manner.

Spin builds on the foundational capabilities of WebAssembly by adding necessary infrastructure, tools, and features for modern application development especially in a cloud-native context and reduces the complexity associated with using pure WebAssembly. It enables developers to utilize the most recent advancements and standards from the WebAssembly community while aiming to provide an intuitive developer experience.

Org repo URL (provide if all repos under the org are in scope of the application)

N/A

Project repo URL in scope of application

https://github.com/fermyon/spin

Additional repos in scope of the application

• SDKs:

  • Spin Python SDK
  • Spin JavaScript SDK
  • Spin Rust SDK
  • Spin .NET SDK
  • Spin Nim SDK

• Plugins:

  • Spin Plugins Index Repository
  • Fermyon Platform Plugin
  • Spin Test Plugin

• Triggers:

  • Spin Command Trigger
  • Spin SQS Trigger
  • Spin Cron Trigger

Website URL

https://www.fermyon.com/spin

Roadmap

https://github.com/fermyon/spin/blob/main/ROADMAP.md

Roadmap context

No response

Contributing Guide

https://github.com/fermyon/spin/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/fermyon/spin/blob/main/CODE_OF_CONDUCT.md

Adopters

Microsoft, Docker, SUSE, NGINX, ZEISS

Contributing or Sponsoring Org

Fermyon Technologies

Maintainers file

https://github.com/fermyon/spin/blob/main/MAINTAINERS.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

The original interest in WebAssembly and the need for Spin was born out of problems and constraints the Fermyon team ran into while working with containers in cloud native environments. After years of contributing to the WebAssembly community, iterating on the Spin project and getting feedback from both end users and vendors, we’re excited to see the optimism for and practical use of WebAssembly with Spin in Kubernetes and cloud native environments. The Spin project has a reached a point where there is adoption, interest, and excitement from end users and vendors, and the Spin community is looking for a neutral home for multi-stakeholder collaboration and governance. We strongly believe in building a a collaborative, sustainable, and diverse community and think the CNCF will provide the perfect home to do just that. We hope that by being part of the CNCF, we also encourage further integration with CNCF and cloud native projects and contribute our learnings and perspectives to the WebAssembly community.

Benefit to the Landscape

Spin brings the benefits of Wasm to the Kubernetes and cloud native community. It allows end-users to have a solution when they run into limitations with containers or scenarios where WebAssembly provides obvious benefits. It also unlocks use cases where the characteristics of Wasm enable experiences that were not possible or not reliable previously. It ultimately helps end users more efficiently use resources while providing developers with a consistent, polyglot developer experience for building event-driven, serverless applications.

Cloud Native 'Fit'

Landscape: Serverless
TAGs: TAG Runtime + TAG App Delivery

Spin operates as both a runtime and a developer experience. As a runtime, it aims to be an opinionated embedding of the Wasmtime runtime that provides support for things like observability and lifecycle management. The current Spin Factors refactor will allow for the Spin runtime to be extensible and for capabilities to be customized based on host environment. TAG Runtime’s objective is “to enable widespread and successful execution of the full spectrum of workload types”. This aligns nicely with what Spin is doing with Wasm workloads and the SpinKube project and we think it’d be a natural fit here. Spin would benefit from the learnings from this group and be able to contribute to the conversation around making executing WebAssembly workloads a more cloud native experience.

There is also some overlap with TAG App Delivery as Spin also focuses on building, packaging, deploying and running applications in cloud-native and serverless environments aligning it with the goals of TAG App Delivery. Spin’s primary distribution mechanism for Wasm artifacts are OCI Artifacts, which ties into the work of wg-artifacts. WebAssembly presents unique opportunities to build more resilient, secure, scalable, and impactful applications, thereby enhancing the robustness and power of cloud native computing environments. As the use of Wasm in the cloud-native space matures and grows, new patterns around deployment and what to expect when running an application will also emerge. It would be great to ensure those patterns are represented in current cloud native tooling under TAG App Delivery working through the TAG and ensure Spin is integrating with more existing cloud native tools.

Cloud Native 'Integration'

Spin unites WebAssembly and cloud native environments in a way that is familiar to the cloud native community and takes advantages of cloud native best practices. Spin has a seamless integration point with Kubernetes via SpinKube which is a set of projects that enable Spin applications to run as Pods in Kubernetes so that end users can take advantage of the benefits of Spin and WebAssembly without having to overhaul their current environment. Spin applications are packaged as OCI artifacts. Spin applications also seamlessly integrate with existing services meshes, O11y setups via Open Telemetry integration, CI/CD pipelines, and scaling solutions.

Cloud Native Overlap

The WasmEdge, wasmCloud, knative and krustlet projects in the CNCF ecosystem have some overlapping objectives with Spin. WasmEdge, Spin, and wasmCloud each use a different Wasm runtime and have different developer experiences for building applications. And although they each have some level of support for running their applications on Kubernetes.

According to the wasmCloud documentation, "wasmCloud is compatible with, but not dependent on, Kubernetes". With wasmCloud, Pods in a cluster are the wasmCloud "hosts" and contain N Wasm applications.

On the other hand, with Spin via the containerd-shim-spin and containerd/runwasi projects, there is a 1:1 relationship between Pods and Wasm applications. Since all Wasm apps are represented as Pods, you can easily use existing tooling such as Cilium, Istio, HPA, KEDA, and Dapr.

WasmEdge is a runtime for embedded functions, microservices, udf, smart contracts, and IoT devices. The WasmEdge Runtime is excellent for packaging inside your software, but is more akin to Wasmtime (the runtime used by Spin) than it is to Spin itself. Spin is hyper-focused on event driven serverless applications (that respond to events from HTTP requests/Queue messages/...) and also focused on the development and deployment experience.

Spin fits in a similar domain as serverless projects in the Cloud Native ecosystem. Like Knative, Spin is targeted at engineers who build serverless applications and want a Kubernetes native experience. The defining distinction is that Spin applications are Wasm applications, giving them a greater level of isolation (as every request is fully isolated), fast start-up times, and simplified management of system dependencies.

Krustlet is another project in the CNCF space that runs Wasm on Kubernetes; however, it is no longer maintained - the team that developed it did go on to develop runwasi however.

Similar projects

Knative, wasmCloud, wasmEdge, krustlet

Landscape

Not yet

Business Product or Service to Project separation

N/A

Project presentations

Not yet

Project champions

David Justice (Microsoft) - Wasm-wg co-chair

Additional information

No response

[dims]

@michelleN can you confirm if we can close out #90 for SpinKube? (and that will be part of this proposal itself?)

[endocrimes]

@dims The projects should ideally remain separate as they have very different goals (great developer tool and core runtime vs great at doing all the deployment-distributed-bits)

Spin has a lot of users who will never touch a kubernetes cluster, and keeping them separate is "nice" for ensuring that those folks take an equal weight to those who deploy to Kubernetes and related places.

[TheFoxAtWork]

Related to #90 will be considered together.