This article provides guidance and best practices for migrating computing workloads to Google Cloud Platform (GCP). This guide is for cloud compute architects and system architects who are already familiar with general cloud computing concepts.
Benefits of migrating to Compute Engine include:
Costs. With sustained use discounts (SUD) on Compute Engine virtual machines (VMs), costs can be significantly lower than managing hardware or virtual machines (VMs) in a traditional data center. When migrating from a different cloud to GCP, you can take advantage of those same pricing advantages.
Agility. Most customers realize an immediate improvement in agility, because you can create virtual machines in almost an instant, without having to wait for resources to be acquired and provisioned. You can quickly spin up new applications, experiment with them, and turn them off as necessary.
Overhead. Usually data centers require many different vendors, each with their own relationship, billing model, and contracts. Moving to the cloud can significantly reduce that overhead. Your staff no longer have to deal with the management overhead of running a data center. Instead, all your employees can focus on what makes your business thrive.
Because the majority of all technical workloads require computing resources, or compute, this article focuses on migrating VMs, with some of other services that make applications work, such as databases, messaging, and analytics.
Migration is not just a single, giant step. The following sections describe the recommended steps.
Calculating the costs
The first step, before moving any VMs, is to calculate the cost of the move. This means evaluating the cost of what you are currently running in your data centers. This is not just the cost of the physical machines. It also includes the cost of the networking gear, power, cooling, staffing, and leasing of the data centers. Google works closely with technology partners like Cloud Physics and Stratazone to provide free discovery and assessment tools for your existing IT landscape.
When you've calculated those costs, you then need to have a cost model for the cloud. You should consider:
- What kind of operating system will you use? Does that require a license or not?
- What kind of virtual machines types will you use? They come in a variety of sizes and the costs depend on the size. You will need to have some idea of what kind of performance characteristics your applications have.
- Beyond virtual machines, what other services does your application require, and how are they priced?
- Do these applications require any licensed software? How much will that cost and is it available in the cloud?
These are all cost considerations you need to have planned before a single VM is moved. Your GCP sales team can help you evaluate and calculate these costs.
If you are already using a cloud provider, these calculations might be different. For example, you won't need to consider the cost of leasing your own data center. But the requirement remains. Before migrating, it is important to understand the different billing models between your current provider and Google. For example, if you are migrating from Amazon Web Services (AWS), you can take a look at an assessment of pricing for virtual machines in the Cloud Platform blog.
Assessing the items to migrate
After you have evaluated the cost of the move, then you can start looking at what to migrate. In modern enterprises, there are many different kinds of applications, from customer-facing apps, to back office apps, to developer tools, to experimental applications. Moving all these applications at the same time and the same way doesn’t make sense.
We recommend sorting applications into three broad buckets:
- Applications that are easy to move. These have fewer dependencies, are newer, are written internally so have no licensing considerations, and are more tolerant to scaling and other cloud patterns.
- Applications that are difficult to move. These have more dependencies, are less tolerant to scaling, or have complex license requirements.
- Applications that can’t be moved. Some applications that might not be good candidates to migrate run on specialized or older hardware, have business or regulatory requirements that make it necessary for them to stay in your data center, or have complex license requirements that don’t allow them to move to the cloud.
These are just examples of each of these three buckets, and it is likely your applications have many more deciding factors. Your GCP sales team can help you.
These considerations all apply whether you’re moving from a data center or another cloud provider.
When this work is done, you can pick your first application or applications to migrate. We strongly recommend you migrate a only a few applications at first. The first ones will provide not only the template for future migrations, but also help you define your migration processes.
Designing the migration
When you have decided which applications to move, you need to design what your cloud environment will be before you move anything. The first step is to find out how your current environment compares to GCP. The following table provides a brief overview of the comparison:
|Service Type||Data Center||GCP|
|Compute||Physical hardware, virtualized hardware (VMWare ESXi, Hyper-V, KVM, XEN)||Compute Engine|
|Storage||SAN, NAS, DAS||Persistent disk, Cloud Storage|
|Network||MPLS, VPN, hardware load balancing, DNS||Cloud VPN, CDN Interconnect, Cloud Load Balancing, Google Domains, Cloud DNS|
|Security||Firewalls, NACLs, route tables, encryption, IDS, SSL||Compute Engine firewalls, encryption, IDS, SSL|
|Identity||Active Directory, LDAP||IAM, GCDS, LDAP|
|Management||Configuration services, CI/CD tools||Cloud Deployment Manager, configuration services, continuous integration/continuous delivery (CI/CD) tools|
If you are migrating from AWS, you can use the comparison guide to help evaluate how AWS and GCP services compare.
After you have compared the various services to gain an understanding of what your applications need and use, you can start planning what your environment should look like on GCP.
Before migrating any VMs, you need to build out the environment for the application. The following sections provide recommended steps.
You need to establish who in your company can have permission to create, access, modify, and destroy cloud resources. You must also determine how resources will be paid for. You can find guidance in the IAM best practices documentation.
At this point, you should also determine who has accounts in the cloud. It might not be necessary for everyone at your company, or even all of your developers, to have direct access. You should establish the accounts and the policy for creating and deleting those accounts, up front.
Creating a network
Before you move any VMs, the network they migrate to must exist. Similar to permissions and accounts, it’s important to create this network in advance, because establishing procedures after applications are in flight can be difficult.
When designing a network, it’s important to realize you’re not only creating a network for an application, but a pattern for your company to follow. Consider the following questions:
- Will you have one network for each application or for each environment?
- How will your applications access shared services?
- Will you employ a hub-and-spoke model of networks, or a full network mesh?
- How will you connect the various networks?
- Will you use a VPN connection between them or use a cross-project network?
Given the array of options and the differences between companies, it is difficult to provide prescriptive advice that works in every situation. We recommend only that you evaluate your needs and choose a strategy before you start deploying applications.
The second half of network design is deciding how to connect to your existing resources. Google provides a number of different connection options, depending on your needs.
At the most basic, you can create a VPN connection between your existing resources and Google. With this service, you can create either static or dynamic routes between both locations.
If you need a faster connection to Google, you can engage with CDN Interconnect, who can help you create a direct-leased line to Google.
Finally, you might choose to create a direct link to Google at one of our many direct peering locations.
Planning for operations
When you do have applications running in the cloud, you need to monitor them, retain logs, and operationally manage them, just as you would in any system. You must think about these operations as part of your advanced planning.
There are a number of third-party configuration tools available. Software such as Chef, Puppet, and others can help you. If you already use these tools, you should continue to use them in your GCP environment. If you don't, we strongly recommend evaluating one to see which will work best for you, given the way your developers and operational engineers work. These tools can work with and complement Cloud Deployment Manager, which we recommend you incorporate into your deployment and operational management.
You have a similar decision to make for monitoring and logging. There are several third-party tools that work well on GCP. If you already use one or more of them, you should continue to do so. Otherwise, you should consider a variety of tools, including Stackdriver, which integrates monitoring, logging, and alerting in a single service.
Finally, you should migrate your first application. The first migration will serve as your template for future migrations. You will surely refine your process as you do further migrating, but it’s important to record everything you do in the first migration, in particular.
The next section discusses high-level migration architectures and the steps required to migrate in each scenario.
Broadly speaking, there are three types of migration architectures that you can follow for each application.
The first is completely redesigning an application for the cloud. While this is a viable option, it is out of scope for this article, as it is essentially the same path as creating a new application in the cloud.
The following sections discuss the second and third of these approaches.
This approach is generally the easiest way to start, as it requires the fewest changes to an application. This scenario entails shutting down the existing application and copying the data and virtual machines to the cloud.
Moving the data
The first step in a lift and shift is to move the data necessary to run the application. Often this is the database data, but it can also include static assets that you could move from a SAN to object storage in Cloud Storage. You would also move any data needed locally by the application to Cloud Storage, to be downloaded to Compute Engine persistent disks when your virtual machines launch.
Moving the VMs
The next step is to move your VMs. There are a number of ways to do this, though Google's cloud migration tool, Velostrata, is the preferred option. With Velostrata, your VMs will begin in GCP within a few minutes (on average), ince Velostrata transfers a small boot set to GCP first, starts the application, then transfers and synchronizes data transparently in the background.
Testing the application
After the data and the VMs are running on GCP, you should run the application in test mode to ensure it runs the way you expect. Testing includes meeting your performance metrics and checking that the app is properly deployed, monitored, and logged. Velostrata has built-in testing and right-sizing, helping you validate in-cloud performance, SLAs, and cost.
Moving to production
How long this step takes depends on the nature of the application. In order to switch to where the production application runs, there almost always needs to be some period of time when the application is offline, even though with Velostrata this offline time can be upfront and very short (sometimes as short as 5 minutes). How to move to production without taking an application offline, from the user's perspective, is out of scope for this set of best practices.
Two things determine how long the move can take:
- How long has it been since you did the original data import?
- How long will it take DNS to update entries for your application's front end?
You generally have much more control over the first concern. If you need your time window for moving to production to be small, then you want to make that move as soon as possible after you import the data.
After you have determined an acceptable window:
- Inform your users about the maintenance window.
- Take down your application from its current location.
- Import the missing data to the appropriate location(s) in GCP.
- Switch the DNS entries and turn on the application in the cloud.
If all goes well, the application should be fully migrated and you can let your users start using it again. When you use Velostrata, the software handles the data transfer to the cloud, synchronizes data between source and destination during the migration, and updates the DNS entries for you. This helps reduce significant labor and risk during a migration.
The third architectural approach is a hybrid migration. Here, only part of the application moves to the cloud, typically the front end and possibly the application logic. The back end and associated services remain with the rest of the existing resources. Hybrid migration is a variation on lift and shift; it's useful for when the application can be moved to the cloud but some backend services can’t. This type of migration requires fewer steps than lift and shift. For example, data storage doesn't move to the cloud in this architecture.
Determining the network connection
The first step is to create a connection fast enough between your existing resources and GCP. What this connection looks like depends entirely on your application's profile. In some cases, a VPN might be enough. In others, you will require a dedicated, high-speed line.
Migrating the VMs
The next step is migrating the VM images, similar to the lift-and- shift scenario. Again, at this point you should test the application to make sure it performs as expected in the cloud, linking back to your existing resources.
Moving to production
Finally, your maintenance window is much smaller in this case because you don’t need to migrate data. You still need to:
- Inform your users of a maintenance window.
- Turn off the existing application.
- Switch the DNS entries.
- Turn on the application in the cloud.
If all goes well, your app should be running on GCP. At this point, you can once again let your users access it.
Using the GCP migration tool, Velostrata
Velostrata provides an agentless cloud migration tool that lets users efficiently migrate VMs to GCP in minutes. Velostrata uses streaming technology to reduce migration time, provides right-sizing recommendations before you migrate to help you choose appropriate instance types, and integrates with VMware vCenter to provide a single pane of glass for managing VM migrations. Velostrata also offers a web-based interface to organize and automate mass migrations of VMs.
Velostrata is free to use for customers migrating to GCP. Standard billing rates apply for all other GCP products used or consumed during or after the migration. For example, if you use Compute Engine VMs to deploy Velostrata, you'll need to pay for those instance-hours. Additional information on the GCP products used by Velostrata is available on the Velostrata pricing page.
For more information, see the documentation for using Velostrata to migrate your VMs to GCP.