Cloud-native and Enterprise Java? Hold my beer!
0 gefällt mir56 aufrufe
Das Dokument diskutiert die Herausforderungen und Entwicklungen von Jakarta EE im Kontext von Cloud-Native-Architekturen und Microservices, insbesondere die Veränderungen mit Jakarta EE 10, das ein minimalistisches Core Profile einführt. Es hebt die Vorteile von Quarkus hervor, wie schnellere Startzeiten und geringeren Speicherbedarf, und erläutert, wie moderne Laufzeitumgebungen die traditionellen Konzepte von Enterprise Java transformieren. Abschließend wird betont, dass ein adaptiver Ansatz bei der Softwareentwicklung in Zeiten von Container-Technologien und Microservices entscheidend ist.
Cloud-native and Enterprise Java? Hold my beer!
- 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
- 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?
- 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
- 37. MicroProfile JWT Auth via @Inject & @Claim
- 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
- 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
- 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
- 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