When you’re adopting a new public cloud infrastructure, you need to decide what is the best way to migrate your data. There are three ways you can do this: by refactoring your applications, lifting and shifting them onto a platform, or by containerizing the applications. In this post, we’ll break each of these options down so you can make the most informed choice for your business needs:
Refactoring
When we talk about “refactoring” your applications for the public cloud, it’s basically a modern way of saying that we need to re-write these applications for the specific cloud environment you want to use. Vendors encourage you to refactor your apps to be cloud-native—to THEIR cloud. Doing so ensures that you are getting the maximum efficiency from the application — to run faster, be more cost-efficient, and be able to leverage all of the cool feature functionalities that the vendor offers. In fact, if you are moving one of your core applications to the public cloud, it’s highly recommended that you refactor.
But a warning bell might have gone off when I explained that refactoring means rewriting the apps… and rightly so. Re-writing an application—especially while keeping all the rich features and high customer experience–can take years depending on how complex it is. On top of the time it takes, the cost, risk, and chance of failure (or disappointing marginal success) are extremely high. The success and failure of refactoring an application can make or break a career, given the time, resources, brainpower, and money that go into the process.
On top of all this, refactoring for a particular cloud ensures that your applications are no longer cloud-agnostic. In order to shift data and applications from one public cloud to another, you will need to go through the time-consuming and risky refactoring process all over again. But with high risk comes high rewards. Companies that refactor their apps successfully to be truly cloud-native will be able to fully reap the benefits that brought them to the cloud in the first place.
Lift and Shift
If you’re not looking to bet your career by refactoring your applications, you can lift and shift instead. Lifting and shifting requires that you copy your applications (installer and file system data) and reinstall it in the cloud, onto a platform (Windows or Linux typically). While this is significantly faster and presents far less risk and cost than refactoring, you also don’t get the cool feature functionalities, scalability, and performance that comes with natively leveraging the cloud. If you are migrating an app that you are planning to retire within the next few years, or you have an application that is going to be too costly, will take too long, or is too risky to refactor, then lift and shift is probably the best option for you.
Modernization with Containers
Imagine that you and your friends want to go deep-sea fishing one Saturday. You wouldn’t go out and buy a superyacht for a three-hour tour, would you? You’d rent a fishing boat for a few hours. The third option for moving data to the public cloud is the equivalent of this analogy: putting applications into containers. By leveraging containers, you can strategically use key components of a complex application in the cloud without running the entire operating environment. Containers encapsulate only the runtime code required by your application. You can self-execute these containers without maintaining the overhead of running the whole environment. Need additional features from the complete application? These can be reached through a shared common library. Moving applications to the cloud through containers is quick, simple, and doesn’t require that you fully refactor to a specific new API. If you’re looking to eventually refactor your app for the cloud, containers are a great stopgap to start getting key data, features, and functionalities on the cloud while the entire app is being rewritten.
One Final Option….
Refactoring, lift and shift, and containers are the three main options for moving applications to the cloud. But what if none of these options offer what you need? Perhaps you are planning to refactor in the future but need to move the application – the whole application – to the cloud today. Or maybe you want the ease of lift and shift but the full suite of feature functionalities and performance that come with being cloud-native.
By decoupling data from the underlying infrastructure and providing a virtual control and data plane with uniform data services across any cloud, data can quickly and easily be migrated to any infrastructure of choice, and onto either a platform or to a cloud-native solution: whether that be the public cloud, a private cloud, or a hybrid configuration. Plus, by placing the data on this virtual layer, you can turn off expensive cloud resources and reduce your monthly cloud spend.
Summary:
Migration to the Cloud
When you’re adopting a new public cloud infrastructure, you need to decide what is the best way to migrate your data. There are three ways you can do this: by refactoring your applications, lifting and shifting them onto a platform, or by containerizing the applications. When we talk about “refactoring” your applications for the public cloud, it’s basically a modern way of saying that we need to re-write these applications for the specific cloud environment you want to use. If you’re not looking to bet your career by refactoring your applications, you can lift and shift instead. Lifting and shifting requires that you copy your applications (installer and file system data) and reinstall it in the cloud, onto a platform (Windows or Linux typically). While this is significantly faster and presents far less risk and cost than refactoring, you also don’t get the cool feature functionalities, scalability, and performance that comes with natively leveraging the cloud. Imagine that you and your friends want to go deep-sea fishing one Saturday. You wouldn’t go out and buy a superyacht for a three-hour tour, would you? You’d rent a fishing boat for a few hours. The third option for moving data to the public cloud is the equivalent of this analogy: putting applications into containers. By leveraging containers, you can strategically use key components of a complex application in the cloud without running the entire operating environment.
