The Physical Impossibility of “Migrating to the Cloud”

Ask most companies today about their application strategy and they’ll say, “We’ve got it covered, we’re moving to the cloud.” To which I ask, “What are you moving to the cloud?”

You have people who have to log in — that person isn’t in the cloud, they’re connecting to the cloud, and there’s an app and a device sitting in a physical place that isn’t in the cloud. You have data coming in from things like GPS or biometric devices — a physical location and a human being can’t move to the cloud. Everything is connected, and while your back-office systems are in the cloud, a big part of your ecosystem resides in the hands of human beings walking around on the face of the Earth.

And let’s not forget, it’s not just humans connecting. In our modern era of open APIs and automation, other services need to connect to your data — maybe a SaaS CRM tool or a vendor logistics system. Those things we don’t control will never be part of our cloud, and all need their own identity and authorization independent of the tools available in whatever cloud platform we choose.

And then let’s think about what “the cloud” is.

Companies like Amazon offer a great suite of basic tools. We all start with the infrastructure as a service model (IaaS), where you get a virtual machine that looks and feels like a physical computer. This saves our operations teams from having to worry about failed power supplies, wiring up ethernet cables, and other physical hardware issues. But we still have an operating system, software running on that operating system, and all the vulnerabilities that come with it.

The traditional corporate cloud implementation looks a lot like an on-prem ecosystem. You have instances in a private network that are whitelisted to each other and to other key systems. Your business data is still being generated out in the physical world, so you may have security rules to allow a third party to upload data regularly. That third party might be in another cloud network, but for all intents and purposes, it’s not it your cloud. It needs security and identity that you don’t directly control.

The next step is PaaS, or platform as a service. I love things like Amazon’s RDS databases for their scalability and easy setup. Of course, it’s still a database, and it can still be compromised. You need to understand how to build a database not only for performance, but for security, no matter what tools are offered. And that data still needs to get in there, which means we’re back to people and devices that sit in our physical world in places like coffeeshops and home networks.

When we get to things like AWS’s Lambda services, we run into another security problem: you have to use Amazon’s. Your business requirements or legal compliance may require fine-grained control, yet AWS gives you what they give you, and workarounds get costly because you’re hacking around their systems or – worse yet – leaving the low-cost environment to verify transactions in a high-cost environment.

Then there’s the simple problem of square pegs and round holes. Cloud services are great, to a point. If you have legacy systems, they may end up being substantially more expensive to run in the tools provided in a cloud environment. It may even be prohibitively complicated to lift and move existing systems, which means a complete ground-zero rewrite.

Sometimes old systems need to be thrown out, but a cloud migration strategy is the ultimate “rip and replace” strategy. So, while many companies are talking about moving to the cloud, most companies don’t have much success fully moving everything to the cloud.

What we see is a fractured attempt to move some things, and because we’re now dealing with two worlds – what came before and the cloud tools – we see two sets of security policies, two sets of identity management, and sometimes more because the IaaS and PaaS ecosystems don’t overlap. What was supposed to be an exercise in simplicity suddenly becomes a security nightmare for all the reasons we need a single identity and security model (see our post on Why We Secure Our Systems for more on that).