Share this post:
Do you have a modernized WebSphere application in your business running on your on-premise infrastructure? If you’ve migrated your old application code to the present-day WebSphere Application Server (WAS) version and updated your development environments / delivery pipelines to modern practices, it’s time to move your application to the WebSphere Application Server as a Service (WASaaS), a hosted cloud environment on Bluemix.
In our last blog entry, WebSphere on the Cloud: Application Modernization, we explained how you can modernize your existing WebSphere applications with minimal changes and migrate them to the cloud, lowering your costs and simplifying maintenance (if you have not already done so, before diving into today’s post, I recommend reading it). If you’re interested in code and more details, all the phases of our work are available in github.com/ibm-cloud-architecture/refarch-jee.
In this blog, we will be covering Mitigation. Detailed documentation can be found at github.com/ibm-cloud-architecture/refarch-jee/blob/master/phases/phase2.md. This blog highlights the important steps in the Mitigation phase. This phase focuses on iteratively moving core pieces of compute-based business logic to cloud-based services.
Nowadays, cloud is everywhere. Ease of access, low cost, flexibility, and scalability have made cloud so popular. But on-premises systems have their own advantages, like better customization and control. Consequently, many businesses prefer a hybrid approach, leaving some of their resources on-premises and moving some of their heavier resources to the cloud, rather than going fully cloud-based. For the reference WebSphere application here, we adopted the hybrid approach as well.
In this phase, we moved core pieces of compute-based business logic to cloud-based services while most existing database and messaging capabilities are left undisturbed in their existing environments. Additional networking and security practices are usually defined during this phase, as the scenario we are entering is a hybrid cloud scenario.
Note: If you are not familiar with the IBM Cloud Reference Architectures and their benefits, check them out in the IBM Cloud Garage Method:
Get started with architectures
By the end of this phase, you will be able to adopt WebSphere on Cloud as well as integrate with your existing resources that are still on-prem.
WebSphere Application Server as a Service (WASaaS)
Applications keep on changing and continue to evolve—so must your application server. Are you looking for a way to deploy your WebSphere Application Server on cloud easily in a reliable manner? If so, IBM WebSphere Application Server in IBM Bluemix is for you.
IBM WebSphere Application Server in IBM Bluemix is a service that facilitates quick setup on a pre-configured WebSphere Application Server (Liberty), Traditional Network Deployment, or Traditional WebSphere Base instances in a hosted cloud environment on a virtual machine guest with root access to the guest operating system. For our reference application, we are using the WAS Base Plan. Based on your services, choose the environment that is best suited for your environment.
You may be wondering: If your WAS application is running on the cloud, how do you protect public services from network-based attacks? No worries! A VPN protects the public service from generic port scans and other network-based attacks. However, it is important to note that the service VPN you use to access your service instance might be shared between multiple Bluemix organizations and users.
After your WebSphere Application Server in Bluemix service instance is provisioned, you can access your VM in several ways. You can connect over a secure VPN to get SSH, traditional WebSphere Admin Console, and application access to your VM. You can also connect your VM to the internet with a public IP address and provide access through a limited number of ports.
Private VPN Access: The VPN configuration is scoped to your organization and region. It is valid for one year from the time it was created. Multiple OpenVPN client connections can be established simultaneously by using the same VPN configuration. You can connect to your VM’s private IP address over the VPN connection. Your Liberty Admin Center (9080, 9443), traditional WebSphere Admin Console (9060, 9043), SSH (22), and ports other than 80/443 are only accessible through the VPN connection.
Any agent installed (monitoring, management such as UCD, database connection, etc.) needs an explicit port open on the OUTPUT chain to work. To open ports on the firewall, use the script
openFirewallPorts.sh provided on the WAS instance in Bluemix node.
Public Internet Access: Optionally, you can request a public IP address for your WebSphere server VM. When the access to your public IP is opened, the IP address is associated with your VM, and ports 80 and 443 are opened at the gateway. However, by default, Liberty Core, and traditional WebSphere Base servers do not open ports 80 and 443. However, ports 80 and 443 are opened by default on the IBM HTTP Server. Therefore, you might need to configure your Liberty Core and traditional WebSphere Base servers to listen for application traffic on port 80/443 when you use public IP.
Just like the first phase, here also we are going to leverage and take the most advantage of tools already out there to help moving your business logic to cloud-based services.
It’s time to migrate our Customer Order Services application from on-premises resources to execute on the WebSphere Application Server as a Service on IBM Bluemix.
Like we did before, we use the Migration Toolkit for Application Binaries. More specifically, we are going to run the Analysis report to uncover potential issues when we move our existing WebSphere Application Server V9.0 applications to run on the cloud (WASaaS) rather than on on-premise resources.
For doing so, we run the same command:
java -jar binaryAppScanner.jar binaryInputPath --analyze [OPTIONS]:
binaryInputPath is an absolute or relative path to a JEE archive file or directory that contains JEE archive files.
- In this case, we need to update the options to the current WebSphere Application Server version as well as to the target IBM platform.
That is, our
[OPTIONS] this time are:
--sourceAppServer=was90 --targetAppServer=was90 --sourceJava=ibm8 --targetJava=ibm8 --targetJavaEE=ee7 --targetCloud=wasVM
This generates the report below. Take a second look at it. Does something stand out in your mind?
Yes, all the ones in the green boxes were already reported during the previous code migration phase! But why do you see them again? Did we address the issues previously?
The reason these issues appear again in this report is because we did not address them previously, i.e., we are ‘lifting & shifting’ our existing old WebSphere Application Server applications running on existing on-premises resources to a newer WebSphere Application Server version and different IBM platform. That is, we want to do that ‘lift & shift’ in the simplest and least intrusive manner.
So, apart from the issues above, we are just left with three others. The Analysis report flags these issues and provides possible solutions for the problem. You can have a closer look of the issues and the possible solutions for the reference application in phase2.md#code-analysis.
Migrating your WebSphere Application Server applications from your on-premise resources to WebSphere Application Server as a Service (WASaaS) on Bluemix requires a detailed verification of:
- On-premise resources your applications will still need to connect to like databases or security registries. For that, IBM Bluemix offers services like Secure Gateway.
- URL hosts and ports used by your applications since they won’t be running on the same well-known static resources and won’t use the same ports.
To move our compute-based traditional WAS resources to the cloud, we need them to securely connect to on-premise resources so that they can access application data and security registries for authentication and authorization purposes. But how do you connect them?
To securely connect cloud applications to on-premises or cloud-based remote locations, you can use a VPN tunnel such as the Bluemix Secure Gateway or SoftLayer Gateway as a Service.
In our case for the reference application, we have configured our WebSphere Application Server as a Service instances to use the IBM Bluemix Secure Gateway service to connect the application server— and thus its applications —to the on-premise DB2 database instance and LDAP server.
Are you worried about the security of your application? Of course! Any application security mechanism is always a shared effort between the application itself and the web server that hosts and makes this application available to users.
The application must implement security constraints that the web server should handle and provide. Data is the most frequent resource to secure and especially when this data is confidential or private. However, we do not only need to protect how the data is accessed and handled by the applications, but also how it is serviced or made available to users or the public in general.
For the reference application, WebSphere Application Server as a Service instances will:
- Authenticate users using an LDAP server, which is located on premises and accessed through the Secure Gateway service.
- Authorize users based on their role.
- Use LTPA tokens to encrypt authentication information exchanged by servers.
For more information on the security mechanisms and considerations for both the application and the web server, see the Security.md in the reference architecture entry; it details the application security and how we chose to implement our security model in a hybrid environment.
Voilà, your WebSphere application is now on the cloud!
Ready! Set! Go!
Make use of this blog and mitigate your application with ease. Finally, you will have your own WebSphere applications on cloud with your desired resources on-premises running in a hybrid environment. Hope you enjoyed the mitigation process.
For more information about the Bluemix Secure Gateway:
For more information about configuring the SoftLayer Gateway as a Service:
Other useful resources: