Vaporizing Cloud Risks

The path to the cloud is strewn with risks, but Australian IT services provider Thomas Duryea Consulting has made a successful journey to cloud computing as a business.

A cloud-of-clouds approach is providing new types of IT services to TD’s many Asia-Pacific region customers. Part 1 of this three-part series addresses the rationale and business opportunity for the company’s cloud-services portfolio, which is built on VMware software.

The discussion continues with an exploration of how TD designed, built and commercialized an adaptive cloud infrastructure — specifically, on how a variety of risks associated with cloud adoption and cloud use have been identified and managed by actual users of cloud services.

Learn more about how adopters of cloud computing have effectively reduced the risks of implementing cloud models from Adam Beavis, general manager of cloud services at Thomas Duryea in Melbourne, Australia. The interview is conducted by Dana Gardner, principal analyst at Interarbor Solutions.

Download the podcast (26:58 minutes) or use the player:

Here are some excerpts:

Dana Gardner: Adam, we’ve been talking about cloud computing for years now, and I think it’s pretty well established that we can do cloud computing quite well technically. The question that many organizations keep coming back with is whether they should do cloud computing. If there are certain risks, how do they know what risks are important? How do they get through that? What are you in learning so far at TD about risk and how your customers face that?

Adam Beavis: People are becoming more comfortable with the cloud concept as we see cloud becoming more mainstream, but we’re seeing two sides to the risks. One is the technical risks, how the applications actually run in the cloud.

What we’re also seeing — more at a business level — are concerns like privacy, security, and maintaining service levels. We’re seeing that pop up more and more, where the technical validation of the solution gets signed off from the technical team, but then the concerns begin to move up to board level.

We’re seeing intense interest in the availability of the data. How do they control that, now that it’s been handed off to a service provider? We’re starting to see some of those risks coming more and more from the business side.

Gardner: I’ve categorized some of these risks over the past few years, and I’ve put them into four basic buckets. One is the legal side, where there are licenses and service-level agreements, issues of ownership and permissions.

The second would be longevity. That is to say, will the service provider be there for the long term? Will they be a fly-by-the-seat-of-the-pants organization? Are they are going to get bought and maybe merged into something else? Those concerns.

The third bucket I put them in is complexity, and that has to do with the actual software, the technology, and the infrastructure. Is it mature? If it’s open source, is there a risk for forking? Is there a risk about who owns that software and is that stable?

And then last, the long-term concern, which always comes back, is portability. You mentioned that about the data and the applications. We’re thinking now, as we move toward more software-defined data centers, that portability would become less of an issue, but it’s still top of mind for many of the people I speak with.

So let’s go through these, Adam. Let’s start with that legal concern. Do you have any organizations that you can reflect on and say, here is how they did it, here is how they have figured out how to manage these license and control of the IP risks?

Beavis: The legal one is interesting. As a case study, there’s a not-for-profit organization for which we were doing some initial assessment work, where we validated the technical risk and evaluated how we were going to access the data once the information was in a cloud. We went through that process, and that went fine, but obviously it then went up to the legal team.

One of the big things that the legal team was concerned about was what the service level agreeement was going to be, and how they could capture that in a contract. Obviously, we have standard SLAs, and being a smaller provider, we’re flexible with some of those service levels to meet their needs.

But the one that they really started to get concerned about was data availability … if something were to go wrong with the organization. It probably jumps into longevity a little bit there. What if something went wrong and the organization vanished overnight? What would happen with their data?

That’s where we see legal teams getting involved and starting to put in things like the escrow clause, similar to what we had with Software as a Service for a long time. We’re starting to see organizations’ legal firms focus on doing these, and not just for SaaS — but Infrastructure as a Service as well. It provides a way for user organizations to access their data if provider organizations like TD were to go down.

So that’s one that we’re seeing at the legal level. Around the terms and conditions, once again being a small service provider, we have a little more flexibility in what we can provide to the organizations on those.

Once our legal team sits down and agrees on what they’re looking for and what we can do for them, we’re able to make changes. With larger organizations, where SLAs are often set in stone, there’s no flexibility about making modifications to those contracts to suit the customer.