Practical Guide to Cloud Service Level Agreements Version 1.0

Transcription

1 Practical Guide t Clud Service Level Agreements Versin 1.0 April 10, 2012

2 Cntents Practical Guide t Clud Service Level Agreements Versin Acknwledgements... 4 Wrkgrup Leaders... 4 Extended Wrkgrup Members... 4 Additinal Reviewers... 4 Intrductin... 5 Current SLA Landscape... 5 Guide fr Evaluating Clud Service Level Agreements... 7 Step 1: Understand Rles & Respnsibilities... 7 Step 2: Evaluate Business Level Plicies... 9 Step 3: Understand Service and Deplyment Mdel Differences Step 4: Identify Critical Perfrmance Objectives Step 5: Evaluate Security and Privacy Requirements Step 6: Identify Service Management Requirements Step 7: Prepare fr Service Failure Management Step 8: Understand the Disaster Recvery Plan Step 9: Develp an Effective Management Prcess Step 10: Understand the Exit Prcess Summary f Keys t Success Wrks Cited Additinal References Cpyright 2011 Clud Standards Custmer Cuncil Page 2

3 2011 Clud Standards Custmer Cuncil. All rights reserved. Yu may dwnlad, stre, display n yur cmputer, view, print, and link t the Practical Guide t Clud Service Level Agreements at the Clud Standards Custmer Cuncil Web site subject t the fllwing: (a) the Guidance may be used slely fr yur persnal, infrmatinal, nncmmercial use; (b) the Guidance may nt be mdified r altered in any way; (c) the Guidance may nt be redistributed; and (d) the trademark, cpyright r ther ntices may nt be remved. Yu may qute prtins f the Guidance as permitted by the Fair Use prvisins f the United States Cpyright Act, prvided that yu attribute the prtins t the Clud Standards Custmer Cuncil Practical Guide t Clud Service Level Agreements Versin 1.0 (2012). Cpyright 2011 Clud Standards Custmer Cuncil Page 3

4 Acknwledgements The Practical Guide t Clud Service Level Agreements is a cllabrative effrt that brings tgether diverse custmer-fcused experiences and perspectives int a single guide fr IT and business leaders wh are cnsidering clud adptin. The fllwing participants have prvided their expertise and time t this effrt. Wrkgrup Leaders Jhn Meegan (IBM) Lead Technical Editr; Intrductin and Keys t Success Sectin Leader Gurpreet Singh (Ekartha) Current SLA Landscape and Disaster Recvery Sectin Leader Steven Wdward (Clud Perspectives) Rles & Respnsibilities; Perfrmance Objectives Leader Salvatre Venticinque (Secnd University f Naples) Service & Deplyment Mdel Sectin Leader Massimilian Rak (Secnd University f Naples) Service & Deplyment Mdel Sectin Leader David Harris (Being) Business Plicies Sectin Leader Gerry Murray (Frt Technlgies) Business Plicies Sectin Leader Beniamin Di Martin (Secnd University f Naples) Business Plicies Sectin Leader Yves Le Rux (CA Technlgies) Security and Privacy Sectin Leader Jhn McDnald (CludOne Crpratin) Service Management Sectin Leader Ryan Kean (The Krger C.) Service Failure Management Sectin Leader Marln Edwards (Hbken Cnsulting Grup, LLC) Disaster Recvery Sectin Leader Dave Russell (IBM) Management Prcess Sectin Leader Gerge Malekks (Pwersft Cmputer Slutins Ltd) Exit Prcess Sectin Leader Extended Wrkgrup Members The wrkgrup leaders wish t recgnize the fllwing individuals fr their utstanding effrts t prvide cntent, share their expertise and ensure cmpleteness f the Practical Guide t Service Level Agreements: Amy Whl (Whl Assciates), Asher Bnd (Elastic Prvisiner, Inc.), Claude Baudin (cebe IT & KM), Christpher Ferris (IBM), Melvin Greer (Lckheed Martin), Richard Miga (Synergistic Slutins), Thmas Smers (IBM). Additinal Reviewers The fllwing reviewers prvided feedback n the Practical Guide t Clud Service Level Agreements: Jenny Huang (AT&T), Karen Caraway (The MITRE Crpratin), Kenneth Dilbeck (TMFrum), Rpali Thapar (IBM), Tbias Kunze (Red Hat). Cpyright 2011 Clud Standards Custmer Cuncil Page 4

