Making the Case For and Against Lift-and-Shift Cloud Migration
A common approach to cloud migration is to simply port material to the cloud, which is not always the best decision, considering the complexity of modern apps.
Join the DZone community and get the full member experience.Join For Free
There’s a trend being played out in companies of all types and sizes: They’ve dipped their toes in the cloud-computing waters with secondary, peripheral IT projects, learned some valuable lessons, met with more successes than failures, and are now ready to migrate their core apps and processes to the cloud. For several good reasons, recreating every internal system to its cloud-native counterpart is impractical: too costly, too disruptive, too slow, and, generally, too risky.
What works for many organizations facing this situation is adopting the lift-and-shift approach to cloud migration. You port your apps and data resources to a cloud infrastructure with minimal changes to the existing code. As you can imagine, lifting and shifting modern, multifaceted applications from an in-house data center to a cloud infrastructure has both advantages and disadvantages. For many internal systems, lifting and shifting to the cloud is worthwhile. For others, reworking the apps capitalize on specific cloud features is a better option.
When Containerizing Works, and When it Doesn’t
Conventional wisdom says placing legacy apps and workloads in containers to port them to the cloud is a bad idea. Gartner analyst Traverse Clayton states that containerizing existing systems adds the container’s “technical debt” to the equation, which is another word for “overhead”: Now you’ve got two platforms to manage instead of just one. Clayton is quoted in a November 28, 2016, article by InfoWorld’s Bob Violino.
The exception, according to Clayton, is when containerizing lets a company extend the lifecycle of its legacy apps. For one thing, containers allow faster development iterations. More importantly, placing existing systems inside containers conforms to the overall trend in organizations away from reliance on virtualization and toward exclusive use of containers for all applications.
Clayton states that a common misconception is that containerization optimizes an enterprise’s server use by increasing server “density.” However, only “mega-web scale companies and cloud providers” are large enough to realize significant server-optimization benefits from containerization, according to the analyst.
How Containerization Stacks Up Against Lift-and-Shift and ‘Refactoring’
In a December 4, 2015, article on Cloud Technology Partners, David Linthicum describes an intermediate step between the lift-and-shift approach and what he calls “refactoring,” which customizes the application specifically for the cloud. “Partial refactoring” modifies only portions of the application code, so the conversion is quicker than complete refactoring, but the app will miss out on some cloud benefits, and it will be more expensive to operate.
An in-between approach to moving applications from the data center to the cloud is partial refactoring, which gets you to the cloud faster but skips some cloud features and increases costs. Source: Cloud Technology Partners
When compared to containerization, refactoring and lift-and-shift migration come up short in terms of features, performance, portability of code and data, agility, and governance/security, according to Linthicum’s analysis. He notes, however, that containers are still a relatively new technology, and the value proposition for competing migration approaches is likely to improve in the future.
Containers currently offer advantages over refactoring and lift-and-shift, particularly in terms of data and code portability, but the situation is likely to change in the future as other cloud-migration approaches are enhanced. Source: Cloud Technology Partners
Greatest Benefit of Lift and Shift: Speed
It’s one thing to envision 100-percent cloud-native applications in your company, and it’s a very different thing to do the step-by-step planning of such a massive transition. When speed is of the essence, taking the lift-and-shift road can minimize your downtime. Situations best suited to transfer as-is from the data center to the cloud are when consolidating or shutting down data centers, preparing for or reacting to a merger or acquisition, and relocating your disaster-recovery or high-availability operations.
The other side of the equation is a “greenfield” migration that recreates the application in a form optimized for the cloud. These applications may serve as the templates for future automated development and deployment, allowing you to design from scratch policies for security, performance, and cost. An obstacle for many companies is the competition for people with the skills required for developing, deploying, maintaining, and enhancing cloud applications.
To address the talent gap, Stephen Orban, head of the enterprise strategy for Amazon Web Services, recommends that companies implement a cloud training and certification program for their IT workers. Orban was interviewed by Computerworld’s Sharon Gaudin at the recent AWS re:Invent conference in Las Vegas. According to Orban, the cloud represents a golden opportunity for anyone working in IT, yet many IT staffers hesitate to expand their cloud skills due to fear of the unknown. The more fluent IT managers are in cloud technology, the faster the migration to cloud services.
Cloud Migration Is Now Seen as ‘Table Stakes,’ Not a Business Differentiator
It has reached the point where any business without a cloud operation is playing catch-up with the competition. That’s the conclusion of VMware chief technology officer Chris Wolf in a December 5, 2016, post entitled “The Third Industrial Revolution: 2017 and Beyond.” The IT executives Wolf meets with agree that adopting an agile, programmatic infrastructure is now one of the costs of doing business, or “table stakes,” rather than a way to distinguish your firm from the competition.
Wolf believes we are on the verge of a new era in networking and security that decouples workload security from an arbitrary IP address that is a nightmare to manage when an app is moved or redeployed, to a unique global identifier, such as the app name, so the “security context” follows the application automatically. A big part of making programmatic infrastructures practical in the short run is accommodation for legacy systems, which will be able to share and benefit from the “globally consistent” operational layer. The same management and processes are applied for security, auditing, and performance regardless of where the application runs.
Cloud-Migration Plans: Shorter, Heavier on Details
How the “cloud conversation” has evolved in recent years was one of the trends noted by Computerweekly’s Carolyn Donnelly following Amazon’s recent re:Invent show. In a December 9, 2016, article, Donnelly states that enterprises no longer devise cloud-migration strategies extending two or more years into the future. Today, the migration plans span no more than 18 months, and often as few as 11 months. More importantly, the plans are much more specific these days, which indicates the person doing the planning intends to do the plan implementation as well rather than leaving the hands-on work to their successor.
Another recent trend sees companies making the cloud transition in two parallel tracks: Some apps are still being lifted and shifted to a bare-metal infrastructure as a service (IaaS) so they can realize cloud resource efficiencies in the short term; while other apps are being rebuilt as cloud-native to make them as agile as possible to develop, deploy, and maintain.
It’s as if the cloud seeds that were planted years ago in the form of one-off applications intended as a proof of concept are now blooming into full gardens that will be the foundation of the organization’s digital transformation. Lift and shift still plays a role in the migration process, but that role is likely to wane as application “lifecycles” are replaced by the cloud’s continuous-deployment model.
Published at DZone with permission of Darren Perucci, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.