Compute in orbit is a serious idea: abundant solar power, radiative cooling, proximity to sensing satellites that generate more data than any downlink can carry. But most of the conversation is about the processor and the thermal envelope, and very little of it is about the part that decided every data-center generation — the fabric, the interconnect software, and the operational tooling that lets a customer trust the system with a workload.
What decided the last three generations on the ground
Look at how terrestrial data centers actually evolved. Processors got faster, and everyone had access to the same processors. The companies that pulled ahead were the ones that solved the problems between the processors: moving data across thousands of nodes without stalling, keeping tail latency bounded, isolating a failed node without taking the rack with it, and giving operators enough visibility to run the whole thing with a small team. The network interface, the fabric, the transport, and the management software were where the margin lived — and they were built by people who understood that a data center is a distributed system first and a collection of servers second.
Having owned the software for data-center NIC and Ethernet controller product lines shipped with the largest server and cloud vendors, we would say the same thing to a founder building for orbit that we said to those building for the rack: the differentiation is in the network stack, the observability, and the failure handling.
The orbital fabric has three tiers, and one of them is the sky
An orbital compute node has a fabric inside the spacecraft, a fabric between spacecraft, and a link to the ground. The first looks like a rack. The second looks like a data center with a very unusual floor plan — nodes that move relative to one another, links that come and go on a schedule, bandwidth that changes with geometry. The third is the slowest and most contested link in the system, shared with everything else the operator needs to move, and available only when a ground station is in view.
Treat the ground link as a first-class tier of the fabric, with the same scheduling and fault-tolerance discipline as the others. Workloads should be placed and results staged with the downlink schedule in mind. Data that cannot be sent should be summarized, not lost. And the whole thing must be simulated — link budgets, contact windows, node failures, congestion — long before the flight hardware exists, because you will not get to rerun the experiment after launch.
The orbital node is a NIC problem before it is a CPU problem. The team that over-invests there early will own the platform.
Design the networking software first
This is the practical recommendation, and it runs against the instinct of most hardware-led space teams. Before the processor is chosen, write the interface contracts between nodes. Decide how the fabric handles a node that stops responding, a link that degrades, a partition that lasts ninety minutes. Build the telemetry that will let a ground operator understand the state of a system they cannot touch. Then choose compute that fits inside that architecture, rather than choosing compute and discovering the architecture afterward.
The software for this exists in pieces on the ground — congestion control, delay-tolerant transport, distributed schedulers, fleet observability. What does not exist is the integration of those pieces under space constraints, and that integration is the product.
Where space makes it harder
Add the constraints that make it space — no repair after launch, radiation, a decade of unattended operation — and the right-first-time discipline of first-pass silicon and automotive-grade reliability becomes mandatory rather than admirable. The engineering discipline here is RAMS: reliability, availability, maintainability, and safety, applied from the architecture down. Every component needs a failure mode analysis. Every software update needs a path that cannot brick the node. Every operator action needs to be reversible from the ground.
That combination — data-center networking software, first-pass silicon discipline, and space-grade reliability engineering — is rare in one team. It is the reason we opened a space practice.
Red Tomatoes Enterprises · Published · Updated