5 Intrductin This dcument is an extensin f the Practical Guide t Clud Cmputing white paper that was delivered by the Clud Standards Custmer Cuncil (CSCC) in Octber, The aim f this guide is t prvide a practical reference t help enterprise infrmatin technlgy (IT) and business decisin makers as they analyze and cnsider service level agreements (SLA) frm different clud service prviders. The paper will give guidance t decisin makers n what t expect and what t be aware f as they evaluate SLAs frm their clud cmputing prviders. A checklist f key criteria fr evaluating and cmparing SLAs frm different prviders will be included. Additinally, this paper will highlight the rle that standards play t imprve interperability and cmparability acrss different clud prviders, and identify areas where future standardizatin culd be effective. SLAs are imprtant t clearly set expectatins fr service between the clud cnsumer (buyer) and the clud prvider (seller). Each clud entity engaged by the enterprise shuld have a clud SLA defined, including: clud prvider, clud carrier, clud brker and even clud auditr. Cnsideratin must als be given t the different mdels f service delivery: Infrastructure as a Service (IaaS), Platfrm as a Service (PaaS) and Sftware as a Service (SaaS)) as each mdel brings different requirements. This paper fcuses primarily n the SLA details between the clud cnsumer and clud prvider, and fcuses n the requirements that are cmmn acrss the varius service mdels (emphasis is given t the IaaS service mdel since SLAs are mre advanced in this area). The Practical Guide t Clud Service Level Agreements cntains a set f guidelines and strategies t help decisin makers in all majr activities related t clud SLAs. The sectin entitled Current SLA Landscape explains the dynamics that currently exists between cnsumers and prviders in the SLA space and the impact that cmpany size has n the pwer t negtiate terms. This sectin als highlights the nuances f SLA develpment fr different service mdels. The sectin entitled Guide fr Evaluating Clud Service Levels Agreements is the heart f the guide. It prvides a prescriptive series f steps that clud cnsumers shuld take t evaluate clud SLAs with the gal f cmparing clud service prviders r negtiating terms with a prvider. It prvides guidance fr the business and service level bjectives f the SLA, highlighting what t be aware f and hw t cmpare service levels acrss different clud prviders. This sectin takes int accunt the realities f tday s clud cmputing ecsystem and pstulates hw it is likely evlve in the future, including the imprtant rle that standards will play t imprve interperability and cnsistency acrss prviders. Current SLA Landscape The Service Level Agreement (SLA) serves as a means f frmally dcumenting the service(s), perfrmance expectatins, respnsibilities and limits between clud service prviders and their users. A typical SLA describes levels f service using varius attributes such as: availability, serviceability, Cpyright 2011 Clud Standards Custmer Cuncil Page 5

6 perfrmance, peratins, billing, and penalties assciated with vilatins f such attributes. Welldesigned SLAs can significantly cntribute t reducing causes f ptential cnflict and can facilitate issue reslutin befre a dispute materializes. T guarantee an agreed service level, service prviders must be capable f measuring and mnitring relevant metrics. But ften there is a gap between crrelating the metrics cllected and mnitred by service prviders t higher-level functinal guarantees which are f interest t cnsumers. This prblem is quite challenging and develpment f SLAs by service prviders has t take this int accunt. This is typical fr all types f clud services and is acute fr SaaS prviders which ffer applicatins at higher levels f functinality. This is amng the many reasns why SLAs fr SaaS applicatins usually lack stringent service level guarantees. A vast majrity f SaaS and PaaS prviders simply ffer n SLAs, althugh they strive t develp internal peratins that cntribute t increased reliability. The situatin fr IaaS is better than SaaS and PaaS, but mst public clud infrastructure services are available nly thrugh nn-negtiable standard cntracts. They strictly limit the prvider s liability and the remedies d nt prvide significant benefit t cnsumers in case f service disruptins. Furthermre, mst IaaS prviders put the burden f SLA vilatin ntificatin and credit request n their custmers. Since a vast majrity f the users f IaaS public cluds are small and medium businesses (SMB), the pressure n clud prviders t ffer stringent SLAs is minimal. In tday s nascent clud services industry, SLAs prvided by clud vendrs are increasingly being viewed by cnsumers as unsatisfactry frms f prtectin that weigh heavily in the prvider s favr. Disputes ften arise ver the structure f the agreements, mnitring f perfrmance, and service unavailability. The reasns fr this are numerus and cver bth the challenges faced by clud prviders, and the lack f market pwer by cnsumers t ptentially seek mre stringent agreements. Recent cases f clud service utages highlight the dilemma fr clud cnsumers. In sme cases, the SLAs ffered by prviders were lse enugh t ensure that service prviders were nt vilating the terms f the SLA despite a serius utage in missin critical areas f the service. In such cases, clud cnsumers had n ptins t seek adequate penalties despite significant adverse effects. Clud prviders are taking accunt f such prblems and are beginning t ffer different service ptins that shield custmers frm such risks. In general, the larger the custmer deplyment, which translates t higher subscriptin and upfrnt fees, the mre pwer custmers exert in negtiating stringent SLAs. Even in the case f SaaS prviders, large custmers are successful in negtiating a strnger agreement, where nne may be ffered t SMB custmers. This des pint t the trend that as clud deplyments prliferate t larger enterprise custmers, the demand fr strnger SLAs will intensify. As cmpetitin increases at all levels, better SLAs will inevitably becme a cmpetitive factr. At that time, large enterprises and SMBs, alike, will be able t chse based n mre flexible and mre favrable SLA terms and, in general, these terms will imprve. Cpyright 2011 Clud Standards Custmer Cuncil Page 6

