[Sandbox] Spin #116
Comments
|
@michelleN can you confirm if we can close out #90 for SpinKube? (and that will be part of this proposal itself?) |
|
@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. |
|
Related to #90 will be considered together. |
|
FYI. WASM WG wrote a doc with an assessment and recommendation here (In collaboration with TAG-Runtime) |
|
TAG Contributor Strategy has reviewed this project and found the following:
|
|
It would be good to have some information under Business Product or Service to Project separation; last I checked Spin was the foundation of Fermyon's products, and it would be good to know how you're going to handle having it belong to a foundation, operationally. If you're already maintaining rigorous upstream/downstream separation, then that field is the place to explain that. Thanks! |
|
Hey, @jberkus, great question! At Fermyon we do not use the Spin project internally directly as part of Fermyon’s products; it is part of the workflow developers use to build their applications, but the internal runtime we use in production (LHC) is an entirely separate project — it takes a dependency on a set of Spin libraries, but it has entirely separate build and release pipelines, set of maintainers, and more importantly, goals. We have always believed Spin belongs in a neutral organization, and we have planned for and built a clear upstream/downstream relationship between Spin and internal Fermyon products. And we have held this view consistently from the very beginning of the company and of the Spin project — with a clear pledge to always keep Spin open source (the second commit to the project introduces the Apache 2 license), re-affirmed the goal to have Spin as a multi-stakeholder project, an improvement proposal process for evolving the project, and talked about the separation in what we do open source (Spin), and what we don’t (our internal high-density executor, LHC) — here is a blog post from 2023 that articulates this and talks specifically about Spin and our internal systems. Thanks again for the question — I hope this answers, and I'm happy to go into details about any area of the project. |
|
Please note of the updated recommendation and assessment doc from the WASM WG here: #116 (comment) Thank you. |
|
/vote This will cover both spin and spinkube |
Vote created@mrbobbytables has called for a vote on The members of the following teams have binding votes:
Non-binding votes are also appreciated as a sign of support! How to voteYou can cast your vote by reacting to
Please note that voting for multiple options is not allowed and those votes won't be counted. The vote will be open for |
|
/check-vote |
Vote statusSo far Summary
Binding votes (6)
|
| User | Vote | Timestamp |
|---|---|---|
| 0xE282B0 | In favor | 2025-01-14 16:37:03.0 +00:00:00 |
| rajatjindal | In favor | 2025-01-14 16:44:36.0 +00:00:00 |
| radu-matei | In favor | 2025-01-14 16:54:14.0 +00:00:00 |
| squillace | In favor | 2025-01-14 17:02:03.0 +00:00:00 |
| jprendes | In favor | 2025-01-14 17:03:18.0 +00:00:00 |
| fibonacci1729 | In favor | 2025-01-14 17:17:46.0 +00:00:00 |
| michelleN | In favor | 2025-01-14 17:21:50.0 +00:00:00 |
| technosophos | In favor | 2025-01-14 17:25:21.0 +00:00:00 |
| bacongobbler | In favor | 2025-01-14 17:32:01.0 +00:00:00 |
| cpuguy83 | In favor | 2025-01-14 17:34:31.0 +00:00:00 |
| tschneidereit | In favor | 2025-01-14 17:37:20.0 +00:00:00 |
| jsturtevant | In favor | 2025-01-14 17:58:38.0 +00:00:00 |
| Mossaka | In favor | 2025-01-14 17:59:21.0 +00:00:00 |
| calebschoepp | In favor | 2025-01-14 18:06:29.0 +00:00:00 |
| kate-goldenring | In favor | 2025-01-14 18:30:01.0 +00:00:00 |
| mattfarina | In favor | 2025-01-14 18:35:54.0 +00:00:00 |
| mikkelhegn | In favor | 2025-01-14 19:46:24.0 +00:00:00 |
| devigned | In favor | 2025-01-14 20:25:30.0 +00:00:00 |
| bridgetkromhout | In favor | 2025-01-14 20:25:56.0 +00:00:00 |
| simongdavies | In favor | 2025-01-14 20:27:32.0 +00:00:00 |
| jonititan | In favor | 2025-01-14 20:52:46.0 +00:00:00 |
| everpeace | In favor | 2025-01-15 0:54:36.0 +00:00:00 |
| benbrandt | In favor | 2025-01-15 5:18:59.0 +00:00:00 |
| KaiWalter | In favor | 2025-01-15 6:54:31.0 +00:00:00 |
| fabistb | In favor | 2025-01-15 7:52:50.0 +00:00:00 |
| iapicca | In favor | 2025-01-15 12:28:43.0 +00:00:00 |
| vdice | In favor | 2025-01-15 14:58:57.0 +00:00:00 |
| flavio | In favor | 2025-01-15 15:10:40.0 +00:00:00 |
|
/check-vote |
|
Votes can only be checked once a day. |
Vote closedThe vote passed! 🎉
Summary
Binding votes (9)
|
| User | Vote | Timestamp |
|---|---|---|
| @0xE282B0 | In favor | 2025-01-14 16:37:03.0 +00:00:00 |
| @rajatjindal | In favor | 2025-01-14 16:44:36.0 +00:00:00 |
| @radu-matei | In favor | 2025-01-14 16:54:14.0 +00:00:00 |
| @squillace | In favor | 2025-01-14 17:02:03.0 +00:00:00 |
| @jprendes | In favor | 2025-01-14 17:03:18.0 +00:00:00 |
| @fibonacci1729 | In favor | 2025-01-14 17:17:46.0 +00:00:00 |
| @michelleN | In favor | 2025-01-14 17:21:50.0 +00:00:00 |
| @technosophos | In favor | 2025-01-14 17:25:21.0 +00:00:00 |
| @bacongobbler | In favor | 2025-01-14 17:32:01.0 +00:00:00 |
| @cpuguy83 | In favor | 2025-01-14 17:34:31.0 +00:00:00 |
| @tschneidereit | In favor | 2025-01-14 17:37:20.0 +00:00:00 |
| @jsturtevant | In favor | 2025-01-14 17:58:38.0 +00:00:00 |
| @Mossaka | In favor | 2025-01-14 17:59:21.0 +00:00:00 |
| @calebschoepp | In favor | 2025-01-14 18:06:29.0 +00:00:00 |
| @kate-goldenring | In favor | 2025-01-14 18:30:01.0 +00:00:00 |
| @mattfarina | In favor | 2025-01-14 18:35:54.0 +00:00:00 |
| @mikkelhegn | In favor | 2025-01-14 19:46:24.0 +00:00:00 |
| @devigned | In favor | 2025-01-14 20:25:30.0 +00:00:00 |
| @bridgetkromhout | In favor | 2025-01-14 20:25:56.0 +00:00:00 |
| @simongdavies | In favor | 2025-01-14 20:27:32.0 +00:00:00 |
| @jonititan | In favor | 2025-01-14 20:52:46.0 +00:00:00 |
| @everpeace | In favor | 2025-01-15 0:54:36.0 +00:00:00 |
| @benbrandt | In favor | 2025-01-15 5:18:59.0 +00:00:00 |
| @KaiWalter | In favor | 2025-01-15 6:54:31.0 +00:00:00 |
| @fabistb | In favor | 2025-01-15 7:52:50.0 +00:00:00 |
| @iapicca | In favor | 2025-01-15 12:28:43.0 +00:00:00 |
| @vdice | In favor | 2025-01-15 14:58:57.0 +00:00:00 |
| @flavio | In favor | 2025-01-15 15:10:40.0 +00:00:00 |
| @raravena80 | In favor | 2025-01-15 16:49:26.0 +00:00:00 |
| @adamreese | In favor | 2025-01-15 16:53:35.0 +00:00:00 |
| @VamshiReddy02 | In favor | 2025-01-15 18:44:42.0 +00:00:00 |
| @ThorstenHans | In favor | 2025-01-16 8:37:26.0 +00:00:00 |
|
/vote |
|
Only repository collaborators can create a vote @bplasmeijer. For organization-owned repositories, the list of collaborators includes outside collaborators, organization members that are direct collaborators, organization members with access through team memberships, organization members with access through default organization permissions, and organization owners. |
|
This is great! Dear @mrbobbytables given that the vote passed AND that the vote was for (per this comment) both for spin and spinkube to be brought together in Sandbox, I'm now looking for the onboarding issues! Mind you, that was just last week -- but we're excited! Thank you all in advance. :-) |
|
It was on my TODO for today to create the onboarding issues :) Sooo with that I've created #330 for following up on sandbox onboarding. I'll go ahead and close this out and further follow up can occur there :) |
github-project-automation
bot
moved this from 🤔 In voting
to ✅ Done
in Sandbox Application Board
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:
Plugins:
Triggers:
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
Trademark and accounts
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
runwasihowever.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
The text was updated successfully, but these errors were encountered: