The first thing to “consider” is that SLAs (Service Level Agreements) are not written for customers, rather they are written by and for service providers. So unless you are a Fortune 1,000 customer with unlimited legal resources don’t ever expect to be compensated for data loss. You will be lucky to get a credit for the affected month.
The next factor is the cognizant party nature embedded in SLAs. Specifically there are different types of service providers; those which have multiple legal risk surfaces and those which have effectively only one (1).
For instance, a cloud backup vendor providing both the infrastructure AND a service has at least two (2) risk surfaces because they are involved with the actual assets of their customer(s). If that same vendor is providing the infrastructure and the service THROUGH a reseller channel then it jumps to at least three (3) surfaces.
Typically the SLAs for a vendor who is providing the actual service AND the infrastructure upon which that service runs are one-offs. In other words, there is an implicit individual SLA with each customer and it is architected to protect the provider by limiting responsibility because the vendor – or vendors if you include the channel – is/are technically “capable” of accessing the data. This means that the SLA must be designed to “thread the needle” and mitigate exposure on single accounts.
Keep in mind also that vendors with individual SLAs can triage which of their customers will receive immediate attention in times of crisis and which will wait their turn. This means the SLA is actually part of a larger profit/loss calculation at various points in your relationship.
Contrast this with an IaaS vendor who is not making any special arrangements based on customer identity and has absolutely no idea what is going on in any given cloud computer, and therefore need only address a single risk surface.
Since an IaaS vendor is only providing the infrastructure with no influence or visibility into the services running on that infrastructure they can operate on a generic one-size-fits all basis. This usually manifests as a terms and conditions checkmark on the credit card form you fill out.
This way the vendor exposure is limited to nominal penalties for service outages and reminders that you will get nothing if your data is lost. On the surface this seems less attractive but in reality it is actually better for most normal organizations for a couple of reasons.
- First, because the SLA is stretched over a large number of undifferentiated customers there is a very real incentive to keep the “crowd” from becoming dissatisfied and talking about it.
- Second, because the risk surface is much broader and less specific, third party out-of-band requests are harder to satisfy because the IaaS provider, by design, does not have ready access to the customer’s data.
Point being that ownership is much clearer with IaaS as opposed to SaaS and even PaaS.
Using the cloud backup example again, if you run your own software then the ownership is clearly delineated. In fact, when you attach a drive to one of your cloud computers, it is bound by the same limitations as a normal drive. In other words, while it is attached to your cloud computer, it can not be attached to another computer, just like in your data center.
Of course there is lots more to this subject but the basic premise is that sometimes being part of a crowd has it’s benefits.