Jake Robinson is a Solutions Architect at Bluelock. He is a VCP and former CISSP and a VMware vExpert. Jake’s specialties are in infrastructure automation, virtualization, cloud computing, and security.

JAKE ROBINSON
Bluelock

Working at an Infrastructure-as-a-Service provider, I see a lot of IaaS application migration. Migration occurs in both directions–from physical servers to cloud, from private cloud to public cloud (and back), and to private cloud from public cloud.

Though it occurs often, migration shouldn’t be rushed. A poor migration strategy can be responsible for costly time delays, data loss and other roadblocks on your way to successfully modernizing your infrastructure.

Each scenario is different based on your application, where you’re starting from, and where you’re going.

Best Practice: Pick Your Migration Strategy.

• Option 1: Just data migration. This is typically the correct choice for Tier 1 and 2 applications. If you choose to migrate your VM or vApp, it’s still going to be constantly changing. If it’s a Tier 1 application you won’t be able to afford a lot of downtime, so typically, we’ll recommend invoking some sort of replication. Replication is a complex, detailed subject in itself, but the key to understanding it is to identify the size of the data, the rate of change and the bandwidth between the source and target. As a general rule, if your rate of change is greater than or equal to your bandwidth, your migration will likely fail. That’s because the rate of change refers to everything coming in to the app, it’s gaining gravity as the rate comes in. The bandwidth is like the escape velocity it requires to get off the ground, or migrate. You need a high enough bandwidth to “overtake” that rate of change.

• Option 2: Machine replication.  This is best for Tier 1 and 2 applications that can afford some downtime and it involves stack migration.  There is less configuring in this scenario, but there is more data migrating. Option two is best if you’re moving to an internal private cloud. You will be able to replicate the entire stack, because you have plenty of bandwidth to move stuff around. It’s important to note the portability of VMware-based technology, because VMware allows you to package the entire VM/vApp, the entire stack, into an OVF. The OVF can then be transported anywhere if you’re already on a virtualized physical server.

• Option 3: P2V migration. You typically see this for Tier 2 and 3 apps that are not already virtualized. The concept involves taking a physical app and virtualizing it. VMware has a VMware converter that does P2V, and it’s very easy to go from a physical to a private cloud using P2V.  It is, however, an entirely different set of best practices, and you should do some extended research to make sure you have the latest updates, best practices and suggestions. In option three, there is no replication; however, those apps can be shipped off to a public cloud provider to run in the public cloud after being virtualized.

• Option 4: Disaster Recovery. A final path some companies take is to treat it as a Disaster Recovery (DR) scenario.  Setting up something to do basically replication from the physical to one machine to another. They choose to replicate the entire stack from point a to point b, and then click the failover button.

Now, let’s say you have identified the best vehicle and path to migrate your application. Before you actually get to work there is still quite a bit of information to evaluate and incorporate.

Best Practice: Understand the Gravity of Your Data.

When moving Tier 1 applications from a physical data center to a private or public cloud, we have to take data gravity into account, and the data itself will be the weightiest part.

There’s no easy way to shrink down the data, so you need to evaluate the weight of the data in the app you’re considering migrating. Especially if you’re a high transaction company, or if it’s a high transaction application, there would be a lot of data to replicate. The data of the app constitutes 99 percent of the data gravity of the application.

Another aspect that you should evaluate as part of your pre-migration plan is to determine how connected your VM or vApp is to other apps. If you have a lot of applications tightly coupled to the application you want to migrate, the cloud might not be an option for that application, or at least only that application.

Best Practice: Identify How Your Apps Are Connected.

Does your application have data that other applications need to access quickly? If so, an “all or nothing” philosophy of migration is your best option. If you have an application that is tightly coupled to two or three others, you may be able to move them all to the cloud together. Because they are still tightly coupled, you won’t experience the latency that would occur if your cloud-hosted application needed to access a physical server to get the data it needs to run.

A step beyond identifying how many apps are tied to the application you wish to migrate, work next to identify which of those applications will be sensitive to latency problems. How sensitive it can be should be a consideration of whether you migrate the app or not.

To be able to check this best practice off your list, be very sure you understand everything your application touches so you won’t be surprised later, post-migration.

Each application, and migration strategy, is unique, so there is no detailed instruction manual that works for everyone.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.