This article provides guidance and best practices for migrating computing workloads to Google Cloud. 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 the following:
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 Google Cloud, 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 apps, 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 apps 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 and the cost of what you are running in your data centers. This calculation includes not just the cost of the physical machines, but the cost of the networking gear, power, cooling, staffing, and leasing of the data centers.
To help you evaluate these costs, 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 know your costs, you then need a cost model for the cloud. Consider the following:
- 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 apps have.
- Beyond virtual machines, what other services does your app require, and how are they priced?
- Do these apps 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 Google Cloud 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's 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 apps, from customer-facing apps, to back office apps, to developer tools, to experimental apps. Moving all these apps at the same time and the same way doesn't make sense.
We recommend sorting apps into three broad buckets:
- Apps 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.
- Apps that are difficult to move. These have more dependencies, are less tolerant to scaling, or have complex license requirements.
- Apps that can't be moved. Some apps 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's likely your apps have many more deciding factors. Your Google Cloud 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 app or apps to migrate. We strongly recommend you migrate only a few apps 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 apps 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 Google Cloud. The following table provides a brief overview of the comparison:
|Service type||Data center||Google Cloud|
|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, Cloud 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 Google Cloud services compare.
After you have compared the various services to gain an understanding of what your apps need and use, you can start planning what your environment should look like on Google Cloud.
Before migrating any VMs, you need to build out the environment for the app. 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 Cloud 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 apps are in flight can be difficult.
When designing a network, it's important to realize you're not only creating a network for an app, but a pattern for your company to follow. Consider the following questions:
- Will you have one network for each app or for each environment?
- How will your apps 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's 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 apps.
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 Cloud Interconnect, which 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 apps 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 Google Cloud 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 Google Cloud. If you already use one or more of them, you should continue to do so. Otherwise, you should consider a variety of tools, such as Stackdriver Logging, Stackdriver Monitoring, and Stackdriver Error Reporting.
Your first migration will serve as your template for future migrations. As you do further migrations, you'll likely refine your process, but it's important to record everything you do in the first migration.
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 app.
The first is completely redesigning an app for the cloud. Although this is a viable option, it's out of scope for this article, because it is essentially the same path as creating a new app in the cloud.
The following sections discuss the second and third approaches.
This approach is generally the easiest way to start, because it requires the fewest changes to an app. This scenario entails shutting down the existing app 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 app. 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 app 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. Migrate for Compute Engine, is the preferred option. With Migrate for Compute Engine, your VMs will begin in Google Cloud within a few minutes (on average), after Migrate for Compute Engine transfers a small boot set to Google Cloud, starts the app, then transfers and synchronizes data transparently in the background.
Testing the app
After the data and the VMs are running on Google Cloud, you should run the app 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. Migrate for Compute Engine 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 app. In order to switch to where the production app runs, there almost always needs to be some period of time when the app is offline, even though with Migrate for Compute Engine, this offline time can be upfront and very short (sometimes as short as 5 minutes). How to move to production without taking an app offline, from the user's perspective, is out of scope for this set of best practices.
Two factors 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 app's frontend?
You generally have much more control over the first factor. 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, do the following:
- Inform your users about the maintenance window.
- Take down your app from its current location.
- Import the missing data to the appropriate location(s) in Google Cloud.
- Switch the DNS entries and turn on the app in the cloud.
If all goes well, the app should be fully migrated and you can let your users start using it again. When you use Migrate for Compute Engine, 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 app moves to the cloud, typically the frontend and possibly the app logic. The backend 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 app 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 Google Cloud. What this connection looks like depends entirely on your app's profile. In some cases, a VPN might be enough. In other cases, you'll need 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 app 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 do the following:
- Inform your users of a maintenance window.
- Turn off the existing app.
- Switch the DNS entries.
- Turn on the app in the cloud.
If all goes well, your app should be running on Google Cloud. At this point, you can once again let your users access it.
Using Migrate for Compute Engine
Migrate for Compute Engine provides an agentless cloud migration tool that lets users efficiently migrate VMs to Google Cloud in minutes. Migrate for Compute Engine 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. Migrate for Compute Engine also offers a web-based interface to organize and automate mass migrations of VMs.
Currently, Migrate for Compute Engine is free to use for customers migrating to Google Cloud. Standard billing rates apply for all other Google Cloud products used or consumed during or after the migration. For example, if you use Compute Engine VMs to deploy Migrate for Compute Engine, you'll need to pay for those instance-hours. Additional information on the Google Cloud products used by Migrate for Compute Engine is available on the Migrate for Compute Engine pricing page.
For more information, see the documentation for using Migrate for Compute Engine to migrate your VMs to Google Cloud.