Leverage the Cloud: Move your workloads to Google Cloud Platform

Introduction

The cloud can be terrifying for some, but magical for others. It creates opportunities that a lot of people can only dream of, but without proper knowledge it can do more harm than good. We at Devoteam Cloud Services have multi-year experience working with Google Cloud and can help you leverage the cloud in a professional and safe manner that fit your organization.

This short article will give you an introduction to migration of virtual machines to Google Cloud Platform and challenges that may arise. I will give you an overview of how a VM migration is performed, the tools that are commonly used and how they are used, as well as the pitfalls that you should keep in mind during your planning. This should not be seen as a replacement for official documentation or such, but as a complementary quickstarter and reminder of common risks.

This article is aimed at people working with one of their first migration projects and is in need of guidance and pointers to successfully move one or more workloads to Google Cloud Platform. If you're currently looking for help to migrate your own workloads to Google Cloud, feel free to send me a message and we'll give you the help you need! I do advise you to reach out even if you only need guidance through your own migration project since we can be a helping hand in your cloud adoption.

VM Migrations

Migration of virtual machines is a process where virtual machines are moved from one environment to another. A migration can be a move between two private data centers, from private cloud to public cloud, or from one public cloud provider to another. This article will cover a migration of virtual machines from a private cloud running on vSphere to a public cloud provided by Google Cloud, but most of the information is generic for all source environments.

There are three different strategies that can be used when migrating workloads to Google Cloud Platform; Rip and replace, Improve and move, and Lift and shift.

Rip and replace is the least common strategy that is being used, except if you consider staying at the private cloud, which only correlates to 5 % instead of Rip and replace's 10 % of the total workloads that has been assessed. Rip and replace, also referred as Go Cloud Native, means that most of the application has to be rewritten to work with the cloud. It is a strategy that is being used when the current application isn't meeting the requirements set up and it is no longer worth maintaining in the private cloud setup.

A relatively common migration strategy is Improve and move, which correlates to around 30 % of all workloads that has been assessed. This strategy focuses on moving the workload from vSphere to Google Cloud and at the same time improve the application by taking advantage of Cloud Native tools, such as changing database solution, replacing the CI/CD pipeline or containerizing the application. This is done to improve aspects of the application such as portability, simplicity and replication.

The most common strategy being used in migration projects specifically to Google Cloud is Lift and shift, which correlates to around 40 % of all assessed workloads. Lift and shift is the strategy where workloads in theory are moved to Google Cloud without any changes. Since more or less no migrations can be pure lift and shift, the migration is in practice done with as few changes as possible instead of no changes. This is the case because minor changes are most of the time needed to make the application run in the new environment, such as IP address changes. The article is mainly based upon this strategy.

The remaining 15 % consists of two groups of workloads. The first 10 % are applications that have been retired before a move to the cloud has occurred, and the last 5 % are migrations that cannot neatly fit into one of the previously mentioned categories.

Process and Tools

To help with the migration to Google Cloud you can take advantage of multiple tools that can help throughout the migrations different phases; Assess, Plan, Deploy and Optimize.

The migration process starts with the assess phase, also referred to as the discovery phase. Here we can use tools such as CloudPhysics and StratoZone that automatically gathers data about the workloads running in vSphere. Meetings and discussions can be held parallel to the automated insight gathering that can add context and scope to the project, such as estimations and key data that are not available from the automated tools mentioned above. The gathered information can then be analyzed to be able to group workloads together and pick a first mover, which is the workload or group of workloads to be moved first. Best practice for picking a first mover is to group the workloads by the following order:

1. High business value, low effort to implement.
2. High business value, high effort to implement.
3. Low business value, low effort to implement.
4. Low business value, high effort to implement.

The second phase in the migration process is the planning phase. This focuses on creating a landing zone in Google Cloud Platform for the migration. A landing zone is the foundation in Google Cloud Platform that you need in order to migrate and run the workloads in Google Cloud. The foundation consists of setting up monitoring, logging and cost control, creating the network setup, as well as defining IAM policies and firewall rules. Terraform is a cloud agnostic IaC tool that is widely used in the industry, commonly used in our projects and recommended by Google themselves.

When the discovery and planning phases have been finished, the migration itself begins with the help of Migrate for Compute Engine. The phase starts with a test period where clones of the workloads running in vSphere are seamlessly started in Google Cloud Platform without affecting the workloads running in vSphere. These virtual machines get data streamed to them from vSphere and are used for testing before the full migration is performed. When the workloads have been tested and approved, the full migration may start. The workloads in vSphere become unavailable during the migration, but become fully available in the cloud within 10 minutes while the data is continuously streamed from vSphere to Google Cloud Platform until all data has been migrated and the connection to vSphere can be cut.

A successful migration will result in running and working workloads in Google Cloud Platform, but there are still a lot that can and should be done to fully take advantage of the benefits of the cloud, and that is where the optimize phase comes into the picture. The application can be modified to take advantage of Cloud Native tools to improve the experience for the end user. These tools and modifications can for example be managed instance groups, load balancers, different data storage solutions, advanced encryption management and automated containerization.

Common Pitfalls

Pitfalls during a migration project can be many, and their size and complexity may vary a lot. Here I want to give you some pointers to what you should think about during your migration projects to minimize risk for unnecessary trouble.

Are the source workloads properly set up?

The workloads that you want to migrate to the cloud have to be properly set up when working with automated tools, such as Migrate for Compute Engine. This is because the tool expects a certain behavior and configuration from the virtual machines to successfully migrate and validate the machine in the cloud. For example do virtual machines running Linux OS have to install a specific preparation kit for Migrate for Compute Engine. Things such as SSH servers needs to be pre-installed and configured as well to give Migrate for Compute Engine the possibility of validating the workloads when they have been migrated to Google Cloud.

Is the Internet connection good enough?

Google are supporting multiple ways of connecting to their network and migrate the virtual machines. The selected option should be mainly influenced by your own Internet connection. How is the bandwidth? Is the connection stable? You should take a closer look into Dedicated/Partner Interconnect if you have a troublesome connection to the Internet or that the bandwidth is slow, otherwise you could consider using VPN tunnels instead. Interconnects support a higher bandwidth than the VPN tunnels, either by having a physical connection between your on-premises network and Google's network, or by having a partner in-between providing a Partner Interconnect.

Plan, plan, plan...

Migration projects are usually structured in short cycles where you start by planning for the upcoming migration sprint. This means that all planning must not be done at the start of the project. All information is more often than not unnecessary to gather since it will not bring value to the current work. Even though all planning must not be done at the start of the project, it is important to make sure to gather all the information that we need to be able to create a plan that is executable for the upcoming sprint. Lacking information may lead to architectural decisions that is not compatible with the workloads when they are running in the cloud, which means that you have to go back to the drawing board after your first migration sprint.

Last Words

This article has given you an overview and introduction to the steps that are performed in a migration of virtual machines, but the steps are much more complex and involve more work than what is described here. It has also given you a few pointers to what should be considered when planning and executing a migration project, but there is more that should be taken into consideration to not be forced to spend unnecessary time on redoing already done work.

I am only one of many specialists working at Devoteam Cloud Services and we are more than happy to help you in your cloud adoption. It does not matter if you are new to the cloud, have a background working with another cloud provider or if you already have workloads running in Google Cloud Platform. We as a premier partner are willing to provide the guidance that you need to find the best solutions to your problems!

Please feel free to contact us through our website or contact me directly here at LinkedIn for further help!