Moving enterprise web applications from on-premises environments to a public cloud environment can be a challenging task, especially when the on-premises environments are distributed in nature, such as a WebSphere Application Server Network Deployment (WAS ND) environment. There are two reasons for this challenge. The ease and speed of moving these on-premises applications depends on the ease of learning and the level of automation built into the public cloud environments to deploy these distributed environments. Secondly, the cost of running applications in a public cloud environment becomes an important factor to consider when moving applications.
This competitive research studied the labor and cost aspects of moving an enterprise web application deployed in an on-premises WAS ND environment to a WAS ND in the public cloud.
The scope of this study is to build out the WAS ND V9.0 topology as depicted in the diagram below.
The deployment steps we took were:
- Deploy the following WAS ND components for a two node WAS cluster
- WAS Deployment Manager
- WAS Application Server Node1
- WAS Application Server Node2
- IBM HTTP Server (IHS)
- Create a WAS cluster across the two WAS nodes
- Install a web application on the WAS Cluster
- Configure an IHS (Load Balancer) to spray requests to the WAS Cluster
- Access the deployed web application through the IHS from a Browser
Learning time findings
The learning time of deploying WAS ND environment using AMIs on AWS by third party was 15 times longer than deploying the same environment using WebSphere service in Bluemix ® as depicted in the graph below.
The results of this study showed WAS ND on IBM Bluemix is significantly easier to learn than Amazon Web Services (AWS) for these reasons:
- The Bluemix portal is intuitive, simple to use and provides clear documentation with step-by-step instructions on how to use the WebSphere service, making it easy to deploy a WAS ND environment.
- Understanding various concepts in AWS such as security groups for successful communication between the VMs of the WAS ND environment takes a significant amount of time.
- AWS does not provide DNS resolution for hostnames. The hostnames of the VM change after every restart of the VM, hence the user needs to understand that he must use internal IP addresses for all VMs in the WAS ND environment to ensure proper network communication is established between the VMs in the environment.
- Unlike Bluemix, the AWS documentation is weak in explaining the issues outlined above, requiring a significant amount of the user’s time to resolve problems.
Deployment time findings
Lifting and shifting to WAS on Cloud in Bluemix is 3.5 times easier and faster than third party WAS ND Service on AWS as shown in the graph below.
The results of this study showed that deploying WAS ND on IBM Bluemix is significantly faster to deploy than on AWS using third party Amazon Machine Images (AMIs) for the following reasons:
- In AWS, the user needs to implement several manual tasks around building the VMs to ensure the VMs in the WAS ND environment can communicate internally. These tasks require deep AWS expertise, hence there is a significant learning curve. With Bluemix, internal communication between the VMs is taken care of during the deployment of the WAS ND environment.
- In AWS, each of the four VMs in the WAS ND topology needs to be manually deployed and configured separately which consumes significant time in the deploy stage. With Bluemix all the four VMs in the WAS ND environment are deployed and configured together with the click of one button.
- In AWS, the third party AMIs do not offer an IHS AMI, hence the user needs to manually deploy it in a separate VM and configure it into the WAS ND environment. With Bluemix, the IHS component is automatically deployed and configured with the rest of the WAS ND environment.
Operational cost per month
The cost to run enterprise web applications on WAS ND in Bluemix is four times less expensive than running it on AWS using third party AMIs as shown in the graph below.
The results of this study showed that running WAS ND on Bluemix is significantly less costly to run than on AWS using third party AMIs for the following reasons:
- The WAS ND licensing and infrastructure costs on AWS provided by the third-party provider are significantly higher than that of the same on IBM Bluemix.
- AWS has data transfer costs while Bluemix has none regardless of the amount of data moved.
- On AWS, one needs to acquire and assign a static public IP to the IHS (Load Balancer) VM in the WAS ND environment to avoid changing the IP every time when the VM restarts in AWS. These static public IPs in AWS are not free. In Bluemix, the VMs in the WAS ND environment already have static IPs that do not change on the VM restart. Since the WAS ND environment is protected behind an OpenVPN firewall, the user in Bluemix can request public IPs free of charge and assign it to the IHS VM in the WAS ND environment.
In summary, this competitive study showed that moving a WAS ND application from on-premises to Bluemix, consumes significantly less time to learn, less time to deploy and costs less to run compared to AWS using third party WAS ND AMIs.