The evolution of the Glassfish 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.
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
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
|
- 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
- a full Linux kernel always in memory
- process scheduling
- virtualized networking
- overlay filesystems
- namespace and cgroup overhead
- faster startup
- lower latency
- higher throughput
- better performance on the same hardware
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
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 IBM Semeru Runtime JRE and Glassfish8 Full by GithubAction Pipeline
- version them
- publish them as artifacts
- prepare them for the cloud provider
- faster
- more predictable
- more cost-efficient
- HPA
- scheduler
- pod replacement
- control plane
- auto-scaling groups
- versioned VM images
- VM-level health checks
- instance replacement
This means:
- faster scaling
- fewer instances to maintain
- lower cost per unit of load
Kubernetes
- new image
- rollout
- pod drain
- old pod termination
- new Unikernel image
- auto-scaling group update
- new instances start
- old instances terminate
- faster
- more predictable
- less expensive
 |
 |
- 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
- 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