Compute Services

WebSphere on the Cloud: Application Modernization

Share this post:

Do you have existing Java applications running on WebSphere Application Server? Do you want to migrate them to the cloud? Are you looking for faster migration, easier deployment, and cheaper overall management? Are you thinking of a way to migrate your application with minimal changes?

If so, you are in the right place! Maintaining the older, back-leveled applications becomes increasingly difficult and costly as time goes on. Using the right strategy, it is easy to migrate your WebSphere applications to stay current with minimal changes at lower costs.

In our last post, we took high-level view of our process for moving WebSphere applications to the cloud. If you haven’t read that one yet, see Taking WebSphere Applications to the Cloud! for an end-to-end overview of what our process entails. You can also read more details covering all phases of our work in our GitHub repository, available at github.com/ibm-cloud-architecture/refarch-jee.

Today we will focus on Modernizing the Existing Application. This is also documented in more detail in phase1.md on GitHub. We’ll be covering the highlights here in this blog post.

Note: If you are not familiar with the IBM Cloud Reference Architectures and their benefits, check them out in the IBM Cloud Garage Method:

The bulk of our initial work is done by tools provided in the WebSphere Application Server Migration Toolkit. As a reminder, our goal is to run our production workload on IBM WebSphere Application Server on Cloud, running on IBM Bluemix, using the “lift and shift” methods we’ll cover here.

Application Modernization Steps

IBM WebSphere Application Server on Cloud moves the applications to the cloud without making any changes to them. The same applications and workloads of the existing IBM customers on-premise and new IBM customers can run on IBM cloud too. However, WebSphere on Cloud supports only WebSphere Application Server version 8.5.5 or higher.

As such, we’ll need to leverage the tools provided to plan, assess, and migrate our existing, stable WAS7-based Enterprise Java application to a suitable version that will run on WebSphere on Cloud. We’ll do this in four simple steps:

  1. Planning
  2. Assessment
  3. Source Migration
  4. Configuration Migration

The following steps walk you through the process of applying the WebSphere application migration techniques to our example application, Customer Order Services. This application, along with documentation and setup instructions, is available in the ibm-cloud-architecture/refarch-jee-customerorder/tree/was70-dev project on GitHub.

Step 1: Planning

To successfully move to newer versions of WebSphere, a set of tools will assist with evaluating the cost of transferring your application. This step covers the Migration Strategy, Migration Discovery, and Total Cost of Ownership (TCO) tools available in the WebSphere Application Server Migration Toolkit.

Migration Strategy Tool

Do you want to learn about migration alternatives for the future of your WebSphere applications? We sure wanted to know what our options were, just in case we had better options than what was preselected in WebSphere on Cloud.

Using the Migration Strategy Tool, you will be asked a series of questions, which lead down a choose-your-own-adventure type path for all the possible combinations of deployment targets.

In our case, after easily navigating the questions, we validated our decisions for WebSphere on Cloud as our deployment target. To reduce our overall capital expenditure, we were looking for a hosted cloud service with minimal code-change and re-architecture needed. Something WebSphere on Cloud is perfect for and this tool confirms our decisions!

Migration Discovery Tool

Now our next steps are planning how much effort is required to move our applications from their existing infrastructure to WAS on Cloud. Fortunately, we can get a quick, free, and completely anonymous estimate online. The Migration Discovery Tool provides a rough estimation (in number of days) of the required effort to migrate our Customer Order Services application to WebSphere through a questionnaire and analysis of historical data.

The tool walks you through a couple of questions related to the installation, application and testing. Based upon your answers, it generates a summary of the rough order of magnitude (ROM) estimations, scope, timeline required to migrate your application to the desired target platform.

The results above are from an assessment of our WAS7-compatible Customer Order Services application. As different resources will move through the migration process at different speeds, there are best, expected, and worst case assessments provided, as well as breaking down specific required activities that are needed throughout the migration. This is a great validation and reminder tool to plan your overall migration effort!

