sergio fer (Jun 04 2026 at 18:24): sergio fer (Jun 04 2026 at 18:24):When we talk about cloud computing, the standard unit is the Virtual Machine or the Container. But both abstractions carry an enormous overhead: slow initialization and a virtualized network stack that penalizes latency.
We asked ourselves: What if we reduced the computational unit to its purest expression in silicon, while maintaining the security and elasticity of the cloud?
Thus was born the Compute Cell, the fundamental building block of our orchestrator: the CCR (ComputeCell Runtime).
For the end user, the experience is zero-friction. To trigger a 5-million native iteration Monte Carlo simulation, this is what we send via a POST request from Postman:
JSON
{
"id": 301,
"kind": "BatchProcessing",
"runtime": "Python",
"command": "import math, random, time; start=time.time(); data = [max(100 * math.exp((0.05 - 0.5 * 0.2**2) + 0.2 * random.gauss(0, 1)) - 105, 0) for _ in range(5000000)]; print(f'--- MEGA MONTE CARLO --- | Result: {sum(data)/5000000:.6f} | Pure Exec: {time.time()-start:.4f}s')",
"profile": { "cpu": 0.1, "gpu": 4.0, "memory": 0.9, "io": 0.0 }
}
No Docker image packaging, no cluster configuration. But what happens in the backend exposes a distributed systems architecture based on In-Process Virtualization:
Hardware Calibration: Upon booting, the orchestrator does not rely on environment variables. It audits the actual physical hardware (threads and tensors) and "materializes" static cells. These are not VMs; they are pre-warmed memory pointers isolated via WebAssembly.
Dual-Runtime on a Tokio Server: The heart of the network. We managed to multiplex within the same asynchronous Tokio server both Serverless workloads (HTTP 1.1 over WASI Preview 1) and heavy K8s Lite streams (gRPC over Component Model Preview 2). Both coexist concurrently on the same port without blocking the main thread.
Hybrid Resource Allocation: We operate in two modes. For Serverless, we use exact resource declaration (the "profile" in the JSON). For K8s Lite, we apply Statistical Multiplexing by evaluating the load in real time. This way, the user only needs to request the ID of a pre-provisioned Pod (e.g., AI TIER for ultra-heavy compute), select the language, and spin up their DevOps pipelines instantly.
Self-Destruction and Zero Entropy: After dispatch, the cell executes the script straight to the silicon (completing 5 million iterations in 3.04s on a standard laptop, with no prior cache). It returns the result via O(1) shared memory and cleans itself up. The Load drops back to 0.00 on the next tick. Zero memory leaks.
We have managed to abstract all the complexity of a "K8s Lite" behind a simple POST request. We are building a Unikernel-as-a-Service where the infrastructure gets out of the code's way.
Pat Hickey (Jun 04 2026 at 21:16):Hi, this post and your other one posted today doesn't seem like a discussion item but maybe a blog post? Its not clear at all from your post how this has relevance to any bytecode alliance projects or to webassembly
sergio fer (Jun 04 2026 at 22:56):Hi Pat, thank you for the feedback. I apologize if the post was not clear regarding its relation to the community's work.
To clarify the relevance: My implementation, the CCR (ComputeCell Runtime), is built specifically to address the challenges of in-process virtualization and orchestration using WebAssembly components.
The technical relevance lies in:
Component Model / WASI integration: My work implements a dual-runtime multiplexing mechanism on a Tokio server that concurrently handles Serverless workloads (HTTP/1.1 over WASI P1) and K8s-Lite streams (gRPC over Component Model P2). This directly relates to current discussions about bridging the gap between existing WASI standards and the ongoing evolution of the Component Model.
Computational Unit Abstraction: I am exploring how to reduce the computational unit to a "Compute Cell" by utilizing shared memory at the component level to achieve $O(1)$ data transfer, minimizing the overhead that container-based runtimes currently impose on distributed systems.
The goal is to demonstrate that we can orchestrate these components at a bare-metal level without the friction of traditional image packaging or OS-level virtualization. I’m sharing this because I believe it provides a functional benchmark for the performance targets we are aiming for within the Bytecode Alliance, and i wan't to make new connections for this new infrastructure.
I'm happy to provide more details on the implementation if you're interested in the performance metrics regarding the multiplexed execution.
sergio fer (Jun 04 2026 at 23:04):i doesn't have a solid network or strong connections to put this work up to people who maybe interested on discussing about building a robust infrastructure cause it requires debating ideas and challenging conventional wisdom, so I greatly value feedback from the community.
My primary goal at this stage is to make this technology available to technical teams that truly need to address latency, cost, or cold-start issues in their current deployments.
If you’re facing these bottlenecks in your infrastructure, or are simply interested in accessing our Community Edition to conduct your own performance tests, the door is wide open.
You can email me directly at admin@maleantdatasystemsolutions.com.
Chris Fallin (Jun 04 2026 at 23:05):I'll second Pat's general message: while we welcome discussion of the technical field and related projects, your posts IMHO cross a line into "self-promotion of outside work", which we generally don't want on our platforms.
In particular, this from your other thread
We are opening access to the engine for tech teams, startups, and infrastructure enthusiasts. If you want to benchmark this architecture against your own workflows under a technical evaluation license with no commitment, send me a DM.
and this from here
make this technology available to technical teams
[ ... ]
If you’re facing these bottlenecks in your infrastructure, or are simply interested in accessing our Community Edition to conduct your own performance tests, the door is wide open.
You can email me directly at [ ... ]
are straightforward commercial solicitation, which IMHO is a violation of our community norms. We do not welcome solicitation of users for your commercial software on our platform.
cc @Till Schneidereit @Oscar Spencer for TSC opinion and moderation
sergio fer (Jun 04 2026 at 23:08):if ur request its to me to change such self promotion i can do it, no problem, im not greedy at all. I really love wasm, and programming i just wanna make some friends and networking :stuck_out_tongue:, oh its gone, np... my bad for not reading the rules
Last updated: Jul 29 2026 at 05:03 UTC