7 Guide fr Evaluating Clud Service Level Agreements Befre evaluating any clud SLA, cnsumers must first develp a strng business case and strategy fr their clud cmputing envirnment. This includes identifying specific services that will be deplyed in the clud alng with a clear understanding f the criticalness f these services t the business. A check n the exit clauses f current hsted services cntracts is als imprtant. Only after this strategic analysis has been cmpleted can the cnsumer effectively evaluate and cmpare SLAs frm different prviders. With the clud business case and strategy as a prerequisite, this sectin prvides a prescriptive series f steps that shuld be taken by clud cnsumers t evaluate clud SLAs with the gal f cmparing clud service prviders r negtiating terms with a prvider. The fllwing steps are discussed in detail: 1. Understand rles and respnsibilities 2. Evaluate business level plicies 3. Understand service and deplyment mdel differences 4. Identify critical perfrmance bjectives 5. Evaluate security and privacy requirements 6. Identify service management requirements 7. Prepare fr service failure management 8. Understand the disaster recvery plan 9. Define an effective management prcess 10. Understand the exit prcess Requirements and best practices are highlighted fr each step. In additin, each step takes int accunt the realities f tday s clud cmputing landscape and pstulates hw this space is likely t evlve in the future, including the imprtant rle that standards will play t imprve interperability and cmparability acrss prviders. Step 1: Understand Rles & Respnsibilities In rder fr cnsumers t understand specific rles and respnsibilities explicitly r implicitly stated in a clud SLA, it is imprtant that they are aware f the varius actrs that can ptentially participate in a clud cmputing envirnment. The Natinal Institute f Standards and Technlgy (NIST) Reference Architecture 1 identifies 5 unique clud actrs: Clud Cnsumer. The persn r rganizatin that maintains a business relatinship with, and uses service frm, clud prviders. Clud Prvider. The persn, rganizatin r entity respnsible fr making a service available t clud cnsumers. Clud Carrier. The intermediary that prvides cnnectivity and transprt f clud services frm clud prviders t clud cnsumers. Clud Brker. An rganizatin that manages the use, perfrmance and delivery f clud services, and negtiates relatinships between clud prviders and clud cnsumers. Clud Auditr. A party that can cnduct independent assessments f clud services, infrmatin system peratins, perfrmance and security f the clud implementatin. 1 Refer t fr mre infrmatin n the NIST Reference Architecture. Cpyright 2011 Clud Standards Custmer Cuncil Page 7

8 The use f the term brker varies significantly and shuld be clarified with the varius stakehlders, especially in cntext f a clud SLA. An entity may prvide brker services and functinality, but as a legal rganizatinal entity nt be recgnized as a clud brker. Fr example, an entity may perfrm research and negtiate n behalf f a cnsumer, but the actual SLA and cntract terms are between the clud cnsumer and clud prvider. The distinctin f acting brker like vs. being an actual brker will evlve as the clud cmputing industry matures and terminlgies becme mre cnsistent. Due t these cmplexities this paper des nt address all the SLA cnsideratins fr clud brkering. Cnsumers need t recgnize the activities and respnsibilities f each clud actr that is engaged in delivering their clud envirnment, and precisely define requirements and desired service levels fr each actr. This paper fcuses primarily n the clud cnsumer/clud prvider SLA, althugh ther SLAs may be addressed in a particular cntext. In sme cases, the cnsumer/prvider relatinship will indirectly include additinal actrs. Figure 1 belw illustrates an envirnment where a clud prvider has established a SLA with tw clud carriers t establish service levels fr cmmunicatin and transprt. In additin t clud prvider expectatins, the cnsumer/prvider SLA in this example may als include specific carrier and transprt expectatins. In this case, the clud prvider is als acting as a brker fr the ther tw clud carriers. Figure 1. Indirect Relatinships Each clud SLA will be unique based upn the cnsumers requirements and the clud ecsystem under cnsideratin. SLAs can cntain varius expectatins between the actrs and are nt limited t quantitative measures, but can include ther qualitative aspects such as alignment with standards and data prtectin. It is strngly recmmended that clud cnsumers gain a slid understanding f the Cpyright 2011 Clud Standards Custmer Cuncil Page 8

9 spectrum f SLAs that currently exist fr clud prviders (and ther actrs as apprpriate) in rder t cmpare prviders and assess tradeffs between cst and service levels. 2 The fllwing sectins, which cver the clud SLA evaluatin steps in detail, will each elabrate n the expected respnsibilities between cnsumer and prvider fr bth business level and service level bjectives. In rder t make sund business decisins, it is imprtant that cnsumers understand what t expect frm their clud prvider. This, in turn, will help them define their wn respnsibilities and help them assess the true cst f mving t the clud. Step 2: Evaluate Business Level Plicies Cnsumers must cnsider key plicy issues when reviewing a clud SLA since there are interdependencies between the plicies expressed in the SLA and the business strategy and plicies develped in ther aspects f the business. The data plicies f the clud prvider, as expressed in the SLA, are perhaps the mst critical business level plicies that shuld be carefully evaluated. The duty f care a clud prvider has t its clients and their data is partly gverned by the data prtectin legislatin applicable in the user s lcal jurisdictin and als in thse jurisdictins in which its data may reside r made available. Cnsumers shuld carefully cnsider these legal requirements and hw the SLA their prvider(s) ffers deals with issues such as mvement f data t ffer multisite redundancy acrss several jurisdictins. Table 1 highlights the critical data plicies that need t be cnsidered and included in the clud SLA. Table 1. SLA data plicies Data Plicy Descriptin / Guidance Data Preservatin Timely and efficient capturing and preservatin f data is critical t maintaining the rganizatinal memry f a business r the general user. It enables the data cntrller t address peratinal, strategic and litigius situatins frm an infrmed perspective. Clud users shuld ensure the service supprts their data preservatin strategy that includes surces, scheduling, backup, restre, integrity checks, etc. Data Redundancy Users shuld ensure they have an apprpriate data preservatin strategy that addresses redundancy within the system. This shuld be cmplemented by the SLA their clud prvider ffers and can be tested t demnstrate service availability. The cnsumer shuld be cncerned as t the prtectins ffered r mitted by the 2 Refer t the Queen Mary Schl f Law Legal Studies Research Paper titled Cntracts fr Cluds: Cmparisn and Analysis f the Terms and Cnditins f Clud Cmputing Services at fr a cmprehensive analysis f leading clud service prviders. Cpyright 2011 Clud Standards Custmer Cuncil Page 9

