A Developer's Guide To Lift-And-Shift Cloud Migration: Detail
A Developer's Guide To Lift-And-Shift Cloud Migration: Detail
A developer’s guide to
lift-and-shift cloud migration
Table of contents
1 Introduction............................................................................................................................................... 2
5 Summary....................................................................................................................................................17
facebook.com/redhatinc
@redhat
linkedin.com/company/red-hat
redhat.com
Introduction
With the growing adoption of cloud models, many organizations are seeking ways to move to cloud-
native development. New applications can be developed entirely using cloud models and services,
exploiting microservices, autonomous development teams, agile and continuous deployment, and
containerized and orchestrated cloud deployments. Unfortunately, completely rewriting all legacy
applications is seldom feasible due to the required time and cost.
To remain agile and competitive, organizations must migrate and modernize existing JavaTM apps and
adopt cloud-native development. For most companies, this process involves reusing existing func-
tionality and data as much as possible, moving existing workloads to a modern deployment platform,
and finally applying new processes, products, and technology.
Once those steps are accomplished, developers can begin to “strangle the monolith” to incrementally
replace select in-app functionality with microservices.
This guide covers the lift-and-shift process using Red Hat® software, detailed in Figure 1 below,
involving:
1. Analyzing
an existing monolithic application using Red Hat Application Migration Toolkit and
migrating to open, standard interfaces.
2. Updating the code and configuration to run on Red Hat JBoss® Enterprise Application Platform.
3. Deploying
the monolith as a container on Red Hat OpenShift® Container Platform where features
like automatic scaling, integrated clustering, and failover can enhance the application.
• Thorntail/MicroProfile
• Spring Boot
• Node.js
• Eclipse Vert.x
Red Hat Application Migration Toolkit looks for common resources and highlights technologies and
known trouble spots when migrating applications. The toolkit provides a high-level view into the tech-
nologies used by the application, and offers a detailed report that organizations can use to estimate,
document, and migrate Java EE applications to Red Hat JBoss Enterprise Application Platform.
Note: Red Hat Application Migration Toolkit is typically only part of a larger application migration
and modernization program. These programs are usually comprised of well-defined and repeatable
phases over weeks or months, and can involve many people from a given organization.
To learn more about Red Hat’s philosophy and proven methodology, check out the Red Hat
Application Migration Toolkit documentation and developer homepage.
Red Hat Application Migration Toolkit can be installed and used in a few different ways:
• Web console. The web console for Red Hat Application Migration Toolkit allows a team of devel-
opers to assess and prioritize migration and modernization efforts for a large number of applica-
tions. It allows you to group applications into projects for analysis, and it provides numerous reports
that highlight the results.
• Eclipse plugin. The Eclipse plugin for Red Hat Application Migration Toolkit provides assistance
directly in Eclipse and Red Hat JBoss Developer Studio for developers making changes for a migra-
tion or modernization effort. It analyzes your projects using Red Hat Application Migration Toolkit,
marks migration issues in the source code, provides guidance to fix the issues, and offers automatic
code replacement when possible.
All of these access methods can be downloaded from the Red Hat Application Migration Toolkit page.
For installation instructions, please refer to the documentation for each of these access methods. For
multi-user scenarios, the web console is a good option. This document references the CLI for simplic-
ity. The steps that follow summarize operation of Red Hat Application Migration Toolkit.
Once the Red Hat Application Migration Toolkit CLI is has been installed, verify that the tool was
installed properly by running:
$ ${HOME}/rhamt-cli-4.0.0.Beta4/bin/rhamt-cli --version
> Red Hat Application Migration Toolkit (RHAMT) CLI, version 4.0.0.Beta4.
2. Run the Red Hat Application Migration Toolkit CLI against your project
The Red Hat Application Migration Toolkit CLI has a number of options to control how it runs. Here
the CLI is used to run against a project called monolith, generating a report by the same name.
Substitute ~/projects/monolith below with the name of your actual project under study.
$ ~/rhamt-cli-4.0.0.Beta4/bin/rhamt-cli \
--sourcemode \
--input ~/projects/monolith \
--output ~/rhamt-reports/monolith \
--overwrite \
--source weblogic \
--target eap:7 \
Note the use of the --source and --target options. These options allow you to target specific
migration paths supported by Red Hat Application Migration Toolkit. Migration paths include:
Wait for the toolkit run to complete before continuing. When complete, you should see something
similar to:
To view the report, direct your local browser at the following file:
~/rhamt-reports/monolith/index.html
You should see the landing page for the report as shown in Figure 2. The main report landing page
lists the applications that were processed, along with issues that were encountered. Each row on the
page contains a high-level overview of the story points, the number of incidents, and the technolo-
gies encountered in the application.
• The incidents and story points by level of effort of the suggested changes.
Note: Story points are an abstract metric commonly used in Agile software development to estimate
the relative level of effort needed to implement a feature or change. Red Hat Application Migration
Toolkit uses story points to express the level of effort needed to migrate particular application con-
structs—and the application as a whole. The level of effort will vary greatly depending on the size and
complexity of the application(s) to migrate.
• Application Details provides a detailed overview of all resources found within the application that
may need attention during the migration.
• Unparsable shows all the files that Red Hat Application Migration Toolkit could not parse in the
expected format. For instance, a file with a .xml or .wsdl suffix is assumed to be an XML file. If the
XML parser fails, the issue is reported in this section and also where the individual file is listed.
• Remote Services shows all remote services references that were found within the application.
• EJBs contains a list of Enterprise Java Beans found within the application.
• JBPM lists all of the Java Business Process Management-related resources that were discovered
during analysis.
• JPA contains details on all Java Persistence application programming interface (API)-related
resources that were found in the application.
• About describes the current version of Red Hat Application Migration Toolkit and provides helpful
links for further assistance.
Note: Some of the above sections may not appear depending on what actual issues were detected in
the project.
Now that the Red Hat Application Migration Toolkit report is available, you can begin migrating the app.
Many applications will have platform-specific code that needs to be updated to use standard Java EE
interfaces, including:
• Startup code to perform functions or schedule jobs upon starting or stopping the app.
In each case, the Issues Report will suggest possible solutions. In the real world, addressing some of
these issues may require additional thought as part of the migration. However, implementing these
changes makes the code much more portable.
After necessary changes have been made, Maven can be used to build and package the app to make
sure the changed code still compiles:
If the code builds successfully (displaying BUILD SUCCESS), you will be able to move on to the next
issue in the Issues Report.
Run the command below to clean the old build artifacts, re-execute the Red Hat Application
Migration Toolkit CLI, and analyze the new project. Again, substitute the location of your project for
~/projects/monolith.
~/rhamt-cli-4.0.0.Beta4/bin/rhamt-cli \
--sourceMode \
--input ~/projects/monolith \
--output ~/rhamt-reports/monolith \
--overwrite \
--source weblogic \
--target eap:7 \
~/rhamt-reports/monolith/index.html
After successful migration, the corresponding application should report zero (0) story points, indicating
that the app has been successfully modernized, and is now ready to be moved to Red Hat JBoss EAP.
Download the latest release of Red Hat JBoss EAP. Then install Red Hat JBoss EAP locally by running
the following command in the terminal window. Adjust the file name to match the downloaded version.
$ export JBOSS_HOME=$HOME/jboss-eap-7.2.0
Red Hat JBoss EAP provides a wildfly-maven-plugin tool that can stop, start, deploy, and configure
the platform directly from Apache Maven. After the maven-plugin tool is configured, it can be used to:
After using Red Hat Application Migration Toolkit, the application is largely standards-based. It can
be configured by launching Red Hat JBoss EAP to start, add resources, and shut down the applica-
tion, as follows:
Note: The reason we are using wildfly:start and wildfly:shutdown is because the add-resource
command requires a running application server. After we have added this resource we do not need to
run this command again.
Access the application by loading the following URL into your browser:
Before moving on, terminate the application by typing CTRL-C in the terminal window.
Open the pom.xml file and add a Red Hat OpenShift profile.
<profile>
<id>openshift</id>
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/webapp/WEB-INF</directory>
<filtering>true</filtering>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
<outputDirectory>deployments</outputDirectory>
<warName>ROOT</warName>
</configuration>
</plugin>
</plugins>
</build>
</profile>
• Username: XXXXXX
• Password: XXXXXX
You will see the Red Hat OpenShift Container Platform landing page:
• Name: coolstore-dev
This will take you to the project overview. There is nothing there yet, but that is about to change.
Use the CLI to deploy the components of the monolith. To deploy the monolith template using the
CLI, execute the commands below.
$ oc project coolstore-dev
$ oc new-app coolstore-monolith-binary-build
This step will deploy any databases required by the application as well as Red Hat JBoss EAP, but it
will not start a build for the application.
You can see the components being deployed on the Project Overview, but notice that there are “No
deployments for coolstore.” You have not yet deployed the container image built in previous steps,
but you will do that next.
In this development project, we have selected to use a process called binary builds. This process
builds locally and just uploads the artifact (e.g. the .war file) instead of pointing to a public Git repos-
itory and having the source-to-image (S2I) build process download, build, and then create a container
image for us. The binary deployment will speed up the build process significantly.
First, build the project once more using the openshift Maven profile, which will create a suitable binary
for use with Red Hat OpenShift Container Platform (this is not a container image yet, but just the
.war file). We will build the project with the oc command line.
Wait for the build to finish and the BUILD SUCCESS message.
Finally, start the build process that will take the .war file, combine it with Red Hat JBoss EAP, and
produce a Linux® container image. That image will be automatically deployed into the project, thanks
to the DeploymentConfig object created from the template:
Check the Red Hat OpenShift web console, and you should see the application being built. In this
case, a PostgresSQL database has already been deployed.
This command will be used often to wait for deployments to complete. Be sure it returns success when
you use it. You should eventually see:
Note: If the above command reports Error from server (ServerTimeout) then simply re-run the
command until it reports success.
When the process is complete, you should see the application deployed successfully with blue circles
for the database and the monolith:
Figure 13. Blue circles imply that the application has deployed successfully
Figure 14. Click the link to launch the application in your browser, running on Red Hat OpenShift Container Platform
Summary
This process has demonstrated how to migrate an existing Java EE app to the cloud with Red Hat
JBoss Enterprise Application Platform and Red Hat OpenShift Container Platform. Now you are
ready to start modernizing the application by breaking the monolith into smaller microservices in
incremental steps, while employing modern techniques to ensure the application runs well in a distrib-
uted and containerized environment.
redhat.com Copyright © 2019 Red Hat, Inc. Red Hat, Red Hat Enterprise Linux, the Red Hat logo, and JBoss are trademarks or registered trademarks of
#F19179_0919 Red Hat, Inc. or its subsidiaries in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the U.S. and
other countries. Java and all Java based trademarks and logos are trademarks or registered trademarks of Oracle America, Inc. in the U.S.
and other countries.