Cloudcontract vraagt om aangepaste SLA

Met de komst van cloud computing verandert het hele ict-landschap. Hardware en software met eventuele licenties worden niet meer aan de eindgebruiker verkocht en kosten worden afgerekend via een dienstenmodel. Dat heeft verstrekkende gevolgen voor de servicecontracten die tussen bedrijven worden opgesteld. Onze experts van het topic Cloud Computing vertellen hoe er met service level agreements (SLA) moet worden omgegaan in een cloudcontract.

Berrie Pelser, internet (cloud) hosting specialist, Ber|Art Visual Design

Er zijn naar mijn mening twee zaken die erg belangrijk zijn in een servicecontact bij cloud computing: uptime en back-up.In het servicecontact moet dus uitgebreid ingegaan worden op de uptime (met garantie) en de gebruikte back-uptechnieken zoals live (VPS) mirror en tweedagelijkse volledige externe back-ups. Hoe snel kan een volledige back-up teruggezet worden. Met andere woorden, wat is de maximale downtime? Een hoge uptime haal je door te zorgen dat alle systemen altijd up-to-date zijn en veilig (PCI-compliant). Ook dit moet in het servicecontract (updates en upgrades van besturingssysteem, LAMP, controle paneel en beveiliging). Ook haal je hogere uptimes en voorkom je problemen door een zeer goed (intern en extern) monitoring-systeem. Een uitgebreid monitoring-systeem mag niet ontbreken in een servicecontact. Uiteraard moet de bereikbaarheid (telefoon/e-mail) 24/7 beschreven worden in het servicecontract. Verder uiteraard de algemene zaken als de tijdsduur van het contact, de prijzen, wat gebeurt er met third-party sofware en het onderhoud ervan.

Klaas de Jong, solution consultant, ETC

Gebruikers omarmen meer en meer een ‘op dienstverlening gerichte ict-omgeving' (SOA) uit de cloud. Kwaliteit en betrouwbaarheid van webdiensten zijn daarbij altijd belangrijke factoren. Wat echter van eindklant tot eindklant verschillend is, zijn de eisen die zij aan webdiensten stellen. Het is daarom vrijwel onmogelijk om vanuit alle perspectieven van de cloud de verwachtingen van de klant te managen. Na onderhandeling komen cloudleverancier en eindklant tot een overeenkomst voor levering van een ‘op dienstverlening gerichte WEB-omgeving'. In termen van een ‘op dienstverlening gericht ict-omgeving' heet een dergelijke overeenkomst een SLA.

Er zijn een aantal essentiële verschillen tussen het afsluiten van een SLA bij een gewone ict-dienstverlener en bij een cloudleverancier. Het is vrijwel onmogelijk om met de definities uit een gewone SLA alle facetten te beschrijven van een webgebaseerde ict-dienst. Wat zijn de gevolgen voor eindklanten als andere eindklanten een te grote belasting op de webinfrastructuur leggen? En hoeveel sessies kan een eindklant gegarandeerd/gelijktijdig gebruiken, zonder ‘overboeking' van het totaal aantal beschikbare sessies?

IBM heeft standaarden gedefinieerd in de vorm van WSLA's (web service level agreements). Deze vormen een aanvulling op bestaande SLA's en dienen zeker een rol te spelen bij onderhandelingen tussen aanbieders en eindklanten van een ‘op dienstverlening gerichte WEB-omgeving'.

Alex Bausch, oprichter, VeiligMobiel

Zoals er nog op elk softwarepakket wordt beschreven aan welke vereisten de hardware moet voldoen, is dit totaal niet meer relevant voor cloud-computing. In plaats van hardwarevereisten gaat het hier om de browsers die ondersteund worden. Dit is een belangrijk onderdeel van een serviceovereenkomst. Uiteraard speelt hier het dilemma dat de nieuwe mogelijkheden van nieuwe browsers benut moeten worden, maar menig grote onderneming werkt nog steeds op Internet Explorer 6 uit 2001. Een ander verschil met een 'klassiek' servicecontract is de duidelijk te definiëren hardware waarop de service wordt geleverd. In de cloud zijn gebruikers niet meer aan specifieke hardwarecomponenten te koppelen. Dit zal dus geen onderdeel van het servicecontract meer zijn.

