Modernizing legacy applications with Quarkus

For a long time, companies chose Java Enterprise Edition (later renamed Jakarta EE) and application servers such as JBoss or Wildfly to run large, business-critical applications. This combination undoubtedly offered advantages over other solutions, including an extensive ecosystem of mature libraries, stable programming interfaces, and reliable further development.
Ever since cloud and container-based software operations became popular in the 2010s, older monolithic applications have increasingly become a burden and make it difficult to implement a modern cloud strategy. The main reason for this is the traditional operating model of classic Jakarta EE application servers. These application servers run as heavyweight, independent processes within the Java Virtual Machine. They bundle all Jakarta EE functions in a central runtime environment and host one or more applications within it.
The high resource consumption and slow start-up time of an application server pose a major problem in a cloud environment. In on-premises operations, the resources are available and hardly cause any additional costs once the hardware has been provided. In cloud operations, they represent a significant cost factor. In addition, the high resource consumption, the complex configuration, and an operating model that is not container-oriented prevent efficient horizontal scaling. However, this is precisely what is important to take advantage of the benefits of the cloud.
 

Due to the problems described, companies are faced with the question of how to deal with their old applications. Completely redeveloping functioning and proven applications involves considerable risks. These applications contain knowledge about business processes and optimizations gained over many years. Reconstructing all the solutions and decisions that went into them would require an unforeseeable amount of effort. What’s more, implementing them in a technology that the core developers are not familiar with can lead to new errors and problematic solutions.
Modernization is a much simpler approach than developing something new. Quarkus is a modern and powerful Java framework that is particularly well suited for modernizing Jakarta EE applications.
 

In fact, Quarkus is more than just a framework. It is a technology stack for developing cloud-oriented, high-performance applications. Unlike Spring Boot, for example, Quarkus does not rely on completely new technologies. It continues to use the familiar and proven interfaces of Jakarta EE, which already form the basis of applications on application servers such as JBoss or Wildfly.
According to the Quarkus mission statement, the stack is crafted from the best of breed Java libraries and standards. This enables a large part of the existing code to be reused. Developers who have been working with Jakarta EE for years will quickly learn how to use the Quarkus ecosystem and can continue to apply the knowledge they have acquired.

Quarkus also offers many advantages that make it perfect for modern applications:

• Quarkus pursues a “container first” approach, which makes it particularly easy to develop for a cloud environment.
• Quarkus applications start up quickly and don’t use a lot of resources during runtime. By compiling them as native applications, it is possible to optimize them further.
• A large number of extensions, an active community, and support from large companies such as RedHat and IBM ensure continuous maintenance and further development.
• Extensive support for developers and a consistent focus on the goal of developer joy ensure that developers remain satisfied and highly productive. Fast development iterations and useful tools help to bring new features to production maturity quickly.

Despite all the advantages that Quarkus offers, every migration also brings its challenges. For example, Quarkus implements the Jakarta EE standards like the classic application servers, but not to the same extent. Migration from Enterprise Java Beans (EJB) to the lean CDI-based beans requires the most adaptation. 
In addition, connecting legacy peripheral systems can be very challenging. Not everything that was previously complicated in the application server and required individual solutions can be transferred to Quarkus without further adaptation.
As a general rule, migration is easier when an application has closely followed the Jakarta EE standard and its implementation has incorporated best practices as far as possible. On the other hand, more individual solutions or deviations from the standard mean that migration is more complex and redevelopment of individual application parts is needed more often.
 

At ti&m, we help our customers to modernize their software. We contribute our many years of experience in maintaining classic Jakarta EE applications and developing modern cloud solutions.
We always start by analyzing the existing application and its peripheral systems. We determine which components can be adopted with only minor adjustments, which components require more significant modifications, and which require new solutions.
We then work with the customer to draw up a plan for the migration and put it into action with the customer and their developers. It is particularly important to us to avoid big-bang releases. Instead, we proceed in manageable iterations of limited scope and risk. 
At the same time as the actual development, we train the customer’s developers. Our aim is to ensure that the developers who have worked on the application previously will also be able to maintain it in the future. Building on their existing knowledge of the application and the Jakarta EE standards, we teach them the necessary skills for developing with Quarkus.
The goal is to create a modern application that will continue to reliably support the customer’s business-critical processes in the future. It has to be easy to develop and must enable smooth operation in the cloud.