Introduction to VM
Migration
Learn how to...
Place VM Migration in the Google Cloud Adoption Framework
Distinguish major migration strategies
Know when to choose the Lift & Shift
Apply a recommended methodology to migration projects
Agenda
Where do you start?
Migration types
Best Practices
Migrating VMs is a small part of the overall concept of cloud adoption. In this chapter
we need to fit it in its place.
How do you see cloud transition?
Move Adapt Invent
Objective Cost optimization, Maximizing business IT as a center of
Minimize CapEx, value, Optimizing IT business innovation and
Minimize disruption, operations, leveraging agility
Extend application life new technology
Example Move an existing mission Leverage cloud services Make automated
use cases critical solution off aging to ingest, stream, enrich, predictions in real-time
hardware and to the and analyze with ML
Cloud
Let’s think about the business drivers for migration. Is it a quick lift & shift to migrate
away from an expensive data centre?
Are you trying to build a leaner, more agile IT organisation, with automatically scaling,
resilient infrastructure, and DevOps / SRE?
Or are you looking to transform your business through new technologies like big data
and AI?
Google Cloud Adoption Framework (GCAF)
As you’d expect from Google, we think about cloud adoption more broadly than just
tech.
A cloud migration gives you the opportunity to rethink how technology enables your
business.
● Learn - cloud means learning new skills, and training (or retraining). But it also
changes the way you learn. Cloud resources are cheap, disposable and
democratised - people can learn and innovate safely.
● Lead - adopting cloud can be a huge change. It needs a clear vision from the
top; but it also means sharing knowledge and good practice across the
organisation. We recommend a ‘Centre of Excellence’-style team
● Scale - use the cloud adoption to build repeatable, scalable practices -
DevOps, CI/CD, infrastructure-as-code
● Secure - of course, you need to trust your deployment in the cloud. We’ll help
you think about how your security model will change in the cloud.
In you broader engagement with the customer, you may well be using the Google
Cloud Adoption Framework. This tool is used to help partners and their customers
reason about the level of cloud maturity within an organization and the work that
needs to be done to evolve. VM Migration projects are typically undertaken by
organizations at the Tactical level of maturity, with the focus being on cost reduction
and avoiding risk. As a partner, not only are you trying to successfully complete VM
Migration projects, but you also want to focus on moving the customers from the
Tactical maturity level into the Strategic level with training, post-migration optimization,
etc.
Business leaders are
under pressure to deliver
quickly on Migration and modernization top the
digital initiatives... CIO’s agenda
In the race to serve customer needs,
many enterprises can’t afford to take on
68% 59%
Migration existing Evolve our application
prolonged migration efforts
applications to the cloud portfolio to promote
agility and innovation
Source: Forrester
Warmer: We talk to Business and IT leaders all the time who are evaluating public
cloud providers. Business leaders in particular are under pressure to deliver on digital
initiatives. Competitive pressures and the need to respond quickly to customers and
partners make time-to-value a driving concern. Not every enterprise can afford to take
on a prolonged 12-18 month migration effort where benefits are only realized at the
end.
Migration, who’s done this already?
Migrated from Data Centers Migrated from AWS
Migrated 100% of Dev/Test workloads
from on-prem to GCP. 160% increase in Completed one of the largest AWS to GCP migrations
cores consumption post migration; for Target.com. Migration included move to
increasing performance of production and Kubernetes and Spinnaker CD platform.
Big Data workloads.
Rearchitected migration plan from AWS to
Migrated likely the largest Hadoop cluster preemptible VMs (pVMs) and GCS. 40% cost
in the world, along with over 300PB of savings over AWS for comparable workloads due to
data, to increase speed and lower costs. incremental billing.
Migrated 4PB of data in 70 days (from At the end of 2016, Lush migrated the entire
beginning of data transfer to fully ecosystem of 17 global eCommerce websites, onto
running on GCP). Google Cloud, in 22 days.
Migrated e-commerce and mobile #14 on the Fortune 500, migrated thousands of
services to GCP; rearchitected several applications from on-prem and AWS into GCP using
elements into microservices to power Velostrata. Saved 5+ hours per server in IT labor
record-breaking holiday sales. through Velostrata’s agentless architecture.
You aren’t alone in this journey. https://cloud.google.com/customers/#/
Where does VM Migration live?
Where does VM Migration fit?
This diagram shows how the specific task of VM migration fits within larger cloud
adoption patterns. Google conceptualizes cloud adoption as being driven by one or
more of five pillars, such as Modernize Infrastructure, Accelerate Applicating
Innovation and so on. Pillars in turn consist of solutions, which are focused on a
particular area within the pillar e.g. the Modernize Infrastructure pillar includes the
Migration, Hybrid Cloud, and Backup Archival and DR solutions. Migration in turn
consists of multiple workloads, which roughly map to a workflow that represents a
single project. VM Migration is shown as one of the possible eleven individual
workloads that could make up a Migration solution.
This way of thinking about cloud adoption patterns is reproduced in much of Google’s
messaging about cloud e.g. see https://cloud.google.com/solutions/
Agenda
Where do you start?
Migration types
Best Practices
Migration strategies at a glance
Lift and Shift Go Cloud Native
Public
40% 10%
Remain On-premises Improve and Move
On-prem
5% 30%
Classic apps & operations Cloud-native apps & operations
These numbers are based on Google’s experience with customers.
For the “missing 15%” above, 10% of applications are retired before moving to the
cloud, while 5% don’t fit neatly into any category.
And just so you know, you never really do a pure “lift and shift”. There are always a
certain amount of improvements you need to make to an existing application to get it
to run in the cloud. Those changes may be minor (e.g. change IP address
assignment) or more significant changes (make use of container technologies).
So the part of this slide that’s of key interest to us, is that 70% diagonal. Everything
we do related to this course in somewhere in there.
Remain On-premises
Public
On-prem
Rigid & expensive
Classic apps & operations Cloud-native apps & operations
The good? You have full control over everything. Security, servers, DR, OS, etc.
The bad? You have full control over everything :-)
That means:
● Expensive commitment to data center, personnel, and hardware
● Lots to manage
● Requires high levels of security expertise
● Slow to innovate because how fast can you pop in new servers
● Not easy to experiment at any scale
Cloud native
Developer Available
productivity Efficient & ops agility
Public
Portable Pay for use
Scalable Secured
On-prem
Classic apps & operations Cloud-native apps & operations
Rip and replace: start over in the cloud
Developer Available
productivity Efficient & ops agility
Public
Portable Pay for use
Scalable Secured
On-prem
Rigid & expensive
Classic apps & operations Cloud-native apps & operations
Rip and Replace means rewriting existing applications to run under Google Cloud.
This can be quite challenging with major legacy applications, due to poor
documentation, lack of application knowledge etc. There usually needs to be a strong
motivation (or “pain point”) to embark on this type of project. The benefit though is that
you get to take full advantage of everything the cloud has to offer once you’re finished
with the migration.
Rip & replace: overview
What it is When to use it
Completely rewriting When the current application
an application for, and isn’t meeting its goals
in, the cloud
When the current application isn’t
worth maintaining and the cloud
offers technical or financial benefits
Rip & replace: pros & cons
Pros Cons
Takes full advantage of the cloud Doesn’t work for off the shelf apps
Removes technical debt Requires significant code rewrite
Easily scalable Takes longer / more effort than lift & shift
Highly available May not support niche scenarios
Highly managed Requires new tools
Requires updated skill sets
Need to re-evaluate existing plans
The pros of moving to the cloud are that you can take advantage of all the cloud
facilities, such as scalability, availability etc. However it takes a major effort to tear
down the old app and then rebuild it to get there.
Improve and move
Developer Available
productivity Efficient & ops agility
Public Portable Pay for use
Scalable Secured
Developer productivity
Portable
On-prem
Scalable
Available
Classic apps & operations Cloud-native apps & operations
Make improvements to the existing on-prem application, e.g., containerization,
standard OS images, updated developer pipeline, database changes, etc. It is not a
complete re-write like ‘rip and replace’.
Improve & move: overview
What it is When to use it
Modernizing an application in Current infrastructure
the process of migrating it isn’t supported in cloud
An updated version
is necessary
Like ‘rip and replace’, there often has to be a pain point to motivate this strategy. For
example, we’ve been using a database that just can’t handle the load we’re placing
on it. Since we have to modernize/change the database anyway, perhaps we start
exploring cloud solutions for the DB and other parts of our app. We decide to replace
the DB with spanner, move to the cloud, and then continue improvements once we’ve
made the move. Another option might be to convert the application to a containerized
format, then lift it into GKE.
Improve & move: pros and cons
Pros Cons
Portable Often requires refactoring
Scalable May not work for off the shelf apps
Highly available Requires new tools
Environmental consistency Requires updated skill sets
Need to re-evaluate existing plans
Takes longer than lift & shift
Updated skills sets can be a big issue, as working within the cloud often requires new
skills compared to on-prem. How companies support and manage this change is
crucial
Lift, shift, and optimize
Efficient & ops agility Developer Available
productivity Efficient & ops agility
Public Pay for use
Portable Pay for use
Secured
Scalable Secured
On-prem
Rigid & expensive
Classic apps & operations Cloud-native apps & operations
This is our class, right here. Lifting to the cloud gives us access to easy machine
scaling, managed instance groups, and a lot of other cloud native features, without us
having to rewrite the application. It also typically allows for much better rightsizing and
significant cost savings.
Lift & shift: overview
API gateway +
VPN/Interconnect
What it is When to use it
Moving applications as Applications that can run
they exist to the cloud unmodified in the cloud
Speed is necessary
Little appetite or need
for change
Lift and shift can extend the life of applications that have already proven their value.
Perhaps they are on aging servers which will need to be replaced to keep on prem, or
they just can’t handle the new load and moving to the cloud might offer solutions to
some of the scaling problems, with relatively little in the way of code changes. Note:
moving an application with NO changes is very rare - usually some changes are
required.
Lift and shift can help companies get into the cloud relatively quickly, and in a
relatively low-risk way.
Lift & shift: pros & cons
Pros Cons
Easiest migration Not inherently cloud-ready
Use existing tools Scales vertically (generally)
Use existing skills Is not highly managed
No tools change Does not work for all apps
Supports off the shelf software Does not leverage cloud pricing
(generally)
Fast way to migrate to the cloud
Under lift and shift you may not be using all the native cloud facilities, such as
managed services. But it does get you to the cloud quickly, where it’s applicable.
Often times the answer is not “either or”, but “all of the
above”
28% 47% 25%
Application complexity
Complex 20 46 67 5%
7252
Medium 127 568 22 25%
3540
3004
Simple 668 747 633 71%
Total applications Applications in Applications in scope
UK,US and APAC after excluding ones Lift and Move and Transform
categorised for retiring Shift Improve
Target migration approach
These numbers are based on migrations performed by Google for particular clients.
Note that they are only actually lifting and shifting about third (28%) of the
applications. Also notice that L&S by itself is almost never the full solution. It’s usually
a mix of various options for a variety of apps.
Agenda
Where do you start?
Migration types
Best Practices
Migration to GCP can be tricky
● GCP ≠ AWS ≠ Azure
○ Make sure you and the client understand differences
● Many organizations rush
○ Management says we have to do this now!
○ Do proper planning, build a solid foundation
● Need the proper skill set
○ Traditional roles need to be transitioned to GCP roles
○ Training!
● Different financial and operational models
○ CapEx to OpEx shift
○ Pay as you go
Every public cloud has its own nuances and particularities, and GCP is no exception.
Make sure the client understands this. It doesn’t matter how much they know about
AWS, GCP isn’t exactly the same.
More and more the problem isn’t, will we go to the cloud, it’s trying to slow the
migration down so it gets done right. Manager goes to conference. Manager comes
back all cloud evangelized and really excited. Manager dictates: “We need to move to
the cloud, like, yesterday.” A poor discovery leads to a poor foundation, a poor
foundation leads to recurrent problems, security vulnerabilities, and technical debt.
Risks and mitigations
Risk Mitigation
Improper sizing Better planning + metrics-based rightsizing
Security vulnerabilities Build a better foundation
Need the proper skillset Learn, then lead
Different financial and operational Learn the transition away from CapEx
model towards OpEx and pay as you go
Mitigated through discovery, foundation, migration, and optimization
Security vulnerabilities may result because the client misunderstands their security
responsibilities, and/or mis-configure the security tools available to them in the cloud.
Remember, GCP is a shared security model. Google is clear on their responsibilities
and all they do, but is the client as clear about their own responsibilities when it
comes to the cloud? In this class we will talk about a number of different risks and
how we can mitigate them. It all starts with discovery...
Pre-VM migration assumptions
● The business case for VM migration has been made
○ The client buys in
○ Solid executive sponsorship
● Assessments have been done
○ Inventory taken, TCP/ROI calculated
○ Frequently part of the sales cycle
● Lift and shift is appropriate for at least some apps
● You understand what success looks like
○ And how it will be measured
● Client is creating a Center of Excellence team
We are assuming that the business case has been made for VM migration, and the
project has solid executive sponsorship to smooth the execution of the migration
project e.g. facilitate access to secure data centers/servers.
A Cloud Center of Excellence is an internal team within the client who has Google
Cloud skills and can advocate for and technically support the project.
Google’s VM migration process
Assess/Discover Plan/Foundation Migrate! Optimize your
your application Create a landing Pick a path, operations and
landscape zone to the cloud and get started save on costs
Cloud migration is the journey, the end-to-end lifecycle whereby
things move from other locations (on-prem, other clouds) and into
GCP is the destination where these things migrate to,
the GCP.
and which are often modernized/optimized in-cloud
afterwards.
Migration is complex with many potential paths, but in general customers go through
the following journey for migration and all phases can be accelerated through
automation and tooling:
Discovery: Understand details of on-prem environment to define migration plan.
Customers (or a System Integrator) usually prefers to use tools they are familiar with
and incase they don’t have one, they are looking for something that is simple to use,
easy to deploy, non-disruptive, comprehensive (server, storage, usage profile,
applications, OS and licences etc) and secure (collected data won't be misused)
Assessment: Discovery data is used to define post migration solution architecture,
pricing and phased migration. This phase is complex with many knowledge intense
design tradeoffs that determine final solution architecture and pricing (e.g: VM
shapes, Node types/general fleet or sole tenant, Container vs. VM, CPU Overcommit
(for ST nodes), License optimization (BYOL), customer managed DB vs. SP managed
vs. cloud native DB etc).
Plan/Foundation: Landing Zone preparation: Customer customer (or SI partner) sets
up the overall Cloud environment so that workloads can be migrated (billing account
taxonomy, Identity and Access Management rules, Resource Groups, Network and
firewall rules, ….)
Migration: Once customers completes the above phases, they are ready to migrate
workloads (VMs, Containers, DB, or data)
Optimize: Now that it’s in GCP, how can it be made to run better and more cost
effectively
Your strategy for cloud adoption Retire
guides the approach, but every Decommission
workload is different Retain
Leave on-premise
Rehost
Simple lift and shift from legacy to GCP
Migration Replatform
Optimize
Factory Move and improve as you migrate to GCP
Discover Plan
Refactor
Transform and modernize the application
Change Replace
Factory
Use new COTS/SaaS over legacy applications
Each of your apps will flow through this journey. The path for each is different.
Consider it like an agile backlog, or a pipeline.
Our 'migration factory' is an iterative, sprint-based process to migrate (or lift and shift)
VMs that, at most, require minimal changes. You can migrate a lot of workloads
quickly, and benefit from efficient use of resources, rightsized machines, and Google’s
network. We can also replatform - upgrading, or even containerizing your workloads
as they’re migrated. Once migrated, you’ll optimize - use Cloud Monitoring as a
single-pane-of-glass monitoring solution. Rightsizing and instance groups can reduce
costs and improve reliability. CI/CD pipelines for your apps and infrastructure will give
you cloud-native agility even for VMs.
Our ‘change factory’ will help you where you want to refactor or rewrite your
applications. Take advantage of cloud native tools and technologies to help you scale
and innovate. As you’d expect from Google, this is developer- and business-centric.
We focus on your business goals, bring SRE practices and Google’s open,
collaborative ways of working to your organization, while respecting that you may
have constraints and norms of your own. Apps that follow this path for migration are
typically a small subset, but often the most valuable to you.
Note: It’s likely that a number of the applications/services whose VMs you initially put
through the migration factory will later be refactored or replaced as a lower priority after
the initial migration is complete.
