Every organization today is paying what we call the “Abstraction Tax”; layers upon layers of middleware, service meshes, sidecars, and orchestration tools that were supposed to simplify operations but instead created a new complexity crisis. A simple “hello world” service now requires init containers, sidecar proxies, service mesh configurations, ingress controllers, and dozens of YAML files. We’ve all seen bloated sidecar code that completely overwhelms the value it brings; 2GB of proxy infrastructure to route 1KB messages.

Like sedimentary rock forming over millennia, each layer of abstraction seemed reasonable at the time. But now we’re excavating through geological strata of configuration just to deploy a simple service. The service mesh alone; Istio, Linkerd, Consul; adds 500MB+ of proxy sidecars to every pod, turning your elegant microservice into a lumbering giant.

But what if we could eliminate the bloat from containers themselves?

The Proven Path: Learning from MirageOS

Let’s start with something that already works. MirageOS, built at Cambridge University using OCaml, has quietly revolutionized how we at SpeakEZ Technologies think about micro-VMs, containers and microservices. The project’s 2008 goal was to create a portable, lightweight, and secure runtime by restructuring virtual machines into modular, reusable library components. You might not know it, but even today MirageOS powers parts of Docker Desktop’s networking layer. Amazon Web Services used it for years with their Xen infrastructure. This isn’t experimental; it’s battle-tested in production at massive scale.

What makes MirageOS special? While Docker containers strip away the need for multiple OS kernels by sharing one, they still carry significant baggage - package managers, shells, system utilities, and libraries that your application might never use. A typical container image includes:

Traditional Container Image:

• Base image utilities (apt, yum, bash, etc.): 50-150MB
• System libraries and dependencies: 100-300MB
• Your application: 50MB
• Result: 200-500MB to run 50MB of code

MirageOS Unikernel:

• Application + only the exact library functions it calls: 5-10MB total
• No shell, no package manager, no unused libraries
• Runs as a lightweight VM in Firecracker or Xen
• Boots in 5-50 milliseconds
• Already proven at AWS and Docker scale

Think of it this way: containers eliminated the need for multiple kernels, which was revolutionary. MirageOS goes further by eliminating everything else that isn’t your actual application. It compiles your code together with only the specific OS functions it needs into a single, sealed unit.

This approach has worked so well that we asked ourselves: what if we could extend this concept using F#, a language that shares OCaml’s heritage but offers even more power for system-level programming?

From Microcontrollers to the Cloud

Our vision began in an unexpected place: STM32 microcontrollers. When building embedded systems, every byte matters. The Fidelity framework has a design option in the LLVM path to statically link F# code directly to low-level library code, and in this case it was ST Microdevices’ CMSIS Hardware Abstraction Layer (HAL). Mapping to that directly instead of through a realtime operating system (RTOS) made our applications into the operating system. No RTOS bootstrapping, just code running on bare metal.

The expected results:

• Significantly smaller payloads on the device
• Extremely fast, deterministic real-time performance
• Mathematically provable security (no OS vulnerabilities)
• Direct hardware control from high-level F# code

This microcontroller strategy led to a revelation: if we can replace the OS on a tiny chip, the same principles could eventually apply to servers and the advanced accelerators that will be driving the next wave of intelligent systems design.

An OCaml Heritage

F# and OCaml share the same ML family heritage, and F# was itself built as an expression of OCaml for the .NET runtime environment. However F# and the Fidelity framework extends those capabilities in crucial ways:

OCaml (MirageOS’s Foundation):

• Excellent functional programming language
• Good low-level capabilities
• Proven in systems programming

F# with Fidelity (The Next Generation):

• All of OCaml’s capabilities
• Superior type system with units of measure and type providers
• Comprehensive tooling and IDE support
• Direct LLVM compilation path (and other backends via MLIR)
• Native interop with C/C++ libraries
• Plans for hardware description capabilities for FPGAs

The Fidelity framework takes F# well beyond its .NET origin story, taking a page from the Fable compiler’s innovative JavaScript path. We compile F# directly to native code without any runtime dependencies. This means we can build unikernels like MirageOS, but with a more adaptive and top-line semantic layer, and using a more adaptive intermediate expression through MLIR that leads to more direct hardware integration.

