tech11 Goes Quarkus: Revolutionizing Our Server Architecture And Optimizing Our Application Server Performance
The popularity of cloud-based environments, with their demands for high availability, high throughput and low cost, requires that service-oriented applications move from a monolithic approach with long boot times and large memory footprints to a future-proof solution.
To meet those demands and to compete with other programming languages, the Java ecosystem needed to evolve. Quarkusio was created to enable Java developers to build applications for a cloud-native world.
In the following article, we will explain our position on Quarkus and why we have chosen to migrate to this revolutionary framework.
What is Quarkus?
For Quarkus, the goal is to make Java the leading platform for Kubernetes and serverless environments.
The Quarkus website states: “Quarkus is a Kubernetes-native Java framework tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries and standards.”
They want to provide developers a framework that allows them to address a wider range of distributed application architectures.
Quarkus represents the application server revolution.
Which framework have we used so far?
Our existing Microservices are based on Jakarta EE and Microprofile running on Wildfly – a classic application server.
Why are we switching to Quarkus?
It is a new and better alternative for cloud support. Quarkus provides a lighter and faster development as well as runtime experience compared to other Java frameworks. It can also compile your Java code into a native executable thanks to distributions such as GraalVM, which means it can run without needing a Java Virtual Machine. The result is a much faster startup time and a smaller memory footprint, so there is less need for computing and memory resources. Additionally, Quarkus is a framework focused on developer productivity with many developer-friendly features. This allows developers to work more efficiently and get their applications up and running faster. Because Quarkus is focused on running well in cloud-native environments, meaning it runs easily in containers and is optimised for microservices architectures, it is a good choice for developers who want to build modern, scalable applications that can run anywhere.
Overall, Quarkus is a great choice in combining a focus on performance and efficiency with features that make it easy for developers to use and adapt to modern cloud-native architectures.
This means lower costs for tech11 and our on-premise customers!
Fact: Less usage of computing power and memory means less power consumption and costs – which makes it more sustainable. On an international scale, this could make a real difference!
Why are we switching to Quarkus only now?
Our work is always focused on the customer, and with a growing number of (micro) services, memory is starting to become a coefficient, so we have to find the right runtime.
With new microservice runtimes?like Quarkus, it is always wise to wait and see. When a framework has reached a certain level of maturity and gets enterprise support, then it is the right time to change. In our particular case, we have been waiting for exactly this level of maturity and extended ecosystem that Quarkus has now achieved to integrate it into our tech stack. We can now offer our customers the best solution with no impact on their production environments and ensure seamless migrations.
What changes for our on-premise customers?
Although cloud hosting is already possible, it will now also offer more potential for our on-premise customers, as they are partially using Kubernetes. In such environments, the startup time of an application is critical. From Wildfly (5 s) to Quarkus (100 ms), there is a huge improvement. In addition to the improved performance, there is also less memory consumption – and memory is essential for all scalable environments.
As we will need less server capacity and RAM, we will also be able to reduce costs for our customers.
领英推荐
What changes for our OPS team?
There are no changes except for slightly different configurations – environmental variables – and a version update.
What changes for tech11 developers?
The only change is the way our modules are executed locally. There should be no difference in the development – code – itself as we only rely on standards/specs like JakartaEE and Microprofile.
However, the developer experience might be different:
What are the alternatives to Quarkus?
Of course, there are many different ones, such as Helidon and Micronaut Framework - see GitHub for more alternatives.
Choosing the right framework for you will always depend on a number of factors, such as…
Our tip: Make sure you know exactly what you need and choose a runtime-environment that meets your needs.
What do our our developers think about Quarkus?
Marc Scheib , Software Architect, Backend:
Quarkus is the ideal solution for microservices development because it provides a simple, fast and well-performing way to run services without the need for an additional application server. It already has a vast ecosystem of extensions, along with great guides and examples, as well as integration support with major IDEs to provide an excellent development experience.
Fabian Halbmann, Software Architect, Backend:
I really like it, because now we can strip down our environment to just what we really need. It’s great to see the performance of native built modules and it’s really fun to work with Quarkus.