📝 mark JAKARTA EE E L'EVOLUZIONE DEL CLOUD CON NANOS UNIKERNEL

Il Futuro del Computing(OnCloud, OnPrem, OnEdge) di Java è Già Qui!!!

L'evoluzione dell'ecosistema Jakarta Enterprise converge verso un'architettura sempre più semplice, efficiente e scalabile, che consente di aumentare sicurezza, essere più performante e ridurre i costi di hardware e infrastruttura. Jakarta EE definisce gli standard moderni per le applicazioni enterprise, le JVM di nuova generazione ottimizzano le performance del runtime. i runtime Jakarta EE o gli Application Server garantiscono robustezza e affidabilità, il tutto gira su NanoVMs che rivoluziona la sicurezza e l'efficienza con il suo unikernels nanos, rimuovendo tutti i layer superflui e non più necessari. Insieme, queste tecnologie rappresentano non solo il presente, ma soprattutto il futuro immediato dello sviluppo enterprise: più veloce, più sicuro.

Esempio di deployment PAYARA 7 Full(JAKARTA EE IMPLEMENTATION) CON AZUL JRE 25 su NANOS UNIKERNEL senza sprechi: più performance, meno costi

---

Introduzione: dall’overhead alla piena efficienza hardware

Il deployment di applicazioni Java enterprise ha attraversato diverse fasi evolutive:

1. Server tradizionali

Ogni applicazione richiedeva un sistema operativo completo e un application server dedicato, con elevato overhead, avvii lenti e costi infrastrutturali importanti.

2. Container e Kubernetes

I container hanno migliorato portabilità e automazione, ma hanno introdotto un nuovo stack complesso fatto di:

• OS Linux completo(anche se alpine)

• container runtime

• cgroup e namespace

• pod, kubelet, CNI, CSI

---

Tutto questo comporta overhead strutturale, consumo di risorse e costi operativi non trascurabili. Oggi, la naturale evoluzione è rappresentata dagli unikernel, e in particolare da Nanos.

Perché Nanos Unikernel

Nanos permette di eseguire applicazioni Java come Payara 7 Full in un ambiente:

• senza OS guest

• senza container runtime

• senza cgroup, namespace o pod

• senza Kubernetes

I benefici principali sono:

• Massimo sfruttamento dell’hardware: CPU, memoria e I/O sono dedicati interamente all’applicazione

• Eliminazione degli sprechi dovuti a layer software superflui.

• Riduzione dei costi: più workload per host, meno VM, meno RAM e CPU inutilizzate. Nanos consente di sfruttare al meglio l'hardware sottostante rispetto ai container.

• Startup ultra-rapido (Nanos unikernel, riducce ancora di più i tempi di start rispetto ai container)

• Sicurezza intrinseca grazie alla caratteristica degli unikernel, nanos fornisce un livello di sicurezza "militare".

In sintesi: stessa applicazione Java, meno overhead, più efficienza, meno costi.

---

1️⃣ Payara 7 Full su Nanos: il concetto chiave

Payara 7 Full è un application server Jakarta EE completo, derivato da GlassFish, che include tutte le funzionalità enterprise senza compromessi.

Con Nanos unikernel è possibile:

1. Pre-configurare Payara offline

2. Includere server, dominio e librerie in un’unica immagine minimale

3. Avviare Payara con un singolo comando Java, senza script e senza OS

Il risultato è un unikernel Java autonomo, pronto all’uso.

---

Pre-configurazione del server

payara7/bin/asadmin create-domain --domaindir /opt/payara7/domains domain1

Configurazione minima del dominio (domain.xml):

<domain>

<configs>

<config  name="server-config">

<http-listener  id="http-listener-1"  port="8080"/>

</config>

</configs>

</domain>

Avvio e stop una sola volta per inizializzare cache e moduli:

payara7/bin/asadmin start-domain domain1

payara7/bin/asadmin stop-domain domain1

Questa operazione viene fatta una sola volta prima della creazione dell’immagine Nanos.

---

Avvio diretto di Payara su Nanos

java \

