The Future of Computing oNcloud, onprem, onedge of Java Is Already Here!

For years, Kubernetes has been regarded as the de-facto standard for modernizing Java applications in a cloud-native direction. Yet Kubernetes is not the only path to scalability, continuous upgrades, and isolation. There is an alternative approach, often underestimated, which consists of leveraging the hypervisors already included and fully managed by the major cloud providers, running Unikernel images based on Nanos.

These images are not merely an alternative to containers: they are lighter, faster, more secure, more performant, and more efficient. Whereas a container coexists with a general-purpose Linux kernel, a Nanos image contains only what the Java application actually needs, allowing the JVM to use 100% of the VM’s CPU and RAM. The result is a leaner environment with higher density, less waste, and lower operational costs.

Cloud Hypervisors Are Already an Orchestrator

When you run on a cloud provider you are already relying on an advanced hypervisor that offers automatic scheduling, hardware isolation, VM-level health checks, auto-scaling groups, and rolling instance replacement. Kubernetes simply layers a second orchestration tier on top of this, and with it comes additional complexity and overhead. With a Nanos Unikernel, the Java application runs directly on the hypervisor: no container runtime, no kubelet, no control plane.

And because a Nanos image carries no Linux, no userland, no shells, and no system processes, every VM resource is dedicated exclusively to the JVM. The practical consequences are higher performance, lower latency, greater throughput, better hardware utilization, and more workloads per physical node than containers allow.

What Changes Compared to Kubernetes 

The Kubernetes model stacks the Java app on the JVM, then a container, then Linux, then Kubernetes, and finally the cloud hypervisor:

 Java App 
   → JVM 
     → Container 
       → Linux 
         → Kubernetes 
           → Cloud Hypervisor

The Nanos model collapses that stack entirely:

 Java App 
  → JVM 
    → Nanos Unikernel 
      → Cloud Hypervisor

You remove Linux, the container runtime, and Kubernetes itself, while keeping scaling, upgrades, and isolation — and you gain a runtime that is lighter, faster, and more efficient than a container. Containers, though marketed as lightweight, still inherit a full Linux kernel resident in memory, process scheduling, virtualized networking, overlay filesystems, and the overhead of namespaces and cgroups. Nanos eliminates all of it, so the application runs with no process context switching and no runtime in the way, which translates into faster startup, lower latency, higher throughput, and better performance on identical hardware.

Nanos Images are Cloud-Native Immutable Images

Each Nanos build produces a single immutable, versioned VM image, ready to be replaced rather than patched. Unlike container images, a Unikernel image carries no Linux, no userland, and no superfluous libraries; it contains only what the application requires and offers no shell, no users, and no SSH. This gives it a minimal attack surface while consuming less CPU and RAM and letting the JVM use everything available. The benefit is twofold: stronger security and higher density, since the same physical node can host more Nanos VMs than containers thanks to the drastically smaller footprint.

CI/CD: GitHub Actions for Building Nanos Images

The CI/CD pipeline plays the same role it would with containers, but the final output is a
lightweight, immutable Unikernel VM.

The repository AngeloRubens/ci-cd-nanos-unikernel shows how to build Nanos images through a GitHub Actions pipeline, version them, publish them as artifacts, and prepare them for the cloud provider. Because the images are lighter than containers, the pipeline itself becomes faster, more predictable, and more cost-efficient.

 

Scaling: The Hypervisor Does Kubernetes’ Job

Where Kubernetes relies on the HPA, its scheduler, pod replacement, and a control plane, Nanos on the cloud relies on auto-scaling groups, versioned VM images, VM-level health checks, and instance replacement. Nanos VMs boot extremely quickly, often faster than containers, and because all CPU and RAM go to the JVM, each instance can absorb more traffic — which reduces the total number of VMs required. The outcome is faster scaling, fewer instances to maintain, and a lower cost per unit of load.

Application Upgrades: Rolling Just Like Kubernetes

The upgrade pattern is strikingly familiar. Where Kubernetes builds a new image, rolls it out, drains pods, and terminates the old ones, Nanos on the cloud builds a new Unikernel image, updates the auto-scaling group, starts fresh instances, and retires the old ones. Because the images are smaller and boot faster, rollouts are quicker, more predictable, and less expensive.

Security: Stronger Isolation than Containers

Container security is configuration-based (seccomp, AppArmor, SELinux, Kubernetes policies). Nanos security is architectural. One application equals one VM, on a minimal kernel, with no shell, no user, no SSH, and no side processes, protected by hypervisor-level isolation. And since there are no system processes competing for resources, everything is dedicated to the JVM, which raises performance while lowering cost.

Conclusion

Running Nanos Unikernel on the cloud lets you leverage hypervisors that are already included and managed, achieve scaling, upgrades, and isolation, and drastically cut complexity and overhead — all while keeping an immutable, GitOps-friendly model and dedicating 100% of resources to the JVM. The payoff is superior performance, higher application density, and significantly lower infrastructure costs. 

Nanos shows that cloud-native can exist without adding complexity,
and can be secure,faster, lighter, safer, more efficient, and more cost-effective.

Further Reading and Resources