Kurt Glazemakers, cto, Terremark Europe

Bij de inhoud van een servicecontract binnen een cloudomgeving is de klantbehoefte leidend. Het moet in essentie beschrijven tot waar de dienstverlening van de cloud-serviceprovider zich uitstrekt en welke specifieke onderdelen onder zijn verantwoordelijkheid vallen. In het geval van een IaaS-omgeving is een aantal elementen evident voor het contract. Dat zijn de minimaal gegarandeerde capaciteit en de gegarandeerde burst- of piekcapaciteit, evenals het gegarandeerde beschikbaarheidspercentage. Leg daarnaast vast hoe de toegangsrechten en toegangsmogelijkheden van beheerders geregeld zijn en welke garanties hiervoor gegeven worden.

Daarnaast moet uit het contract duidelijk worden of de SLA's klantspecifiek, of op ‘neighbourhood'-basis, zijn en of ze voldoende garanties bieden in geval van problemen. Selecteer een IaaS-provider die op een gestandaardiseerd (virtueel) platform draait en eenvoudig up- en downloaden van (virtuele) applicaties ondersteunt. Dan heb je als ict-manager steeds alle flexibiliteit om je strategie bij te sturen indien nodig.

De beveiliging van de cloudomgeving tenslotte is een sleutelelement. Zorg daarom dat geborgd is hoe en met welke frequentie auditing van de beveiliging plaatsvindt en dat je weet welke maatregelen er genomen zijn ter bescherming van ongeautoriseerde wijzigingen van systemen en/of configuraties. Ga na of er een beveiligingsincident-reactieplan met procedures voor het escaleren van ‘intrusion alerts' is en je weet of de cloudprovider tijdig kan ingrijpen bij incidenten.

Jeff Wouters, system engineer, Inter Access

Servicecontracten bij cloud computing zijn het belangrijkste van het hele concept ‘cloud'. Wat als de cloudprovider veroorzaakt dat jouw cloud offline gaat, bijvoorbeeld bij een upgrade van hun hypervisor, of wanneer je niet tevreden bent over de aanbieder en naar een andere aanbieder wilt migreren? Wat als jouw vertrouwelijke documenten ‘per ongeluk'op een website zoals Wikileaks terecht komen of erger… bij de de concurent? Leg dit soort dingen vast in het contract zodat je later niet in een ongewenste situatie kan belanden. Voorzorg is de moeder der wijsheid.

Mike Chung, manager IT Advisory, KPMG

In de praktijk zie ik dat servicecontracten tussen afnemers en cloudproviders tegen bepaalde kenmerkende issues aanlopen. Deze zijn vierledig van aard. Ten eerste zijn de services én service levels die de cloudproviders aanbieden in hoge mate gestandaardiseerd. Er is weinig ruimte voor afwijkingen en aan specifieke wensen kan in veel gevallen niet worden voldaan. Verzoek tot aparte service windows of extra rapportages wordt dan ook zelden door providers ingewilligd. Ten tweede is de monitoring en meting van service levels lastig. Het installeren van monitoring tools op de infrastructuur van de provider is doorgaans, zeker in een publieke cloud, onmogelijk. Derhalve is de afnemer aangewezen op de volwassenheid, integriteit en professionaliteit van de provider. Google of Salesforce.com zal haar klanten wel van rapportages voorzien, maar deze partijen zullen geen volledige inzage in hun systemen geven, althans niet realtime en continu.