10 service prvider. Data Lcatin SLAs which cver single and multi-jurisdictin scenaris are challenging. Verificatin f new data lcatin Users shuld carefully cnsider as part f their data management strategy hw the SLA will cmplement where their data will reside, where it is prcessed, and hw this meets regulatry requirements. Fr example, can the prvider truly deliver a sund technical slutin when data spans several jurisdictins? Can the user trust that the data will be lcated where the prvider cmmits it will be? Clients shuld ensure that when a prvider elects t prvide its service frm anther lcatin it will be required t ntify its clients f the new lcatin and prvide a means fr the client t independently verify where the data will be relcated. Preferably the prvider shuld be required t btain the permissin f the client t relcate the data befre mving t a new lcatin. Data Seizure Legal pwers enable law enfrcement and ther gvernment agencies t seize data under certain circumstances. Cnsumers shuld als ensure there are arrangements in place t make a user s data available in the event that their SLA prvider ges ut f business and the data center prvider lcks access t its systems pending payment f the utstanding accunt. Data Privacy It is a requirement t cnduct business in cmpliance with applicable laws n data privacy prtectin and data security. The declared data privacy plicy frm the prvider shuld be included in the SLA. Examples f privacy terms that shuld be addressed in the SLA include the data sets gathered, data retentin plicies, hw the data is cmmunicated, hw persnal data is stred and used, etc. Refer t the Privacy sectin n page 24 fr mre infrmatin. In additin t data plicies, there are a number f ther business level plicies expressed in the clud SLA that require careful evaluatin. All f these plicies will impact and influence the cnsumer s clud strategy and business case. In many cases, these plicies, as defined in the clud SLA, are nn-negtiable and are similar acrss different clud prviders. Hwever, there will be instances where sme f these plicies can be negtiated and/r sme f these plicies differ sufficiently acrss different clud prviders t warrant careful cnsideratin frm cnsumers. Table 2 belw highlights the critical business level plicies that need t be cnsidered and addressed in the clud SLA. Cpyright 2011 Clud Standards Custmer Cuncil Page 10

11 Table 2. SLA business level plicies Plicy Descriptin / Guidance Guarantees SLA guarantees shuld be defined, bjective and measurable with an apprpriate scaled penalty matrix which cmplements the impact f nn-perfrmance by the prvider. 3 The SLA shuld clarify: What cnstitutes excused r excluded perfrmance Escalatin prcedures Hw service-level bnuses and penalties are administered Remedy circumstances and mechanisms Such guarantees shuld include an availability measurement expressed as a percentage, e.g %, which dentes the amunt f time the service is guaranteed t be wrking. Acceptable Use Plicy Given the dislcated relatinship that can exist between the prvider and the cnsumer (the prvider may nt knw the final end user f its service), the acceptable use plicy will clearly describe hw the cnsumer may use its service and the agreement generally will describe what actins the prvider may take in the event f a breach. List f Services Nt Cvered In tday s clud envirnment, this plicy is typically nn-negtiable and the terms generally favr the clud prvider. The SLA will state under what cnditins and with which described services the cnsumer is supprted. The SLA may als state what is excluded and what cnstitutes illegal use. Cnsumers shuld lk fr explicitly stated exceptins and understand why the prvider has excluded them. Excess Usage Prviders perate business mdels t drive revenue. Cnsumers may find that usage abve their cntracted threshlds may incur premium rates which can be punitive and disrupt their budgets. Cnsumers shuld crrectly size their usage requirements, reduce the pprtunity fr usage creep and cnsider and understand the what-ifs f breach f their usage threshlds. The clud is a great tl t vary the size f the resurce pl yur business buys but, as in any business mdel, buy nly what yu need and avid excess usage charges. 3 Guarantees including measurable metrics will be cvered in greater detail in the sectins that fllw. Cpyright 2011 Clud Standards Custmer Cuncil Page 11