WAS V9 TCO Calculator (On-Premise and Cloud Cost Calculator)

Did you ever compare the on-premise and cloud costs? How do you know which costs you less? As reducing capex is one of our main concerns, we need to be aware of the total cost of ownership and the impacts on it when moving to WebSphere on Cloud.

For this, you can use WAS V9 TCO Calculator . It shows all the initial projection costs for creating new applications or to move the existing applications to Bluemix. This detailed report helps you decide whether to keep the application on-premise or to move it to the IBM Cloud.

See above: It shows a sample projection for maintaining our current Customer Order Services application on-premise, compared to running it on WebSphere on Cloud on Bluemix. If you look at the chart on the right, it’s close to a 67{07c2b926d154bd5dc241f595a572d3349d41d98f2484798a4a616f4fafe1ebc0} savings over the course of three years! That lines up with our goal of reducing capex!

Step 2: Assessment

Reviewing your application provides a better understanding of all potential issues during the migration process. This evaluates the programming models in the application and suggests what WebSphere products support them. For this process, you can use the WebSphere Migration Toolkit for Application Binaries.

The three steps in the Assessment portion of our work are:

  • Evaluation
  • Inventory
  • Analysis

The Evaluation report gives a high-level overview of the programming models found in the application, the WebSphere products that support these programming models, and the right-fit IBM platforms for the JEE application. The Inventory report contains a high-level index of the content and structure of each application, as well as information about potential deployment problems based on the existing Java code. Finally, the Analysis report contains details about potential migration issues in your application. This report gives details about which rules were flagged for your application binaries.

The output of the reports were run against our WAS7-based production-level EAR file for Customer Order Services, which can be built following the directions here.

Evaluation

This is the evaluation report of the reference application Customer Order Services for WAS 7.0. As you can see, our Customer Order Services app fits numerous IBM platforms, including Liberty profile on-premises and on Bluemix, as well as the traditional WebSphere Application Server.

To get the report below, we ran this command:

java -jar binaryAppScanner.jar CustomerOrderServices-0.1.0-SNAPSHOT.ear –evaluate

So far so good! Our goals align with the supported capabilities of our target platforms and now we’ve confirmed that all the required components of our application are supported on our target platform.

Inventory

The report includes a dashboard that reports the number and types of archives found. The counts of Java Servlets, JSP files, JPA entities, EJB beans, and web services are reported per application as well as in an overall summary. For each archive, the Java EE module type and version are included. For utility JAR files, the contained packages are reported up to and including the third sub package.

To get the report, we ran this command:

java -jar binaryAppScanner.jar CustomerOrderServices-0.1.0-SNAPSHOT.ear –inventory

This is the inventory report for the reference application. By scrolling down, we get to the Potential Deployment Problems section. This is where we want to focus most of our attention, as the earlier problems are detected and addressed, the better.

As you can see above, several potential deployment problems were detected. However, these are only potential problems, since our current application does indeed run on our existing production systems. These are simply items, detected at the binary level, of things that may be an issue moving forward. There is no need to resolve these before moving forward; instead, use this list as part of your problem determination toolbox should any issues arise once you perform source and configuration migration.

Analysis

This analysis report runs against a pre-built list of migration rules, which is also utilized in the next section by the Eclipse WebSphere Migration Toolkit plugin. The report generated here comes with an option to read some of the rules more in-depth, as well as keep the migration analysis report as a soft copy for future reference.

To get the report, we ran this command:

java -jar binaryAppScanner.jar CustomerOrderServices-0.1.0-SNAPSHOT.ear --analyze --sourceAppServer=was70 --targetAppServer=was90 --sourceJava=ibm6 --targetJava=ibm8 --targetJavaEE=ee7 --includePackages=org.pwte.example

Again, the main goal of the analysis report here is to quantify the migration effort. Based on the relatively low number of rules flagged in our results (9), we can safely assume this should be a smooth migration. Moving between versions of application servers will always generate some level of warnings and critical issues to be addressed, however, it is best to know as much as you can before starting any migration efforts.

