10 Critical Cloud Migration Planning Factors
This is the 3rd post in the blog series > “10 Critical Cloud Migration Planning Factors”.
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:
3. Selecting Applications: Good Candidates for Migration
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:
#3: Selecting Applications: Good Candidates for Cloud Migration
Not all applications in your data center can be migrated to the cloud.
In your organization, you may have anywhere from 100 to 1,000 to 10,000 applications depending on your business and organization size. So, how to select the good candidates for cloud migration?
In this post, we will discuss criteria for selecting applications that are suitable for Re-hosting in the cloud (In post #2: Three Different Paths to Cloud Migration, we discussed the Re-host, Re-platform and Re-factor options.). The focus will be on technical criteria rather then industry or compliance specific factors. With re-hosting in contrast to re-platforming or re-factoring applications, the emphasis should be selecting groups of applications that can be slotted into “migration waves” rather than working on migrating one server or application at a time.
With the state of the art automation tools for cloud migration, once a group of applications (e.g.: 350 VMs/servers used by Dev/Test) has been identified, it is best to complete the cloud migration of these apps in one wave. This approach is more efficient and can also take into consideration minimizing the impact on end-users using these applications.
I am assuming that either you have completed a “discovery” of the all the apps in your organization or know which group of applications you are interested in migration to the cloud. A “discovery” (more on this in #6: Discovery vs Assessment) can be performed by your IT organization using many 3rd party discovery tools that are cloud aware (rather than just traditional CMDB tools) or you can work with a cloud partner to assist you with the discovery or assessment. In addition to getting an inventory of the application assets, the discovery tools will also provide an application dependency mapping that is essential to planning your cloud migration.
Selecting good candidates for cloud migration is a process of reviewing the target applications against two broad technical categories: i) Architectural considerations that span across a group of applications and ii) Application-specific. Let’s look at the criteria in further detail:
a) Operating System support:
This is straightforward. Does the cloud provider support the operating system your applications run on? It’s not enough to just review what’s available in the marketplace. You need to ensure that the cloud supports the version you are running. If not, your application will need to be re-platformed to the version available in the cloud.
If your application is not Windows or Linux based workload, then you will need to take a harder look For example, AIX, Solaris, HP-UX etc. are not supported in the cloud. For Linux workloads, review the OS distribution version support. For example, RHEL 4 / CentOS 4 are not supported in AWS because the kernel version that ships with those distributions is not compatible.
b) Standard Hardware
Typically this means that your application runs on standardized hardware (x86-based) rather than custom hardware. If the application runs on custom hardware such as an ASIC-based appliance, , then it may not be suitable for migration to the cloud since the corresponding hardware is not available in the cloud. In addition, if your application is working with an appliance based solution (for example, a F5 load balancer appliance), then you will need to find a corresponding software version of the appliance to be able to perform the same function in the cloud.
c) Site Dependency
Does your application have any dependency on another application or service that will only run in your datacenter? For example will your application depend on Microsoft Active Directory, which will run in your datacenter while your application is migrated to the cloud?
If your application or applications require access to any on-premises applications or services, you may need to extend your datacenter network to the cloud so your application can use cloud infrastructure resources but operate seamlessly across one network that spans your datacenter and the cloud. There are a couple of options that should be explored to achieve this 1) Establishing a VPN connection from your datacenter to the cloud , or 2) Implementing a service such as Amazon Direct Connect toextend your datacenter to Amazon’s Cloud ( however, Amazon Direct Connect is only available through an ecosystem of colo providers).
d) Communications Matrix
Building on the site dependency criteria, it is worth assessing whether your target applications depend on other applications and whether these applications communicate to other applications during runtime. Building a communications matrix of what application communicated with what mechanism to which application is a very important planning consideration.
To ensure seamless rehosting in the cloud, it is important to understand the groups of applications that are dependent on each other when planning a cloud migration.
In addition, it is also important to ensure that the type of communications is supported in the cloud. The app architecture may not be conducive to running in a public cloud. For example, an application using multicast, or a cluster based on shared storage architecture will not operate in the cloud.
e) Data Security/Sovereignty
If your organization works with sensitive data that is subject to Regulatory Compliance (example: customer financial data, patient medical information etc) then you will need to ensure that cloud provider is compliant with the requirements).
Data sovereignty requirements have been changing as many countries have regulated new compliance requirements by amending their current laws or enacting new legislation that requires customer data to be kept within the country the customer resides. If your organization works with customers in more than one country and you have datacenters in multiple locations, then as you move your applications and data to the cloud, you will need to maintain ensure you are complying with the data security and sovereignty requirements.
There are many stories about companies moving their application to the cloud and then to their surprise and shock find that their costs are higher and/or the performance is much lower than their current datacenter operation. It is important to keep the following application-specific criteria in mind as well
f) Compute Utilization
Two factors need to be considered: 1) Does your application require vertical scaling?, and 2) Does your application have high compute utilization?
Your legacy applications built on a centralized computing architecture requiring high compute/vertical scaling (for example older database applications) will need a closer look. Find the biggest instance available on the cloud and do a thorough evaluation.
In addition, any applications that have a high utilization (i.e requires operation for long periods during the day and the week) also need a closer look. You will need to do an economic analysis of costs of running the application in the datacenter (no additional capex) to monthly compute costs with matching instances in the cloud
g) Application Latency
Applications whose performance is susceptible to latency may perform poorly in the cloud and may not be suitable for cloud migration. 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.
h) IOPS (Input/Output Operations Per Second)
If your application relies on high transaction processing, you need a solid understanding of your database throughput needs and ensure that the cloud storage tier is configured to deliver on the demands of the database and the application.
There are many write-ups by the cloud providers on this subject.
Here is an excerpt: “…To get the best performance from your database, you must configure the storage tier to provide the IOPS and throughput needed by the database. This requirement applies equally to Oracle Database on Amazon RDS and to Oracle Database on Amazon EC2. If the storage system does not provide enough IOPS to support the database workload, you will have sluggish database performance and transaction backlog. On the other hand, if you provision much higher IOPS than your database actually needs you will have unused capacity.
For Oracle Database storage on AWS, you need to use Amazon Elastic Block Store (Amazon EBS). Amazon EBS volumes offer the consistent low-latency performance needed to run your Oracle Database. Each Amazon EBS volume is automatically replicated within its Availability Zone to protect you from component failure, offering high availability and durability. Amazon EBS provides three volume types: General Purpose (SSD), Provisioned IOPS (SSD), and Magnetic. The three volume types differ in performance characteristics and cost. For the high and consistent IOPS required for Oracle Database, Amazon EBS General Purpose (GP2) or Amazon EBS Provisioned IOPS (PIOPS) volumes will be the right fit.
As you can see, the success or failure of your cloud migration project can depend on making the right infrastructure service selections to balance performance and cost.
i) Working Datasets
Business Analytics applications are typically more suitable to run in the cloud as they may require larger datasets and it will be easier to scale the resources (up and down) in the cloud vs. planning and anticipating demand in the data center. Planning for migration of a large dataset to the cloud is a specialized topic in itself and is not covered in this post.
On the other hand, a working dataset in specialized appliance (like Oracle Exadata or Oracle Exalytics) that makes use of advanced indexing techniques or in-memory databases will require a closer look. It maybe difficult to get similar features and performance in the cloud and hence the application may require a thorough evaluation prior to cloud migration.
The next blog in the series will be #4: Selecting Applications: Bad Candidates for Migration. Stay tuned or subscribe to Clouds.
Please provide your comments about this post to email@example.com. And if you like it, please share.