12 Activatin Prviders will delineate a time at which the service becmes active and the SLA cmmences peratin. This time stamp can then be used t measure time and if an utage ccurs may be used t establish the start f a penalty incurring event. Payment and penalty mdels Gvernance / Versining Examples f activatin include the time at which the cnsumer checks the accept terms and cnditins bx r when the cnsumer acknwledges the secure URL prviding lgin credentials t their new clud service. Frm a SLA cmpliance perspective, it is imprtant fr cnsumers t understand the trigger pints under the SLA s they can independently measure event timing. It is als imprtant t understand when the agreement is in peratin as bth the prvider and the cnsumer have respnsibilities such as Fair Use and Legal Use. The SLA shuld clarify when/hw payment is t be made. Prvider payment mdels vary. Mnthly recurring r pay as yu use mdels are typical. Assciated with these payment mdels are credit terms which may require advanced payment r payment every 30 days. Just in time service prviders are sensitive t pr credit cntrl and are likely t be mre diligent in suspending service. Equally, the cnsumer needs t be diligent in btaining service credit payments fr utages. Prviders services evlve. New features may be added, thers will g ut f warranty, and sme may persist indefinitely. Where the assumptins r cnditins under which the SLA was initially accepted are changed, the cnsumer shuld review the impact n their specific situatin. A gd prvider will maintain a practive plicy f advising cnsumers f changes t their SLA and practice versin cntrl. Cnsumers shuld ensure that there is a mechanism in place t be infrmed f changes and, if nt, amend their cntract t put the nus n the prvider t cntact them at a designated cntact pint with updates within a reasnable timeframe. Renewals Renewals are an pprtunity t bargain fr better rates and relcate t anther prvider if necessary. Prviders may perate aut renewals which state, fr example, this cntract will aut renew n its anniversary if the cnsumer des nt give 90 days ntice f their intentin t cancel. Cnsumers shuld read the terms and cnditins fr the renewal arrangements, and cnsider the cnditins under which a prvider may vary the service terms at renewal. Prvider systems are rganic as are cnsumer requirements. Mre attractive service functinality may be available r mre cnsumer flexibility required. Cpyright 2011 Clud Standards Custmer Cuncil Page 12

13 Transferability Cnsumers shuld cnsider the ptential fr needing t transfer an agreement in the event their business is sld. In additin, the prvider s business may be sld t a cmpetitr and it may suit the cnsumer t relcate and discntinue the cmmercial agreement with the new wner. Cnsumers may perate several accunts with a prvider and want t ffset accunt credits between accunts. Is this supprted in the prvider s cntract terms? Supprt The cnsumer shuld ensure they fllw the reprting guidelines f the prvider t ensure the supprt terms specified in the SLA are activated. An example f a supprt and escalatin matrix is prvided belw. All three target times in the table are assciated with the cmmencement time stamp f the service r the ntificatin f a service affecting event. Pririty Descriptin Target Respnse Time Target Update Time Target Fix Time P1 P2 Prductin sftware unusable/prductin clud servers inaccessible Partial sftware functinality unusable/partial service unavailable 1 hur, Prvider s executive ntified f issue P3 Csmetic issue 1 wrking day P4 Infrmatin request 2 wrking days 1hr Immediate wrk cmmences and cntinues until issue reslved r wrkarund deplyed 4 hurs 1day 2 days, subject t available maintenance slt 1 wrking day 2 wrking days Next sftware release/service update n/a Planned Maintenance All systems require maintenance. Cmplex systems may be designed t include sufficient resurces such that maintenances can be carried ut withut affecting the service. The SLA may, hwever, describe uptime as an availability percentage (e.g %). This is the equivalent f 8.5 hurs dwntime per annum. SLAs may state that this des nt include planned maintenance. Thus, the prvider may have a service utage fr 8.5 hurs + maintenance time under the SLA and the cnsumer is nt entitled t cmpensatin. Subcntracted Services Prviders smetimes include in their SLAs indicatin that the SLA f an upstream (subcntracted) prvider will be passed t the cnsumer and the nly available penalties are thse f the upstream prvider even thugh these may be f a lesser quality than the cnsumer understands when reviewing the SLA f their immediate Cpyright 2011 Clud Standards Custmer Cuncil Page 13

14 prvider. Equally, the cnsumer shuld ensure that the immediate prvider SLA is unambiguus in stating that their SLA applies t the cmplete service and nt limited t the immediate prvider s cmpnent f the verall service. Licensed Sftware Clud services may include third party licensed sftware which is sld n a mnthly licensed basis under a service prvider license agreement. Such sftware is updated regularly by its manufacturer. Industry Specific Standards Additinal terms fr different gegraphic regin r cuntries Prviders may pt t pass the respnsibility fr patching the licensed sftware ver t the cnsumer nce they have started t use the service. This can be preferable t the prvider as later releases may negatively affect the cnsumer s service. The prvider may alternatively push the update in which case the cnsumer, as specified in the SLA, may require ntificatin f the update. Upn ntificatin, the cnsumer can issue an pt ut ptin. Regulated industries, like gvernment, financial services, and healthcare, will have specific and usually quite nerus and cstly standards which must be addressed in the clud SLA and implementatin. Cnsumers wh perate in these regulated industries shuld ensure that the full resurces f their legal team are brught t bear n the negtiatin f the SLA. Cnsumers shuld cnsider the prvider s rigins and primary market. Detailed refinements t the hme market SLA may be required t prperly cver cnsumers wh are lcated in remte markets. Data prtectin legislatin is ne aspect f this. Hwever, cnsumers shuld nt limit their examinatin f the agreement t this slely. Step 3: Understand Service and Deplyment Mdel Differences Services ffered by clud prviders typically fall int ne f the three majr grups f service mdels: Infrastructure as a Service (IaaS), Platfrm as a Service (PaaS), and Sftware as a Service (SaaS). Fr each categry, there are significant differences in the levels f clud resurce abstractin, service level bjectives, and key perfrmance indicatrs that will ptentially be included in a clud SLA. In additin, the level f clarity varies significantly fr each service mdel. In general, PaaS and SaaS bjectives are less precise than IaaS bjectives since the variety f slutins and applicatins ffered by prviders is much brader fr these service mdels. Table 3 highlights the different SLA cnsideratins fr each f the clud service mdels. Table 3. SLA cnsideratins fr Service Mdels Cpyright 2011 Clud Standards Custmer Cuncil Page 14

