News Stay informed about the latest enterprise technology news and product updates.

Cloud migration strategy: Consider portability, security, overall risk

In this Q&A, author Thomas Erl explains why -- and how -- companies should get smarter about portability, security and other cloud migration risks.

In this Q&A, Thomas Erl, co-author of Cloud Computing: Concepts, Technology & Architecture (Prentice Hall, 2013), talks to Senior Site Editor Anne Stuart about why companies need to get smarter about cloud computing. Erl, also the CEO of Arcitura Education Inc., an IT training/certification company, offers insights on cloud portability, integration, security and more. This Q&A has been edited for length, clarity and editorial style.

Thomas ErlThomas Erl

In the introduction to Cloud Computing, you write that "There is no greater danger to a business than approaching cloud computing with ignorance." Could you expand on the need for cloud-related education? What do businesses need to know about developing a smart cloud migration strategy?

Cloud Concepts cover

Thomas Erl: As much as cloud computing is discussed and hyped and has generated excitement in the IT industry, it still comes with a set of risks and challenges that we need to understand clearly to determine exactly to what extent we require cloud-based computing as part of our IT enterprise, or as an extension of our IT enterprise, and to what extent the risks and challenges are justified.

Moving our solutions to cloud environments and just expecting to benefit from all the potential advantages won't work. It's dangerous to just [undertake cloud migrations] because cloud environments differ significantly from other environments.

There are different levels of quality when it comes to the world of cloud vendors. Some are more diligent about the [service-level agreements (SLAs)] that they agree to. Others are less reliable or more volatile. They may be in Europe, and then six months later, be moved somewhere else. They may be subject to acquisition by larger organizations.

[Developing a cloud migration strategy] requires understanding beyond what's in the vendor brochures. You need to understand the architecture of that environment. You need to understand the potential risks and the potential harm to your organization from exposing it to those risks. That influences your ability to properly assess a given cloud and it empowers you to form criteria and then determine what type of cloud environment your organization needs -- and, again, to what extent you should be adopting cloud-based IT resources.

That's extremely important, because traditionally IT is a blank canvas and organizations can create whatever structure or space they want on that canvas; it's completely under their control. But not only is the [public] cloud environment a blank canvas that we can create something powerful or create something chaotic in, it's also an environment that requires us to form a dependency on a third party. In that case, poor design or poor decision-making may create additional problems or challenges that may blindside us.

So there's potential and there's danger. The best way to maximize the potential is to understand the danger and understand which risks are justified. For those you do accept, do what you can do to mitigate them. Whether it's security-related, whether it's related to mobility, whether it's related to legal issues or contractual issues -- [you] can plan for them if you understand them. That just underscores the necessity for education.

Can you talk about portability? Perhaps you could start by outlining the issue, then talk about what businesses need to know about incorporating it into a cloud migration strategy.  

Erl: It's about two things. [The first is mobility.] Public cloud environments are operated by private third-party vendor organizations that benefit from making them proprietary just because it locks in the consumer, just as, traditionally, vendors make certain environments propriety to make it harder to move away from. That is coupled with the fact that there is so little standardization that vendors feel compelled to comply to because the consumer market is not yet demanding it. This allows vendors to have these proprietary environments.

When we move our data and our solutions and other types of IT assets into a cloud, we are moving them into a really distinct environment; often, it is distinct just to that one vendor. For the cloud to work the way we want it to, for it all to connect to and be able to take advantage of all the IT resources that the vendor offers, we need to design the systems, and the layer of technology architectures that we add, in a way that is distinct to that environment. So we couple ourselves to the cloud provider's underlying architecture and infrastructure layers.

The implications are that if we're migrating legacy systems into the cloud, we now have to invest in integration testing to make sure everything is working the way it has worked on-premises traditionally, and that it works the way we want it to work now. It's something we have to understand in terms of budget and impact and timeline and effort. We have to understand [those things] before we sign the cloud provisioning agreement with the cloud provider.

There's potential and there's danger in cloud migrations. The best way to maximize the potential is to understand the danger.

