The road to Quarkus. Why and what to look for
summary
Quarkus claims big reductions in startup time and memory by moving reflection and classpath work to build time and producing GraalVM native images; demo shows a Katacoda weather app deployed as three versions on OpenShift (one on JBoss EAP, one MicroProfile 3.2, one Quarkus-built) with MicroProfile health, metrics exported to Prometheus and OpenTracing traces sent to Jaeger/Solr, all wired without application code changes. JBoss EAP lags MicroProfile support; Quarkus uses ArC DI and Vert.x for reactive IO and noticeably smaller footprints.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:08Java’s enterprise relevance
- 3:44Legacy Java modernization
- 6:23Kubernetes and cloud-native Java
- 7:49Spring Boot’s cloud limits
- 10:20Spring in containers
- 11:50Microservices pitfalls
- 12:58Jakarta EE evolution
- 15:55Customer feedback on Quarkus
- 17:02MicroProfile for cloud-native
- 21:42Jakarta EE vs MicroProfile
- 22:10Native compilation benefits
- 24:42Java SE and Jakarta EE for containers
- 26:42Startup and memory optimization
- 29:03Quarkus architecture
- 31:20Quarkus vs MicroProfile vs Jakarta EE
- 33:09Live demo: legacy to Quarkus
- 39:57Quarkus in OpenShift
- 44:14Quarkus vs Spring Boot performance
- 46:04Q&A