15 Service Mdel SLA Cnsideratins IaaS Clud IaaS SLAs are similar t SLAs fr netwrk services, hsting, and data center utsurcing. The main issues cncern the mapping f high level applicatin requirements n infrastructure services levels. Metrics are well understd acrss the IaaS abstractins (cmpute, netwrk, and strage). Cnsumers shuld expect t find the fllwing metrics in their clud SLA. Cmpute metrics: availability, utage length, server rebt time Netwrk metrics: availability, packet lss, bandwidth, latency, mean/max jitter Strage metrics: availability, input/utput per secnd, max restre time, prcessing time, latency with internal cmpute resurce Cmpute metrics usually exclude service levels fr cmpute perfrmance. Cnsumers are simply guaranteed t have the cmpute resurces fr which they paid with technical enfrcement at the hypervisr level. Netwrk metrics in a clud SLA generally cver the clud prvider's data center cnnectivity t the Internet as a whle, nt t any specific prvider r cnsumer. Denial-f-service (DS) attacks may be explicitly excluded frm the SLA even if the prvider ffers prtectin via firewalls and intrusin detectin systems. There are several standardizatin effrts within the IaaS space which help describe and manage the services ffered at this level. 4 Whenever pssible, cnsumers shuld ensure the clud SLA includes prvisins requiring their clud prviders t supprt pen standard interfaces, frmats and prtcls t increase interperability and prtability. PaaS Tw main appraches exist fr building PaaS slutins: integrated slutins and deplybased slutins. When reviewing the PaaS SLA, cnsumers shuld cnsider tradeffs in flexibility, cntrl, and ease f use t determine which apprach best meets their business needs. Integrated slutins, like Ggle App Engine (GAE) 5, are web accessible develpment envirnments which enable develpers t build an applicatin using the infrastructure and middleware services supprted by the clud prvider. Management f the applicatin and its executin is primarily cntrlled by the clud 4 IaaS standards include: DMTF CIMI (Clud Infrastructure Management Interface), DMTF OVF (Open Virtualizatin Frmat), SNIA CDMI (Clud Data Management Interface), The Open Grup s SOCCI (Service-Oriented Clud- Cmputing Infrastructure), OGF OCCI (Open Clud Cmputing Interface), the ISO Study Grup n Clud Cmputing (SGCC), and de-fact industry alignment n IaaS service level bjectives, warranties, guarantees, perfrmance metrics, etc. 5 Refer t fr infrmatin n Ggle App Engine. Cpyright 2011 Clud Standards Custmer Cuncil Page 15

16 prvider. Typically, service develpers nly have access t a prvider-defined set f APIs (Task API in GAE) which ffer limited cntrl n the crdinatin f cde executin. Deply-based slutins enable deplyment f middleware n tp f resurces acquired frm an IaaS clud prvider, ffering deplyment services t the cnsumers which autmate the prcess f installatin and cnfiguratin f the middleware. 6 These PaaS slutins ffer a rich set f management capability including the ability t autmatically change the number f machines assigned t an applicatin, and selfscaling accrding t the applicatin s usage. Cnsumers must distinguish between PaaS develpment envirnments and PaaS prductin envirnments when reviewing their clud PaaS SLA. PaaS prductin envirnments will typically require mre stringent service level bjectives than PaaS develpment envirnments. The state f PaaS metrics is currently immature with metrics varying significantly acrss prviders. Standards initiatives are just starting t emerge in this space. In the meantime, cnsumers are advised t identify the PaaS services that are critical t their business and ensure that their clud SLAs cntain clear and measurable metrics fr these services. Standards that help identify PaaS services ffered by clud prviders and standard interfaces fr cmmunicating with PaaS prviders t prvisin r manage PaaS envirnments are als lacking. The lack f standards results in pr prtability and interperability acrss prviders. Standards, like OASIS TOSCA 7, are emerging which will help address this issue. Cnsumers shuld ensure their clud SLA includes supprt fr pen standards, as they becme available, t reduce vendr lck in. SaaS Given the wide variatin f services prvided at the SaaS level, it is difficult t prvide a cmprehensive and representative list f SaaS service level bjectives fr cnsumers t lk ut fr in their clud SLAs. Cnsumers shuld expect general SaaS service level bjectives like mnthly cumulative applicatin dwntime, applicatin respnse time, persistence f cnsumer infrmatin, and autmatic scalability t be included in their SLA. Cnsumers shuld ensure that data maintained n the prvider s clud resurces be stred using standard frmats t ensure data prtability in the event that a mve t a different prvider is required. 6 Deply-based slutins are supprted by cmmercial prviders like IBM, Oracle and Micrsft as well gvernment spnsred prjects like OPTIMIS, CONTRAIL, Clud4SOA and mosaic in Eurpe. 7 Refer t fr details n TOSCA. Cpyright 2011 Clud Standards Custmer Cuncil Page 16

