cloud server infrastructure, 3 Steps to Cloud SLA: #2 Exceptions and Limitations
cloud service level agreement, 3 Steps to Cloud SLA: #2 Exceptions and Limitations(1)
The section that the cloud customers should very carefully analyze is the service level agreement’s (SLA) “exceptions” or “limitations” section. The title may vary from one contract to the other; one may title it as “exceptions” the other as “exceptions and limitations”, which are essentially the same. This section lays down what are the conditions when the service is interrupted and the customer cannot blame the vendor. Since there is no blame on the vendor, there is no compensation for the customer.
In an Infrastructure-as-a-Service (IaaS) solution, what the customer essentially pays for is the underlying infrastructure. The customer is delivered the required hardware (fabric) resources. The customer then can deploy servers, arrange them in clusters, increase/decrease their resource use, shut them down, back them up, meaning that he essentially manages the infrastructure the same way as he manages them as if they are in his datacenter. The exceptions begin to shape at this point:
The cloud vendor is not responsible for what the customer does with the servers. If the customer installs a piece of software on the server causing it to become unavailable, the vendor cannot be held responsible.
The cloud vendor is not responsible for what the customer does not do with the servers. The opposite of the previous case: if the customer fails to install the necessary updates which cause any instability or unavailability, the cloud vendor cannot be held responsible.
The cloud vendor is not responsible for the unsupported operating system installations. If the delivered fabric resources are incompatible with some operating systems and the customer installs one of these unsupported operating systems (whether with a workaround, with luck or with some scripts), the cloud vendor cannot be held responsible for the unavailability of this particular system.
The cloud vendor is not responsible for the external network. This both relates to the customer’s connection to the cloud vendor and the issues with the Internet, including the security. For example the cloud vendor cannot be held responsible for the downtime that is a result of a Denial-of-Service attack.
In a Platform-as-a-Service (PaaS) solution, the customer pays for the underlying platform, such as Java, C#, Microsoft SQL Server, DB2, AppEngine etc.. Following the same logic above, the cloud vendor is responsible only for the underlying platform not for what the customer runs on top of it. The vendor makes the DB2 instance up and running for the customer but does not care about the custom plugins, applications or external connections to the instance.
And finally, in a Software-as-a-Service (SaaS) solution, the cloud vendor is responsible for the service as a whole. He is responsible for the availability of the service components defined in the contract as a whole, which makes the boundary of responsibility wider than the IaaS and PaaS vendors.
The exceptions and limitations are further defined in a “misuse clause” (or “abuse clause” if you will). This is where the terms of service is violated by the customer and thus the cloud vendor cannot be held responsible. Examples can be:
- purchasing a hosted e-mail platform from a cloud vendor and using it to send spam or mass mails,
- setting up an infrastructure to create/search in rainbow tables,
- creating an infrastructure to set up, deploy or test certain local/remote/Internet attacks.
- Such cases can result in termination of contract without further notice and any compensation.
On the cloud vendor’s side, offering a system – platform, infrastructure or server – and then define and determine the misuse of it is very hard. Therefore the cloud vendors tend to keep the definition of misuse clause as broad as possible, expecting common sense from their customers. But if they receive a lot of complaints about the customer’s use of the services, the vendors are very likely to suspend or terminate the contract with a short notice.
RELATED: cloud server infrastructure, 3 Steps to Cloud SLA: #1 Availability.
RELATED: 3 Steps to Cloud SLA: #3 Compensation
The exceptions and limitations of the cloud contract is not only important to draw the lines between the customer and the vendor, but also for the customer himself. The customer can inform the IT department and arrange the internal procedures accordingly, knowing that the vendor is not to be blamed for certain cases.
In the next article, I will discuss the compensation schemes stated in the service level agreement.