Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt 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 Nebenprojekten wie 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.

1. Ready for the Future?
Jakarta EE in Zeiten von Cloud Native & Co
#WISSENTEILEN
Lars Röwekamp | @mobileLarson

2. @mobileLarson
CIO New Technologies
OPEN KNOWLEDGE
Lars Röwekamp
Das bin ich >
(Architecture, Microservices, Cloud, AI & ML)

3. OPEN KNOWLEDGE
@_openknowledge
Und da arbeite ich
>

4. „Cloud native, yeah! “
Die ganze Welt
Die ganze Welt:
„Cloud native, yeah!“
Enterprise Java
„Hold my beer!“

6. Seien wir doch
mal ehrlich …

7. Seien wir doch
mal ehrlich …

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. Startup : ~ 5000 ms
Memory: >> 100 MB

12. 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 +++

13. EXKURS:
Jakarta EE 10 – Core Profile
• CDI 4.0 Lite*
• JSON-B 3.0
• JSON-P 2.1
• JAX-RS 3.1
• …some additional small stuff
*Introduce a new CDI-lite specification that targets
supporting build time compliation of applications.

16. Ok, vielleicht doch nicht soooo groß, aber …
APPLICATION
SERVER

17. Quelle: https://blogs.oracle.com/javamagazine/post/you-dont-always-need-an-application-server-to-run-jakarta-ee-applications

18. EAR / WAR
vs
Jakarta EE Application Server
My Application Jakarta EE Libraries Super Cool Vendor Stuff
Runnable JAR
Traditional App Server

19. Ok, dann gehen Microservices ja doch, …

20. Ok, dann gehen Microservices ja doch, oder?

21. Jakarta EE
Distributed Runtimes

22. „Ich will aber
mitspielen!“

23. 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 JEE verzichten?

24. Jakarta EE - The Missing Pieces
Was fehlt für Distributed Runtimes?
• Distributed Config Mgt
• Distributed Tracing
• Security Context Propagation
• Monitoring aka Health Checks & Metrics
• Fault Tolerance aka Resilience

27. Wie war das noch mit dem
Jakarta EE Core Profile?

29. Look Mom,
it‘s the CORE PROFILE!

30. > Microprofile

31. MicroProfile „Hello World“
pure JAX-RS
$ java –jar hello-world-bootable.jar
my_code server

32. MicroProfile „Hello World“
pure JAX-RS
$ java –jar bootable.jar --deployment=hello-world.war
my_code
server

33. MicroProfile „REST Service“
pure JEE APIs

34. MicroProfile
Health Check
via @Readiness

35. MicroProfile
Metrics
via @Timed

36. MicroProfile
Fault Tolerance
via @Timeout

37. MicroProfile
JWT Auth
via @Inject & @Claim

38. MicroProfile
JWT Auth
via @RolesAllowed*
*pure JEE

39. ~ 3000 ms / 70 MB

40. Jakarta EE & MicroProfile
PRO
• Standards
• Micro & Makro
• schmal*
• schnell*
• flexibel
CONS
• Bootstrapping
• je mehr, desto* …
* ist stark abhängig von den eingebundenen APIs

41. Jakarta EE
In Zeiten von Cloud-native & Co
ZWISCHENFAZIT

42. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow mid-sized & kinda fast
„we ARE here“
„we CAME from here“

43. 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

44. „Was genau war
noch einmal
das Problem?“

45. „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

46. Aus der Rubik: „Spaß beim Startup …“
internal
once
element
Metadata
Processing
at Startup

47. Aus der Rubik: „Spaß beim Startup …“

49. 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

50. Die Quarkus
Voodoo Regeln

51. „Build-Time
Optimization“
Voodoo #1: be small and fast

52. 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, …

53. .java
(plus dependencies)
.class
(regular)
(1) compile (2) run on JVM

54. .java
(plus dependencies)
.class
(regular)
.class
(optimzed)
(1) compile (2) optimize (3) run on JVM

55. * plus 16 MB /lib
~ 800 ms / 12 KB*
Quarkus
PROD
Mode
$ java –jar quarkus-app/quarkus-run.jar

56. ./mvnw package
FASTJar
Classloader
(since version 1.12)
> java -jar target/quarkus-app/quarkus-run.jar

57. 73 MB 136 MB
REST
Voodoo vs. Traditional:
Memory (RSS)
Quarkus + JVM
(via OpenJDK)
Traditional Stack
(cloud native)

58. 145 MB 209 MB
REST
+ CRUD
Voodoo vs. Traditional:
Memory (RSS)
Quarkus + JVM
(via OpenJDK)
Traditional Stack
(cloud native)

59. Voodoo vs. Traditional:
Boot & First Response
0.94s
4.3s
0 1 2 3 4 5 6 7 8 9
REST
Quarkus + JIT (via OpenJDK)
Traditional Stack (Cloud-native)

60. 2.0s
9.5s
0 1 2 3 4 5 6 7 8 9
REST
+ CRUD
Voodoo vs. Traditional:
Boot & First Response
Quarkus + JIT (via OpenJDK)
Traditional Stack (Cloud-native)

62. „Ahead-of-Time
Compilation“
Voodoo #2: be even smaller and faster

63. Quarkus Voodoo #2
Ahead-of-Time Compilation*
„Write once, run anywhere“ ist in Zeiten von
Containern und damit einheitlichen Laufzeit-
umgebungen obsolet.
*Ahead-of-Time Compilation statt dynamisches scannen / laden von Klassen

64. .java
(plus dependencies)
.class
(regular)
.class
(optimzed)
(1) compile (2) optimize (3) run on JVM

65. .java
(plus dependencies)
.class
(regular)
.class
(optimzed)
(1) compile (2) optimize (3) create native image
executable
(native)

