3 Years of Quarkus in Production, What Have We Learned?
summary
Quarkus is used at scale: a multi-module enterprise repo with 100+ Java devs doubles CI build time (example: 2 → 4 minutes) unless a Maven build cache is enabled, which drops repeated builds to a few seconds and supports a remote cache on Nexus/GitLab CI. Native (GraalVM) cuts idle memory from ~850 MB to ~110 MB and startup from ~7s to ~1s but increases native build time (~15s → ~1min) and complexity. Tracing uses OpenTelemetry with a slow-span filter to keep traces useful. Test profiles restart the app and slow test suites.
AI-written summary · about
chapters (16)
- 0:00Introduction and disclaimer
- 1:27Why Quarkus for migration
- 2:30Developer experience with Quarkus
- 6:21Splitting applications into modules
- 9:30Build caching benefits
- 13:05Secure deployment strategies
- 15:16Memory management in Kubernetes
- 18:06GraalVM native images
- 21:40Inner source and versioning
- 26:58Quarkus upgrades and breaking changes
- 28:44Dependency management pitfalls
- 31:16Testing with Quarkus profiles
- 34:51Minimizing test profile overhead
- 35:36Tracing and performance analysis
- 39:38Tracing as a profiling tool
- 40:21Q&A session
related talks
48m3 years of Quarkus in production, what have we learned?
59mQuarkus for Spring Developers
51mQuarkus why, how and what
45mQuarkus Unleashed
54mQuarkus: Java development turned into delight
48mWhy Quarkus Should Be Your Next Tech Stack: Faster, Greener & Happier
11mAll about Quarkus
45mFaster, greener, and happier- why Quarkus should be your next tech stack