Distributed node runtime / 2024 to present
Orion
Orion explores a specific distributed-systems problem: how several edge computers can converge on the same intended software state without treating every change as an unrelated remote command.
Explore repositoryA successful network call proves delivery, not operation.
Once work spans several devices, configuration, streamed data, persistence, authorization, readiness, and provider failures need one model of what should happen and what actually happened.
I made desired state, observed state, and revision history the shared vocabulary.
The daemon, client, and CLI use the same typed mutations; reconciliation delegates concrete work to local providers; and control traffic stays separate from high-throughput data exchange.
A successful request is not the end state.
Operators declare what should be true. The runtime authorizes the mutation, persists desired state, reconciles providers, observes what actually happened, and feeds that evidence back into the next plan.
CLI · client SDK · operator
Typed requests · authentication · revision checks
Canonical mutations · snapshots · persistence
Compare intent with latest observation
Execute concrete workload or peer operations
Provider result + health + audit
- HTTP / IPC control
- TCP / QUIC data
- Common auth + protocol types
The decisions beneath the summary.
Desired state over remote commands
The control plane owns typed mutations, IDs, protocol versions, canonical revisions, persisted snapshots, and observations. A successful network response records accepted intent; the runtime still has to compare desired and observed state, plan concrete work, and report whether the node converged.
- The daemon, Rust client, and orionctl use the same public request and state contracts
- Revision checks and shared errors make stale or incompatible mutations explicit
- Providers and executors remain local boundaries for concrete workload behavior
Control and data planes
IPC and HTTP can serve local or remote control, while TCP and QUIC serve data-plane exchange. Transport adapters own listeners, codecs, TLS, and connection behavior at the edge. Authorization, desired state, revision semantics, and provider execution remain common regardless of how a request arrived.
- Feature gates let an embedded host exclude network or transport surfaces it does not need
- Local IPC provides a first-class operator path without routing through an external network
- Peer synchronization uses the same versioned state vocabulary rather than defining a second domain model
Reconcile and persistence boundaries
Persistence stores desired revisions and operational records; the reconcile layer compares them with observations and produces a plan; providers and executors perform target-specific actions. This lets alternative providers and storage choices change without teaching transport handlers how to manage workloads.
- Observations feed subsequent reconcile decisions rather than being treated as log-only output
- Fallible typed configuration rejects invalid combinations before the daemon accepts work
- Bounded persistence and audit queues make overload behavior an explicit operational choice
Operator and embedding experience
The node daemon composes authentication, transports, persistence, reconcile work, metrics, and lifecycle behavior. Health and readiness remain distinct, audit records attach to accepted mutation boundaries, structured failure classes reach clients, and release checks validate package contents rather than only a workspace checkout.
- Prometheus metrics, event snapshots, and transport or reconcile counters expose system state
- Docker cluster, soak, and performance suites remain separate from fast workspace tests
- Tarball verification checks the consumable package surface an embedding host receives
What this work does not claim.
Orion is architectural research and is not presented as a dependency shipped in HeliOS.
Multiple transports and provider combinations increase conformance surface even when their state model is shared.
Performance guardrails catch regressions in documented synthetic scenarios; they do not demonstrate production scale or an availability SLA.
Architecture, evidence, and limits.
Explore repository ↗Architecture
- 01 Desired state instead of one-off commands
a node can compare what should run with what it currently observes
- 02 Control plane separated from data plane
configuration and status do not inherit the throughput assumptions of streamed data
- 03 Transports kept at the boundary
IPC, HTTP, TCP, and QUIC adapt shared contracts instead of defining separate system models
- 04 Operational state in the protocol
readiness, failures, audit events, persistence, and peer synchronization are inspectable rather than log-only
Validation
- 01
Health and readiness are tested as different states, while snapshots and transport counters expose where progress stopped
- 02
Containerized suites exercise normal clusters, failures, adversarial inputs, and scale separately from the fast workspace tests
- 03
Release checks cover typed environment configuration, public API compatibility, transport security, concurrency assumptions, and the packaged artifact
Why it matters in practice.
- 01Observations feed the next reconciliation decision, so command delivery is not mistaken for completed work
- 02Local CLI and remote control paths apply the same revision and authorization rules
- 03Feature-gated transports let an embedded host exclude network surfaces it does not use
- 04Readiness, bounded queues, and structured failures make degraded operation visible to clients
- Runtime architecture
- Client SDK
- Operator CLI
- Auth, audit, and observability
- Rust
- SDKs
- CLI
- Observability
- Authentication