Do you want your ad here?

Contact us to get your ad seen by thousands of users every day!

[email protected]

Java and Jakarta EE and the Evolution of the Cloud with Nanos Unikernel

  • January 06, 2026
  • 667 Unique Views
  • 5 min read
Table of Contents

The evolution of the Java and Jakarta Enterprise ecosystem is converging toward an increasingly simple, efficient, and scalable architecture that improves security, delivers higher performance, and reduces hardware and infrastructure costs.

For years, Kubernetes has been considered the de‑facto standard for modernizing Java applications in a cloud‑native direction. However, Kubernetes is not the only way to achieve scalability, continuous upgrades, and isolation. An alternative approach — often underestimated — is to leverage the hypervisors already included and fully managed by major cloud providers, using Unikernel images based on Nanos.

Nanos images are not just an alternative to containers: they are lighter, faster, more secure, more performant, and more efficient. Unlike containers, which coexist with a general‑purpose Linux kernel, a Nanos image contains only what the Java application needs, allowing the JVM to use 100% of the CPU and RAM of the VM. The result is a more efficient environment with higher density, less waste, and lower operational costs.

Why Nanos Unikernel

VMs vs. Containers vs. Unikernels

The Key Point: Cloud hypervisors already have everything you need...

When you use a cloud provider, you are already relying on an advanced hypervisor that provides:

  • automatic scheduling
  • hardware isolation
  • VM-level health checks
  • auto-scaling groups
  • rolling instance replacement

Kubernetes adds a second orchestration layer on top of this, introducing additional complexity and overhead. With Nanos Unikernel, the Java application runs directly on the hypervisor, with no container runtime,no kubelet, and no control plane.

And because a Nanos image does not include Linux, userland, shells, or system processes, all VM resources are dedicated exclusively to the JVM.

This results in:

  • higher performance
  • lower latency
  • higher throughput
  • better hardware utilization
  • more workloads per physical node compared to containers

What Changes Compared to Kubernetes

Kubernetes Model

Nanos Unikernel Model

With Nanos:

  • you remove Linux
  • you remove the container runtime
  • you remove Kubernetes
  • you keep scaling, upgrades, and isolation
  • you gain a runtime lighter, faster, and more efficient than containers

Containers, although considered “lightweight,” still inherit:

  • a full Linux kernel always in memory
  • process scheduling
  • virtualized networking
  • overlay filesystems
  • namespace and cgroup overhead

Nanos eliminates all of this. The Java application runs directly on the hypervisor, with no process context switching and no container runtime.
The result:

  • faster startup
  • lower latency
  • higher throughput
  • better performance on the same hardware

Nanos Images = Cloud-Native Immutable Images

Each Nanos build produces a single immutable VM image, versioned and ready to be replaced.
Unlike container images, Unikernel images:

  • do not include Linux
  • do not include userland
  • do not include unnecessary libraries
  • contain only what the application needs
  • have no shell, no users, no SSH
  • have a minimal attack surface
  • consume less CPU and RAM
  • allow the JVM to use all available resources

This not only increases security but also enables higher application density: on the same physical node you can run more Nanos VMs than containers, thanks to the drastically smaller footprint.

CI/CD: GitHub Actions for Building Azul 25 + Payara 7 on Nanos Images

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

The repository AngeloRubens/ci-cd-nanos-unikernel demonstrates how to:

  • build Nanos images with Azul JRE and Payara7 Full by GithubAction Pipeline
  • version them
  • publish them as artifacts
  • prepare them for the cloud provider

Because Nanos images are lighter than containers, the pipeline becomes:

  • faster
  • more predictable
  • more cost-efficient

Scaling: The Hypervisor Does Kubernetes’ Job

With Kubernetes:

  • HPA
  • scheduler
  • pod replacement
  • control plane

With Nanos on the cloud:

  • auto-scaling groups
  • versioned VM images
  • VM-level health checks
  • instance replacement

Nanos VMs have extremely fast boot times, often faster than containers. Since all CPU and RAM are dedicated to the JVM, each instance can handle more traffic, reducing the total number of VMs required.

This means:

  • faster scaling
  • fewer instances to maintain
  • lower cost per unit of load

Application Upgrades: Rolling Just Like Kubernetes

The upgrade pattern is surprisingly similar.

Kubernetes

  • new image
  • rollout
  • pod drain
  • old pod termination

Nanos on the cloud

  • new Unikernel image
  • auto-scaling group update
  • new instances start
  • old instances terminate

Since Nanos images are smaller and faster, rollouts are:

  • faster
  • more predictable
  • less expensive

Security: Stronger Isolation than Containers

Container security is configuration-based (seccomp, AppArmor, SELinux, Kubernetes policies).
Nanos security is architectural.

And because there are no system processes, all resources are dedicated to the JVM, increasing performance and reducing costs.

Nanos Is a Better Choice

  • you want scaling and rolling upgrades
  • you want to reduce operational costs
  • you want to maximize the cloud hypervisor
  • you want better security, higher density, better performance, and lower costs

Conclusion

With Nanos Unikernel on the cloud you can:

  • leverage hypervisors already included and managed
  • achieve scaling, upgrades, and isolation
  • drastically reduce complexity and overhead
  • maintain an immutable, GitOps-friendly model
  • dedicate 100% of resources to the JVM
  • achieve superior performance
  • increase application density
  • significantly reduce 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

5 More Reasons to Choose Apache Pulsar Over Apache Kafka

Table of Contents 1. Getting along with multi-tenancy2. Have we got a quorum yet? Replication3. Tiered storage, event sourcing dreaming4. End-to-end encryption and gobbledygook5. Broker balancing actCommunity and ecosystemLegit Kafka alternative Author’s note: I originally published this blog post in …

6 Considerations when Building High-Performance Java Microservices with EDA

Renowned for its resilience and low latency, EDA is a reliable choice for developing robust, high-performing microservices.

7 Reasons to Choose Apache Pulsar over Apache Kafka

When you set out to build the best messaging infrastructure service, the first step is to pick the right underlying messaging technology!

A Case for Databases on Kubernetes from a Former Skeptic

Looking back at the pitfalls of running databases on Kubernetes I encountered several years ago, most of them have been resolved.

All of these problems are hard and require technical finesse and careful thinking. Without choosing the right pieces, we’ll end up resigning both databases and Kubernetes to niche roles in our infrastructure, as well as the innovative engineers who have invested so much effort in building out all of these pieces and runbooks.

A Fresh Look at Embedded Java

Java is the environment that offers the highest developer productivity thanks to its many amazing tools, evolutions, and community.

Do you want your ad here?

Contact us to get your ad seen by thousands of users every day!

[email protected]

Comments (0)

Highlight your code snippets using [code lang="language name"] shortcode. Just insert your code between opening and closing tag: [code lang="java"] code [/code]. Or specify another language.

No comments yet. Be the first.

Mastodon

Subscribe to foojay updates:

https://foojay.io/feed/
Copied to the clipboard