Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
8. Controller
Manager
Scheduler
API Server
etcd (k/v-Store) Cloud Controller Mgr*
Control Plane (Master Noder) Worker Node 1
Worker Node 2
kubelet
kubelet
Container Runtime
Container Runtime
kube-proxy
kube-proxy
k8-Objects*
k8-Objects*
End User
Developer
kubectl
cli/api/
dashboard
Kubernetes Cluster
(ideas taken from DevOps Mojo by Ashish Patel)
*optional
Data Plane (Worker Nodes)
9. Seien wir doch mal ehrlich …
Bedarf in Zeiten von Cloud & Co.
• klein aka niedriger Speicherbedarf
• schnell aka geringe Startup Time
• flexibel aka Modularisierung
10. Seien wir doch mal ehrlich …
Jakarta EE ist eher
• groß aka hoher Speicherbedarf
• langsam aka lange Startup Time
• unflexibel aka alles oder nix*
* gilt selbst für das stark abgespeckte WebProfile?
+++ BREAKING NEWS: Jakarta EE 10 führt minimalistisches CORE Profile ein +++
18. Aber ist das wirklich ein Problem?*
Enterprise Java ist
• stabil
• verbreitet
• standardisiert
• btw: erstes E in JEE steht für Enterprise
* Warum nicht einfach auf verzichten?
19. Jakarta EE - The Missing Pieces
Was fehlt für Distributed Runtimes?
• Monitoring aka Health Checks & Metrics
• Distributed Tracing
• Distributed Config Mgt
• Fault Tolerance aka Resilience
• Security Context Propagation
20.
21.
22. Wie war das noch mit dem
Jakarta EE Core Profile?
32. Jakarta EE & MicroProfile
PRO
• Standards
• Micro & Makro
• schmal*
• schnell*
• flexibel
CONS
• Bootstrapping
• je mehr, desto* …
* ist stark abhängig von den eingebundenen APIs
34. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow mid-sized & kinda fast
„we ARE here“
„we CAME from here“
35. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow super slim & turbo fast
„we ARE here“ „we DREAM to be here“
„we CAME from here“
mid-sized & kinda fast
37. „I started thinking about my application’s performance—in this case,
the bootstrap time—and asked myself whether I was happy
with the actual time my application took to start up. The answer was no.
And, nowadays, this is is one of the most important
metrics to be considered when working with
microservices, mainly on a serverless architecture.“
Filipe Spolti, Red Hat
38. Aus der Rubik: „Spaß beim Startup …“
internal
once
element
Metadata
Processing
at Startup
41. Was bedeutet das für Cloud-native?
„Container First“ Ansatz von Quarkus
• schmale Pakete == kleine Container Images
• schnelle Boot Time == sofortiges Scale-up
• geringer RSS* Speicher == mehr Container**
*RSS = resident set size (all RAM consumed by a process),
** mehr Container bei gleichem RAM
44. Quakus Voodoo #1
Build-Time Optimization
Ein Großteil der „möglichen“ Dynamik zur
Laufzeit wird gar nicht benötigt. Daher lässt
sich die Auflösung deren Abhängigkeiten in
die Compile-Time verschieben.*
*@Inject, @Observes, @Path, @GET, …
55. Quarkus Voodoo #2
Ahead-of-Time Compilation
„Write once, run anywhere“ ist in Zeiten von
Containern und damit einheitlichen Laufzeit-
umgebungen optional.*
*Ahead-of-Time Compilation statt dynamisches scannen / laden von Klassen
72. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow super slim & turbo fast
Jakarta EE & MicroProfile plus Quarkus / AoT*
Old School J2EE
mid-sized & kinda fast
76. „You are NOT Amazon,
Twitter or Netflix.“*
* unless you are Amazon, Twitter or Netflix ;-)
77. Enterprise Java in Zeiten von Cloud & Co ….
Voodoo Regeln eXtended Version
• “FatJARs are evil.“
• „Layered Containers are good.“
• „Small layered Containers are even better.“
• „Small* layered native Containers are best.“
* Distroless Container Image als extreme Variante
79. „FATJars verlängern die
DEV Roundtrips unnötig.
Daher ist besser mit
mehreren unterschiedlichen
Layern zu arbeiten.“
*Don't Put Fat Jars in Docker Images:
https://phauer.com/2019/no-fat-jar-in-docker-image/