Ten derde hebben we vaak te maken met statische servicecontracten in een markt die zich razendsnel ontwikkelt. De diensten en mogelijkheden van de cloud zijn volop in ontwikkeling. De op dit moment vastgelegde kwaliteitseisen kunnen binnen enkele maanden volkomen achterhaald zijn. Zo bieden bijvoorbeeld cloudproviders, ten dele gedreven door de eisen van haar klanten, steeds verfijndere methoden aan ten aanzien van gebruikersauthenticatie en -autorisatie. Ten slotte ligt de daadwerkelijke uitdaging voor grote organisaties in het beheren van verschillende contracten en contractvormen over meerdere rechtsdomeinen. De cloud mag dan wel een opkomend fenomeen zijn, in de praktijk blijven organisaties zaken doen met outsourcers, ict-integratoren, traditionele ict-fabrikanten met daarbij een groeiend aantal cloudproviders. Het orkestreren van deze hybride ict-omgeving inclusief contractbeheer wordt dan ook de belangrijkste succesfactor.

Valery Jacobs, technisch consultant, Valid

Service level agreements zijn in bepaald opzicht niet meer dan een hulpmiddel voor situaties waarin het kwaad al is geschied. Een vergoeding van de hostingkosten zal niet in alle gevallen de gevolgschade compenseren. Omdat cloudproviders klanten van groot en klein formaat hun diensten willen aanbieden en SLA's meestal voor beide categorieën hetzelfde zijn, is het moeilijk afspraken te maken die aansluiten op het belang van een klant. Iedereen wordt dus als gelijke behandeld en dat kan zowel voordelig als nadelig uitpakken.

Waar het bij cloudcomputing met name om draait is het vertrouwen dat men in een cloudprovider heeft en in hoeverre het cloudplatform in staat is risico's te minimaliseren. Het minimaliseren van risico's is voor een groot deel de verantwoordelijkheid van de techniek achter een cloudplatform. Wat vaak over het hoofd wordt gezien is dat sofware die in de cloud draait zich ook moet gedragen als cloudsoftware. Wat dit wil zeggen is dat de architectuur van een systeem dat naar cloud gemigreerd moet worden, of voor de cloud ontwikkeld wordt, bepaalde spelregels moet kunnen volgen. Virtualisatie en service oriented architecture zijn voorbeelden van ontwikkelingen uit de techniek die de cloud mogelijk maken en hun eigenschappen kunnen niet zomaar genegeerd worden door de systemen die erop moeten draaien. Een SLA kan niet als vangnet dienen voor een ondoordachte cloudstrategie, het houdt de cloudprovider misschien alert maar maakt ons, helaas, niet onschendbaar.

Frank van der Lecq, bid manager, NetApp

In de meeste servicecontracten staan boeteclausules centraal, vanuit het argument ‘we willen een stok achter de deur'. Dat lijkt krachtig, maar werkt in de praktijk averechts: mogelijke boetes eindigen toch in de kostprijs. Beter is het om in het contract te zetten dat bij X keer missen van de SLA de cloudprovider verplicht is om de migratie naar een andere omgeving te verzorgen. Dat is niet in te calculeren zonder je uit de markt te prijzen en zo bereik je eerder wat je zoekt: de beste service.

Rob Kurver, algemeen directeur, Voipro Nederland

Het ultieme servicecontract voor SaaS-diensten is eenvoudigweg de portemonnee: als de dienst niet voldoet dan vertrekt de klant met zijn business naar een concurrent. Of vertrekken veel klanten en valt de provider om. Van levensbelang voor de provider is dus om goede prestaties te leveren.

Het bijzondere van een echte SaaS-dienst is immers dat hij 24×7 door velen gebruikt wordt en dus in principe geen downtime of hersteltijd kent. Storing is storing, daar heeft iedereen direct last van. Let op, we praten hier niet over een gevirtualiseerde applicatie die voor een specifieke klant gebruikt wordt (de term SaaS wordt nog wel eens vrij geïnterpreteerd), maar een echt multi-tenant platform waar iedereen gelijktijdig gebruik maakt van dezelfde applicatie, met dezelfde feature set en dezelfde performance issues. Bovendien is bij SaaS sprake van betalen naar gebruik, per maand (of misschien paar maanden). Dus veel minder vendor lock-in, elke maand moet de klant opnieuw tevreden worden gesteld, anders verdwijnt hij. Voor PaaS en IaaS ligt het een tikje complexer, maar in essentie niet veel anders. Supersimpel systeem!