-
Notifications
You must be signed in to change notification settings - Fork 15
Roadmap to the 1.0 MVP
waSCC 1.0 provides a lightweight, secure, distributed actor model framework that dramatically reduces boilerplate and aims to facilitate a napkin to production development and operations model. waSCC hosts automatically form self-healing clusters called lattice
s, which enable cluster formation to seamlessly span on-premise, edge, cloud, and IoT environments.
These lattices can be treated as a single, flat topology regardless of the number of underlying disparate infrastructures on which they are deployed. Through a lattice-based control plane, developers and operations personnel can manage declarative deployments. The lattice will respond to such deployments by scheduling actors and capability providers, retrieving their images from a Gantry repository, verifying their embedded security claims, and managing their configuration bindings.
waSCC hosts support hundreds of actors--each of which often compile down to less than 1MB in size--allowing for compute density and utilization ratios previously thought impossible in purely container-based solutions. The waSCC host runtime is available with multiple underlying WebAssembly engines (supporting JIT, interpreted, and resource-constrained environments). The main host process as well as the wcc
CLI (a single tool for managing signing keys, signing WebAssembly modules, interacting with a lattice
, and interacting with Gantry repositories) are available for installation on all major operating systems and architectures as single-line installations from major package managers like apt
, snap
, brew
, nix
and installation sources for Windows. waSCC host will even be available for automatic installation on specialized linux versions like Raspbian
and OpenWRT
.
waSCC aspires to the simplicity and ease of use of nomad while liberating developers with the power and flexibility of the actor model and the speed and portability of WebAssembly, changing the way distributed applications are built. waSCC is equally well suited to FaaS (Functions as a Service) and Microservices, and can support everything from the smallest hobby projects to the largest enterprise solutions.
The ability to support declarative deployments is one of the defining key features of the 1.0 MVP. The following is a rough, very high-level list of the things that need to be accomplished for this epic:
- Decide on a format for a deployment bill of materials / manifest.
- Create a provider archive format that can be signed w/embedded manifest (to be deprecated once we can build WASI-based capability providers)
- Support this provider archive format so Gantry can store/retrieve native capability provider plugins (OS-/arch- specific shared objects)
- Support imperatives in lattice control plane for scheduling capability providers
- Implement the vinculum, an agent that compares desired state with observed state and issues control plane instructions to close the gap
In order for waSCC to be suitable for use for mainstream projects from hobbies to the enterprise, we will need more capability providers, including:
- Relational Database Capability Contract
- PostgreSQL implementation
- mySQL implementation
In order for waSCC to work in large, potentially multi-tenant environments, it needs special features and functionality to ensure it can run in regulated environments.
- Support host labels which can be used for affinity/anti-affinity behavior for actor scheduling
- Support host labels for affinity/anti-affinity behavior for capability provider scheduling
- Support a real-time block list of actors and providers that can be used in case of intrusion, malicious, or potentially dangerous behavior
- Build an authorizer plugin that allows for additional constraints during authorization to be supplied by Open Policy Agent. Potentially evaluate the use of OPA's ability to compile policies into
wasm
, which we might be able to store in Gantry for application to a lattice - Support the monitoring, storing, and exposure of "actor time" usage, which can be used for multi-tenant environments or in enterprise environments that require "charge back" functionality
waSCC needs to be extremely fast, lightweight, and support massive scale. It also needs to be able to operate in resource-constrained environments like edge and IoT devices and maximize compute density in the cloud.
- Re-evaluate the use of OS threads versus async code to maximize the number of actors we can support per host, keep the code base clean, and potentially speed up call processing.
- Re-evaluate the use of scatter-gather queries to obtain information about a lattice. The larger a lattice and the more infrastructure boundaries are crossed, the longer these queries will take, and the more likely a vinculum process will have incorrect information and make mistakes in attempting to resolve state gaps. Possibilities here include gossip protocols or distributed caches in lieu of the ad hoc queries.
The following would be nice to have, but are not on the critical path to reaching 1.0:
- Lightweight web console for observing and managing a lattice
- OpenFaaS Gateway Capability provider - allow alias tags on registered/bound actors to expose function calls through an OpenFaas gateway. This would have the net effect of being able to use simple OpenFaas REST calls to invoke actors in a lattice.
- Additional event/streaming capability providers:
- Apache Kafka
- NATS Streaming (aka STAN)