A cloud service level agreement (SLA) is traditionally defined as a contract between a service provider and a consumer. The cloud service provider and consumer agree to what's in the contract regarding what the service level quality should be, and what happens when the quality falls below the guaranteed level.
For example, a Platform as a Service (PaaS) provider and a PaaS consumer agree in the SLA that the platform is available to the PaaS developers 99.999% of the time. They agree when the platform becomes unavailable that the provider pays a fee for the downtime; the penalty fee doesn't apply to scheduled maintenance, hardware failure, or Acts of God.
An expanded definition of a SLA
The global trade association TM Forum expands a SLA's traditional definition to include expectations of parties that provide other types of services. Some possible relationships between initiating and destined parties are:
- Service provider to end user
- Service provider to vendor
- Service provider to enterprise
- Enterprise to end user
- Network provider to cloud service provider (a network access provider)
- Vendor to network provider, service provider, or enterprise
- Content provider to content aggregator or advertiser
Not all parties are cloud-based; for example, a vendor may be either on-premise or cloud-based.
Complex SLA relationships
Let's look at SLA relationships and how each can become more complex.
Scenario 1. A cloud PaaS provider begins with three SLAs (not at the same time) that it has negotiated with a PaaS developer, a vendor, and an enterprise. If the provider offers services to additional vendors, it would need to negotiate new SLAs with them. Each SLA comes with a different set of start and end service dates. Each vendor, in turn, negotiates a SLA with a network service provider. Not all vendors work with the same network service providers.
Scenario 2. A cloud provider agrees with the network provider and vendor to the terms in a SLA. If the provider gets services from new vendors, it would need to negotiate a SLA with each vendor. Each SLA comes with a different set of SLA parameters.
Scenario 3. An enterprise gets services from several providers and vendors. Each vendor provides service to network service providers and cloud providers that have negotiated with the vendor on SLA guaranteed service levels.
SLA parameter scenarios
Not all SLAs have the same types of parameters. Let's look at SLA parameter scenarios.
Scenario 1. A service provider gets services from 10 vendors and agrees to each vendor's SLA about performance, delivery, and cost parameters. The values for each parameter are different for each SLA.
Scenario 2. A SLA doesn't care whether the Software as a Service (SaaS) application runs on a proprietary or interoperable Infrastructure as a Service (IaaS); if a service provider goes out of business, the customer may not be able to transfer the applications to another proprietary IaaS.
Scenario 3. The SLA adds Radio Frequency Identification (RFID) events as a parameter. Events that can be recorded and monitored for SLA compliance include:
- Whether actual observations of an event was successful;
- When the cases are loaded upon a pallet; and
- Whether inventory levels of a product at a warehouse are at the optimal level.
Scenario 4. The SLA adds temperature-sensing Internet of Things devices as a parameter. The devices are used to measure, record, and monitor the temperature of perishable foods at a refrigerated compartment at a warehouse or in trucks in the supply chain. SLA compliance ensures the temperature stays within the acceptable range and, that the backup refrigerator can be immediately activated if the primary refrigerator breaks down.
Managing multiple SLAs
Before you know it, you can get lost in a mountain of SLA documents, each with different expectations by all parties. One SLA sets the service availability parameter at 99.999%, while some SLAs are set at 99.99% and 99.9%.
To handle multiple SLAs, you should appoint a SLA manager to oversee the changing SLA relationships between among the parties. This manager needs to understand that each agreement will have a different set of parameters.
Judith M. Myerson is a Systems Engineering Consultant and Security Professional. She is the editor of Enterprise System Integration and the author of RFID in the Supply Chain. She has researched and published articles on a wide range of cloud computing topics, RFID, security, networking, and mobile. She was awarded a Master of Science degree in Engineering (Computer and Information Sciences). President of a toastmasters group, Judith was awarded her Advanced Communications Gold certificate. She is a member of The Operational Security Professional Association.