distribution-spec
spin
Our great sponsors
distribution-spec | spin | |
---|---|---|
54 | 22 | |
719 | 4,697 | |
3.3% | 3.9% | |
7.8 | 9.9 | |
9 days ago | 6 days ago | |
Go | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
distribution-spec
-
The transitory nature of MLOps: Advocating for DevOps/MLOps coalescence
Back in 2013, a little company called Docker made it really easy to start using containers to package up applications. A big key to their success was the OCI (you can learn about that here), an industry wide initiative to have standards around how we package up our applications. Because of OCI standards, we have hundreds (maybe thousands?) of tools that can be combined to manage and deploy applications. So why aren’t we using this for packaging up Notebooks and AI models as well? It would make deploying, sharing, and managing our models easier for everyone involved.
-
The Road To Kubernetes: How Older Technologies Add Up
Kubernetes on the backend used to utilize docker for much of its container runtime solutions. One of the modular features of Kubernetes is the ability to utilize a Container Runtime Interface or CRI. The problem was that Docker didn't really meet the spec properly and they had to maintain a shim to translate properly. Instead users could utilize the popular containerd or cri-o runtimes. These follow the Open Container Initiative or OCI's guidelines on container formats.
-
Coexistence of containers and Helm charts - OCI based registries
OCI stands for Open Container Initiative, and its goal as an organization is to define a specification for container formats and runtime.
-
Bazzite – a Steam0S-like OCI image for desktop, living room, and handheld PCs
https://opencontainers.org/
Here is Containerfile from the repo: https://github.com/ublue-os/bazzite/blob/main/Containerfile
-
Distroless images using melange and apko
apko allows us to build OCI container images from .apk packages.
- OCI image from dockerfile
- Fat OCI images are a cultural problem
-
Progressive Delivery on AKS: A Step-by-Step Guide using Flagger with Istio and FluxCD
Flagger's load testing service can be installed via a Kustomization resource based on manifests packaged as an artifact in an Open Container Initiative (OCI) registry
-
Creating Kubernetes Cluster With CRI-O
CRI-O is a lightweight container runtime for Kubernetes. It is an implementation of Kubernetes CRI to use Open Container Initiative (OCI) compatible runtimes for running pods. It supports runc and Kata Containers as the container runtimes, but any OCI-compatible runtime can be integrated.
-
What is the current status of Docker and how far is it from getting ported?
So somebody else created runj (runj is an experimental, proof-of-concept OCI-compatible runtime for FreeBSD jails.) https://github.com/samuelkarp/runj
spin
-
4 Ways to Participate in Advent of Spin - A Wasm Coding Challenge
We built (and open-sourced) Spin to make the developer experience easier, and we want to show you this through Fermyon's Advent of Spin. You will be presented with fun coding challenges that'll help you learn to build with Spin and WebAssembly.
-
Flawless – Durable execution engine for Rust
linky: https://github.com/fermyon/spin#readme (Apache 2; and while I don't see any CLA, interestingly they do require GPG signed commits: https://developer.fermyon.com/spin/contributing-spin#committ... )
-
Spin 1.0 — The Developer Tool for Serverless WebAssembly
We are delighted to introduce Spin 1.0, the first stable release of the open source developer tool for building serverless applications with WebAssembly (Wasm)! Since we first introduced Spin last year, we have been hard at work together with the community on building a frictionless developer experience for building and running serverless applications with Wasm.
-
Waggy v0.3 Released!!
“Waggy is used for writing WAGI (WebAssembly Gateway Interface) compliant API routers/individual handlers. WAGI was developed by deislabs for accepting and routing incoming HTTP requests with WebAssembly via a configuration file (modules.toml) defining routes, modules, volumes to be mounted, etc. WAGI can run as a stand alone server, or with a framework such as the Fermyon/Spin framework Go SDK. Waggy allows for the flexibility of handling the routing via the modules.toml, or to define it code (Waggy is written in Go), as well as various pieces of convenient functionality such as the new features described above!!”
Waggy v0.3 is out now!! Along with some minor bug fixes, v0.3 comes with two major improvements, being the ability to configure loggers for WaggyRouters and WaggyHandlers alike, as well as a convenience wrapper for serving files as responses. One other big unplanned, but welcome improvement is the ability to use Waggy in conjunction with Fermyon’s Spin Go SDK for writing WAGI microservices that can also make outgoing HTTP calls.
-
WasmEdge
They’re VC-funded and will vendor lock-in you. See their response to my discussion:
https://github.com/fermyon/spin/discussions/861
With WasmEdge there is no vendor lock-in, it’s opaque and standards-based
-
The Missing Kubernetes Type System
Webassembly is also gaining steam for server workloads due to several advantages (less overhead, better capability based security, composability, ...).
See Spin [1], Wasmcloud [2], Lunatic [3], etc.
My system is based on a distributed Webassembly runtime.
The reason for taking inspiration from Kubernetes is making deployment of distributed workloads on that runtime easy.
A nice benefit for a Kubernetes alike system is that the equivalent to controllers can be much more light-weight WASM actors that are easier to deploy and scale.
[1] https://github.com/fermyon/spin
-
Spin – WebAssembly Framework
(one of the authors of Spin here.)
First, both Spin and the component model are in their early stages, but there are a few things I'd mention here:
- as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/)
- we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment.
- all "platform features" we want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165)
- we are closely following the tooling in the component model (https://github.com/bytecodealliance/wit-bindgen/pull/183) and will add support for natively executing actual components once that is available upstream.
Hope this is helpful!
(one of the authors of Spin here.)
WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche..., and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/):
- the response times — here are some benchmarks for requests that simulate 1 ms of work — https://fermyon.github.io/spin-benchmarks/criterion/reports/...
What are some alternatives?
wasmCloud - wasmCloud allows for simple, secure, distributed application development using WebAssembly components and capability providers.
lunatic - Lunatic is an Erlang-inspired runtime for WebAssembly
wit-bindgen - A language binding generator for WebAssembly interface types
jib - 🏗 Build container images for your Java applications.
component-model - Repository for design and specification of the Component Model
proxmox-lxc-idmapper - Proxmox unprivileged container/host uid/gid mapping syntax tool.
dive - A tool for exploring each layer in a docker image
spec - WebAssembly for Proxies (ABI specification)
appleprivacyletter - An open letter against Apple's new privacy-invasive client-side content scanning.
bartholomew - The Micro-CMS for WebAssembly and Spin
containerd - An open and reliable container runtime
runc - CLI tool for spawning and running containers according to the OCI specification