Using the WebSphere Migration Toolkit for Application Binaries, we have a confident understanding of what we may need to change, how long it should take us to change it, and how relatively complex our migration efforts should be.

Step 3: Source Migration

Now, like any seasoned developer, we’re ready to make the necessary changes to our application! To do so, we’ll make use of another toolkit, the WebSphere Application Migration Toolkit. This Eclipse-based Migration Toolkit provides a rich set of tools that help you migrate applications from third-party application servers, between versions of WebSphere Application Server, to Liberty, and to cloud platforms such as the Liberty for Java Instant Runtime, IBM WebSphere on Cloud and Docker.

This toolkit scans your application and provides pointers to all the necessary source code changes that need to be performed. The main difference from our previous evaluation work is that we’re now working inside of our IDE and this provides us with available quick fixes! You can do a side-by-side comparison of the original code with the quick fix for understanding the changes better and then apply them.

Following the guidance of the migration toolkit, we’ve now made the minimal changes suggested to our application source code with the expectation of deployment on a WebSphere Application Server V9 server. Having made these code changes, all we have left is the configuration migration before we deploy our application and declare it modernized—mostly!

Step 4: Configuration Migration

For anyone that has done any amount of WebSphere application development or management, they know the configuration of an Enterprise Java Application Server is just as important as the application code running on it. As such, specific focus should be applied to the migration of configuration data and the application specifics from existing functioning environments to prospective current versions.

The migration of server configuration data should be done before deploying the application on our deployment target, an instance of WebSphere Application Server V9. The configurations can be migrated from traditional WebSphere application servers or from third party application servers too.

In the case of Customer Order Services, we are migrating from a WebSphere V7 runtime to a WebSphere V9 runtime, so most of the generated artifacts are easily used to move over JDBC resources, J2C authentication data, and library-specific configuration & metadata.

When you are moving from WebSphere Traditional, you can make use of Migration Wizard. Full profile migration can be done using WASPreUpgrade and WASPostUpgrade commands as well using the graphical user interface, the WebSphere Configuration Migration Tool.

This tooling will generate Jython-based configuration scripts that can now be run against the new target deployment environment, thus replicating the existing, functional configuration data of the source environment. Migration is now much simpler and more automated than a series of manual, human checks that could take weeks or longer!

Next Steps

Ready to try migrating your own WebSphere application? Grab all the free tools described earlier and use them to finish your migration process with ease. As mentioned in the introduction of this blog post, this is just the first step in taking your applications to the cloud! The first phase was quite exhaustive, but now you have a WebSphere Version 9 application that can confidently be deployed on a local WebSphere V9 server instance, WebSphere on Cloud, or Traditional WebSphere running inside Docker containers!

We’ll be back in a few weeks with our next blog post covering the mitigation / migration steps of our approach. We’ll cover adopting WebSphere on the Cloud and how we integrate with our existing resources that are still on-prem!

For some additional resources in the meantime, you can check out the documentation from some of our referenced materials below:

Senior Solution Architect

More Compute Services stories
May 6, 2019

Are You Ready for SAP S/4HANA Running on Cloud?

Our clients tell us SAP applications are central to their success and strategy for cloud, with a deadline to refresh the business processes and move to SAP S/4HANA by 2025. Now is the time to assess, plan and execute the journey to cloud and SAP S/4HANA

Continue reading

April 18, 2019

Load Balancing API Calls Across Regions with IBM Cloud Internet Services and Cloud API Gateway

In this article, we'll explore load balancing traffic across two geographically-separated backends built on IBM Cloud Functions. We'll use the IBM Cloud API Gateway to deploy the same API definition in both regions, and then intelligently route traffic with IBM Cloud Internet Services.

Continue reading

April 15, 2019

The IBM Multicloud Approach by Example

Our clients want the same consistent control plane across all their cloud properties. This post outlines how to deploy IBM Cloud Private on AWS, but the same approach applies to other cloud infrastructure platforms.

Continue reading