In this second part of a two-part story on cloud computing, executives from four major cloud service providers respond to customer questions and concerns about service-level agreements and data ownership. You can read the first part of this story, which focused on cloud security and outages, here.
The executives, from Microsoft, Amazon.com, Rackspace and Salesforce.com, discussed these customer concerns at the recent Gartner Catalyst conference in San Diego.
How can customers be assured they will maintain data ownership and be free from data tampering?
It's commonplace now for cloud service providers to spell out in end-user agreements that customers are the keepers of their data. At the same time, it's understood that in running the cloud service, the provider has access to that data. This ability for the cloud service provider to "reach inside," so to speak, has long been a concern of potential users of cloud technology, who are accustomed to having complete control over access to their data.
I think most of us want service-level assurance more than we want a service-level agreement.
vice president and head of platform research, Salesforce.com
With cloud, the traditional model of allowing a single administrator access to all data should be replaced, said Peter Coffee, vice president and head of platform research at Salesforce.com Inc. Cloud computing calls for a more nonhierarchical model, which Salesforce.com employs. "We use a much more granular model, in which administrative privileges might include creation and deletion of items but don't necessarily include the right to read them," he said. "In the multi-tenant model, you can do that."
Allowing the least amount of privilege possible to each person working on a system is the right idea, said John Engates, chief technology officer at Rackspace Hosting. And no one should be immune to the restrictions. In that company's locked-down data center, even the CTO can't enter unescorted. "We've had that in our compliance requirements for many years -- that the only people who can go into the data center are people required to work in that facility at that time, so their access is actually shut down and removed [when they aren't working]," Engates said.
Any information that would serve to identify particular customers is stripped out, so even those who have physical access can't discern where a particular company's data is located. "That just doesn't happen in a cloud environment," Engates said. This is the case for physical servers as well as software, he added.
"Having a separation of responsibilities helps a lot, because you don't give the guy that has physical access all the keys to the kingdom from a logical access perspective," Engates said. "This is an area where once you put that policy in place -- using either process or policy or a technical solution to prevent it -- you only have to do that once in the cloud. You have to do that every single time in a traditional organization."
In this era of "big data," customers also carry concerns their data will be mined. According to Gartner, this is a particular concern of customers using Software as a Service (SaaS). This concern does come up from Office 365 customers who want to know if things they write about in their emails are suddenly going to show up as targeted advertising, said Bill Hilf, Microsoft's general manager for Windows Azure. Microsoft has no interest in analyzing or mining information from Office 365, and stays completely separated from end-user data, he said. This separation can easily be accomplished, he added, by encrypting information at rest or in transit or by using a myriad other technical solutions.
As a general rule, customers need to understand not only these separation controls, but also what is written in their service-level agreement (SLA) and end-user licensing agreement, Hilf said. "Not to be heretical, but there are some cases where I tell customers 'You actually shouldn't move your data, you really should keep it on-premises,'" he said. "There are reasons to do that. Sometimes they're geopolitical reasons -- not just financial -- or they're regulatory reasons, where it could start wars if data moves between borders. There has to be a rational, pragmatic conversation of when to use this technology and where does data sit."
Is there too much emphasis on SLAs?
It's difficult to think about cloud without thinking about uptime. If ultimate control of your software or infrastructure is given over to another company, what could be more important than knowing that service will be working? But as these cloud service providers were eager to point out, there is a lot more going on -- that's more vital to a customer's business -- than potential outages. While it is important to have a base-level understanding and expectation of what the service is, said Hilf, the real meat that customers need to focus on is contained in end user licensing agreements (EULA).
Read more about data ownership and SLAs
How data-privacy policies help secure cloud applications' success
Cloud insurance, secure identity management and SLAs
Tips for tackling uptime in the cloud
"If you want to know if we will indemnify you if someone sues you for IP violations, that's not in our SLA -- that's in our sales contract or EULA if you're buying an off-the shelf product," Hilf said. "I do think [an SLA] is important because it's an expectation: Is this thing going to go down for eight hours a year or 80 hours a year? I've got to know, but I think people overload [the SLA] as the contract for all things cloud."
Charlie Bell was an Amazon Web Services (AWS) user for years before he became its vice president of utility computing. In that time, he never found a helpful SLA, he said. What is really needed on the engineering or customer side is an understanding of how the solution is supposed to behave and how you can engineer with it, he added.
"It's very hard to get very fine-grain about all the things you need at an engineering level to do your job in SLAs, and at the end of the day it's not going to be the few dollars you get back on a support agreement that matters in that situation," Bell said. "[SLAs] should still be there to keep the suppliers on their toes, but what you really want is the infrastructure services, or whatever level you're operating at, to manage themselves."
At Salesforce.com, SLAs aren't the norm -- many customers don't have them. Coffee likens putting SLAs into the base price of a cloud service to putting trip insurance into the base price of airline tickets. Most people, he said, wouldn't want to pay for that. "Embedding a non-trivial SLA in the base cost of a service would increase the cost floor in ways that many customers would not find valuable," he added.
For example, it doesn't benefit the customer for a cloud service provider to put an SLA on a test and development service where people don't mind if they have to reschedule a test run. Rather, it reduces the transparency and granularity of cost, which isn't in a customer's best interest, Coffee contended.
"I think most of us want service-level assurance more than we want a service-level agreement," Coffee said. "I'm always happy to talk about how we achieve the state of mind of service-level assurance with whatever we need to do: giving you controls, giving you visibility, giving you reporting. … Ultimately everybody's happier in that environment than they are with lawyers arguing with lawyers."
Let us know what you think about the story; email Karen Goulart, Features Writer.
Dig deeper on Cloud computing for enterprise CIOs
Karen Goulart, Senior Features Writer asks:
Do you place a lot of importance on your cloud SLAs?
0 ResponsesJoin the Discussion