Thomas Duryea Consulting provides insights into how leading adopters successfully solve cloud risks
Leading Australian IT services provider Thomas Duryea Consulting has made a successful journey to cloud computing as a business, and a cloud-of-clouds approach is providing new types of IT services to their many Asia-Pacific region customers.
The latest discussion continues a three-part series on how Thomas Duryea, or TD, designed, built, and commercialized an adaptive cloud infrastructure. This second installment focuses 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 was conducted by Dana Gardner, principal analyst at Interarbor Solutions.
Below are some excerpts.
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?
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.
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 (SLAs), 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 datacenters, 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?
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 agreement 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 (SaaS) 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 (IaaS) 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.
Tell us about your organization, how big you are, and who your customers are, and then we'll get back into some of these risks issues and how they have been managed.
Traditionally, we came from a system-integrator background, based on the east coast of Australia — Melbourne and Sydney. The organization has been around for 12 years, and had a huge amount of success in that infrastructure services arena, initially with VMware.
Other companies heavily expanded into the enterprise information systems area. We still have a large focus on infrastructure, and, more recently, cloud. We've had a lot of success with the cloud, mainly because we can combine that with a managed service.
We go to market with cloud. It's not just a platform where people come and dump data or an application. A lot of the customers that come into our cloud have some sort of managed service on top of that, and that's where we're starting to have a lot of success.
As we spoke about in part one, our customers drove us to start building a cloud platform. They can see the benefits of cloud, but they also wanted to ensure that for the cloud they were moving to, they had an organization that could support them beyond the infrastructure.
That might be looking after their operating systems, looking after some of their applications such as Citrix, etc, that we specialize in, looking after their Microsoft Exchange servers, once they move it to the cloud and then attaching those applications. That's where we are. That's the cloud at the moment.
Is there something about the platform and industry-standard decisions that you've made that helps your customers feel more comfortable? Do they see less risk because, even though your organization is one organization, the infrastructure is broader, and there's some stability about that that comes to the table?
Definitely. Partnering with VMware was one of our core decisions, because their platform everywhere is end-to-end standard VMware. It really gives us an advantage when addressing that risk if organizations ask what happens if our company doesn't run or they're not happy with the service.
The great thing is that within our environment — and it's one part of VMware's vision — you can then pick up those applications, and move them to another VMware cloud provider. Thank heaven, we haven't had that happen, and we intend it not to happen. But, for organizations to understand that, if something were to go wrong, they can move that to another service provider without having to re-architect those applications or make any major changes. This is one area where we're well getting around that longevity risk discussion.
Is there a confluence between portability and what organizations are doing with disaster recovery (DR)? Maybe they're mirroring data and/or infrastructure and applications for purposes of business continuity and then are able to say, "This reduces our risk, because not only do we have better DR and business continuity benefits, but we're also setting the stage for us to be able to move this where we want, when we want."
They can create a hybrid model, where they can pick and choose on-premises, versus a variety of other cloud providers, and even decide on those geographic or compliance issues as to where they actually physically place the data. That's a big question, but the issue is business continuity, as part of this movement toward a lower risk, how does that pan out?
That's actually one of the biggest movements that we're seeing at the moment. Organizations, when they refresh their infrastructure, don't see the value refreshing DR on-premises. Let the first step cloud be "let's move the DR out to the cloud, and replicate from on-premises out into our cloud".
Then, as you said, we have the advantage to start to do things like IaaS testing, understanding how those applications are going to work in the cloud, tweak them, get the performance right, and do that with little risk to the business. Obviously, the production machine will continue to run on-premises, while we're testing snapshots.
It's a good way to put a live snapshot of that environment, and how it's going to perform in the cloud, how your users are going to access it, bandwidth, and all that type of stuff that you need to do before starting to run up. DR is still the number one use case that we're seeing people move to the cloud.
As we go through each of these risks, and I hear you relating how your customers and TD, your own organization, have reacted to them, it seems to me that, as we move toward this software-defined datacenter, where we can move from the physical hardware and the physical facilities, and move things around in functional blocks, this really solves a lot of these risk issues.
You can manage your legal, your SLAs, and your licenses better when you know that you can pick and choose the location. That longevity issue is solved, when you know you can move the entire block, even if it's under escrow, or whatever. Complexity and fear about forking or immaturity of the infrastructure itself can be mitigated, when you know that you can pick and choose, and that it's highly portable.
It's a roundabout way of getting to the point of this whole notion of software-defined datacenter. Is that really at heart a risk reduction, a future direction that will mitigate a lot of these issues that are holding people back from adopting cloud more aggressively?
From a service provider's perspective, it certainly does. The single-pane management window that you can do now, where you can control everything from your network — the compute and the storage — certainly reduces risk, rather than needing several tools to do that.
And the other area where the venders are starting to work together is the integration of things like backup, and, as we spoke about earlier, DR. Tools are now sitting natively within that VMware stack around the software-defined datacenter, written to the vSphere API, as we're trying to retrofit products to achieve file-level backups within a virtual datacenter, within vCloud. Pretty much every day you wake up, there's a new tool that's now supported within that.
From a service provider's perspective, it's really reducing the risk and time to market for the new offerings, but from a customer's perspective, it's really getting in that experience that they used to. On-premises over a TD cloud, from their perspective, makes it a lot easier for them to start to adopt and consume the cloud.
I suppose this is a good segue into this notion of how to make your data, applications, and the configuration metadata portable across different organizations, based on some kind of a standard or definition. How does that work? What are the ways in which organizations are asking for and getting risk reduction around this concept of portability?
Once again, it's about having a common way that the data can move across. The basics come into that hybrid-cloud model initially, like how people are getting things out. One of the things that we see more and more is that it's not as simple as people moving legacy applications and things up to the cloud.
To reduce that risk, we're doing a cloud-readiness assessment, where we come in and assess what the organization has, what their environment looks like, and what's happening within the environment, running things like the vCenter Operations tools from VMware to right-size those environments to be ready for the cloud.
Now, the flip-side of that would be that some of your customers who have been dabbling in cloud infrastructure, perhaps open-source frameworks of some kind, or maybe they have been integrating their own components of open-source available software, licensed software. What have you found when it comes to their sense of risk, and how does that compare to what we just described in terms of having stability and longevity?
Especially in Australia, we probably have 85 percent to 90 percent of organizations with some sort of VMware in their datacenter. They no doubt seem to be more comfortable gravitating to some providers that are running familiar platforms, with teams familiar with VMware. They're more comfortable that we, as a service provider, are running a platform that they're used to.
We'll probably talk about the hybrid cloud a bit later on, but that ability for them to still maintain control in a familiar environment, while running some applications across in the TD cloud, is something that is becoming quite welcoming within organizations. So there's no doubt that choosing a common platform that they're used to working on is giving them confidence to start to move to the cloud.