Een service level agreement (SLA) in ict beschrijft de niet-functionele eisen van een geleverde dienst, zoals een minimale beschikbaarheid of een maximale hersteltijd bij eventueel falen. Aan het niet nakomen van deze afspraken zijn consequenties verbonden, zoals boetes. Binnen outsourcing vormen SLA’s het hart van de contractuele en daarmee te controleren afspraken tussen klant en leverancier. Het tot stand komen van een SLA is een spel van onderhandelaars. Cloud is ook outsourcing, maar klanten zullen op een geheel andere manier met SLA’s moeten omgaan. Hoe doe je zaken met aanbieders voor de cloud die zo groot zijn als Amazon, Google of Microsoft? Je accepteert hun voorwaarden wel of niet: take it or leave it.
Dat je heel goed moet weten waarvoor je tekent, bewijst de outage van Amazon. Een SLA van 99,5 procent beschikbaarheid zegt niets, als je niet precies weet waarvoor en wanneer die ratio geldt. Op 21 en 22 april 2011 had Amazon door een menselijke fout een zware outage in het oosten van de Verenigde Staten: één van de vijf wereldwijde regio’s voor Amazon’s Elastic Compute Cloud (E2C). Elk van deze regio’s bestaat uit meerdere beschikbaarheidzones, die klanten moeten verzekeren tegen downtime. Desondanks ging een hele regio plat en daarmee ook online bedrijven als FourSquare. De hele zekerheid werd onderuitgehaald. Om te voorkomen dat je business keihard wordt geraakt, zul je als klant in meerdere wereldwijde regio’s servers beschikbaar moeten hebben. Amazon heeft beloofd dat alle klanten in de betrokken regio tien dagen aan krediet krijgen. Dat is de prijs die een server kost. Als klant compenseert dit niet voor het feit dat je business plat lag.
Goed achter oren krabben
Ondanks de outage heeft Amazon de SLA niet geschonden. De SLA geldt alleen wanneer er kopieën van instanties in meerdere beschikbaarheidzones zijn. En als die er zijn, dan slaat de 99,5 procent op beschikbaarheid van instanties, ofwel het erbij kunnen. Dat het geheel vervolgens niet werkt omdat de opslagdatabase en de relationele database eruit liggen, is binnen de SLA niet van belang. Doordat de outage lag bij de Elastic Block Storage (EBS) en Relational Database Service (RDS), heeft Amazon de SLA niet geschonden. De tien dagen krediet zijn leuk voor de publieke opinie, maar een voorval als dit bevestigt maar weer eens te meer dat cio's zich heel goed achter de oren moeten zouden krabben voordat ze grote delen van hun business in de cloud te zetten.
Cloud integrity officer
Als klant zul je een eigen architectuur moeten kiezen met meerdere scenario's om de bedrijfscontinuïteit te garanderen. Laat je niet misleiden door je consumentenbril: Google, Apple en Amazon zijn net zo hard als Oracle, IBM of SAP. Wanneer je net als Lilly (groot farmaceutisch bedrijf) zou overwegen om je onderzoeksdata heel flexibel en goedkoop bij Amazon in de cloud te zetten, loop je bij een outage als deze dus ook risico's voor de goedkeuring van nieuwe medicijnen die miljarden moeten opleveren. Lilly gebruikt Amazon Web Services (AWS) voor het analyseren van non-productie data. Vorig jaar wilden ze een aanvullend contract sluiten met Amazon om iets meer high-profile datasets de cloud in te brengen. De contractonderhandelingen liepen echter stuk, omdat Amazon niet meer verantwoordelijkheid wilde dragen bij een eventuele outage. Nu de business steeds afhankelijker wordt van ict, moet je heel goed weten in welke cloud je stapt. Nog even en je bent een cloud integrity officer.
Interessanter is mijns inziens de vraag hoe betrouwbaar een dienstverlening is en welke verbeterslagen je provider maakt wanneer zaken toch onderuit vallen..
Compensatie is leuk, maar het diep in de buidel tasten doe je uiteindelijk nog steeds voor een stabiel en betrouwbaar platform en niet voor de eventuele compensaties..
Zoals je opgemerkt heb, het schrijven en onderhandelen van een SLA is een vak apart. Daar moet je zeker kennis van hebben. Als je bijvoorbeeld die 99,5% uit elkaar trekt en doorberekent dan kom je andere feiten tegen waar je niet blij van kunt worden. Naast het schrijven van SLA moet je ook nog meer kennis hebben van andere onderwerpen die je nodig heb voordat je aan Cloud begint. Dan denk ik laat me maar lekker met de beide benen op de grond staan en kijken naar mensen die op roze “cloud” lopen !!
Mooi artikel, relevant en goed opgebouwd. Ben het ook met de inhoud eens.
Ik wil wel een kanttekening plaatsen. Als Amazone episch faalt en voor langere tijd, dan ben je inderdaad zuur en je hebt weinig in de melk te brokkelen als dit gebeurt. Een goede afweging en een faal strategie zijn voor een bedrijf dan ook van levensbelang.
De outage van AWS overleven was overigens wel goed mogelijk als je de juiste keuzes had gemaakt, maar die kosten natuurlijk ook extra en bieden geen 100% zekerheid.
Niettemin staat er ook wel heel wat tegenover. AWS is goed betaalbaar en biedt mogelijkheden om met een klein team een enorme krachtige toepassing te maken en te beheren. Er liggen dus wel veel kansen en het wordt allemaal steeds beter.
De SLA is hierin dus zeker niet alles bepalend. Een slechte SLA hoeft niet te betekenen dat je geen zaken doet, alleen dat je meer eigen risico hebt. Ik zie vaak gebeuren dat een SLA overgewaardeerd wordt. Ik zie het dan als een aangereden voetganger die vanuit het ziekenhuis roept; “De bestuurder zat fout!”, dat kan wel zijn, maar het beschermt je niet tegen onheil.
Je kunt deze risico’s afdekken door een Software Escrow af te sluiten of dit van je leverancier te verlangen. Die zijn er nu ook voor SaaS. Bezoek de site van Escrow Europe eens.
@ Mischa: Wat een onzinnige ‘sluikreclame’ reactie van Escrow Europe. Ik heb de site bekeken maar heb nog geen flauw benul hoe je met software of saas escrow kunt indekken tegen een outage van (bijv.) Amazon E2C.
Krijg je dan een DVD met je data? En veel succes?
Wat is de Recovery Point?
Wat kost dat? Ik vermoed meer dan wat je voor Amazon E2C betaalt, dus daar gaat je besparing.
On topic: Goed opiniestuk. Als de grote cloud aanbieders echt services + vertrouwen willen leveren, dan zullen zij zelf het initiatief moeten nemen hier iets structureels tegen te doen. En geef de klant de keuze! (bronze/silver/gold model).
Sja, wat doe je tegen dergelijke grote bedrijven en hun “dienstverlening”. Daar ben je niet altijd tegen opgewassen. Anderzijds: techniek is niet feilloos, vooral complexe techniek niet (en ICT en cloud zijn best wel complex). Ook niet als bedrijven het tot hun hoogste doel maken om hun prestaties te laten excelleren.
Misschien kunnen we het ook eens op een andere manier bekijken?
http://www.managementsite.nl/13361/ict-internet/business-ict-dienstverlening-beter-koppelen.html
Even aanhaken bij RS 🙂 Ja, dit is mijn column en nee, geen reclame omdat ik geen product aanbied maar graag inzichten wil uitwisselen.