-Dpayara.domain.dir=/opt/payara7/domains/domain1 \

-Dcom.sun.aas.instanceRoot=/opt/payara7/domains/domain1 \

-Dcom.sun.aas.installRoot=/opt/payara7 \

-cp "/opt/payara7/glassfish/modules/*" \

com.sun.enterprise.glassfish.bootstrap.ASMain

Nessun asadmin, nessun init system, nessun OS.

---

2️⃣ Perché Nanos elimina l’intero stack container

🔹 Stack reale di container + Kubernetes

Un’applicazione Java in Kubernetes non gira mai da sola. Lo stack completo è:

Hardware fisico

└ Hypervisor

└ OS host (Linux)

└ Kernel Linux

├ cgroup (CPU, memoria, I/O)

├ namespace (pid, net, fs, user, ipc)

└ security layer (seccomp, selinux, apparmor)

└ Container runtime (Docker / containerd / CRI-O)

└ Pod Kubernetes

├ kubelet

├ CNI (network overlay)

├ CSI (storage)

└ Sidecar / agent

└ JVM

└ Payara 7 Full

Ogni livello:

• consuma risorse

• introduce latenza

• aumenta complessità e costi

---

🔹 Stack con Nanos Unikernel

Hardware fisico

└ Hypervisor moderno (Gcp, Aws, Azure , Oracle Oci, Alibaba, Xen, Proxmox, Firecracker, KVM, Nitro)

└ Nanos Unikernel

└ JVM

└ Payara 7 Full

✔ Nessun Linux guest

✔ Nessun container runtime

✔ Nessun cgroup

✔ Nessun namespace

✔ Nessun pod

✔ Nessun kubelet

---

a) Eliminazione totale di cgroup, namespace e pod

• cgroup: non necessari → limiti CPU/memoria gestiti dall’hypervisor

• namespace: inutili → isolamento hardware-level

• pod: superflui → 1 unikernel = 1 workload isolato

• kubelet / CNI / CSI: eliminati

L’isolamento non è più software, ma hardware-level.

---

b) Riduzione drastica dei layer

| Approccio | Layer |

| ---------------------- | ---------- |

| Container + Kubernetes | 8–10 layer |

| Nanos Unikernel | 2–3 layer |

Meno layer significa:

• meno overhead

• meno vulnerabilità

• meno patch

• meno complessità operativa

---

c) Massimo sfruttamento dell’hardware

Con i container:

• RAM e CPU consumate da OS, kubelet, runtime, overlay network

Con Nanos:

• tutte le risorse vanno alla JVM e a Payara

• migliore cache locality

• minore latenza

---

d) Startup ultra-rapido

• Container + K8s: secondi / decine di secondi

• Nanos: < 1 secondo

---

e) Riduzione concreta dei costi

• Maggiore densità di workload

• Meno VM, nodi, workernode

• Meno memoria sprecata

• Costi cloud inferiori o di infrastruttura OnPrem

👉 stessa applicazione, meno infrastruttura, meno spese

---

f) Kubernetes diventa opzionale

Con Nanos + hypervisor moderno ottieni già:

• isolamento

• limiti risorse

• networking

• snapshot

• scaling rapido

---

3️⃣ Configurazione Nanos (config.json)

{

"Cmd": "java",

"Args": [

"-Dpayara.domain.dir=/opt/payara7/domains/domain1",

"-Dcom.sun.aas.instanceRoot=/opt/payara7/domains/domain1",

"-Dcom.sun.aas.installRoot=/opt/payara7",

"-cp",

"/opt/payara7/glassfish/modules/*",

"com.sun.enterprise.glassfish.bootstrap.ASMain"

],

"Dirs": [

"payara7"

]

}

---

4️⃣ Conclusioni

Con Payara 7 Full su Nanos Unikernel otteniamo:

• Eliminazione completa dello stack container

• Massimo sfruttamento dell’hardware

• Startup immediato

• Sicurezza intrinseca

• Riduzione significativa dei costi infrastrutturali

👉 **Unikernel non è un’alternativa ai container: è il passo successivo.

**