Disclaimer: All opinions are my own
When it comes to migrating applications to the cloud for the first time, some of the advice out there can be unhelpful.
Particularly, be wary when people start talking about lifting-and-shifting applications (or re-hosting, as it’s sometimes called).
Lifting-and-shifting looks like this:
Take an application that you already have deployed (in a data centre for example). ‘Lift’ it as it is, making no changes to the application (no code optimisation, no refactoring), and ‘shift’ it onto cloud infrastructure (Infrastructure-as-a-Service).
Really all you’re doing is changing the underlying infrastructure that supports the application.
And this can work really well.
- The migration is obviously faster since you’re not having to make changes to the application.
- The application itself isn’t changing so your organisation isn’t going to have to adapt to work with this new cloud-hosted application.
- You can now take advantage of some cloud features.
AWS and other cloud providers even offer tools that automate this kind of migration, which really would make it seem like the most straight forward migration strategy. Providers often recommend it to organisations that are looking to dip their toes in cloud provisioning for the first time.
But it’s not always the best approach. There is the obvious drawbacks: You’re not taking advantage of the cloud in a lift-and-shift. You can’t really utilise the on-demand scaling for applications that are monolithic in design.
But most importantly: if you don’t know anything about cloud and you’re using this strategy to avoid learning how to use it, you’re inviting trouble. Your organisation needs to be strategically prepared for the move — and all your processes need to reflect the shift. It’s a lot more than just running an automated tool (or at least it should be!).
But there’s also the application itself to consider. Is it suitable for a lift-and-shift?
- Is it cloud-ready by design (modular and decoupled)?
- Is the software it needs supported by the cloud provider?
- Is it largely independent in your IT estate?
In our first example, we were looking at an app that was ready to move to the cloud (a ‘cloud-ready’ app as most literature would refer to it). So let’s look at what we will call a ‘cloud-resistant’ app.
If a cloud-ready app is one that is modular in design and decoupled, then a cloud-resistant app is one that is monolithic and tightly coupled. In other words, the state-of-play for a lot of legacy apps that have deteriorated into ‘ball-of-mud’ architecture over the years. Particularly those that started their lives in the early years of digitilisation when best-practice wasn’t really codified (or didn’t reflect what is needed in the modern enterprise) and it was every programmer for themselves. These applications are complicated and can have not-well-understood dependencies!
What about applications that are dependent on software that is not supported by the infrastructure offered by a cloud provider? These providers often assume that their consumers have applications using the latest (or close-to) versions of databases, monitoring tools, security services etc . Or that they all communicate using the latest protocols. But for legacy applications, we know this is not always the case. If you are running a database server that is twenty years old, you are unlikely to find a cloud provider that you can just ‘lift-and-shift’ that database onto.
What about applications that communicate with other applications in your organsiation? In the luckiest case, you might just have to repoint these other services at your new IP address, but if you’ve had to update a protocol to the most secure version to host it on cloud infrastructure, you are now going to have to update that protocol at the other end — so you may now need to undergo a huge discovery and change process to update all the other services. So much for an automated migration!
In some cases, particularly when the application is reliant on software that is not supported by the cloud provider, you may be forced to create a ‘wrapping’ for your application that does all the communicating between your traditional app and it’s new cloud infrastructure. Ignoring all of the new risk introduced by this extra layer, including the latency added for communications, it’s now going to be harder for your devs to go in and make changes. Many cloud providers will recommend ‘moving first and re-factoring later’, but this wrapper makes that process of refactoring much more cumbersome and costly. You might’ve saved money by just updating the application first and making it cloud ready before you migrated it.
It’s never a good idea to make a fundamental change to your applications without fully understanding the implications. Personally, I do not think ‘lift-and-shift’ should be the first step for someone looking to try out cloud provisioning for the first time. The first step should probably be learning more about what migrating to the cloud would mean (or bringing in someone else who does!)
Rey works as a junior solution architect for Capgemini