How to make Java programs cloud-ready: An incremental approach using Jakarta EE and MicroProfile

Modern enterprises are moving applications into the cloud, often using a microservices architecture. This presents a challenge for legacy applications that were designed for standalone, on-premises servers. These applications must be able to interact with other services that are tailored to the cloud along the lines of the twelve-factor app rules. Your applications should offer tracing, monitoring, and metrics to ensure availability and good performance. If you move Java applications to the cloud, you are likely to find their size and memory footprint burdensome, because instances have to be uploaded quickly and run on lean systems.

Luckily, several tools exist to ease the transition of enterprise Java applications to the cloud. This four-part series takes you through the steps to make a Java application cloud-ready. All the tools are free and open source, and we'll run them on Red Hat JBoss Enterprise Application Platform (JBoss EAP) and Red Hat OpenShift Container Platform. Very little Java code needs to be added to the application; we will accomplish nearly everything through tooling and configuration files.

Read the whole series:

• Part 1: An incremental approach using Jakarta EE and MicroProfile

• Part 2: Upgrade the legacy Java application to Jakarta EE

• Part 3: Integrate MicroProfile services

• Part 4: Optimize the runtime environment

Java for the cloud and microservices

Too many developers and architects associate Java EE and Jakarta EE only with monolithic applications and application servers. The monolithic applications are commonly seen as static, not easily updatable, and lacking a path where they can evolve to use the features implemented by a container architecture and cloud environments.

In reality, several of the major Java frameworks are being used to build cloud applications, taking advantage of the evolution of Java specifications to support lighter-weight and distributed applications. Legacy applications can also be upgraded, as you will see in this series. The upgrade path rests on three community-driven specifications:

• Jakarta EE: A specification that allows the evolution of Java applications for containers and the cloud.
• MicroProfile: A set of packages providing tools that are valuable when developing for the cloud.
• Galleon: A popular packaging framework that offers fine-grained control over the contents of an image running an application.

Red Hat implements this set of specifications using JBoss EAP and OpenShift.

To demonstrate how to upgrade a monolithic application using these technologies, I adapted a simple project named weather-app-eap, which is based on Java API for RESTful Web Services (JAX-RS) and Java Persistence API (JPA). The source code is taken from the GitHub page for the weather-app application, which is used in the O'Reilly Media Katacoda course Getting Started with JBoss EAP on OpenShift. I updated the code to run on top of JBoss EAP 7.2.9 and OpenShift 4.7.

After that, I upgraded the application in three steps:

• Moved it from Java EE to Jakarta EE, which sets the stage for the following transformations.
• Inserted MicroProfile specifications to implement patterns needed by cloud applications.
• Optimized the container runtime image to create a more efficient container.

Each of these upgrades will be covered by one article in this series. In this first article, we will focus on setting up the example application for the demonstrations to come. In Part 2, we will upgrade the legacy Java application to Jakarta EE.

Environment and source code

The following components were used to develop the example application for this series:

• Red Hat CodeReady Containers (if you need a local OpenShift instance) or an OpenShift installation (I used version 4.7)
• JBoss EAP 7.3
• JBoss EAP XP 2.0
• Apache Maven 3.5.4
• OpenJDK 11
• Git 2.31.1

The source code is available on my GitHub repository. To better follow the project's evolution, I created three tags for the three application versions:

• Jakarta_EE_version
• MicroProfile_version
• Galleon_Runtime_version

Get the demo application

Your first step is to get the source code needed for the demonstration. Open a terminal, select a directory, and clone the Git repository using the following command:

$ git clone https://github.com/mvocale/JBoss_EAP_cloud_ready.git

Now, go to your project directory and switch to the Jakarta_EE_version tag, where I stored the code used to transform our Java EE 8 application into a Jakarta EE 8 application:

$ git checkout tags/Jakarta_EE_version

The repository contains two subprojects:

