-
Notifications
You must be signed in to change notification settings - Fork 395
Quarkus: Runtime and Framework for Cloud-Native Java - Blog post #2 #2441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,183 @@ | ||
| --- | ||
| layout: post | ||
| title: 'Quarkus: A Runtime and Framework for Cloud-Native Java' | ||
| date: 2025-10-22 | ||
| tags: quarkus runtime framework performance cloud-native | ||
| synopsis: This post explores how Quarkus speeds up development, cuts costs, and streamlines cloud-native Java. | ||
| author: mmaler | ||
| thumbnailimage: /assets/images/posts/mmaler-blog-posts/quarkus-as-a-powerful-runtime.jpeg | ||
| --- | ||
| :imagesdir: /assets/images/posts/mmaler-blog-posts/2-Quarkus-as-a-powerful-runtime/ | ||
| ifdef::env-github,env-browser,env-vscode[:imagesdir: ../assets/images/posts/mmaler-blog-posts/2-Quarkus-as-a-powerful-runtime/] | ||
|
|
||
| = Quarkus: A Runtime and Framework for Cloud-Native Java | ||
|
|
||
| image::/assets/images/posts/mmaler-blog-posts/quarkus-as-a-powerful-runtime.jpeg[alt="Quarkus: Runtime and Framework for Cloud-Native Java", width=100%] | ||
|
|
||
| Cloud platforms favor services that start fast and stay lean. | ||
| Quarkus is engineered for exactly that. | ||
| Buildtime processing reduces runtime overhead and results in rapid startup, a small memory footprint, and frictionless deployment to containers, Kubernetes, and serverless. | ||
| If your Java services need to start in milliseconds, run dense on shared nodes, and still feel great to build, Quarkus was made for that job. | ||
|
|
||
| Quarkus is a Java runtime that seamlessly integrates popular frameworks and libraries, shaping both the structure of modern applications and the developer experience behind them. | ||
| In this post, “runtime” means the full execution stack in production: JVM or native, plus Quarkus and the integrated frameworks. | ||
|
|
||
| Quarkus itself can also work as a framework, as it constitutes a higher-level layer that provides structure and APIs. | ||
|
|
||
| == Why Quarkus stands out? | ||
|
|
||
| In modern software development, runtimes and frameworks form the foundation of productivity and consistency. | ||
| Frameworks promote uniformity, simplify infrastructure, and enable automation at scale. | ||
|
|
||
| image::1-history.png[alt="A brief timeline leading to modern Java and Quarkus", width=100%] | ||
MichalMaler marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Quarkus is a cloud-native Java runtime that integrates multiple frameworks and optimizes them for fast startup, low memory use, smooth Kubernetes and serverless deployments, and a great developer experience with live reload. | ||
| Live reload provides fast feedback by showing code changes immediately without recompiling or restarting the server. | ||
|
|
||
| In addition to speed and live reload, Quarkus integrates established Java specifications such as CDI, JAX-RS, and JPA, with implementations provided by Arc (CDI), RESTEasy (JAX-RS), and Hibernate ORM (JPA). | ||
| It also enforces its own conventions, drives behavior by using annotations, and defines how applications are structured. | ||
|
|
||
| In this sense, Quarkus is a framework that serves as a runtime and platform for cloud-native Java applications. | ||
| It also adheres to industry standards, offering compatibility with technologies such as Spring, Apache Kafka, and Apache Camel to support familiar, flexible development models. | ||
|
|
||
| == Quarkus as a versatile framework | ||
|
|
||
| Beyond staple traits of modern frameworks, Quarkus introduces two platform-defining features: buildtime optimization and deep extensibility. | ||
|
|
||
| * *Buildtime optimization*: Quarkus shifts work from runtime to build time wherever possible. | ||
| This approach reduces startup overhead and memory usage, resulting in a lean, fast, and efficient application tailored for production. | ||
| + | ||
| .Quarkus performs at build time what traditional frameworks do at runtime: reading configuration files, scanning annotations, and building a model of the application. | ||
| image::2-build-time-principle.png[alt="Buildtime principle in Quarkus: being fast by doing less at runtime", width=100%] | ||
| + | ||
| .Thanks to buildtime initialization, the resulting application starts faster and consumes less memory. | ||
| image::3-BuildTimeP-Benefits-JVM.png[alt="Benefits of Quarkus buildtime processing on the JVM", width=100%] | ||
| + | ||
| .All the benefits of buildtime initialization also apply when compiling to a native binary. | ||
| image::4-BuildTimeP-Benefits-native.png[alt="Benefits of Quarkus native image compared to JVM", width=100%] | ||
|
|
||
| * *Extensibility*: Quarkus exposes extension points for everything from startup hooks to request filters. | ||
| Over 800 link:https://extensions.quarkus.io[extensions] allow seamless integration with modern technologies such as Kafka, OpenTelemetry, and OpenID Connect. | ||
| + | ||
| These extensions integrate with Quarkus and participate in its buildtime and runtime lifecycle, making them first-class citizens of the Quarkus platform. | ||
|
|
||
| === Simplified developer experience | ||
|
|
||
| Frameworks succeed when they reduce complexity without sacrificing flexibility. | ||
| Quarkus does exactly that: | ||
|
|
||
| * Preconfigures popular libraries with sensible defaults. | ||
| * Offers unified configuration and developer tooling. | ||
| * Provides instant feedback with live reload and continuous testing. | ||
|
|
||
| This makes Quarkus both powerful and approachable. | ||
|
|
||
| You can start with a simple REST endpoint and scale it into a production-grade service without changing your development model. | ||
|
|
||
| .Frictionless developer experience: Vastly improved development feedback loop, unified approach to producing different package types, and using proven APIs that Java developers already know. | ||
| image::6-Frictionless.png[alt="Frictionless developer experience: live reload, dev services, continuous testing", width=100%] | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same problem - the font is too big. |
||
|
|
||
| These features give developers structure, sensible defaults, and clear conventions during development, and they deliver fast startup, low memory use, and operational consistency in production. | ||
|
|
||
| === Performance that matters | ||
|
|
||
| In practice, the two goals that matter most for production-grade frameworks at scale are fast startup and resilience against cascading failures. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here you use frameworks with a different semantics than in the previous paragraph. |
||
| Rapid startup improves elasticity and recovery, while resilience prevents local faults from spreading and enables services to handle failures gracefully. | ||
| For a broader industry perspective, see the link:https://cacm.acm.org/practice/application-frameworks/[ACM article on application frameworks]. | ||
|
|
||
| Quarkus shifts work from runtime to build time, thus enabling faster cold starts. | ||
| Additionally, it offers the option to generate native executables with GraalVM's native-image, enabling cold starts in milliseconds and a minimal memory footprint, resulting in higher pod density, quicker horizontal scaling, and lower idle costs. | ||
| As such, it enables cost-effective deployment in containers and serverless environments. | ||
|
|
||
| Native images often give faster startup and lower RSS; however, they can deliver lower peak throughput and exhibit scaling limits on multi-core machines. | ||
| Current native images typically use a single-threaded garbage collector, which is inefficient for large heaps and does not benefit from multiple cores. | ||
| We generally recommend native execution for services that run on smaller instances up to two vCPUs with roughly two to four gigabytes of RAM, where startup time and memory footprint dominate cost and user experience. | ||
|
|
||
| JVM execution, by contrast, takes longer to start and warm up. | ||
| However, it can achieve higher peak performance through just-in-time compilation, it scales well beyond two cores, and it offers more capable garbage collectors and tuning options. | ||
|
|
||
| Choose the mode that matches your workload profile, cold-start targets, and cost envelope, and let Quarkus maintain a consistent development model across both paths. | ||
|
|
||
| * If you optimize for native execution, audit reflection and resource usage, enable dead-code elimination friendly patterns, and consider profile-guided optimizations where appropriate. | ||
| * If you optimize for JVM execution, budget for warmup, enable the right GC for your heap and latency goals, and measure steady-state throughput under realistic load. | ||
|
|
||
| Quarkus also includes structured health checks, metrics, and tracing, which align the runtime with production standards from day one. | ||
|
|
||
| Taken together, these in production choices provide measurable wins, as the next examples illustrate. | ||
|
|
||
| image::7-success-stories.png[alt="Real-world success stories using Quarkus", width=100%] | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would note to use that picture but link to the success stories in text. |
||
|
|
||
|
|
||
| === Security | ||
|
|
||
| Quarkus uses a standards-first composable security model. | ||
| You enable what you need and configure it for your environment: | ||
|
|
||
| * **Transport:** Enable HTTPS in the application by configuring TLS. | ||
| * **Authentication:** Choose Basic, form-based, mTLS, OpenID Connect (OIDC), or WebAuthN. | ||
| * **Authorization:** Enforce RBAC on web endpoints with `@RolesAllowed`, `@DenyAll`, and `@PermitAll`. | ||
|
|
||
| This lets you apply the right security controls for each deployment. | ||
|
|
||
| === Observability and control surfaces | ||
|
|
||
| Common control surfaces, such as metrics, logging, tracing, and configuration, are essential for site reliability engineers (SREs) and platform teams. | ||
|
|
||
| Quarkus exposes: | ||
|
|
||
| * Unified logging with link:https://quarkus.io/guides/logging[`quarkus-logging`]. | ||
| * Structured metrics and tracing with link:https://quarkus.io/guides/telemetry-micrometer-to-opentelemetry[Micrometer and OpenTelemetry]. | ||
| * Unified configuration of all the application's aspects by using `application.properties` or environment variables. | ||
|
|
||
| This standardization enables automation and scalable monitoring. | ||
|
|
||
| === Modular and production-ready | ||
|
|
||
| Following a lean-core, modular-at-the-edge approach, Quarkus delivers: | ||
|
|
||
| * A minimal core for fast startup. | ||
| * Pluggable extensions for authentication, tracing, messaging, and more. | ||
| * Dev Services for automatic provisioning of databases, brokers, and containers in dev mode. | ||
|
|
||
| Whether you are building a prototype or deploying to OpenShift, Quarkus adapts. | ||
| This modularity spans both the framework-level APIs developers work with and the runtime behaviors that execute beneath them. | ||
|
|
||
| Because Quarkus modularity is declarative and unified across extensions, it supports a platform-like developer experience without the rigidity of traditional frameworks. | ||
|
|
||
| === Building your stack with Quarkus | ||
MichalMaler marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| We will explore this topic in depth in part three of this series. | ||
| For now, here is how Quarkus fits into the picture. | ||
|
|
||
| Frameworks can serve as a foundation for creating higher-level abstractions. | ||
|
|
||
| Quarkus fits naturally into this model—not by becoming a platform itself, but by enabling teams to build their customized stacks and frameworks on top of it. | ||
|
|
||
| Unlike many traditional frameworks, Quarkus provides a unified extension architecture that supports deep customization. | ||
| Organizations can tailor Quarkus to fit specific domains, technologies, or compliance needs. | ||
| This enables the creation of organization-specific developer experiences, including internal stacks built on a unified Quarkus extension architecture. | ||
|
|
||
| By encouraging consistency, offering buildtime integration, and exposing clean extension points, Quarkus supports the creation of opinionated, scalable internal frameworks without forking or reinventing the core. | ||
|
|
||
| By packaging Quarkus extensions, curated defaults, and service templates into an internal Quarkus stack, teams focus on business logic. | ||
| At the same time, your framework layer standardizes infrastructure, security, and operational integrations across services. | ||
| This has been exemplified by Logicdrop, which refactored its entire Spring Boot stack with Quarkus, reducing container size by ~75%, achieving sub-second startup times, and significantly improving developer productivity. | ||
|
|
||
| For more information, see the link:https://quarkus.io/blog/logicdrop-customer-story/[Logicdrop customer story] and their link:https://quarkus.io/blog/logicdrop-automating-quarkus-with-gitlab/?utm_source=chatgpt.com[GitLab automation write-up]. | ||
|
|
||
| == Conclusion | ||
|
|
||
| Quarkus unifies the strengths of a development framework and a runtime. | ||
| As a framework, it provides structure, conventions, and a cohesive developer experience. | ||
| As a runtime, it delivers fast startup, low memory use, and operational consistency in the cloud. | ||
| This dual role helps teams standardize practices, reduce costs, and ship resilient cloud-native services. | ||
|
|
||
| Quarkus is built in the open under the Apache License 2.0, governed with the Commonhaus model, and developed end-to-end on GitHub. | ||
| Beyond the core project, the ecosystem includes the link:https://hub.quarkiverse.io/[Quarkiverse Hub], a community-run collection of Quarkus link:https://quarkus.io/extensions/[extensions] and related projects. | ||
| The Quarkiverse Hub provides repository hosting with build, CI, and release publishing, so features land as versioned, testable modules you can adopt, fork, or extend. | ||
|
|
||
| image::8-expectations.png[alt="Setting expectations for performance and developer experience with Quarkus", width=100%] | ||
|
|
||
| So, that’s all for now, thank you for reading, and let’s meet again in the third article of this series, which will cover building your own stack with Quarkus. | ||
|
|
||
| For a closer look at how Quarkus makes Java cloud-native, see the https://quarkus.io/blog/mmaler-blogpost-1-intro/[introductory blog post]. | ||
Uh oh!
There was an error while loading. Please reload this page.