Legacy Application Modernization in the Energy Sector: When the Monolith Becomes a Brake

The Starting Point: A Jakarta EE Monolith at Its Limit

Our client, one of the leading transmission system operators in Germany, faced a classic dilemma. A business-critical application was based on a monolithic Jakarta EE (JBOSS EAP) stack. The software worked, but it was rigid.

The challenges were typical for established enterprise IT:

• Lack of scalability: The system could not react flexibly to load peaks.
• High latency: Computationally intensive tasks (including Matlab calculations) slowed down the entire application.
• Dependencies: Changes to a single module required the deployment of the entire monolith.
• Outdated communication: A classic Message Queue (JMS) reached its limits when networking with modern systems.

The goal was clear: the application had to become Kubernetes-ready to support long-term supply security and the integration of renewable energies. However, a pure "lift & shift" into a container would have simply carried over the architectural problems. A true modernization was required.

The Strategy: From Monolith to Microservices with Quarkus

In legacy application modernization within CRITIS (Critical Infrastructure) environments, the risk of failure is the greatest concern. Therefore, together with the client, we decided against a "big bang" approach and opted for an iterative transformation following the Strangler Fig Pattern (gradual replacement).

The technological core of the modernization: Quarkus. The Java framework ("Supersonic Subatomic Java") was chosen to leverage the team's existing Java expertise while drastically reducing resource consumption and optimizing startup times for the container environment.

A significant advantage for daily work is the Quarkus DevMode: it considerably simplifies (local) development by applying code changes in real time without the need for manual rebuilds or application restarts. This immediate feedback loop not only makes the development process more efficient but also reduces the cognitive load for developers, as the focus remains on the code rather than the tooling.

The Architectural Transformation in Detail

To make the application future-proof, we adjusted several key levers simultaneously:

• Microservices instead of Monolith: The application was decomposed into functional services. Critical modules were isolated and migrated to Quarkus.
• Dual-Mode Deployment: A decisive step for risk minimization: we enabled modules to run transitionally in both the old JBOSS context and the new Quarkus environment. This allowed for system tests on the live object without interrupting functionality.
• Event-Driven Architecture with Kafka: The old JMS queue was replaced by Apache Kafka (Redpanda). This not only enabled more stable asynchronous communication between the new microservices but also opened the architecture for future real-time scenarios.
• Scalable Calculations (Matlab): The computationally intensive "Matlab Application Runner" was decoupled as an independent, scalable service in Kubernetes. The result: latency during high-load phases was drastically reduced, as this service can now scale independently of the rest of the application.

Platform Engineering: Automation and Security

Modernizing the codebase yields little if the infrastructure is managed manually. Parallel to the software migration, we established modern platform engineering principles.

• GitOps & CI/CD: Use of Gitea Actions and GitLab CI for automated tests and builds.
• Deployment: Utilizing ArgoCD (App-of-Apps pattern) for declarative, traceable deployment into the clusters.
• Local Development Environment: Developers can now simulate the entire microservice landscape locally (via Kind, Docker), which enormously shortens "feedback loops."
• Data Management: Replacing database blobs with versioned storage in S3 and implementing modern caching solutions to minimize system load and ensure high data availability across various replicas.

Co-Creation: Modernization is a Team Effort

Technology is only half the battle. A key success factor was knowledge transfer. We did not implement the project as a "black box" process but worked closely with the client's in-house development team.

Through pair programming and joint architecture sessions, the TSO employees built deep expertise in Quarkus, Kubernetes, and streaming technologies. Upon project completion, the team was able to operate and further develop the new microservices landscape independently.

Conclusion: Stability Through Change

This project demonstrates that legacy application modernization is possible even in highly regulated, security-critical sectors. Today, the client benefits from:

• Scalability: Services breathe with the load.
• Maintainability: Smaller, decoupled modules instead of an unmaintainable giant.
• Security: Current standards and container isolation.

The modernization has eliminated the risk of a bottleneck and ensures that the IT systems are equipped for the requirements of the energy transition.

Are you facing a similar challenge with legacy Java landscapes? Let us jointly examine what a modernization roadmap for your core systems could look like—from architecture to the enablement of your team.

[Learn more about Cloud & Modernization at Steadforce]

‍