Kubernetes Native Java and Eclipse MicroProfile | EclipseCon Europe 2019
1 like1,138 views
The document discusses the relevance of Java in the context of Kubernetes and cloud-native environments, outlining its evolution and current challenges, particularly regarding startup time and memory usage. It introduces tools and frameworks such as Eclipse MicroProfile and Quarkus aimed at optimizing Java for immutable architectures while maintaining compatibility with existing Java skills. The presentation concludes that adapting to modern cloud conditions requires a reevaluation of past solutions and further innovation in Java's ecosystem.
Kubernetes Native Java and Eclipse MicroProfile | EclipseCon Europe 2019
- 1. RED HAT Kubernetes Native Java and Eclipse MicroProfile (plus other things) Mark Little, VP Engineering, Red Hat
- 2. Who am I? ● Research into fault-tolerant distributed systems since 1986 ○ Arjuna, Argus, Isis/Horus, Emerald, Xerox, … ○ DCE, DCOM, CORBA, HTTP, Web Services, … ● Implemented world’s first 100% Java transaction service in 1995 ○ Yes, we’re still using it today! ● Active in OMG, OASIS, W3C, JCP, GGF and others ○ Co-author of a number of specifications and standards ● Visiting Professor at Newcastle and Lyon ● Industry ... ○ Various startups ○ Bluestone Distinguished Engineer, HP Distinguished Engineer ○ JBoss CTO in 2009 ● These days spend far too much time on conference calls, meetings etc! 2
- 3. Overview ● Why Java in the age of Kubernetes and Linux Containers? ○ Java is dead, right? ● Why did Enterprise Java need to change? ○ Kubernetes and Immutability ○ Incompatibilities with Java and Application Containers ● Eclipse MicroProfile ○ Eclipse Jakarta EE ● Quarkus and principles behind it may be a game changer ○ Optimised for immutable architectures ○ Can work in constrained environments, e.g., low memory footprint 3
- 4. Why is Java still important? ● Still a de-facto language for enterprise developers* ● Large skills base (7-10 million Java devs.)** ● Large and diverse ecosystem ○ Amazon, Fujitsu, Google, IBM, Microsoft, Netflix, Oracle, Pivotal, Red Hat, … ● Large, resilient community ● Much more than just the language! ● The innovation continues ○ Eclipse MicroProfile ○ Eclipse Jakarta EE ○ Java SE faster schedule ○ SubstrateVM 4 Sources: *Tiobe Index : https://www.tiobe.com/tiobe-index/ * IEEE Spectrum : https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2018 I** SlashData - 7.6 million active Java developers (State of Developer Nation, 16th Edition, Q4 2018)
- 5. Historical Enterprise Java Stack 5 Operating System + Hardware/VM Java Virtual Machine (Hotspot) Application Server App App App App App Dynamic Application Frameworks Architecture: Monoliths Deployment: multi-app, appserver App Lifecycle: Months Memory: 1GB+ RAM Startup Time: 10s of sec
- 6. And then along came ... 6
- 7. Monoliths are Evil? Microservices ..? 7
- 8. Followed closely by ... 8
- 9. And then … Kubernetes ● Open source project from Google ● The de facto standard for cluster management for Linux containers ● Packages Orchestration, service discovery, load balancing ○ All behind a simple REST API ● Immutable architectures 9
- 10. The “Java Problem” ● Designed for throughput at the expense of footprint ● Intended to be long running, less focus on startup speed ● Rich dynamic behavior built around mutable bare-metal systems ○ … yet Linux containers are primarily immutable ○ … frameworks and stacks built to leverage key Java capabilities such as dynamism ● Java is trying to pivot (JPMS, AOT, Graal, etc) ○ … but architectural changes to frameworks are required to truly benefit 10
- 11. 11 Container platform Node NodeJS NodeJS NodeJS NodeJS NodeJS NodeJS NodeJS Node Go Go Go Go Go Go Go Go Go Go Go Go Go Go Node HotSpot Heap HotSpot Heap HotSpot Heap HotSpot Heap
- 12. Why footprint matters in the cloud ● Memory is more important than throughput on containers ○ It’s more expensive (requires permanence), unlike CPU cycles ● Microservices multiply overhead cost ○ One app becomes N microservices (e.g. 20 microservices ~= 20GB today!) ● If we do nothing Java alternatives will take over (eventually) ○ Go, Python, Node, PHP, Rust etc. do not have this problem 12
- 13. What we really want ... 13 ● 1 monolith ≈ 20 microservices ≈ 200 functions ● Scale to 1 vs scale to 0 ● Start up time MONOLITH MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE MICRO SERVICE F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF F FFFFFFFFF
- 14. We need a Kubernetes native stack 14 14 Monolith Cloud Native Microservices Serverless Event-Driven Architecture Istio Knative
- 15. It starts with the JVM ● Linux container aware JVM efforts ○ Memory utilisation ○ Processor utilisation ● OpenJDK evolved to work better with Linux Containers ○ Shenandoah GC ● Eclipse OpenJ9 performance improvements ○ JIT-as-a-Service ● Compiled Java? ○ gcj ○ … Dalvik? ○ Avian ○ Excelsior JET ○ GraalVM ● JVM improvements are necessary but not sufficient 15
- 16. APPLICATION SERVER TRANSITION 16 Traditional Application Development Standardized Runtimes & Frameworks Kubernetes Optimized Middleware Application Services for OpenShift Hybrid Cloud App Development Container Platform Caching API Mgmt Business Rules HTTP/ REST Persistence Process Automation Integration Messaging TransactionSecurity Dependency Injection Domains DevOps Clustering Load Balancing Failover Rolling Updates Traditional Middleware + Java Application Server
- 17. Eclipse MicroProfile ● Open Source community specifications for Enterprise Java microservices ● 9 releases in 3 years ● 5 specifications in the pipeline 17 Community
- 19. 19
- 20. Eclipse MicroProfile 3.1 (Oct 2019) 20
- 21. Roadmap items ● Long Running Actions (yes, transactions for microservices!) ● GraphQL ● Reactive Relational Database Access ● Event Data ● Service meshes ● start.microprofile.io 21
- 22. 22
- 24. Eclipse Vert.x ● Responsive: fast, is able to handle a large number of events / connections ● Elastic: scale up and down by just starting and stopping nodes, round-robin ● Resilient: failure as first-class citizen, self-healing ● Asynchronous message-passing: asynchronous non-blocking development model ● 2014 JAX Innovations Award Winner 24
- 25. 25
- 26. 26 WHAT IS QUARKUS? QUARK: elementary particle / US: hardest thing in computer science
- 27. Moving to Compile-Time Boot 27 What does a framework do at startup time? ● Parse config files ● Classpath & classes scanning ○ for annotations, getters or other metadata ● Build framework metamodel objects ● Prepare reflection and build proxies ● Start and open IO, threads etc ● Moved as much as possible to build phase ● Minimized runtime dependencies ● Maximize dead code elimination ● Introduced clear metadata contracts ● Spectrum of optimization levels (all → some → no runtime reflection) Framework Optimizations
- 28. What about MicroProfile? ● Quarkus implements MicroProfile ● We all know the benefits of open standards … ○ No vendor lock-in so applications can be ported across implementations ○ Don’t like something then come in and help evolve it ● MicroProfile in Quarkus enables skills to be immediately brought to the problem ○ And applications from other implementations too! ● Aim to feed more innovations back to MicroProfile and beyond ○ Remember … the JVM needs love too, not just frameworks 28
- 29. 29 JVM CI Sulong (LLVM) Truffle Graal Compiler Substrate VM Java HotSpot VM
- 30. Benefit No. 1: Developer Joy 30 A cohesive platform for optimized developer joy: ● Based on standards (e.g., MicroProfile), but not limited ● Unified configuration ● Zero config, live reload in the blink of an eye ● Streamlined code for the 80% common usages, flexible for the 20% ● No hassle native executable generation ● Unifies imperative and reactive programming ○ Vert.x FTW! ● Re-architected many projects ○ Hibernate, Narayana, Netty, Infinispan, ...
- 31. Benefit No. 2: Supersonic Subatomic Java 31 Quarkus + SubstrateVM 13 MB Quarkus + OpenJDK Hotspot 74 MB Traditional Cloud Native Stack + OpenJDK Hotspot 140 MB REST
- 32. Benefit No. 2: Supersonic Subatomic Java 32 REST + CRUD Quarkus + SubstrateVM 35 MB Quarkus + OpenJDK Hotspot 130 MB Traditional Cloud Native Stack + OpenJDK Hotspot 218 MB
- 33. Benefit No. 2: Supersonic Subatomic Java 3333Boot + First Response Time (in seconds) Quarkus + GraalVM 0.014 Seconds REST REST + CRUD Quarkus + OpenJDK 0.75 Seconds Quarkus + SubstrateVM 0.055 Seconds Quarkus + OpenJDK 2.5 Seconds Traditional Cloud Native Stack 9.5 Seconds Traditional Cloud Native Stack 4.3 Seconds Time to first response
- 34. The New Truth about Java + Containers 34 CONTAINER ORCHESTRATION NodeNode Traditional Cloud-Native Java Stack Traditional Cloud-Native Java Stack Traditional Cloud-Native Java Stack Traditional Cloud-Native Java Stack Node NodeJS NodeJS NodeJS NodeJS NodeJS NodeJS NodeJS Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Node Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus Quarkus
- 35. Conclusions: rethinking the problem ● Our problems are not the same as they were 10 years ago ○ We can’t expect the same solutions to make sense! ○ Containers are small and primarily immutable ● To adapt, we must truly understand conditions and make different trade-offs ○ Eclipse MicroProfile offers a standard way to trim down services ○ But there’s still a lot more work to do across the entire stack ● Enable millions of Java developers to become truly cloud native 35