Why the Lift-and-Shift Model Is Unlikely to Succeed ?

Someone tells you to move your workloads from on premises to a cloud service provider (#CSP): “It will be easy; just lift and shift.” Simple, right? The short answer is no. A CSP and your on-premises environment are very different. Now you may be thinking, well, you move to a CSP because there is some capability or feature that you can’t achieve on premises—like elasticity, resilience, global reach, or economics. All of those are good reasons to consider a move to a cloud! But when it comes to operating workloads in CSPs versus on premises, the way they’re managed is quite different. Consider logging as an example: the output from a CSP will likely differ from what you get from your on-prem hypervisor (or related systems). Can you commingle the logs? Unlikely. Perhaps you can map CSP events to your existing format and keep the same logging infrastructure. If you can, do you have different rules for on prem versus CSP (probably), and different #automation or call routing? Does your application need to provide different event output if running in a CSP versus on prem? All things to consider, develop, test, and refine.

But that example assumes something that’s probably untrue—that the CSP can access your logging systems! Those logs are typically behind firewalls (for good reason). Do you have connectivity from the CSP to behind your firewall? That can take a while to set up and configure.

As for the application itself, you need to ask whether it will run solely in the CSP or as a hybrid for some time. If hybrid, what key databases must you share across the CSP and on prem, what connectivity do you need between the two, and what is an acceptable latency? What about testing in the new architectures? How many more scenarios must you consider?

Separately, how do you move your application from on prem to the CSP? Where are your source code or packages/artifacts stored today? If on prem, can you move those to the CSP for deployment? It’s not always easy to do that; you sometimes need different configurations or builds for CSPs.

Many considerations remain beyond the application, infrastructure, and #DevOps teams—for example, #security. Many datacenters use an intrusion prevention system (IPS). Your security team, if it applies the on-prem rules, will require an IPS running in the CSP that it can control. The problem is that IPSs tend to need access to layer 2 of the OSI Model, which most CSPs will not allow. Security (and other) teams need to rely less on specific tools and rather think at a higher level about what risks an IPS mitigates in the first place and how the CSP addresses those concerns.

Ultimately, your organization needs to be comfortable with the new roles and responsibilities, and with not having 100% control of the environment. Do not underestimate the difficulty in asking people to give up control to a CSP. Building a comfort level with workloads in CSPs takes careful planning, research, testing, and time.

And issues to do with lack of control or ownership extend far beyond just the security team. Examiners and sometimes customers in regulated #industries previously had the right to audit an environment; while onerous, since you controlled the environment, you could comply. With CSPs, you typically do not get the right to audit. You might be able to get the right to examine, but that is fundamentally different. This may mean a change in customer contracts, and ensuring that your regulatory agencies are OK with the move (many now do accept CSPs). Hopefully you can see that moving from on prem to CSP takes a lot of thought, coordination, and consideration. Using CSPs requires a learning curve and maturity. Take the time to do it right.

I will write next time other articles about security at cloud native speed to give you a new projection.