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:
“A stereotype persists that IT is overwhelmingly against the cloud due to perceived security and network concerns. However, 55 percent of respondents said they would embrace cloud DR as long as they could extend their on-premises network and security controls to the cloud. This suggests IT pros aren’t against the cloud, they just want equivalent controls in the cloud. ”
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
About the Author
Related Blog Posts
Build a quantum-safe backbone for AI with F5 and NetApp
By deploying F5 and NetApp solutions, enterprises can meet the demands of AI workloads, while preparing for a quantum future.
F5 ADSP Partner Program streamlines adoption of F5 platform
The new F5 ADSP Partner Program creates a dynamic ecosystem that drives growth and success for our partners and customers.
Accelerate Kubernetes and AI workloads with F5 BIG-IP and AWS EKS
The F5 BIG-IP Next for Kubernetes software will soon be available in AWS Marketplace to accelerate managed Kubernetes performance on AWS EKS.
F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.
F5 Silverline Mitigates Record-Breaking DDoS Attacks
Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.
Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.