Reactive Amsterdam - Maxim Burgerhout - Quarkus Intro
•
0 j'aime•955 vues
Slides of Maxim Burgerhout from RedHat ( @MaximBurgerhout ). This presentation was given at the Reactive Amsterdam meetup: https://www.meetup.com/Reactive-Amsterdam , in collaboration with GOTO Nights Amsterdam. Recording of the talk is here: https://www.youtube.com/watch?v=X2NFGHQzQok
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Reactive Amsterdam - Maxim Burgerhout - Quarkus Intro
Similaire à Reactive Amsterdam - Maxim Burgerhout - Quarkus Intro (20)
Plus de Fabio Tiriticco
Plus de Fabio Tiriticco (13)
Dernier
Dernier (20)
Reactive Amsterdam - Maxim Burgerhout - Quarkus Intro
- 1. Goto Amsterdam Quarkus & KNative Quarkus&Kube-NativeJava 1 Maxim Burgerhout Roel Hodzelmans Business Development Manager Sr Solution Architect maxim@redhat.com roel@redhat.com @MaximBurgerhout @RoelHodzelmans
- 3. Growth in Application Architecture Choices Cloud Native Microservices Serverless Event-Driven Architecture Monolith 3
- 4. Quarkus & Kube-Native Java 4 Monolith Quarkus - Kubernetes Native Java Cloud Native Microservices Serverless Event-Driven Architecture Istio Knative
- 5. GraalVM 5 JVM CI Sulong (LLVM) Truffle Graal Compiler Substrate VM Java HotSpot VM
- 6. 6 “Just Enough Spring Boot” in Quarkus Quarkus 1.0 Quarkus 1.X In Discussion Goal ● Partial framework implementations ● Make Quarkus “familiar” to Spring developers ● Lower the bar for Spring developer adoption
- 7. Moving to Compile-Time Boot THOUGHTS FOR THE FUTURE 7 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 → minimal runtime reflection) Quarkus Optimizations A dynamic runtime on immutable infrastructure is unnecessary overhead
- 8. 8 Quarkus Extensions RESTEasy Netty HibernateORM HibernateValidator MPOpenAPI MPJWT EclipseVert.X Agroal(connpool) NarayanaJTA MPReactive Messaging ApacheCamel ... Quarkus Core Arc (DI) Jandex Gizmo Graal SDK HotSpot SubstrateVM
- 9. Java… the Enterprise Workhorse Microprofile Java EEJ2 EE Monolith Cloud-Native Microservices Serverless Event-Driven Cloud-Native Microservices
- 10. Experts from “cloud-native” Java OS projects Quarkus & Kube-Native Java 10 Eclipse Vert.x Hibernate Eclipse MicroProfileRESTEasy WildFly Undertow OpenJDK
- 11. Quarkus Benefits 11 Through low learning curve, developer efficiency, extension ecosystem Remain competitiveFaster time to market Modern software stack focused on containers and kube that enables fast experimentation and rapid delivery of changes in production Cost Savings .Low memory, fast startup, cloud efficiency, low learning curve, serverless, high density on K8s & cloud
- 12. Why Quarkus? 12 Live coding Unified configuration Developer joy Over 90 extensions “Powered by Quarkus” applications Best of breed libraries and standards Tailors your app for HotSpot & GraalVM Fast boot time and low RSS memory Serverless fit Container first Combines blocking and non-blocking Built-in event bus Unifies imperative and reactive “Quarkus has introduced a new paradigm that puts things upside down on the way things are run under the covers - supporting native, all reflection done at compile time and not runtime is just amazing!” - Talkdesk
- 13. 13 Benefit No. 1: Container First REST + CRUD Quarkus + GraalVM 0.055 Seconds Quarkus + OpenJDK 2.5 Seconds Traditional Cloud-Native Stack 9.5 Seconds Time to first response REST + CRUD Quarkus + GraalVM 35 MB Quarkus + OpenJDK 130 MB Traditional Cloud-Native Stack 218 MB “We went from 1-min startup times to 400 milliseconds”
- 14. 14 A cohesive platform for optimized developer joy: ● Based on standards and more ● Unified configuration ● Live coding ● Streamlined code for the 80% common usages, flexible for the 20% ● No hassle native executable generation Benefit No. 2: Developer Joy “Our developers used to wait 2 to 3 mins to see their changes. Live coding does away with this.”
- 15. 15 Benefit No. 3: Unifies Imperative and Reactive ● Combine both Reactive and imperative development in the same application ● Inject the EventBus or the Vertx context ● Use the technology that fits your use-case ● Key for reactive systems based on event driven apps @Inject SayService say; @GET @Produces(MediaType.TEXT_PLAIN) public String hello() { return say.hello(); } @Inject @Stream(”kafka”) Publisher<String> reactiveSay; @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Publisher<String> stream() { return reactiveSay; }
- 16. 16 Benefit No. 4: Best of Breed Frameworks & Standards Eclipse Vert.x Hibernate RESTEasy Apache Camel Eclipse MicroProfile Netty Kubernetes OpenShift Jaeger Prometheus Apache Kafka Infinispan Flyway Neo4j MongoDB MQTT KeyCloak Apache Tika “Reduced the time for developer productivity due to a small learning curve and existing expertise of the Quarkus extensions.”
- 18. Service Microservice Function > Single Purpose > Stateless > Independently Scalable > Automated > Single Action > Ephemeral > Autonomous > Loosely-coupled Architectural Evolution to Serverless f( ) 18
- 19. Serverless Requirements 19 “We went from 6-7 sec startup time with plain Java on AWS Lambda to 10 milliseconds with Quarkus” Platform that can... ● Scale to 0 ● Rapid scaling (up & down) ● Event mechanism ● Routing and Networking Applications that can… ● Startup quickly ● Respond quickly ● Low on memory ● Require small disk size
- 21. 21 Why do we need Serverless ? Cloud Agility Everywhere Event-driven Applications Focus On Business Results Consistent Scalability
- 22. Historical Enterprise Java Stack 22 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
- 23. Modern Enterprise Java Stack 23 Java Virtual Machine (Hotspot) Application Server App Dynamic Application Frameworks Architecture: Microservices Deployment: Single App App Lifecycle: Days Memory: 100MBs+ RAM Startup Time: Seconds No Change
- 24. Java Serverless Stack 24 Java Virtual Machine (Hotspot) Application Server App Dynamic Application Frameworks Architecture: Microservices Deployment: Single App App Lifecycle: Days Memory: 100MBs+ RAM Startup Time: Seconds No Change
- 25. Quarkus - Optimizing the Stack Quarkus & Kube-Native Java 25 App (Imperative / Reactive) Optimized Application Frameworks Architecture: Microservices, Serverless Deployment: Single App App Lifecycle: Milliseconds to Days Memory: 10MBs+ RAM Startup Time: Milliseconds Java Virtual Machine (Hotspot) Optional
- 26. Cloud Native Java Stack + containers Designing a Java Stack for the future 26 26 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 https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
- 27. Cloud Native Java Stack + containers Designing a Java Stack for the future 27 27 CONTAINER ORCHESTRATION Node EAP, WAS Liberty or Spring Boot EAP, WAS Liberty or Spring Boot EAP, WAS Liberty or Spring Boot EAP, WAS Liberty or Spring Boot Node NodeJS NodeJS NodeJS NodeJS NodeJS NodeJS NodeJS Node Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go Go https://developers.redhat.com/blog/2017/03/14/java-inside-docker/ Node Quarkus on JVM Quarkus on JVM Quarkus on JVM Quarkus on JVM Quarkus on JVM Quarkus on JVM Quarkus on JVM Node Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native Quarkus Native “We could run 3 times denser deployments without sacrificing availability and response times of services”