For Lift and Shift to the Cloud Success Focus on Architecture

There has emerged two distinct models of “going cloud.” The first, most obvious, is the native approach. Native meaning new, either greenfield or rewritten. The native approach encourages a narrow focus on the application, the assumption being that when tailored to the cloud, performance and security become a matter of provisioning the right services in the cloud. Which is not entirely true but it’s close enough that we’ll go with that for now.

The second approach is “lift and shift”, which is focused on exactly what it sounds like: lifting an existing application from its data center foundation and shifting it into the cloud, where it’s placed on a cloudy foundation. Except the focus can’t be just on the application in this model, because the application has dependencies that must be addressed, too. That includes other architectural components that span application and infrastructure services. 

This was recently highlighted in a Cloud Velox report, with a focus on leveraging cloud as the secondary data center. It interestingly noted this finding:

Now, Cloud Velox was focusing on disaster recovery, but it seems that the general issue is more broadly applicable. Lifting and shifting apps to the cloud is a lot more palatable if you can also lift and shift network and security controls (services) along with them.

Basically, if you move an app that has been optimized over the years using app services hosted in the network without those app services, you lose those optimizations. Oh, there’s this misguided belief that simply being out there, in the cloud provides a performance boost because it is physically closer to the Internet backbone and the users who interact with it, and that’s somewhat true, but not entirely. That’s because much of the performance of an application isn’t dictated by network latency. The truth is many of the inefficiencies in an application that lead to poor performance are related to content size and composition, poor connection management, and the inability to properly tune the network stack to match the application’s specific needs.

Security concerns, too, don’t suddenly disappear when you lift and shift an app into the cloud. If the app was vulnerable to XSS or SQLi in the data center, you can bet it’s still vulnerable when you shift it into the cloud*.  If those concerns were addressed in the data center with a web app firewall or security artifacts deployed on programmable proxy, then the app firewall and the proxy had best be lifted and shifted along with the app.

The ability to “lift and shift” an architecture, as opposed to just the application, is one of the reasons behind the growing popularity of a co-located cloud option. There are also arguments for cost savings over on-premise, and better control than in cloud, but certainly one of the more attractive characteristics of a co-located cloud option is the ability to lift and shift an entire architecture and take advantage of the "cloud next door”. Sometimes organizations want to move the data source closer to the cloud-deployed apps to avoid performance-destroying latency required to go all the way back to the corporate data center. Sometimes the business wants to be able to scale out the front end without disrupting the back end (and again, avoid latency). Moving to a co-located cloud provider means they can do that, because the cloud is right there, over a very fast, data center grade interconnect.

Regardless of the approach to cloud (co-lo or public), the key to a successful lift and shift to the cloud is to lift and shift as much of the architecture as possible. Cloud service options not withstanding, it’s important to keep critical app services with its application through its transition to ensure performance and security aren’t compromised by the relocation. 

*Also referred to as Hoff’s Law which, though not really a law, remains as accurate an observation today as when it was first observed in 2009