Cloud Services

Making Your Move to the Cloud – Part 1: Building a Structured Approach to the Cloud

By Michael Francis and RadhaKrishna (RK) Dasari

If you’re considering moving to the cloud, you no doubt recognize that cloud computing represents the opportunity to minimize overhead and maximize agility so IT can deliver significant value back to the organization. By leveraging a more agile and efficient IT environment that leverages pools of elastic, self-managed virtual infrastructure—consumed as a service at the lowest possible cost—you can innovate more rapidly while maintaining reliability, security and governance for all applications and services under IT control.

But once you’ve made the decision to eliminate traditional, costly and inefficient silos of IT infrastructure to create an infrastructure that can intelligently and dynamically respond to business needs, you still need to create a plan to get there. A thoughtful approach will help ensure you get all the benefits of the cloud, with a scalable, secure and manageable solution that addresses your unique business challenges.

This four-part weekly blog series will help you get started, with tips and best practices for planning your migration. Today we will talk about the best ways to build your structured approach to the cloud, and then continue the discussion over the next three weeks with additional posts for:

  • Part 2: Building a Migration Plan
  • Part 3: Tools for Migrating Large Workloads to vCloud Air
  • Part 4: Tips and Tricks from VMware Consultant Field Experience 

The Context of the Discussion

Let’s start with some context and assumptions for this discussion. The context is Infrastructure-as-a-Service and the assumption is that the decision to employ public cloud services is a business decision based upon a more favourable cost model. This is not to say that a public cloud is always a more favourable cost model, just that in this context, in your choice to use a public cloud—as opposed to one of the other cloud models—you have done the analysis, and for the target use case it makes cost-effective sense to use a public cloud.

With that said, the act of procurement of a public cloud for compute capacity is the simple part; it is making use of that capacity for your use case that was central to your business decision – and is potentially the more difficult part.

In this discussion, we are assuming that for your public cloud use case you have done financial modeling. This is not just net new test/development workloads; it is running your existing applications on a public cloud service.

The Considerations

The decision to use public cloud services was a business decision – one founded on business outcomes. The faster and more effectively you can achieve those business outcomes, the sooner the business can see the benefits of the business decision. In contrast, if beginning to achieve the business outcomes takes too long or costs too much, perhaps the choice of vehicle to achieve the business outcome was wrong; not the business outcomes or the business decision, but the vehicle chosen to achieve your goals.

Therefore, when considering public cloud services, the aim should be to align the quality of those service with the quality of service required to support the business outcomes of the given applications/migration candidates being considered. Put simply, it is important that when choosing the vehicle to deliver the business outcome, cost of the vehicle is one factor, and appropriateness of vehicle is the other factor. For example, if you need to ensure a certain number of transactions per second for the expected revenue stream for the application, then you need to ensure the cloud service provider can support that.

Assuming the cloud service provider can meet your required service level, the next step is to build a plan.

The No Plan Option

Not having a migration plan is almost a certain guarantee that business outcomes will not be met. VMware has been engaged by many customers both very large and small to migrate their applications from physical to virtualised platforms. Over that time, we have identified the following common outcomes of customers that failed to achieve business outcomes.

Not All Stakeholders Are on the Same Page

A senior IT executive witnessed the business value of migrating to a new platform. The business case is so compelling; the decision to move forward is made, and a project team tasked with delivering the outcome is created. Unfortunately, not all stakeholders were involved; these stakeholders ranged from business application owners, business application user team leaders, application support teams, and change management teams. During the migration project execution phase, stakeholders raised concerns over the impacts to their applications, their business outcomes, and delayed their system migrations; the project team had to re-think logistics, reschedule systems, modify change and communications plans, and modify human resource assignments.

Workloads Aren’t All the Same

Another issue is the attempt to achieve time-to-value as quickly as possible, but a review of application requirements—or quality of service from infrastructure—is not done, or not done to an adequate level. The result frequently is high profile migration failures, due to application stakeholders having not bought into the business value of the migration; they were not able to see sufficient quality of service delivered to their applications, or the desired impact to their business outcomes. This can lead to early failures instead of quick wins.

Migration Prep Work Not Done

Inadequate prep work before migration can cause different kinds of failures:

  • Failure to identify workload dependencies before migration – such as updating DNS, ensuring access to Active Directory for authentication
  • Failure to determine how certain procedures – such as backups and security checks – will be done in the cloud
  • Failure to identify applications that are inherently not suitable for the cloud – potentially for licensing or support reasons.

Any or all these can result in undesirable and discouraging outcomes.

Unrealistic Time-to-Value Expectations

During the initial business decision to use this new infrastructure platform the analysis focused on the end-state, and did not fully consider the migration state, how long the migration would take, what resources would be required at different times during that state, and what existing business outcomes (such as revenue) will be impacted during the migration state. This created pressure on the migration project to get to the end-state as rapidly as possible.

Loss of Momentum

One of the key things a migration project needs is to maintain momentum. This is especially the case when the delivery of the outcome leverages a technology partner to achieve it. Loss of momentum equals multiple project change requests from the technology partner as expected throughputs of migrations do not materialise, and the commitment the business made to support that throughput is not achieved.

Migration Itself is a Proven Quantity

The technology to migrate an application (lift and shift) has been available for more than a decade. It has evolved to become more flexible in support of varying source types and varying target types, but essentially the process itself is the same. Capture an application workload at a point in time, track and replicate changed data from point A to point B, then reconfigure the operating system at point B to enable the application workload to successfully boot and start the application.

There is a difference between an enterprise mass migration tool and a traditional migration tool with respect to features such as workflow engines, migration workflow designers, migration program reporting, and mass migration scheduling. But the underlying migration mechanism is well understood.

Don’t Focus on the Easy Part

So, if we consider the common issues with migration projects, there are common reasons: a plan involving all stakeholders was not created; there was no consideration of the business context of applications during the migration state; there was no plan to inform or validate the business case; and the focus was on the actual migration activity instead of the end goal of the plan.

A Proven Methodology to Create the Migration Plan

The VMware Migration Assessment Service addresses all the issues above. Over the next few weeks, we will put a spotlight on the Migration Assessment Service. We will look at the methodology and discuss the tools used. And most importantly, we’ll examine how this service can rapidly model a migration and deliver a migration plan with forecasted migration project timelines, migration sequence, application stakeholder buy-in, and the expected goals achieved by the migration.

Take the Next Step:

Want to learn more about how vCloud Air can guide your migration to the cloud? Read the rest of our blog series:

Part 1: Building a Structured Approach to the Cloud

Part 2: Best Practices for Building a Migration Plan

If you’re ready to get started with the hybrid cloud, visit vCloud.VMware.com.

Be sure to check out the vCloud Air Community, where you can join or start a discussion, watch our latest vTech Talk video, enter for a chance to win swag in our monthly giveaways and more. Get started here!

For future updates, follow us on Twitter and Facebook at @vCloud and Facebook.com/VMwarevCloud.

Michael Francis

 

 

Michael is a Principal Architect with Professional Services Engineering. He is responsible for the creation of the Migration Assessment Service including the structure, tools used and methodology. Michael is also an Office of CTO Ambassador; these select set of people are responsible for engaging our customers and our field technical teams with our product development teams. Michael has been with VMware since 2006

 

 

RadhaKrishna

 

RadhaKrishna (RK) Dasari is a Technical Solutions Architect for the Professional Services Engineering team. He specializes in developing architecture designs and service kits for vRealize Automation and vCloud Air. Prior to VMware, RK had a career spanning thirteen years at Dell as a software developer, software architect and pre-sales solutions architect.

Comments

3 comments have been added so far

Leave a Reply

Your email address will not be published. Required fields are marked *