Why Lift and Shift Works Better on a Private Cloud vs a Public Cloud – A Guide for IT Professionals

In this blog:

• Migrating To The Cloud
  • Lift and Shift
  • Refactoring
  • Replatforming
  • Repurchasing
  • Retiring
• Why Is Lift And Shift Getting A “Round 2” Look?
• Lift And Shift And Private Cloud Resource Management
• Lift And Shift- How It Scales With Private Clouds
• Private Cloud vs Public Cloud Resource Efficiency

We have been helping a lot of customers get their cloud costs under control in the last year.  One common theme is this concept of having to redesign an application or deployment because “how it was built does not take advantage of public cloud cost savings.”

Before I address that, lets step back a bit and look at the common ways companies were and are migrating to the Cloud.  I will add my “clarifications” to what I believe is the common mindset.

Migrate to the Cloud – General Strategies

Lift and Shift

Also known as “rehosting,” this approach involves moving applications from on-premise infrastructure to the cloud with minimal or no modifications. Organizations retain the existing architecture so it is a quick transition.

Common Misconception: This method is often used to quickly achieve cost savings by leveraging cloud infrastructure without rewriting applications.

Actual Situation: If you were above the Public vs Private Cloud Cost Tipping Point, Lift and Shift to traditional public clouds will cost you more to run than if you kept it were it was.  You would only really achieve cost savings if you are well below the Tipping Point.

Refactoring

Refactoring, or “re-architecting,” involves modifying the application’s architecture to take advantage of cloud-native features. This can include redesigning the application for serverless computing, microservices, or containerization. While more time-intensive, it enhances scalability and performance.

Common Misconception: Being able to instantly scale up and down is very important to my application.

Actual Situation:  The vast majority of systems, companies, and users do not need to tolerate or support extreme swings in utilization.  Refactoring so you can “scale like Amazon on Black Friday” just doesn’t make sense unless you are that extremely rare company or system.  And for clarity, I mean 1 out of a 1000 might need this crazy level of scaling.

Replatforming

Sometimes referred to as “lift, tinker, and shift,” this approach lies between lift-and-shift and refactoring. It involves making a few optimizations to the application to take advantage of cloud features without a complete overhaul. This can involve moving databases to managed services, using built in Load Balancers, or using built in network tools like Site to Site VPN.  These are handy and generally do make sense versus run them yourself on some kind of DMZ like VM.  That being said, if you are familiar with something like PFSense and love it, switching away isn’t necessary.

One area to highlight is usage of Object Storage.  In the case where you did not have Object Storage as a Service in your existing deployment, you should spend time understanding it.  Object Storage is becoming key for big data, backups, and general operational storage.  We offer it as a standard in our Hosted Private Cloud and as a stand-alone Object Storage cluster.  

Repurchasing

In this approach, organizations shift from existing applications to new cloud-native software, often SaaS (Software as a Service) platforms. Instead of migrating the existing application, a cloud-based equivalent is adopted, reducing the need for infrastructure management.

There are times to do this, for sure.  In the open source world many people and companies like to only use the Open Source version.  If a tool or system is relatively small scale and is not something in your core business, you should consider using a SaaS equivalent.

A classic example is do you build or buy a billing system?  Or a CRM system?  Likely, no.

Retiring

During the migration process, some applications may be deemed redundant or no longer useful. Retiring involves identifying and removing these legacy systems rather than migrating them to the cloud.

Yes, you should do this, of course.

Why is Lift and Shift getting a “Round 2” look?

When looking back at the last 10 years of “Cloud Adoption” there are really two major migration strategies for current workloads – Lift and Shift vs Refactor.

Lift and Shift is often contrasted with rearchitecting/refactoring. Many proponents of the public cloud will advocate changing your software stack to be more “cloud native”. Take advantage of “instantaneous and limitless scaling up and down” to have both a resilient application at any load and the best unit economics.

The first problem with this?  Do you actually need “instantaneous and limitless scaling up and down”?  The answer is no, you don’t and the fact is you do not have an unlimited earning potential when it scales up – but you do have an unlimited cost potential.  The idea of your software or business taking off like a rocket and using that unlimited scale is very appealing.  So appealing that the need for the extensive refactoring or initial engineering gets in the way of releasing the first version and getting the feedback loop going.  Don’t fall for it!

The second problem with this? You are trading a known system, with a known cost, for a refactoring project that has variabilities that will end on a platform that has variable cost. Sometimes the current known cost is simply so high that it seems like you have only the one alternative, refactor. Refactor, rewrite, reinvent the wheel. There are times when you must do this, when it is healthy to do this. And there are times when it is just a waste of key talent that should be working on new features or functionality. For executives currently considering what should be done, we offer a revisit to Lift and Shift and its benefits when combined with private cloud.

Lift and Shift and Private Cloud Resource Management

With private cloud, we put forth an alternative to refactor – Lift and Shift your servers to your private cloud. Once you have reached well known cost tipping points, private cloud is the most predictable and cost effective strategy.

With Private Cloud you have the advantage of controlling your resource allocation, including what is called “subscription rate”. The subscription rate is the ratio between the hardware unit, like a CPU Core, and the virtual resource, a vCPU. This ratio is determined by what the likely usage rate of the resource will be. For example most servers, both bare metal and VMs, run in range of 15% to 40% of the available CPU with rare cases of running at 100% utilization. Rare in this case is something like 5-6 seconds out of a minute, or even less. So 1/12 or 1/10 of your time is spent at or near maximum capacity.

This is such a low usage rate compared to the actual limit that it is typically deemed a waste of purchased resources. It is good management to figure out how to increase usage of the CPU to something closer to its limit, lets say 80%, while still providing sufficient instantaneous burst resouces.

The problem with Lift and Shift in a public cloud setting is that you need the upper limit to keep good performance for your Lift and Shift workload during that 1 out of 10 situations. You have to pay for the ability of your VM to burst to that maximum even though it only runs there for small percentage of the time. Very inefficient from a cost perspective, but necessary.

Lift and Shift – How it Scales with Private Cloud

So why is Lift and Shift different in a private cloud? Summarized, Lift and Shift workloads take advantage of the simple fact that when one of your VMs is not bursting at its maximum, those resources are returned to the Cloud to be used by your other VMs.  As you scale up with more and more workloads on your private cloud, your workloads will approach more statistical norms.  In the case where you have one or just a few types of workloads you will Lift and Shift, your Cloud can be designed at the hardware node level for those workloads.  So as you scale, your costs are directly aligned with your most valuable work. 

One important note – if you have already made the change to public cloud you do not need to refactor to get out of that money pit. Simply Lift and Shift your public cloud based VMs, databases, storage, etc. to private cloud based resources. Join OpenMetal and we will even help you design and execute a highly automated cloud migration plan.

In summary, combining a Lift and Shift Cloud Migration Strategy with the ease of instant on hosted private cloud allows you to keep your developers away from costly refactors and on new products and new features. Private Clouds are the perfect match to Lift and Shift strategies while also offering up the convenience of having cloud native infrastructure for your next generation of applications.