Cloud Migration Strategies and Compute Terms: Rehost, Replatform, Refactor, Containers, Serverless and Spot VMs (Cloud Digital Leader)

A cloud migration moves workloads from where they run today, usually an on-premises data center or a colocation facility, to a cloud provider such as Google Cloud. A workload is a specific application or service together with the compute, storage, data and network resources it needs to run. Migrations are planned and tracked workload by workload, not server by server, because the business cares whether the payroll system or the customer portal works, not which box it happens to sit on.

Three things that are often confused with a workload are not workloads:

• Capacity or consumption, the amount of compute an organization buys or uses each month, is what gets measured and billed.
• A server inventory, the list of physical machines, is an input to discovery. One server can host several workloads, and one workload can span several servers.
• A migration plan sequences workloads into waves with target dates. Each wave contains one or more workloads.

Google Cloud describes the journey in phases: assess the current estate, plan the landing zone and the order of moves, migrate (deploy) the workloads, then optimize them once they are running. Google Cloud supports each phase with tooling such as Migration Center, which gathers inventory data and produces cost estimates, and with programs and partners that help organizations plan and carry out the move. The rest of this lesson covers the vocabulary every phase uses.

Discovery and assessment is the first step of a migration: discovery builds an inventory of the applications that exist, how they depend on each other and how much they use; assessment uses that inventory to estimate cloud costs and choose an approach for each workload. It comes before anything is moved, and it does not move or change anything itself.

Its business value comes from two kinds of finding:

• Dependencies show which applications call each other or share data. Workloads that depend on each other usually have to move in the same wave, or the move breaks something that still runs on premises.
• Usage (CPU, memory, storage, traffic over time) shows what each workload really needs. That supports right-sizing and a realistic estimate of what it will cost to run in the cloud, rather than copying the size of an on-premises server bought for a peak that rarely comes.

Assessment informs decisions; it does not carry them out. It often shows that some applications need changes to run well in the cloud, that some should stay where they are for now, and that some should simply be switched off. Planning the order of moves and modernizing particular workloads are later steps that build on what assessment found.

Retire and retain are the two outcomes in which a workload does not move. Retire means decommissioning a workload because it is no longer needed. Retain means deliberately keeping a workload where it runs today because there is a good reason to, and reviewing that decision later.

A simple test separates them: retire needs a reason to stop, retain needs a reason to stay. An application that is in use and required cannot be retired, however old it is. An unused application has no reason to stay, so retaining it just keeps paying for it. A finding that only says a workload would be easy to move, or would benefit from the cloud, is an argument for migrating it rather than a reason to keep it.

Retaining is not a refusal to modernize. When the reason to stay is a rule about where the workload runs, no amount of change to the application lifts that rule, so it stays in place until the rule or the situation changes.

These four terms describe how much a workload changes when it moves, from not at all (rehost) to a completely new solution (reimagine). Speed falls and cloud benefit rises as you go down the list. The nicknames follow the Cloud Digital Leader exam guide; Google Cloud's architecture documentation uses slightly different labels for some types, so recognize the idea rather than the label.

Rehost

Rehosting copies a workload unchanged onto cloud VMs. It suits deadline-driven moves, such as leaving a data center when its lease ends. Its known drawback is that it moves inefficiencies too: servers sized for on-premises peaks stay oversized, and designs that cannot scale out still cannot. A lift-and-shift estate can therefore cost more than expected and gain little elasticity until the team optimizes it after the move. That is normal and expected, not a sign that the cloud is the problem.

Replatform

Replatforming makes targeted improvements during the move without rewriting the application. The classic example is adopting a managed database so that patching and backups move to the provider. It is the usual answer when a team wants less upkeep but has no budget or time for a rewrite.

Refactor

Refactoring changes the application's code and architecture to gain cloud-native benefits. If the goal needs a different architecture, for instance separate teams shipping features independently or scaling one busy part on its own, only refactoring delivers it: approaches that keep the monolith leave it released and scaled as one unit.

Reimagine

Reimagining starts from the business goal rather than the old application. The organization rethinks the process and builds a new solution. The distinction from refactoring is the one most often tested. Take a retailer's returns process: splitting its returns application into microservices that still require a receipt, a store visit and a manual check is refactoring (same process, new architecture); replacing it with a process where customers start a return online, drop the parcel at a pickup point and are refunded automatically is reimagining (new process).

A migration rarely uses one approach for everything: after one assessment, each workload in the portfolio gets the approach that fits its own constraints. The deciding details are usually stated plainly:

