Read the fine print carefully before signing on the bottom line with a cloud storage vendor.
When it comes to using cloud-based storage, the service level agreement (SLA) is everything. It's a rather dry document, but it lays out in writing exactly you can expect from the storage service provider in return for your monthly payment—both when things go right and when things go wrong.
A key benefit of any cloud service—storage or otherwise—is that economies of scale enable the cloud service provider to offer a commoditized service at a lower price than you could provide it yourself. And that means that the SLA that a service provider will offer you is likely to be the same as the one offered to all of its other customers buying the same service. In practice, that means terms like the types of media that the data will be stored on and the average data access time will usually be fixed.
But that's not to say that you can't negotiate. IDC estimates that about 80 percent of cloud customers accept the boilerplate SLA they are offered. But for larger customers, including enterprises buying storage services, there is certainly some maneuvering room.
So which SLA terms might you want to alter?
One of the key terms for any cloud SLA covers availability and downtime. It's often necessary to read the fine print to establish exactly how this is measured, according to Cal Braunstein, chief research officer at the Robert Frances Group. That's because it could be done on a monthly, quarterly or annual basis, he says.
"If a service provider offers you 'four nines' (i.e. 99.99 percent) uptime, then that allows 50 minutes per year of downtime. That comes to about 5 minutes per month, which you might be able to live with," he says. "But if it is measured on an annual basis, then the service could be down for 30 minutes or more in one month, and you would have to wait until the end of the year just to find out if the SLA has been breached."
Clearly, the way that downtime is measured makes a great deal of difference, and it's something that needs to be pinned down to match your business's needs. "You could certainly negotiate this, and say that you want the SLA to specify no more than 15 minute downtime in any one month or penalties apply, for example," Braunstein says.
Of course, it's important to remember that the SLA doesn't guarantee anything—it simply stipulates what the service provider is supposed to provide. When the service provider is in the breach of the SLA, it faces penalties. Usually these penalties are in the form of service credits, which are not tied directly to the impact of the breach on your business. When serious breaches occur, such as all your data becoming corrupt, you may get monetary payments instead of service credits. But these are unlikely to exceed four times your annual contract value—which is unlikely to be anything like the loss to your business.
The potential for very high losses is the reason why storage providers insist that SLAs include some limit of liability. Clearly, it is in the interest of the service provider to make this as low as possible. But it is not necessarily the case that it is in your interest as a customer to make it as high as possible, says Martin Kratz, head of the technology practice group at Calgary-based law firm Bennett Jones. "You are going to have to pay more to a service provider if you want them to accept more liability," he points out. "You certainly want them to have some level of liability, to encourage them to provide the service you expect, but when it comes to managing the risk of loss to your business, you might want to investigate if insurance might possibly be a cheaper option," he adds.
Other key SLA terms for cloud storage services cover geography—where the data is stored—as well as security and privacy. Most service providers like as much flexibility as possible when it comes to where you data is stored, so it's up to you as the customer to ensure the SLA restricts data to certain geographies or provides suitable security measures if that is necessary to comply with data privacy or other industry regulations.
It's also worth spelling out in the storage SLA what happens if there are changes to privacy laws or compliance procedures that mean you need your storage provider to change the location of your data or put additional security measures in place. Kratz recommends that your SLA should include a term about regulatory change assistance that specifies that changes will be at your cost, but that the service provider should make the changes and charge for them at normal or pre-agreed rates. Failure to do this leaves you at the mercy of the service provider to carry out the changes without charging excessive or unexpectedly high rates.
Robert Frances Group's Cal Braunstein also recommends reading the agreement carefully to see what rights the cloud storage provider has to read your data. "The provider needs the right to read your data to move it—perhaps to a different tier of storage. You wouldn't want them to be able to go through it and analyse it for non-support purposes—perhaps to get new business prospects—but some SLAs don't mention that." His point is that if something is not expressly dealt with in an SLA, you shouldn't assume that it is not an issue.
Another key SLA consideration is about getting your stored data back if you decide to switch providers. "Service providers always say that you can get data back, but the big question is when," says Robert Mahowald, an analyst at IDC. "You need to ask how long it will take them to get it to you and it what form? Will it be a CSV file? Or can the data be migrated to the database of your choice—will it be usable or will it need transformation? And can you get all the copies of your data? Data availability is key, so you need to push for these details in an SLA."
You also need to tie down whether you will be expected to pay for storage during the time that the service provider is returning data to you, whether you have to pay for service provider staff to return your data, and whether there are extra charges for cleaning up archived data as well, he concludes.