17 In additin t service mdels, service deplyment terms shuld be included in a clud SLA. These terms shuld clarify t bth parties signing the SLA the infrmatin required t verify the crrectness f deplyment actins. Specifically, these terms shuld identify: Deplyment mdel Deplyment technlgies adpted The deplyment mdel included in the SLA shuld clearly specify ne f the fllwing ptins: Private, Cmmunity, Public, r Hybrid. Cnsumers must be well educated n the characteristics and differences in each f these deplyment mdels since ptential value and risk varies significantly. 8 Table 4 highlights the different SLA cnsideratins acrss the deplyment mdels. 9 Table 4. SLA cnsideratins fr Deplyment Mdels Deplyment Mdel SLA Cnsideratins Private (On-site) SLA cnsideratins fr Private (On-site) are similar t thse f a traditinal enterprise IT SLA. Hwever, given that data center resurces may be shared by a larger number f internal users, cnsumers must ensure that critical service bjectives like availability and respnse time are met via nging measurement and tracking. Private (Outsurced) SLA cnsideratins fr Private (Outsurced) are similar t Private (On-site) except clud services are nw being prvided by an external clud prvider. The fact that IT resurces frm the prvider are dedicated t a single cnsumer mitigates ptential security and availability risks. Cnsumers shuld ensure the clud SLA specifies security techniques fr prtecting the prvider's perimeter and the cmmunicatins link with the prvider. Cnsumers shuld cnsider the criticalness f the service being deplyed t justify the added expense f this mdel ver the Public mdel. Public SLA cnsideratins fr the Public mdel are greater than the Private (Outsurced) mdel since the prvider s IT resurces are nw shared acrss multiple cnsumers. As a result, cnsumers shuld carefully review the clud SLA t understand hw the prvider addresses the added security, availability, reliability and perfrmance risks intrduced by multi-tenancy. The ability t measure and track specific service level bjectives becmes mre 8 Refer t the Practical Guide t Clud Cmputing fr cnsideratins n selecting a deplyment mdel. 9 The Cmmunity deplyment mdel is nt called ut explicitly in the table since it is very similar t the Public deplyment mdel. Cpyright 2011 Clud Standards Custmer Cuncil Page 17

18 imprtant in the Public deplyment mdel. Cnsumers shuld als ensure the clud SLA prvides adequate methds and prcesses fr nging measurement. Hybrid SLA cnsideratins fr the Hybrid mdel are similar t the Public mdel with the increased likelihd fr unique integratin requirements between clud and enterprise services. As a result, cnsumers shuld ensure the clud SLA adequately cvers their service and data integratin requirements. In additin t specifying the deplyment mdel, the SLA shuld clarify hw a service is made available t service users n a given clud prvider, fr example: A web applicatin is deplyed n an applicatin server as a WAR file 10 (the applicatin server enables WAR uplading). A grid applicatin is deplyed n a grid cntainer as a GAR (Grid Archive) file. A virtual machine is deplyed n an IaaS prvider as a virtual machine disk image that may be represented in ne f many different frmats. Adptin and supprt fr standards like the Distributed Management Task Frce (DMTF) Open Virtualizatin Frmat 11 (OVF) is recmmended. When SLAs are signed, a clear descriptin f the technlgies invlved in the deplyment f services may be specified (fr example, WAR, GAR, OVF, etc.). Nte that there is a clse relatinship between deplyment technlgies and the kind f services being ffered. Step 4: Identify Critical Perfrmance Objectives Perfrmance gals within the cntext f clud cmputing are directly related t efficiency and accuracy f service delivery. Perfrmance cnsideratins ften include: availability, respnse time, transactin rate, prcessing speed, but can include many ther perfrmance and system quality perspectives. 12 Cnsumers must decide which measures are mst critical t their specific clud envirnments and ensure these measures are included in their SLA. Perfrmance statements that are imprtant t the clud cnsumer shuld be measureable and auditable, and dcumented in the SLA prviding a cmfrt level t bth parties. Perfrmance cnsideratins are dependent n the supprted service mdel (IaaS, PaaS and SaaS) and the type f services prvided within that mdel, fr example, netwrk, strage and cmputing services fr IaaS. 10 Refer t fr mre infrmatin n the WAR (Web applicatin ARchive) file. 11 Refer t fr mre details. 12 System quality measures that culd be included in service perfrmance include accuracy, prtability, interperability, standards cmpliance, reliability, scalability, agility, fault tlerance, serviceability, usability, durability, etc. Cpyright 2011 Clud Standards Custmer Cuncil Page 18

