Java-Applikationsserver 2.0 à la Quarkus
Nahtoderfahrung
Als „Supersonic Subatomic Java EE“ wirft Red Hat das neue Java-Framework Quarkus ins Rennen. Seine Schöpfer haben bewährte Enterprise-Java-Prinzipien und -Standards weitergedacht und legen die Grundlage für die Entwicklung von Microservices und Cloud-nativer Anwendungen.
Microservices teilen eine Anwendung in unabhängige Prozesse auf, die über Protokolle wie HTTP miteinander kommunizieren. Server-Features von Java EE (Java Enterprise Edition) wie verteilte Deployments, Clustering, CORBA-/IIOP-RMI-Kommunikation oder bunte Administrationskonsolen spielen in Microservices und Cloud kaum mehr eine Rolle. Auch das Deployment von WARs (Web Application Archive) scheint zunächst fehl am Platz.
Mit der starken Verbreitung von Containertechniken wie Docker mit CoW-Filesystemen (Copy on Write) wurde allerdings das Deployment aus alten J2EE-Zeiten wieder attraktiv. Die Applikationsserver haben immer schon strikt die Infrastruktur von der Implementierung der Geschäftslogik getrennt. Da in Docker nur jeweils die oberste Schicht veränderbar ist, lässt sich auch bei einem Deployment eines Microservice nur jeweils die oberste Schicht des Filesystems ändern. Die Installation des Applikationsservers, egal wie groß, liegt unveränderlich darunter. So wird nur die oberste Schicht bei jeder Änderung der Geschäftslogik in eine entfernte Docker Registry übertragen. Aufgrund des „Content Addressable Storage“ erkennt Docker vorhandene Schichten und überträgt diese nicht mehr in die Registry. Je kleiner das Paket, das sogenannte Thin WAR, desto schneller das Deployment. Die Vorzüge dieser Trennung verwenden alle Betreiber von Docker- und so auch Kubernetes-basierten Cloud-Umgebungen zur Verkürzung der Deployment-Zeiten. Im Gegensatz dazu wird ein Uber-JAR- beziehungsweise Super-JAR-Deployment immer wieder die gesamte Runtime verpacken, obwohl sich tatsächlich nur ein Bruchteil des Archivs ändert.