Thomas Erl, author,"Cloud Computing: Concepts, Technology & Architecture"

More strategically, [here's another thing] we have to understand: What if, after making this investment -- six months, 12 months, 18 months later -- we decide we don't want to be in this cloud vendor's environment? We're not happy with the vendor's service, or we found another cloud provider and want to move it there, or we want to bring things back in-house. What is the impact of doing so? How much of the effort that we're putting into this is specific to this cloud environment? To what extent have we coupled ourselves, and what is the impact of decoupling from the provider and moving everything somewhere else?

That's an analysis we have to perform. We have to document and put numbers to it in terms of effort and cost, so that when we proceed with an adoption with a cloud provider, we [understand] that if we ever want to want to move on to some other environment, this is what we accept in terms of responsibility and impact.

Sometimes that's a bit of a revelation to our [business] organization. Suddenly, they realize [for example]: "It's going to cost $500,000 just to move away from this cloud vendor. That's too much risk. We can't form a dependency with our mission-critical applications in a cloud environment and then be held hostage by that environment just because we can't afford to move away from it." That might be a factor in not proceeding with cloud adoption at all.

[Second is the integration issue.] The integration testing part of it is straightforward. It's commonly understood that it's something you need to do to get up and running. What's less clearly understood is this planning consideration, this analysis of what we would need to do if we ever want to move away and the implications of that. That's another part of the education aspect: Any organization needs to know this before making significant commitments to a cloud provider because you don't ever want to be held hostage.

Security comes up in any discussion of cloud computing. Could you talk about security issues that companies should consider in developing a cloud migration strategy? We'd also like to hear more about a concept you mention in Cloud Computing -- the issue of "overlapping trust boundaries."

Erl: In the world of cloud computing, security becomes more of a common concern than in any preceding area of IT that I can recall. In traditional IT environments, there was a security specialist who would step in and take care of the security architecture and respond to attacks and threats. That worked fine because, in that environment, the security concerns were more easily isolated.

In cloud environments, especially in public cloud environments, there needs to be a broader understanding of security technologies and risk among all project team members than previously [was typical] in noncloud environments. That's because we're now putting data in an environment that's outside of our control. It's within the control of a third-party cloud provider. We may have some level of control, but we don't have complete control.

There are security implications to various decisions we make, right down to how an application is developed, how an application is used, quality assurance and testing [and project management staging]. There may be exposure to outside attackers or vulnerabilities because it is not a fully controlled environment. It affects just about everyone. There needs to be a great understanding of what security implications may come out of certain decisions and certain ways that we use data and applications in a cloud environment.

We're delivering these solutions for an environment that we have limited control over. [Underlying] a lot of these concerns is that we may be using virtualized IT resources that share and that are hosted by physical IT resources accessed by multiple different cloud consumers at any point in time. Each cloud consumer has its own trust boundary that extends to its virtualized IT resources, but most of those IT resources are residing on the same physical server, so those trust boundaries, from a physical architecture, naturally overlap.

If the physical server is attacked or compromised, it can impact all of those IT resources and anything beyond that that might be depending on those IT resources. It's not just about bringing solutions down. It's about access to data, or the abuse of data or the attempt of malicious actions. The attacker may be one of the cloud consumers that has gained legitimate access to their virtualized IT resources with their own trust boundaries.

[Even dedicated servers can't guarantee security.] Even when we say, 'We want this physical server just for us; no other cloud consumer can access it,' it's still part of a larger ecosystem in a cloud environment that's in a different location and is out of our control.

So we need to have a level of trust in how the cloud provider manages security controls and what measures they take to guarantee security and the safety of what we place there. Again, [we may] discover months after we have moved to a cloud environment that our environment is vulnerable or has been attacked and we've lost data or data has been stolen -- and that it's happening not because of our neglect, but because of the neglect of the cloud provider. Then we say, 'This can't continue; we want to move away' -- and that brings us back to mobility considerations, [including the question] 'Can we even afford to move away?' You never want to find yourself in that situation.

Dig Deeper on Cloud computing security