VMware Cloud Ops Blog: Workload Assessment for Cloud Migration, Part 1: Identifying and Analyzing Your Workloads

http://blogs.vmware.com/cloudops/?p=277

Wednesday, June 19, 2013 1:15 PMVMware Cloud Ops Blog: Workload Assessment for Cloud Migration, Part 1: Identifying and Analyzing Your WorkloadsVMware Blogs

Conducting a thorough workload analysis can make or break the success of a cloud strategy.

If you are successful with assessing workloads and placing them in the appropriate private, hybrid and public cloud environments, then this will help you fulfill your cloud strategy, thus helping you enable greater agility and cost efficiency. If your assessment is unsuccessful, then these benefits will be much harder to achieve and you could see higher costs, lower performance and unhappy customers.  Remember, success breeds success, so if you have happy customers who are realizing the benefits of your cloud implementation, others will be knocking at your door. If you are unsuccessful, the pipeline of customers will very rapidly dry up.

In this four-part series, I'll explain four main considerations that you should examine when performing a workload assessment. In this blog, I'll suggest a framework to use to classify workloads as potential candidates for moving to a cloud environment. My next three blog posts in this series will cover service portfolio mapping, analyzing the cost and benefits of moving to the cloud, and last but not least, stakeholder analysis.

Common Questions

When assessing workloads to identify candidates, I often find myself asking:

• What criteria should be considered when determining what workloads are a good fit for a new cloud environment?
• What is the best way to capture and evaluate the criteria with minimal effort and impact on a busy IT department?

A thoughtful and efficient workload assessment framework can simplify and streamline the analysis. Without the right methodology, it can be difficult to know where to start, let alone where to finish. The larger the number of workloads, the more complex the prioritization task becomes.

Here are common considerations and requirements that factor into a potential migration:

Business Impact:

1. Take a look at the workload and evaluate its impact on your business. Is it a business critical workload? How does it affect and impact your company? Take the answer to this question and assess it against where you are on your cloud journey. You wouldn't want to move mission critical workloads in to your cloud during your first days after "go live" would you?
2. For which application lifecycle phase will the workload be used (for example, development, test or production)? What are the different requirements for each environment?

Application Architecture:

1. Is the application written for cloud environment? If not, make sure you understand the impact of migrating it into the cloud.
2. How hard/expensive is it to refactor the application for new environment e.g. do you need to remove hard coded resource paths? What are the scaling considerations, can you already horizontally scale to add capacity by adding instances or can you only scaling up by adding more resource to a single instance?

Technical Aspects:

1. What operating systems, databases or application servers are being consumed or provided and how hard will it be to also migrate them into the cloud?
2. Do your database, application server and web server run on the same type of platform?

1. What quantity of CPU, memory, network and storage are typically used/needed? Can your cloud implementation support this?
2. What commercial and custom software support the workload?
3. What are the dependencies or integration touch points with other workloads?

Non-Functional Requirements:

1. What are the required service levels, performance, capacity, transaction rates and response time? Again, can your cloud implementation support this?
2. What are the supporting service requirements?  Backup, HA/DR, security or performance monitoring?  Are specific monitoring or security agents required?
3. Are there encryption, isolation or other types of security and regulatory compliance requirements?

Support & Costs:

1. What are the support resources and cost for a given workload? For example, two full-time equivalent employees per server – how much does this resource cost?  Also, don't forget licensing, how does the software vendor deal with cloud implementations of their software and what are the cost implications?
2. What are the operational costs for space, power, cooling and so on? What will be saved by migration?

One thing remains through all of this – the benefits of moving these workloads must always outweigh the costs and the risks.

To get started on the journey of migrating your workloads to the cloud, remember these takeaways:

• Always think about how your workload directly affects your company. With a thorough review of each of your workloads, you'll know what changes to anticipate when you begin the migration process.
• Make sure you're thinking in the cloud mindset. Before beginning the migration process, make sure your applications are cloud-ready. If they aren't already, make sure you have the proper strategy in place to bring them up to cloud-ready speed.
• Be prepared. Not only do your employees need to know about these changes, but make sure your cloud implementation is prepared for the capacity (including cost) it will take your company to migrate to the cloud.

Check out our list of great blogs on workload migration and stay tuned for Part 2 of this series, where we'll look at service portfolio mapping and how to determine the target cloud service and deployment model for each candidate workload.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.