This is the 4th post in the blog series > “10 Critical Cloud Migration Planning Factors”.
4) Selecting Applications: Bad Candidates for Cloud Migration
A recent CIO survey by JP Morgan projects “41.6% of corporate workloads at big companies are expected to be running in the public cloud within the next five years, up from 16.2% today.” This level of cloud migration marks a MASSIVE shift. Enterprises face a daunting challenge to migrate their on-premises workloads into the cloud. However, unlike the famed and perilous wildebeest migration on the Serengeti plains, enterprise workloads can smoothly and securely migrate to the cloud if Enterprise IT considers the following critical planning factors:
4. Selecting Applications: Bad Candidates for Migration
5. Pitfalls in Migrating Complex Apps to the Cloud
6. Discovery versus Assessment for Cloud Migration
7. Software Licensing: Can I run this app in the cloud?
8. Manual versus Automation: Pros and Cons for Cloud Migration
9 Cost Analysis: On Premises vs Cloud
10. Critical People Factors: Right Stakeholders? Right Skills?
In this post, we will cover
#4: Selecting Applications: Bad Candidates for Cloud Migration
Not all applications in your data center can be migrated to the cloud.
In post #3, I covered the criteria that could help you look at your application portfolio and filter the ones that are more suitable for cloud migration.
In this post, we will discuss criteria for selecting applications that are less suitable for Re-hosting in the cloud. The public cloud is evolving rapidly and the cloud providers are racing to overcome technical barriers to running your workloads in the cloud. However, the following factors and examples will allow you to quickly identify which application or group of applications will be challenging to migrate to the cloud.
a) Applications Running on Proprietary/Custom Hardware
If your datacenter application runs on custom hardware, then it may not be possible to virtualize it. If it cannot be virtualized, it cannot be re-hosted in the cloud.
There are various classes of applications requiring custom/proprietary hardware:
- Applications like Oracle Exadata, Oracle Exalytics and Oracle Exalogic running on engineered systems that cannot be re-hosted
- Applications running on mainframes cannot be migrated to the cloud without modernizing or refactoring for the cloud
- Applications dependent on a physical machine (e.g.: Scanner requiring a specific MAC address, App requiring specialized hardware drivers that cannot be virtualized)
- Applications that required the purchase of an appliance (e.g.: Load-balancer, Intrusion Detection/Prevention) may require further investigation to determine if the vendor provides a virtual appliance alternative
While the above class of applications cannot be re-hosted in the cloud due to hardware dependencies, you may want to check if your appliance vendor provides a software version of the application in the Cloud Marketplace. For example, F5 Big IP products are sold as appliances with hardware optimized to deliver security and performance. However, F5 also makes available F5 Big IP Virtual Edition for AWS in the cloud market place – where you can Bring Your Own License (BYOL) to run it in the cloud
b) Applications Running on Proprietary/Custom Operating Systems
Applications running on proprietary operating systems that are not supported in the cloud are not good candidates for re-hosting. Like applications running on custom hardware, these applications may require modernizing or refactoring for the cloud.
c) Applications Requiring Low Latency
Applications whose performance is susceptible to latency may perform poorly in the cloud and may not be suitable for cloud migration. Some legacy applications were not written to run in a distributed computing environment. Running a legacy application in the cloud may increase the latency and degrade user experience. Latency tolerant rather than real-time applications are more suitable for cloud migration.
You may want to determine the latency of the application from the cloud datacenter (availability zone) and your users and ensure that the user experience is not impacted.
d) Application Clusters Using Shared Disk Architecture or IP Multicast for cluster communication
Clustering is typically used to improve availability and scalability. Application clusters that use shared-disk architecture (as opposed to shared nothing architecture) or IP multicast for communicating with other nodes in the cluster are not suitable for cloud migrations.
For example, Elastic Block Store (EBS) volumes in AWS cannot currently be attached to more than one EC2 instance at a time. This implies that any application cluster using shared-disk architecture is not suitable for cloud migration. In AWS and Azure, the network does not natively support multicast; therefore an application cluster using multicast for cluster communication is not suitable for cloud migration.
An example of an application cluster using shared disk architecture is Oracle Real Application Clusters (RAC).
Weblogic or JBoss Application Server clusters configured with IP multicast for communicating with other nodes in the cluster are not suitable for cloud migrations. You would first want to use an alternative to using multicast to handle cluster messaging and communications before considering migrating these clusters to the cloud.
CAVEAT: Public clouds are rapidly evolving. New capabilities and services are being announced and delivered by cloud providers at a staggering pace. What may not have been supported last year is available today.
With this context in mind, what is not suitable for cloud migration today may be an appropriate fit for cloud migration next year. I will make an effort to keep this blog post updated as new capabilities are announced and delivered.
The next blog in the series will be #6: Discovery versus Assessment. This is out of sequence, but I have received feedback to prioritize this post ahead of #5.
Stay tuned or register for the Cloud newsletter.