• weather-app-eap: The project source code based on Java EE 8, that will run using JBoss EAP 7.2 and OpenShift 4.7. This subproject will remain the same throughout our journey.
• weather-app-eap-cloud-ready: The source code that we will modify to make the Java EE 8 application cloud-ready.

You can also find a shell script, deploy-openshift.sh, that contains all the instructions needed to install the components implemented on top of OpenShift. If you don’t want to perform every single step that I describe, you can establish a connection with CodeReady Containers or an OpenShift remote cluster and launch the application there.

Deploy the application on OpenShift

Now we will connect to OpenShift to deploy the application developed using Java EE 8 and JBoss EAP 7.2. If you decided to use Red Hat CodeReady Containers, start it and log in as a developer using the following commands:

$ crc start
$ oc login -u developer -p developer https://api.crc.testing:6443

Otherwise, if you have an available OpenShift environment, log in as follows, replacing the $token and $server_url placeholders with the proper values:

$ oc login --token=$token --server=$server_url

Create the project that will host your application:

$ oc new-project redhat-jboss-eap-cloud-ready-demo --display-name="Red Hat JBoss EAP Cloud Ready Demo"

Create and configure the PostgreSQL database

The application needs a database to store information; we will use PostgreSQL for this purpose. Create and configure the database next:

1. Import the image containing the application:

   $ oc import-image rhel8/postgresql-12 --from=registry.redhat.io/rhel8/postgresql-12 --confirm

2. Create the PostgreSQL application:

   $ oc new-app -e POSTGRESQL_USER=mauro \
     -ePOSTGRESQL_PASSWORD=secret \
     -ePOSTGRESQL_DATABASE=weather postgresql-12 \
     --name=weather-postgresql

3. Add the PostgreSQL icon to your database:

   $ oc patch dc weather-postgresql --patch '{"metadata": { "labels": { "app.openshift.io/runtime": "postgresql" } } }'

Import the JBoss EAP 7.2 OpenJDK 8 image

Now, import the JBoss EAP 7.2 OpenJDK 8 image that we will use to deploy the traditional application:

$ oc import-image jboss-eap-7/eap72-openshift --from=registry.access.redhat.com/jboss-eap-7/eap72-openshift --confirm

Build and deploy the application

Finally, build and deploy your application:

1. Create a new build for the application:

   $ oc new-build eap72-openshift --binary=true --name=weather-app-eap

2. Run the Maven build:

   $ cd weather-app-eap && mvn clean package

3. Start the build for your application:

   $ oc start-build weather-app-eap --from-file=target/ROOT.war --wait

4. Create the application:

   $ oc new-app weather-app-eap -e DB_SERVICE_PREFIX_MAPPING=weatherds-postgresql=DB \
    -e DB_JNDI=java:jboss/datasources/WeatherDS \
    -e DB_DATABASE=weather \
    -e DB_USERNAME=mauro \
    -e DB_PASSWORD=secret \
    -e DB_DRIVER=postgresql \
    -e DB_NONXA=true \
    -e DB_URL='jdbc:postgresql://$(WEATHER_POSTGRESQL_SERVICE_HOST):$(WEATHER_POSTGRESQL_SERVICE_PORT)/weather'

5. Expose the route in order to test the application:

   $ oc expose svc weather-app-eap

6. Add the JBoss EAP icon:

   $ oc patch dc weather-app-eap --patch '{"metadata": { "labels": { "app.openshift.io/runtime": "eap" } } }'

Explore the application on OpenShift

If you have successfully deployed the application, you can see it in the OpenShift console, as shown in Figure 1.

Now, select the application from the topology view, at the bottom of the Resources tab, as shown in Figure 2.

Click the link under Routes—>Location to view the application's output, as shown in Figure 3.

Conclusion to Part 1

We've gone through these steps to ensure that you can get the legacy Java application running. In the articles that follow, we'll perform part of the upgrade. At the end of each article, the application will be deployed and usable, just as it is now.

Next up: Part 2: Upgrade the legacy Java application to Jakarta EE.