Cloud-native vs lift and shift: which way to choose?

Cloud transition might seem a daunting task for many enterprises, given the complexity of their legacy software and architecture. Should you lift and shift your apps or go cloud-native?

Lifting and shifting the software is a process of moving the unchanged infrastructure and software from on-prem servers to the cloud. It’s like you go on a trailer from one trailer park to another. You obviously don’t need to change a trailer to a muscle car for that. The main reason is cutting the expenses, usually. However, if you change nothing, you carry the flaws of the old system with you to the new cloud location.

Lift and shift: disaster recovery, resource spending cuts, etc.

There are certain scenarios, however, when such a move can be feasible. For example, the company must meet a budget threshold and the on-prem infrastructures are always a cost center of IT operations. Here are some cases when the apps can be safely lifted and shifted to the cloud:

• Commercial customer-facing apps that have clear-to-define patterns of resource usage and client-server interactions
• On-prem systems that will never need intense autoscaling, like HR systems, internal wikis, FAQs and other resources
• Drastic production relocation in the face of data center lease contract termination

While the lift and shift approach can be feasible as a short-time solution for mission-critical systems (or a long-term allocation of auxiliary systems), many enterprise businesses had realized that in order to use the cloud efficiently, one has to use it to the fullest extent. There are simply bottlenecks and single points of failure (SPOF) like the vertically-built databases that cannot be removed without disassembling the system and reassembling it anew.

This also makes impossible using the autoscaling and serverless computing features the cloud platforms provide. Obviously, if the app was built without these features in mind, its architecture cannot support them, which leads us to a necessity of redesign of the app from scratch to become cloud-native. Or change your trailer to a muscle car and go to Las Vegas, NV to win a jackpot, if we continue our analogy.

Cloud-native: long-term redesign for long-term benefits

On the contrary to lifting and shifting, redesigning the apps to become cloud-native takes quite a long time. It is an intricate process that consists of several main parts:

• Assessment of the existing state of your business ecosystem
• Determining the preferred course of actions for your digital assets:
  – lift and shift as is
  – redesign from scratch
  – ditching certain components altogether and/or replacing them with cloud-native analogs (like moving from a dedicated MySQL server to AWS RDS)
• If the move to cloud-native app and infrastructure is chosen, the whole ecosystem is redesigned using the tooling and platform capabilities of the chosen cloud service provider and the roadmap is created
• The new app code is developed according to the roadmap specified previously, building the CI/CD pipeline along the way and provisioning immutable infrastructure as code to support it
• The new apps and systems go through all the stages of application lifecycle management (ALM) and software development life cycle (SDLC)
• The newly-built components are integrated into a holistic system. The best part of it is that due to the use of the open source DevOps tools such systems are cloud-agnostic and work with containerized apps, allowing smooth autoscaling, the use of serverless computing and all the newest cloud features
  – a monolithic application could be split into microservices and containerized with some kind of orchestrating tool like Kubernetes
  – the infrastructure can be described in manifests (AWS CloudFormation, Terraform, Google Cloud+Ansible, etc.)
• The progress so far is validated to ensure all the transition goals are met
• The systems are launched to production and the legacy infrastructure is dropped for good

As compared to lifting and shifting the apps, building their cloud-native analogs is a time-consuming and resource-costly process, of course. However, it delivers several benefits that cannot be overestimated:

• TCO reduction. You pay for the computing resources used as you go. No capital upfront investment for data center maintenance and ensuring infrastructure redundancy.
• Operational expenses optimization. Autoscaling to meet the needs of the moment and opting for serverless computing options like AWS Lambda, Azure Functions, GCP Serverless or IBM Cloud Functions. The resources are allocated precisely when and they are needed and as much as needed, instead of overpaying for idle servers on standby.
• Endless optimization. With the cloud, the business is not constrained to rigid operational structures and patterns. The systems can be adjusted according to the needs of the hour or to reflect the updated company strategy and vision. In addition, the flexibility of the cloud allows for endless search and implementation of service optimization, allowing the business to remain competitive and ever-efficient.

There is a point to consider, though: it all depends on the scale of operations and the tasks at hand. If the enterprise goes global and requires lots of resource-intensive tasks (like Big Data analytics or training Machine Learning models for predictive decision-making support), using bare-metal data centers with an added Infrastructure-as-a-Service layer is definitely more feasible. The public cloud serves as the medium to connect them in that case unless the company decides to go for a private cloud or hybrid cloud strategy.

Final thoughts on choosing the cloud-native vs lift and shift

To sum it up, both cloud-native and lift and shift approaches to cloud transition are feasible, depending on your business operational patterns and goals. However, we sincerely believe — and know for sure from our hands-on experience — the complete redesign of the app architecture and underlying infrastructure to be more rewarding in the long run.

Despite the larger initial investment and longer transition time, going for cloud-native software ecosystem ensures the utmost flexibility of operations. This also provides the ability to integrate the latest technology and practices in order to gain and retain the competitive edge over not-so-techy market players, optimize the resource allocation and deliver a steadier, bigger ROI.

This story was initially posted on my company’s blog — https://itsvit.com/blog/cloud-native-vs-lift-shift-way-choose/