A Kubernetes Replacement Emerges

As we continued to design these capabilities, a novel idea emerged. Just as MirageOS replaced traditional containers for specific applications, a future Fidelity “unikernel” could become the entire orchestration layer, effectively replacing Kubernetes.

This is where it’s worthwhile to note one of the more stark divergence of F# beyond its OCaml heritage: the MailboxProcessor, which implements Erlang-style actor model concurrency. This isn’t just a language feature; it’s a different philosophy of system design. Erlang powers WhatsApp, Discord, and telecom systems that require 99.9999% uptime. The Erlang VM (BEAM) is essentially an operating system that manages millions of lightweight processes with fault isolation and supervision trees.

F# has many of these concepts built in:

• MailboxProcessor: Erlang-style actors with message passing
• Async & Computation Expressions: Lightweight concurrency
• Immutable by default: No hidden mutable state challenges
• Pattern matching: Message handling like Erlang’s receive blocks

The Fidelity framework extends far beyond F#’s base MailboxProcessor implementation. Our Olivier actor model and Prospero orchestration layer create a complete actor hierarchy with deterministic resource management.

As detailed in our article on RAII in Olivier and Prospero, Prospero’s design serves as a system-level scheduler that coordinates actor lifecycles with arena-based memory allocation and sentinels, solving the “byref problem” that plagues managed runtimes while providing Erlang-style supervision trees. This means each actor gets its own memory arena that lives exactly as long as the actor does - no garbage collection, just deterministic cleanup. And with BAREWire zero-copy and IPC memory mapping the data and message passing would occur at hardware speed with little to no intervening abstraction to get in the way.

This means adapting MirageOS to F# isn’t just about creating unikernels; it’s about integrating and extended Erlang-style operating system where actors coordinate through message passing. Each actor would become a fault-isolated unit that can fail and restart without affecting others. This is the architecture that keeps telecom switches running for decades without downtime. And we see it as a design that is once again meeting its moment with the advent of new accelerators that are taking over the next wave of AI.

Traditional Kubernetes Deployment:

• Base OS (Linux): 2GB overhead
• Kubernetes components: 500MB per node
• Service mesh: 500MB per pod
• Container runtime: 200MB
• Your application: 50MB
• Total: ~3.2GB to run 50MB of business logic

Proposed Fidelity Unikernel Deployment:

• Complete unikernel (OS + App): 10MB total
• Actor-based orchestration built in: No external orchestrator needed
• Message-passing networking: No service mesh required
• Direct hypervisor execution: No container layer
• Total: 10MB to run your complete application with Erlang-style reliability

This represents what becomes possible when MirageOS’s proven approach is combined with F# and Fidelity’s uniquely designed actor model capabilities. MirageOS already achieves startup times below 10 milliseconds and memory footprints smaller than a typical web page. Our Fidelity framework aims to bring these same benefits to F# developers while adding Erlang-style fault tolerance and supervision.

A Macrocontroller Operating System

Here’s where our microcontroller experience meets cloud-scale ambition. Just as we innovated with replacement of the RTOS on STM32 chips by statically linking to hardware abstraction layers, we are considering designs that may someday replace generic operating systems by compiling directly to those hardware system interfaces. It would require a significant undertaking but for use cases where security and efficient execution in a hardware-software co-design space, it could be a crucial feature.

The progression is logical:

1. Microcontrollers: Fidelity applications ARE the OS
2. Cloud VMs: MirageOS proves it works; we extend it with F# beyond OCaml’s limits
3. Bare Metal: Direct server access without the security exposure of the traditional OS

MirageOS has shown this isn’t just possible; it’s could be seen as preferable for many built-for-purpose workloads where the CPU and memory is part of an orchestration layer where accelerators are doing the majority of “the work”. Our Fidelity framework vision extends to embrace this emerging technology landscape.

The New Reality: Heterogeneous Computing

Modern computing isn’t just about CPUs anymore. AI workloads need GPUs and TPUs. Stream processing demands FPGAs. Adaptive algorithms benefit from CGRAs. Future applications will use neuromorphic chips that compute like brains.

Traditional approaches treat these as “accelerators” bolted onto a CPU-centric system. But what if each processor type ran its own specialized unikernel?

