This write-up is an in-depth insight into the Lift & Shift cloud migration strategy. It covers all the frequently asked questions about it such as What is Lift & Shift? When to consider this particular strategy amongst the other cloud migration strategies available when moving the workload to the cloud? What are the pros & cons of it?
So, without any further ado.
Let’s get on with it.
1. What is Lift & Shift Cloud Migration Strategy?
Lift & Shift cloud migration strategy, as the name says, simply means lifting the workload running on-prem & hosting it on the cloud with minimal or almost no architectural changes or code refactoring.
When there aren’t many changes be it at the code or the workload architecture level, this would naturally be the simplest of the cloud migration strategies.
Since there are minimal changes the cloud system architecture looks pretty much similar to the on-prem system architecture with subtle changes. This migration strategy is also known as Re-Hosting.
I said fitting because they are many types of cloud compute instances pre-configured for different types of workloads. I’ll talk more about the instances up ahead in the write-up;
The first question when speaking of workload migration to the cloud that pops up is why move to the cloud at all? What are the upsides of it? Why take so much hassle?
This write-up Why Use Cloud? How Is Cloud Computing Different from Traditional Computing? Will answer all your questions about it. Do give it a read.
2. When to Use Lift & Shift Cloud Migration Strategy?
A business can consider lifting & shifting its workload to the cloud if it is spending quite an amount of money on its on-prem infrastructure & thinks moving the service to the cloud will bring down the costs significantly.
Businesses also want to migrate quickly to the cloud as their data centre lease expires.
The workload in this scenario can be lifted & shifted to the cloud & can then be re-architected later for further optimizations & to leverage the other cloud offerings.
Instant lift & shift brings down the heavy on-prem deployment costs. Provides high availability, fault tolerance, scalability, elasticity & disaster recovery to the service.
Besides the costs, the other reason for considering this approach is the intention of getting rid of the onus and the headache of infrastructure maintenance & enable the engineering team to focus on bringing new features to the market.
One another reason for considering the lift and shift cloud migration strategy is when re-architecting the application or designing it from the bare bones is not an option. This could be due to the costs associated with it, time & resource constraints, re-architecting the workload could disrupt the running business etc.
Lift & shift migration assistance by the cloud providers helps the businesses move legacy apps to the cloud easily & be worry free of a lot of things primarily the infrastructure maintenance.
3. What Kinds of Workloads Are Suitable for Lift & Shift Migration to the Cloud?
Lift & Shift doesn’t necessarily mean moving the entire workload as a whole in one single move to the cloud. It can be done in parts too.
What module or service to move to the cloud first depends on what the engineering teams decide after meditating on their service architecture;
Though any kind of application can be lifted and shifted to the cloud still applications which are loosely coupled are easier to migrate.
Systems which would not have a significant gain in performance or cost reduction even after the re-architecture are the best fit to be lifted & shifted.
Complex & resource heavy systems such as the big data processing and analytics or monolithic systems etc. might not be suitable for lifting & shifting to the cloud as they could do better after getting re-architected.
Even if we lift and shift tightly coupled and resource intensive apps to the cloud they have to be re-architected for cost and performance optimizations or it might defeat the whole purpose of migration.
Well, these are just general guidelines. There is no one size fits all perfect workload migration strategy to the cloud. Everything is a trade-off and there are always a lot of things to consider.
4. How Are Workloads Lifted & Shifted to the Cloud?
The first step of lifting and shifting the workload to the cloud is accessing & validating stuff.
What do I mean by that?
There are several validations we need to run to gauge the viability of moving a particular service to the cloud. For instance, we need an entire list of dependencies the workload has, be it a separate storage tier, additional compute power, if the service is running on bare-metal or leveraging virtualization, any proprietary library, run-time tech & frameworks, operating systems, their versions, infrastructure integration & network requirements, comprehensive metrics study of the service, what are the resource requirements at the time of peak traffic, back-up requirements, does the service needs containerization etc.
There are automated tools provided by the cloud provider, I’ll talk about it down the article, which run these dependency validations to get the lay of the land.
Massive workloads are lifted & shifted to the cloud in parts to minimize the risk and any sort of disruption to the business.
A super-fast high bandwidth secure network connection is established between the company’s on-prem data centre to the cloud data centre to stream over the data from on-prem to the cloud.
Generally, this is the storage data from the database but it also includes the static and the blob storage. Data saved in the persistent disks of the instances to save the user state is also replicated over to the cloud.
Even if the workload is not architecturally fit to run in the distributed environment of the cloud. It can use the cloud compute resources to run just like it is running on-prem.
Cloud provides different kinds of compute instances built for different use cases such as high CPU compute instances, High Memory instances, Instances with GPU power for graphics rendering and running machine learning algorithms & stuff.
Business can pick the fitting instance types based on their workload requirements.
AWS with the help of lambda functions smoothly scales up the computing power on lift & shift workloads. It also provides instance placement groups to improve the reliability of lifted & shifted workloads that cannot yet leverage the HA & other native features of the cloud due to the design constraints.
Once the lift & shift is done, stuff can be re-architected at a later point in time to leverage the other features of the cloud.
Cloud providers generally provide advanced tools which assist in the Lift & Shift migration. These tools take care of all the testing & validations of the configurations. Cut down the migration complexity. Provide rollbacks in case anything goes south. Provide dashboard analytics etc. The entire migration process is highly automated.
To get into more technical details of the migration read the Lift & Shift migration whitepaper by Google Cloud.
5. Cloud Native vs Lift & Shift
Cloud-native simply means running micro-services wrapped up in containers leveraging the full features of the cloud such as HA, portability, scalability, elasticity, disaster recovery etc.
On the contrary Lift & Shift, workloads are like black boxes migrated to the cloud with minimal or almost no modifications.
Naturally, a lift and shift workload has design constraints which blocks it from leveraging the full features of the cloud. There are reasons why businesses forklift their workloads on to the cloud, I’ve already talked about it.
Also, gradually over time, these workloads can re-architected to leverage the distributed cloud infrastructure. Adjust across the cloud IaaS & PaaS.
Picking a cloud-native approach is ideal when we are thinking of re-designing the application & have a longer period of time in mind for long term benefits. It involves a lot of code writing, iterations, refactoring & stuff, unlike Lift & Shift.
Up next, I’ll quickly cover the pros & cons of the lift & shift strategy.
6. Lift & Shift Cloud Migration Strategy Pros & Cons
Immediate cost benefits.
No infrastructure management overhead, engineering teams can focus on feature development.
Cloud scalability, security, disaster recovery.
Ability to leverage the cloud product marketplace.
Difficult optimization, workloads may need re-architecting.
Cannot leverage the full power of the cloud due to design constraints.
Might get vendor locked-in.
7. More On the Blog
Well, Guys!! This is pretty much it on the lift & shift workload migration to the cloud. If you liked the article, do share it with your folks.
You can follow 8bitmen on social media. Subscribe to browser notifications to stay notified on the new content on the blog.
I’ll see you in the next write-up;
- Distributed Systems & Scalability #1 – Heroku Client Rate Throttling
- Zero to Software/Application Architect – Learning Track
- Java Full Stack Developer – The Complete Roadmap – Part 2 – Let’s Talk
- Java Full Stack Developer – The Complete Roadmap – Part 1 – Let’s Talk
- Best Handpicked Resources To Learn Software Architecture, Distributed Systems & System Design