66. ~ 20 ms / 40 MB
Quarkus
NATIVE
Mode
$ ./rest-service-runner

67. ~ 20 ms / 40 MB
Quarkus
NATIVE
Mode
$ ./rest-service-runner

68. 12 MB 73 MB 136 MB
Voodoo vs. Traditional:
Memory (RSS)
Quarkus + Natice
(via GraalVM)
Quarkus + JVM
(via OpenJDK)
Traditional Stack
(cloud native)
REST

69. 28 MB 145 MB 209 MB
REST
+ CRUD
Voodoo vs. Traditional:
Memory (RSS)
Quarkus + Natice
(via GraalVM)
Quarkus + JVM
(via OpenJDK)
Traditional Stack
(cloud native)

70. Voodoo vs. Traditional:
Boot & First Response
Quarkus + Native (via GraalVM)
0.016s
0.94s
4.3s
0 1 2 3 4 5 6 7 8 9
REST
Quarkus + JIT (via OpenJDK)
Traditional Stack (Cloud-native)

71. 0.042s
2.0s
9.5s
0 1 2 3 4 5 6 7 8 9
REST
+ CRUD
Voodoo vs. Traditional:
Boot & First Response
Quarkus + Native (via GraalVM)
Quarkus + JIT (via OpenJDK)
Traditional Stack (Cloud-native)

72. Aber was ist
mit WORA?

73. WORP* ist
dass neue
WORA!
*write once, run predictable

74. create native image
executable
(native)
containerize native image
docker container
(ubi/distroless)

75. „Power of
Standards“*
Voodoo #3: be convenient
* (de facto) Standards plus Quarkus Extension Framework

76. Quarkus Voodoo #3
Power of Standards
(Industrie)Standards als Basis nutzen bei
gleichzeitiger Möglichkeit von proprietären
Erweiterung.

77. .class
(regular)
.class
(optimzed)
optimize via Quarkus
optimized libraries
(3rd party & custom)

78. .class
(regular)
.class
(optimzed)
optimize via Quarkus
optimized libraries
(Jakarta EE Core Profile)
?

79. „Minimize Development
Turnaround Time“*
Voodoo #4: spark joy for developers
* and more, e.g Quarkus Testing Framework
+++BONUS MATERIAL+++

80. Quarkus Voodoo #4
Spark Joy for Developers
Das Maven Goal quarkus:dev erlaubt via
hot reaload* extrem kurze Turnaround-Zeiten
in der Entwicklung.

81. ./mvnw package ./mvnw quarkus:dev
*hot reload
in action

82. ~ 1200 ms / 10 KB*
* Paket besteht nur aus MANIFEST.MF (CP Info) und dev-mode-context.dat
Quarkus
DEV
Mode

83. * Experimental Developer UI

84. Und DAS
funktioniert?

85. Quarkus „Voodoo“
Limitations (GraalVM / SubstrateVM)
• Dynamic Classloading*
• Native VM Interfaces*
• Reflection*
• Dynamic Proxies*
• Class Path Resources* *muss via native-image CLI/API vorab registriert werden
(siehe auch: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md)

86. Quarkus „Voodoo“
Limitations (GraalVM / SubstrateVM)
• Dynamic Classloading*
• Native VM Interfaces*
• Reflection*
• Dynamic Proxies*
• Class Path Resources* *muss via native-image CLI/API vorab registriert werden
(siehe auch: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md)
„Brauche ich nicht!
Oder etwa doch?“

87. Quarkus „Voodoo“
Limitations (ArC DI / CDI)
• Conversational Scope
• Decorators
• Portable Extensions
• bean.xml ignored
• …

88. Quarkus „Voodoo“
Limitations (ArC DI / CDI)
• Conversational Scope
• Decorators
• Portable Extensions
• bean.xml ignored
• …
Quarkus
Extension
API*
*(siehe auch: https://quarkus.io/guides/cdi-integration)

89. Jakarta EE
In Zeiten von Cloud-native & Co
FAZIT

90. 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

91. Ok, aber
brauche
ICH das*
wirklich?
*super slim, turbo fast via AoT

92. Runtime Sicht auf Netflix User Management Microservice(s)
Death Star Architectures at it‘s best …

93. Death Star Architectures at it‘s best …

94. „You are NOT Amazon,
Twitter or Netflix.“*
* unless you are Amazon, Twitter or Netflix ;-)

95. 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

96. „FATJar sind böse?
Warum das?“

97. „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/

98. OS
JRE
app-v1.jar app-v2.jar app-v3.jar
70 MB
126 MB
63 MB 63 MB
63 MB

99. app-v1.jar 63 MB
DEPENDENCIES
53 MB
changes rarely
RESOURCES
8 MB
changes from
time to time
CODE
2 MB
changes frequently

100. OS
JRE
code-v1.jar code-v2.jar code-v3.jar
70 MB
126 MB
2 MB 2 MB
2 MB
Dependencies
Resources
53 MB
8 MB

103. Zeit für
Fragen?
Immer!

104. Vielen
Dank!
#WISSENTEILEN
by open knowledge GmbH
@_openKnowledge | @mobileLarson
Lars Röwekamp, CIO New Technologies

105. Folie 01: © Biletsky Egeniy, iStockphoto.com
Folie 05: © Ljubco, iStockphoto.com
Folie 06: © Orba Aljia, iStockphoto.com
Folie 44: © foxaon1987, Shuttertock.com
Folie 90: © Framework Wonderland, Shutterstock.com
All other pictures, drawings and icons originate from
• pexels.com, pixabay.com, unsplash.com,
• flaticon.com
or were made by my own.
BILDNACHWEIS