The Fidelity Advantage for Heterogeneous Systems:

• One Language, Many Targets: F# code compiles to optimal code for each processor type
• No Runtime Translation: Direct compilation to GPU kernels, FPGA bitstreams, or neuromorphic circuits
• Unified Memory Model: Our BAREWire protocol enables zero-copy sharing between processors
• Provable Safety: Mathematical verification that also informs optimization

This is the new reality of intelligent systems design. As specialized chips proliferate, the ability to compile efficient, secure code for any processor becomes the ultimate competitive advantage.

Heterogeneous Intelligence

Here’s where traditional approaches completely fall apart. Modern AI and HPC workloads don’t just run on GPUs. They need CPUs for orchestration, TPUs for tensor operations, and even FPGAs for custom math processing. Soon CGRAs will provide reconfigurable logic, and neuromorphic chips will produce brain-inspired computing. We see Fidelity taking center stage for all of those coming waves of innovation.

Kubernetes treats all of this as “resources” to be scheduled. But that’s like treating a Formula 1 car, a cargo ship, and a fighter jet as just “vehicles”; technically true, but you’re missing everything that matters.

Native Intelligence for Every Accelerator

We won’t just schedule workloads on accelerators. Our designs will compile native unikernels specifically for each type of processor:

Each accelerator runs only what it needs. No ‘generic’ operating system. No bloated sidecars or container runtime. Just pure, optimized computation at the speed of silicon. The full spectrum on delivery mechanisms would be available: deployment to a Kubernetes cluster, triggered within a serverless framework, or operate on their own in high-speed delivery platforms built-for-purpose.

Security Through Simplicity

Traditional security is like building higher walls around a sprawling city. Zero Trust is like requiring ID badges at every door.

But what if there were no doors to guard?

Unikernels provide security through radical simplification:

• No Shell: Can’t spawn a shell if there isn’t one
• No Utilities: No ls, cat, wget, or curl to exploit
• No Network Stack: Unless explicitly needed
• No File System: Unless explicitly required
• Immutable by Design: Can’t modify what doesn’t exist

It’s not that we’ve hardened the attack surface; we’ve eliminated it. A traditional Linux container has approximately 200 system calls available. Our unikernels typically need fewer than 20. That’s not a 10% improvement in security; it’s a 90% reduction in attack vectors.

The MirageOS Inspiration: Proven at Scale

This isn’t theoretical. MirageOS, the OCaml-based unikernel system already powers parts of critical internet infrastructure. Docker uses MirageOS components. Cambridge University deploys it in production. XenProject relies on it for secure isolation.

Our vision is to bring this proven approach to F# developers through the Fidelity framework, extending it with our patented innovations:

• BAREWire Protocol: Zero-copy communication between accelerators
• Interaction Nets: Optimal reduction for parallel computation
• Delimited Continuations: Efficient handling of asynchronous operations
• Type-Safe Hardware Access: Compile-time verification of hardware operations

Breaking Free from Kubernetes: The Post-Orchestration Era

Kubernetes was designed for a world of general-purpose containers on general-purpose servers. But specialized computing requires specialized orchestration. Our approach:

Nomad-Style Simplicity

Instead of Kubernetes’ 1.5 million lines of code, we use HashiCorp Nomad’s elegant 100,000 lines, extended with our custom schedulers for heterogeneous hardware.

Direct Hypervisor Control

Why put containers in VMs in Kubernetes when you can run unikernels directly on the hypervisor? We have preliminary designs to integrate with:

• Firecracker: Amazon’s microVM technology (powers Lambda)
• Solo5: Lightweight unikernel monitor
• Xen: Battle-tested isolation
• KVM: Native Linux virtualization

Purpose-Built for Heterogeneous Computing

Our orchestrator will have a built-in understanding of the fundamental differences between accelerators:

Traditional Kubernetes:
"Schedule this pod somewhere with a GPU"

Fidelity Orchestrator:
"Compile dataflow graph to FPGA bitstream,
 Load tensor operations to TPU,
 Configure CGRA for adaptive filtering,
 Coordinate via CPU control plane,
 Stream results through shared CXL memory"

The Business Case: 10x Better, Not 10% Cheaper

This isn’t about marginal improvements. It’s about fundamental advantages that compound:

