In de wereld van uitbesteding van ict-dienstverlening is beschikbaarheid een van de belangrijkste service levels in de gesprekken tussen uitbesteder en service provider. Je verwacht dan ook dat dit, in ieder geval op IaaS niveau, een van de belangrijkste onderwerpen is in de wereld van cloud dienstverlening. Maar dat lijkt gek genoeg niet het geval te zijn.
Een van de hobbels die bedrijven moeten nemen alvorens gebruik te maken van cloud dienstverlening is het durven loslaten van de volledige, bijna hands-on grip op ict-dienstverlening. Iets wat in de wereld van uitbesteding, de keuze voor ‘make’ versus ‘buy’, al 25 jaar een veelbesproken onderwerp is. Zie zo ook de recente blog van Gijs in ‘t Veld over ‘rondrennende mannetjes en SLA’, inclusief de vele reacties hierop.
Toch zijn er steeds meer bedrijven die de keuze maken voor uitbesteding, in de ruime zin des woords, waarbij we hier in Nederland zien dat we van een periode van single sourcing via multi-sourcing nu naar micro-sourcing gaan. Een ontwikkeling die prima aansluit bij het cloud computing paradigma.
Als we dan de invalshoek van infrastructuurdienstverlening nemen, dan gaan veel discussies tussen klant en leverancier over service levels, waarbij beschikbaarheid zo´n beetje het belangrijkste service level is. De percentages vliegen je om de oren, en er wordt goed gekeken naar het prijsverschil versus het risicoprofiel van 99,8 procent versus 99,9 procent. Je kunt daar gekscherend over doen, maar zoals we allemaal weten: zonder ict draait geen bedrijf. Wat mij betreft is het dan ook niet meer dan logisch dat we goed nadenken over zaken als beschikbaarheidspercentages. Zeg ik, komend uit de ’traditionele’ outsourcingswereld.
Beschikbaarheid
Als we dan de wereld bekijken door een ‘cloud bril’, en vanwege de invalshoek in dit verhaal wordt dat dan IaaS en soms een beetje PaaS, verwacht ik dat het onderwerp beschikbaarheid ook een hoofdrol speelt. Vanzelfsprekend op basis van de standaard serviceniveaus zoals die door cloud service providers worden aangeboden. Da´s logisch. Die trend voor standaardisatie van dienstverlening (op basis van standaard architectuurkeuzes, standaard dienstverleningprocessen en standaard service levels) was in het uitbestedingswereldje ook al zo´n tien jaar aan de gang. Dan zal beschikbaarheid ook een van de belangrijkste onderwerpen in de cloud wereld zijn, in ieder geval op IaaS niveau. Toch?
Nou … dat lijkt niet altijd, en wellicht zelf steeds minder, het geval te zijn. Het gaat veel over security en data privacy, en da´s ook een heel belangrijk onderwerp. Het gaat ook over vergelijkbaarheid van prijzen, waarbij het besef er is dat je appels met appels moet vergelijken. Er wordt steeds beter gekeken naar de daadwerkelijke prestaties van cloud diensten. Maar ook in deze vergelijkingen lijkt het aspect beschikbaarheid niet veel aandacht te krijgen. Performance, aantallen, maten, prijs. Daar draait het om. Alleen … wat heb ik aan een hele goedkope zeer goed presterende virtual machine met precies de juiste specificateis voor mijn workload als die er vervolgens iedere week twee uur uitligt?
Als Microsoft problemen heeft met Azure, vliegen de tweets je om de oren. De messen worden geslepen in diverse blogs, en Microsoft biedt publiekelijk excuses aan. Een nette reactie, en het probleem wordt opgelost. De toekomst zal uitwijzen of de beschikbaarheid van Microsoft´s Azure dienstverlening goed genoeg is en blijft voor zakelijke klanten.
Opvallend stiller
In het geval van AWS, volgens Gartner op dit moment de topspeler in de IaaS wereld, is het opvallend stiller. Vorig jaar december lag Netflix er een flink aantal uren uit, tijdens Kerst. Daar is toentertijd veel over te doen geweest. Recent lag de dienstverlening er een half uur uit. Er waren wel wat kritische reacties te horen, maar lang niet zoveel meer. En toen vlak daarna de Elastic Block Storage eruit lag in het data center aan de oostkant van de VS, bleef het stil. Alsof het de normaalste zaak van de wereld was.
Raar, erg raar. Het lijkt er soms een beetje op alsof klanten gewend raken aan downtimes van cloud diensten. Het misschien zelfs incalculeren. Voor ontwikkel- en testomgevingen kan ik me dat nog enigzins voorstellen, maar voor productie … snap ik dat echt niet. We moeten kunnen bouwen op cloud diensten, of dat nou voor privégebruik of voor zakelijke toepassingen is. Op basis van service levels die we in service level agreements afspreken. Daar zit ‘m natuurlijk voor de consumentenwereld de crux, want veelal worden er geen service levels afgesproken en … als de dienstverlening gratis is, wordt het ook moeilijk om dat te eisen. Maar voor zakelijk gebruik moet je er als gebruiker van op aan kunnen dat de dienstverlening in de lucht is . In een wereld waarin we er voor kiezen om steeds afhankelijker te worden van een keten van cloud dienstverleners kan het niet zo zijn dat we apathisch worden voor slechte prestaties. Ik geloof in cloud computing, ben een believer van de “api-economie”, maar laten we wel serieus blijven werken aan de beschikbaarheid van cloud diensten. Overigens ook aan integriteit en vertrouwelijkheid, maar da’s voor een volgende keer.
Beschikbaarheid van cloud instances of zelfs complete datacenters is een minder belangrijk issue voor moderne apps. Voor de traditionele, monolithisch gebouwde applicaties uiteraard wel, maar kan het zijn dat die (nog) niet en masse op Azure/Amazon worden gedraaid?
Ach, beschikbaarheid is er in vele soorten en maten. Dat de server up is betekent nog niet dat je dienst het doet. En juist on-premises (al dan niet in eigen datacenter) zie je dat werkelijke uptime (de tijd dus dat gebruikers geen storingen ervaren) niet veel beter is dan bij de grote cloud providers. Vooral bij legacy en grote verwevenheid door de tijd heen ontstaan er storingen die wellicht door infrastructuur niet als downtime aangemerkt worden, maar wel leiden tot praktische downtime, de tijd dat een medewerker of klant zijn werk niet kan doen.
Downtime kan ook veroorzaakt worden door een overbelaste database server die de aanvragen vanuit de applicatie locked of throttled. Of dat de bandbreedte dichtslipt omdat teveel mensen aan het videoconferencen zijn.
Beschikbaarheid is wel belangrijk, maar de zekerheid tussen 99,8 en 99,999 kost enorm veel centen en als je deze doorrekent naar incidenten en kosten is het nog maar de vraag waarvoor je kiest.
Er zit natuurlijk ook nog een verschil tussen consumenten producten Netflix / Spotify en bedrijfskritische systemen waarin falen mensenlevens in gevaar brengt.
Het blijft iets om rekening mee te houden, maar de garantie van uptime wordt niet gegarandeerd door een goede SLA, maar door een robuust opgezette architectuur.
“maar laten we wel serieus blijven werken aan de beschikbaarheid van cloud diensten. Overigens ook aan integriteit en vertrouwelijkheid, maar da’s voor een volgende keer.”
pcies, first things first 😉
Een down of up percentage zegt niet zo veel, het gaat meer om de momenten waneer, hoe vaak hoe veel etc 99,9% invullen op een feestdag zal iedereen een feest vinden, maar elke maand bij het afsluiten van de boeken weer net niet. natuurlijk begint het bij de architectuur, maar ook het monitoren en de mogelijkheid van vervanging en de wijze waarop. Los daarvan is er nog zoiets als gebouw en locatie-toegankelijkheid. Niet elk systeem is direct te benaderen vanwege veiligheidseisen, gebouw bewaking, of brandveiligheidsvoorzieningen. Voor multi-user of openbare infrastructuren komend aar nog een paar “dimensies” bij.
Kortom uptime productie is een complexer iets in de wat meer ingewikkelde infrastructuren.
Henri,
Stuk gaat verder op de SLA problematiek welke Gijs startte en die bij uitbesteding meer als prijsinstrument dan kwaliteitsnormering gebruikt lijkt te worden. Maar je bent aan de beterende hand door een duidelijk verschil te maken tussen de ‘low-entry’ oplossingen en de hoge eisen die aan andere systemen gesteld worden, de ‘on-premise’ klok wordt dan ook nooit gestolen omdat iedereen er elke seconde naar kijkt;-)
Wie een ‘cloud bril’ op heeft maar denkt als de chauffeur van een bommenwerper mist dus Zijn doel omdat de real-time visibility ontbreekt.
Ewout, dan ben ik benieuwd wat je van mijn stuk vandaag gaat vinden (weet niet welke tijd het geplaatst wordt).
En ik ben realistisch dan ik blijkbaar soms overkom. Ik weet dat consumenten anders zijn dan business gebruikers, toch is het een mooi streven om als bedrijf/dienst voor de business het idee te geven dat het net zo gemakkelijk is als de consumentendienst. Dat men niet ziet wat voor enorme inspanning je achter de schermen moet leveren om iets er simpel uit te doen zien neem ik dan voor lief. Automation, self service en workflow zijn de bom!
@Henri,
Ik heb mijn kritische noten toegevoegd aan jouw stuk.
Het zou het mooi zijn als Marc zich eens in de discussie zou mengen want nu is het geen bom maar een drol deponeren.
P.S.
Zoek eens op OODA loop wat door menselijke ‘override’ geen loop zou moeten zijn, autonome drones hebben namelijk een aantal nadelen;-)
Euh … volgens mij ga ik Henri’s stuk eens doorlezen. Word ik zo maar opgeroepen om me in een discussie te mengen. Nou … dat slaan we niet af natuurlijk 🙂