If you are using or thinking about using cloud storage, you are likely familiar with service level agreements (SLAs) from cloud providers that offer guarantees around the availability of your data and sometimes the durability of your data. The numbers associated with the guarantees are often expressed in 9’s. The table below illustrates how these availability numbers translate into expected yearly downtime. Note the considerable difference in downtime between 2, 3 and 4 9’s.

Beyond just the numbers, an important aspect of the cloud SLA is understanding how your business is compensated if the terms are not met. Typically, a provider who does not meet the SLA will reimburse a user for the unplanned downtime. This is often in the form of a refund of the service fee for the period of the outage. Some providers may offer to reimburse a multiple of that service fee (i.e. 2X, 3X, etc). That may appear confidence-inspiring, but how does it all add up for your business?

Let’s take a simple example: If your business applications use a Terabyte of cloud storage that costs $150/month, one full day outage is worth approximately $5 in provider fees. If the provider offered a 100% SLA that reimburses 3X downtime, that’s a $15 reimbursement.

Now what is the cost of a day-long outage to your business? Well, there’s possible revenue loss. Perhaps your business makes $2000/day in revenues that you can no longer realize.  If two employees were unproductive the day of the outage, perhaps you lost $1000 or more in productivity. As you can see by now, $15 in compensation does not begin to address the $3000 loss your business has sustained. In practice, cloud SLAs may not address your cost of doing business, unless you happen to customize them specifically to do so – a highly unlikely negotiation for a public cloud service without dramatically impacting the pricing of the service.

Does this make cloud SLAs relatively worthless? Not really – SLAs can be a planning tool if they can be backed by empirical data. On the other hand, SLAs can be misleading if they are merely a thinly-veiled insurance policy that only covers provider costs. In her article SLAs Throttle Cloud Adoption, Pam Baker examines some of the pitfalls of cloud SLAs in more detail.

A more useful tool in planning may be architectural visibility into the cloud storage provider. Although SAS70 Type II and SSAE16 are good starting points for understanding the reliability of the physical data centers that house cloud storage, moving a level further down in visibility to data management policies can assist planning dramatically. For instance, how many copies of data are maintained and across how many data centers? What data protection practices are in place? Is there off-premise data protection? Are there snapshots of data you can roll back to in case of human error? All of these parameters are highly relevant when architecting a local storage solution. They are just as relevant when architecting a storage solution that extends to the cloud.

The fact is, many IT managers and administrators are very adept at building systems that conform to a set of best practices around data protection and disaster recovery. Architectural visibility allows administrators to build solutions that extend to the cloud but follow the same best practices used in high-availability on-premise deployments.  For instance, if a cloud storage provider only offers a tier of disk storage with no additional data protection, that may call for a local copy of data on-premise. Perhaps if the storage is replicated across cloud sites, there is still a need for snapshots for continuous data protection (CDP) to avoid corruption of data due of human error, viruses, etc. Even with both replication and CDP policies at the cloud provider, there may still be a need for some last resort backup in case all else fails. Simply put, transparency and visibility provides knowledge that can build better and more robust storage configurations using the cloud. Moreover, it encourages ownership and accountability on the IT administrator’s part, which SLAs do not replace.

So while SLAs are helpful in conveying a cloud provider’s commitment to their offering, they are not a substitute for architectural visibility. As witnessed by some of the cloud outages earlier this year, using cloud is not a substitute for best practices. In the same vein, SLAs are no substitute for the visibility and the insight required to uphold best practices around system design, whether on-premise, in the cloud or hybrid.

Bookmark to:
Del.icio.us | digg | Twitter | MySpace |
FaceBook | reddit | Stumble Upon |