Performance Multiplication

• Boot time: 1000x faster (5ms vs 5 seconds)
• Memory usage: 100x smaller (5MB vs 500MB)
• Deployment density: 50x more instances per server
• Network latency: 10x lower (microseconds, not milliseconds)
• Security incidents: 90% fewer attack vectors

Cost Revolution

When you run 50x more workloads per server with 100x less memory, infrastructure costs don’t decrease linearly; they collapse:

• Server costs: 75% reduction
• Memory costs: 90% reduction
• Operational overhead: 80% reduction
• Security audit costs: 60% reduction
• Debugging time: 70% reduction

Development Velocity

One language (F#) compiles to every target. No more:

• CUDA for GPUs
• OpenCL for FPGAs
• TensorFlow for TPUs
• Verilog for hardware
• Python glue code
• YAML orchestration

Just write business logic. The compiler handles the rest.

Real-World Applications: Where This Matters Most

Financial Services: Microsecond Advantages

High-frequency trading firms need every microsecond. Our FPGA unikernels process market data at wire speed; literally as fast as the network can deliver it. No OS overhead. No context switches. Pure computation.

Healthcare: Secure by Design

HIPAA compliance becomes trivial when there’s no OS to audit. Patient data processing runs in isolated unikernels that literally cannot access anything beyond their designated memory region.

Edge AI: Intelligence Everywhere

Deploy AI inference to edge devices without the Linux overhead. A complete vision processing pipeline in 10MB instead of 1GB. This enables AI on devices that couldn’t previously support it.

Defense: Unbreachable Systems

Military systems require the highest security. Unikernels provide mathematical proof of isolation. If it’s not in the binary, it cannot be exploited.

The Migration Path: Evolution, Not Revolution

Smart enterprises don’t flip switches; they turn dials. Here’s the journey:

Starting Small

Begin with a single workload. Perhaps an internal tool or a non-critical service. Deploy it as a unikernel alongside your existing infrastructure. When it runs without issues, people notice.

Adding Acceleration

Introduce GPU acceleration for your ML workloads. Then FPGA processing for your streaming analytics. Each success builds confidence. Each deployment reinforces the advantages.

Expanding Adoption

As teams see the benefits; reduced costs, improved performance, simplified operations; adoption naturally accelerates. Critical systems can be migrated when the organization is ready, not before.

The New Normal

Eventually, your infrastructure becomes a hybrid of traditional systems and unikernels, each used where they make the most sense. Some legacy systems may never migrate, and that’s perfectly fine. The goal is optimization, not uniformity.

The Competitive Imperative: First-Mover Advantages

Every technology wave creates winners and losers. The companies that moved from mainframes to servers won. The companies that embraced the cloud early won. The companies that adopted containers efficiently won.

But those were incremental advantages. Unikernels provide exponential advantages:

• Efficiency Gap: While competitors burn millions on cloud infrastructure, you run the same workloads for thousands
• Security Moat: While competitors patch vulnerabilities, you’ve eliminated entire categories of attacks
• Performance Edge: While competitors optimize code, you’re running at hardware speed
• Talent Leverage: While competitors hire DevOps armies, your developers deploy directly

Beyond Virtualization: The Deeper Revolution

This isn’t just about replacing containers with unikernels. It’s about rethinking computation itself:

Memory-Centric Computing

With CXL and our BAREWire protocol, memory becomes the communication fabric. No more copying data between devices. Accelerators share memory pools directly. A GPU can read FPGA results without CPU involvement. This isn’t just faster; it’s a fundamental architectural shift.

Adaptive Hardware

CGRAs (Coarse-Grained Reconfigurable Arrays) can reshape themselves for different workloads. Our compiler generates configurations that transform the hardware to match the computation. Imagine hardware that molds itself to your algorithm.

Neuromorphic Future

Brain-inspired chips are coming. They don’t run programs; they learn patterns. Our framework already supports spiking neural networks compiled directly to neuromorphic hardware. While competitors are still figuring out how to deploy to GPUs, you’ll be deploying to brain chips.

The Open Secret: Why Others Can’t Copy This

Building this requires five things that rarely come together:

1. Deep Hardware Knowledge: Understanding CPU microarchitecture, GPU programming models, FPGA synthesis, and emerging accelerators
2. Language Design Expertise: Creating a type system that can express all these computational models
3. Compiler Engineering: Building an MLIR-based compiler that can target everything
4. Mathematical Foundations: Using formal verification to prove correctness and enable aggressive optimizations
5. Systems Thinking: Seeing how it all fits together

The formal verification aspect provides unique advantages. We mathematically prove our compiler transformations preserve program semantics. This enables:

• Customer Assurance: Not “we tested it thoroughly” but “we proved it correct”
• Aggressive Optimization: When you can prove transformations are safe, you can optimize far more aggressively than traditional compilers that must be conservative
• Regulatory Compliance: Formal verification for safety-critical systems in healthcare, aerospace, and finance
• Reduced Debugging: Proven-correct code eliminates entire categories of runtime errors

Our team brings together all five of these rare capabilities. Combined with four patents protecting our key innovations and years of research and development already invested, we’re positioned to deliver this vision.

The Path Forward: What You’ve Always Suspected

If you’ve made it this far, you’ve probably had that nagging feeling for a while now. The one that says “this can’t be sustainable.” Every new abstraction layer, every additional proxy, every extra configuration file; they all add up to a complexity tax that keeps growing.

You were right to be skeptical.

The emergence of specialized processors; GPUs, TPUs, FPGAs, CGRAs, neuromorphic chips; isn’t just changing hardware. It’s creating an imperative for software to evolve. The old model of piling abstractions on top of general-purpose systems doesn’t work when every chip is specialized. Hardware-software codesign isn’t just an optimization anymore; it’s becoming the only way to remain competitive.

You’ve recognized something important: the future belongs to those who can harness these new architectures efficiently. Not through more layers of abstraction, but through direct, purposeful compilation to each processor’s strengths.

A Partnership Approach

We see this as a partnership, not a product sale. Every organization’s journey will be different. Some will start with a single proof-of-concept service. Others might begin with new greenfield projects. Many will run hybrid architectures indefinitely, and that’s perfectly reasonable.

What matters is having options. The ability to deploy traditional containers when they make sense, and unikernels when efficiency matters. The flexibility to target GPUs, FPGAs, or neuromorphic processors with the same codebase. The choice to gradually evolve rather than revolutionize overnight.

A Vision Supporting Today’s Reality

We understand that you have significant investments in existing infrastructure. Teams trained on Kubernetes. Workflows built around containers. Compliance processes tied to current architectures. These aren’t obstacles to overcome; they’re assets to leverage.

Bridge Technologies

Our approach includes comprehensive bridge technologies:

BAREWire Kubernetes Integration:

• Deploy Fidelity unikernels within existing Kubernetes clusters
• Full compatibility with kubectl and existing tooling
• Gradual service-by-service migration options
• No “big bang” transitions required

Protocol Translation:

• Native support for gRPC, REST, GraphQL
• Seamless communication with legacy services
• No need to rewrite existing microservices
• Performance improvements without disruption

Hybrid Management:

• Unified monitoring across containers and unikernels
• Single operational view of heterogeneous deployments
• Existing tools continue working
• New capabilities added incrementally

Supporting Your Teams

Change is hard, especially for technical teams who’ve invested years mastering current technologies. Our approach respects this expertise:

• Familiar interfaces that gradually introduce new concepts
• Compatibility modes that ease transitions
• Training and support tailored to your team’s pace
• Options to maintain some systems in Kubernetes indefinitely

Investment Protection

Your current infrastructure becomes the foundation for evolution:

• Kubernetes clusters can host unikernel workloads
• Existing CI/CD pipelines need minimal adjustment
• Current monitoring and logging infrastructure remains relevant
• Service meshes can be gradually optimized rather than replaced

The goal isn’t to invalidate what you’ve built. It’s to give you new options for what you build next. Some services will always make sense as traditional containers. Others will benefit dramatically from unikernel efficiency. Having both options, with seamless interoperability, gives you the flexibility to optimize where it matters most.

The future includes both unikernels and traditional deployments, working together. Your existing investments remain valuable. Your teams’ expertise continues to matter. The path forward respects your current reality while opening new possibilities.

We’re here to enable a common vision of the future, however that takes shape for you.