• No users or a replacement exists: retire.
• A regulation, recent hardware investment or a contract keeps it in place: retain, and review later.
• A hard deadline and no changes allowed: rehost.
• Less operational effort without a rewrite: replatform onto managed services.
• A goal that needs a new architecture, with time and budget accepted: refactor.
• A new way of doing the business, not a better copy of the old one: reimagine.

For example, a university with an intranet wiki that duplicates a newer collaboration tool, a research-lab system whose data must stay in the country's own facility, and a shared file server that has to be out of the data center within weeks would retire the wiki, retain the lab system and rehost the file server. Many organizations also combine approaches over time for the same workload: rehost first to meet a deadline, then replatform or refactor once it is running in the cloud.

A virtual machine (VM) is a software-defined computer with its own operating system, running on a physical host alongside other VMs. A container is a package of an application together with the libraries and settings it needs, which shares the host's operating system kernel instead of carrying its own full operating system.

Virtual machines let one physical server run many isolated servers, each with its own OS. That is why lightly used physical servers can be consolidated onto far fewer machines. In Google Cloud, VMs are provided by Compute Engine (its business value is covered in the infrastructure offerings lesson).

Containerization solves the "works on my laptop, fails in production" problem: because the container includes the application's dependencies, it behaves the same on a developer laptop, in testing and in production, and on any platform that runs containers. Containers are started from images; a container registry stores and versions those images but does not run them.

Containers are lighter and faster because there is no full operating system to boot or store for each one; the host's kernel does that work for all of them.

A microservices architecture builds an application as a set of small, independent services that talk to each other through APIs, each deployed, released and scaled on its own. The alternative, a monolith, is one application deployed as a single unit, so every change needs a full release and the whole application scales together.

The business value is independence. During a sale, an online store built from microservices can scale only its checkout service while the rest of the site stays as it is, and separate teams can ship features to their own services without waiting for one big release. Each service usually owns its own data, so a change in one does not force changes in the others.

Microservices are commonly packaged as containers, and an organization running hundreds of containers needs software to manage them. Kubernetes is the open-source container orchestration system that does this: it places (schedules) containers onto machines, restarts containers that fail, and scales them with demand. Google Cloud's managed Kubernetes service is Google Kubernetes Engine (GKE), covered with the other infrastructure offerings.

A managed service is one where the cloud provider runs and maintains the underlying infrastructure and software, handling provisioning, patching, scaling and upkeep, so the customer's staff can focus on using the service. Serverless computing goes furthest in that direction: the customer runs code or containers with no servers to provision or manage, the platform scales automatically, including down to zero when idle, and the customer typically pays only while requests or events are being handled.

Managed services are about who does the operational work: running in the cloud does not by itself make something managed, and how a service is priced does not decide it either. The test is whether the provider, not your staff, provisions, patches and maintains it.

Serverless fits event-driven work (reacting to file uploads or messages) and workloads with long idle periods. In general, the more of the stack the provider runs, the less upkeep the customer does and the less it pays for idle time:

Google Cloud's serverless compute products, Cloud Run and Cloud Run functions, are covered in the infrastructure offerings lesson.

Spot VMs are Compute Engine virtual machines that run on Google Cloud's spare capacity at a deep discount compared with standard VMs, in exchange for the fact that Google Cloud can stop (preempt) them at any time when it needs the capacity back. They suit fault-tolerant, interruptible work such as batch processing, rendering, simulations that save checkpoints, and test environments. They do not suit live, customer-facing services such as a payment API, where a sudden stop would drop requests.

Spot VMs have no maximum runtime: they keep running until they are preempted or you stop them. That is the difference from the older preemptible VMs, which offer the same kind of discount but always stop after at most 24 hours. Google Cloud recommends Spot VMs over preemptible VMs for new work, and because nothing stops a Spot VM at a fixed deadline, long-running jobs are interrupted less often.

Other Compute Engine pricing and placement options solve different problems: committed use discounts lower the price of steady usage in exchange for a one- or three-year commitment, and sole-tenant nodes dedicate a whole physical server to one customer, at a premium, for isolation, compliance or licensing needs. Neither can be stopped by Google Cloud to reclaim capacity.

Autoscaling automatically adds instances when demand rises and removes them when it falls, so capacity follows demand. Load balancing spreads incoming requests across a group of instances and stops sending traffic to any instance that fails its health checks. They are usually used together, and each solves a different problem.

• Autoscaling keeps an application responsive during unpredictable surges and stops the organization paying for peak capacity all day. It changes how many instances run.
• Load balancing shares traffic across the instances that exist and routes around failures, so users keep being served when one server goes down. It decides where each request goes.

Neither one does the other's job. A load balancer does not create instances when traffic triples, and autoscaling alone does not stop users being sent to a failed instance.