19 Of curse, in rder fr perfrmance bjectives t be meaningful, measurement is a critical cnsideratin where clarity and cnsistency are very imprtant, if nt crucial, t gain trust in the clud. Measuring withut cntext is useless and perfrmance metrics are n different. It must be clear hw the metric will be used and what decisins will be made frm the metrics, cntinually evaluating and aligning with specific gals and bjectives. This sectin will fcus n tw perfrmance metrics: availability and respnse time. The intentin is t prvide a basic framewrk t help identify and define clud metrics that will be meaningful and cnsistent. This sectin is nt meant t be exhaustive - it des nt cntain all the ptential metrics and pssible definitins. Many f the measurement and metric definitins may already be supprted by yur clud prvider; therefre the specific interpretatin f the term in cntext f a specific slutin is critical. Sme calibratin may be required between existing captured measures and thse specifically requested as part f the SLA. Industry standard measures with applicable definitins shuld be used t imprve cnsistency, enabling meaningful cmparative and trend analysis. Fr instance, IEEE als has gd measurement definitins and categrizatins fr activities such as maintenance. 13 Other rganizatins and private benchmarks exist. The key is t always calibrate values t get an apple t apples cmparisn t an apprpriate level f accuracy. T be effective, a perfrmance metric must be clearly defined in the SLA and understd by bth parties. Here are the generally accepted definitins fr the tw metrics f interest: Availability. Percentage f uptime fr a service in a given bservatin perid. Respnse time. Elapsed time frm when a service is invked t when it is cmpleted including delays (typically measured in millisecnds). Table 5 describes three different example scenaris (netwrk availability, strage availability, and service respnse time) and the specific perfrmance infrmatin required fr each. Table 5. Availability and Respnse Time metrics examples Netwrk Availability (example) Strage Availability (example) Service Respnse Time (example) Metric Name in SLA Netwrk Percentage Available Critical Business Hurs Strage Percentage Available Service XXX Respnse Time in a Given Hur; Service YYY Respnse Time in a Given Hur. 13 Other standard measures include the Internatinal Sftware Measurement Assciatin Internatinal Functin Pint Users Grup that retains several sftware measurement guidelines (such as ISO/IEC 20926) that are used fr benchmarking and wrks clsely with the Internatinal Sftware Benchmarking Standards Grup. Cpyright 2011 Clud Standards Custmer Cuncil Page 19

20 Cnstraints Critical time is business hurs 12AM GMT t 12PM GMT Mnday thru Friday N cnstraints Respnse times will nly be evaluatd fr services XXX and YYY which are PaaS reuseable services that will be invlked by ur applicatins. Cllectin Methd Machine Machine Machine Cllectin Descriptin Using the DMTF, OGF 14, r ther standard t cnsistently cllect the measures. Using the DMTF, OGF, r ther standard t cnsistently cllect the measures. Using the DMTF, OGF, r ther standard t cnsistently cllect the measures. Frequency f Cllectin The netwrk is pinged every ne minute. Specific strage services (read and update) are randmly pinged every ne minute. Fr each XXX and YYY service invked, the respnse time will be cllected. Other Infrmatin Cnsidered 60 secnds f uptime fr each successful ping. Cnsidered 60 secnds f uptime fr each successful ping. Each service will be reprted separately. Hurly averages will be calculated. Clarificatin N reference t quality r availability f specific service. This is exclusively a measure f netwrk availability. N reference t quality r availability f specific service. This is exclusively a measure f strage availability. N idividual services reprting is needed (fr example, listing f all services that exceeded SLA agreed respnse time). Usage 1 in SLA Netwrk availability will be 99.5% between 12AM GMT t 12PM GMT Mnday thru Friday. Strage availability will be 99.9%. Respnse time fr XXX service must be less than 500 MS, YYY service less than 200 MS. Usage 2 in SLA Fr any day when netwrk availability is less than 99.5%, a 20% discunt will be applied fr the entire day netwrk charges. Fr any day when strage availability is less than 99.9%, a 50% discunt will be applied fr the entire day strage charges. If in any given hur the respnse times as stated are nt met, all services f that type during that hur will be prcessed at n charge. Clud resurces, bth hardware and facilities, shuld als be cnsidered when assessing critical perfrmance bjectives fr clud SLAs. Hardware includes: cmpute (CPU and memry), netwrks (ruters, firewalls, switches, netwrk links, and interfaces), strage cmpnents (hard disks), and any ther physical cmputing infrastructure elements. Facilities include: heating, ventilatin and air cnditining (HVAC), pwer, cmmunicatins, and ther aspects f the physical plant. Resurces need t be clearly stated in the SLA t clarify scpe, cnstraints and expectatins fr the clud cmputing services f interest. T be successful, higher level business bjectives and gals need t be understd such that critical resurce metrics can be identified that address facility and hardware 14 Refer t fr mre infrmatin n the Open Grid Frum. Cpyright 2011 Clud Standards Custmer Cuncil Page 20