Cloud-native vs lift and shift: which way to choose?
- Ansible Autoscaling AWS Cloud DevOps MySQL News Terraform Tools
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.
See more: How to avoid cloud migration mistakes
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.
IT Svit is a managed services provider with ample field experience in enterprise-grade cloud transition and digital transformation for industry-leading market players in financial, marketing and analytics sectors. We support multiple mission-critical systems and infrastructures for our customers, enabling them to always be several steps ahead in the race for innovation, disruption and customer satisfaction. Would you like to transform your business IT-infrastructure into a lean, mean, cloud-native machine? Drop us a line and we’ll make it true!
Feel free to browse through the latest insights and hints on the DevOps, Big Data, Machine Learning and Blockchain from IT Svit!
Agile vs DevOps: Merging Fail-Fast Agile with Well-Planned DevOps
Fail-fast Agile and well-planned DevOps are the two sides of a single coin, though they are not essentially the same. Merging them is possible through understanding their core values and practices.
AWS Summit 2018 London: highlights and takeaways
Gathering about 12,000 attendees and more than 4,000 live streamers, AWS Summit London was a tremendous event, highlighting all the new stuff AWS is ready to offer to the business.
10 reasons to give cloud computing a go
Cloud transition is not a buzzword anymore. With more than 52% of enterprise businesses having their digital transformation already completed, the cloud becomes the new standard.
Big Data analytics in the banking sector
Big Data Analytics can become the main driver of innovation in the banking industry — and it is actually becoming one. We list several areas where Big Data can help the banks perform better.