A cloud service-level agreement is typically the part of a contract where the service is carefully defined and the metrics for measuring and reporting adherence to agreed-upon service definitions are spelled out.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Within the context of storage, a service-level agreement (SLA) may be defined for services provided by a vendor to the IT organization (maintenance and support, for example); services provided by the IT shop to its "customers" (availability and uptime); or for services provided by an outsourcing agent to the business or IT organization (such as storage clouds). In the vendor-consumer relationship, the real purpose of an SLA is to mollify consumer concerns about the potential for bad outcomes, usually by specifying harsh and punitive remedies for sub-par performance by the service provider.
In a real sense, the cloud SLA is a predefined exit strategy, like a prenuptial agreement in a marriage. It sets the bar for performance, methods for measuring performance, procedures for rectifying deficits and, in the worst case, for dissolving the relationship and obtaining reimbursements or reparations.
Public clouds -- the delivery of IT services or infrastructure across a network -- are the latest evolution in IT outsourcing strategies and require cloud service-level agreements. Like service bureau computing in the 1980s, and application service providers (ASPs) or storage service providers in the 1990s, public clouds are conceived as a way to delegate to a network-accessed service provider some or all the work currently performed by a company's internal IT organization. In some cases, only select work or infrastructure is outsourced; in other cases, senior management elects to exit the IT business altogether and place all IT functions in third-party service provider control.
There are many theories of business value offered by vendors of cloud services. In general, cloud services are presented as an alternative for delivering resources or applications to the organization that will save money, both in terms of capital expense and operating expense, while maintaining current service levels or delivering improved service levels. The contractual obligation, therefore, is for the service provider to deliver to the customer the same or better service at lower overall cost -- music to the ears of senior managers who believe IT is not a core competency of their firms or that it is simply an expense they choose not to bear.
In the case of cloud storage or cloud-based storage services -- which may include remote management of local storage infrastructure or ancillary services such as backup or archive that augment existing operations and infrastructure -- SLAs are key. For storage resources (capacity), a basic cloud SLA must address capacity and its cost, availability and access cost, service setup and, if necessary, tear down, security provisions and management. For disaster recovery services (backup, archive and so on), SLAs need to specify capacity, access, security, setup and tear down, and the speeds and other delivery metrics of functions such as data restore, data migration, data retirement, media destruction, e-discovery support and more.
Service-level agreements become extremely important when you understand that they establish the seeds of success or failure of an outsourcing contract. The first inclination is to set the service bar high by requiring the vendor to deliver better service than you ever received from your in-house shop. But if you set availability goals that are greater than any availability numbers ever achieved in your own local environment, the vendor is almost certain to fail to meet those standards. The inclination is to set the bar too high, both as a hedge against the uncertainties associated with any new outsourcing agreement and as a means to discourage vendors from taking the job -- which is often the case when the IT department (which may have an interest in not outsourcing their work) is asked to draft SLAs for the new vendor relationship.
Specifying a high bar with service levels is not, in itself, a death knell for the service relationship. Rather, it is the mechanism chosen to deal with SLA deficits that can sustain the relationship or bring it to its knees. In some cases, SLA shortfalls can be addressed through financial offsets in monthly service billing combined with management meetings to review problems, their causes and strategies that will be implemented to rectify shortcomings. Such arrangements provide ways to remediate issues so they do not simply result in contract cancellation. Alternatively, companies can use SLAs as a rapid exit from contractual relationships that are simply not worth pursuing.
It is worth noting that SLAs are rather flimsy instruments for specifying and policing any sort of network-based application or infrastructure service. The outsourcing agent, the cloud service provider, cannot realistically guarantee any sort of availability or performance level, regardless of how well it executes on internal processing activities. The service providers are at the mercy of the public switched telephone network (PSTN) -- the granddaddy of all clouds.
The PSTN, which includes competitive local exchange carriers, incumbent local exchange carriers and interexchange carriers, provides most of the wide-area network (WAN) plumbing used to move signals and data back and forth between cloud vendors and consumers. Facilities and services of this public network are leased by a number of sub-agents or by cloud companies directly, but the underlying performance of the WAN -- its latency, jitter and throughput -- is what ultimately determines the actual service level experienced by the cloud consumer. The bottom line is that even the best effort on the part of a cloud service provider will likely be thwarted from time to time by the vicissitudes of the public WAN infrastructure itself, negating the vendor's ability to control its adherence to any performance-based SLA.
The above was part of the problem that killed service bureau computing and ASPs in their day, and it will likely be a central hurdle for contemporary cloud providers and users. If your company is taking the leap of faith required to embrace public clouds, an understanding of the mitigating influence of public WANs needs to be embodied in the SLA.