Of het nu gaat om een it-afdeling die een private cloud-omgeving inricht of een service provider die klanten een cloud-service wil verkopen, zodra de prestaties teruglopen of sterk fluctueren loopt het vertrouwen van de klant direct terug. We zullen dus in de vorm van een service level agreement (sla) de afspraken goed moeten vastleggen. De cloud vraagt echter om een ander soort sla dan we gewend zijn. Daarom is een nieuwe rol nodig voor application performance management( apm)-tools.
Een cloud service die wat performance betreft gaat haperen of die af en toe niet beschikbaar is, wordt door de interne of externe klant simpelweg niet geaccepteerd. Of het nu om intern gerichte of voor externe gebruikers bedoelde applicatie gaat, men eist nu eenmaal een betrouwbare, veilige en consistent presterende webapplicatie. Er is maar één manier om dit te kunnen garanderen en dat is door de gehele keten aan systemen en applicaties die nodig is om de cloud service aan de klant te bieden in één geheel te beheren. Met andere woorden: end-to-end performance management.
Buiten directe controle
In zijn meest eenvoudige vorm is cloud computing een manier om tot een betere toegang tot informatie te komen voor werknemers, partners en klanten. Informatie in de cloud moet altijd, overal en via ieder willekeurig apparaat beschikbaar zijn. Dit vereist uiteraard wel dat in de cloud geplaatste applicaties op een effectieve manier worden beheerd. De belangrijkste uitdaging hierbij is natuurlijk dat de applicatie gehost wordt op een systeem dat buiten de directe controle van de eigen it-afdeling valt. Een it-manager wordt dus geconfronteerd met een nieuwe uitdaging: hoe kan ik voldoen aan de sla die ik voor deze applicatie met de business heb afgesloten als zich een technische storing voordoet buiten mijn eigen it-organisatie? Op dat moment heeft deze it-manager immers geen enkele technische controle over de systemen die een storing vertonen, maar wordt hij wel afgerekend op de gevolgen van zo'n incident.
Cloud service providers staan er niet om bekend dat zij graag sla's op maat van individuele klanten afsluiten. Als ze het al doen worden echter vaak twee belangrijke punten over het hoofd gezien. Allereerst gaat het niet alleen om beschikbaarheid van de service of applicatie, maar ook over performance. Bovendien is de service provider slechts één component in een almaar complexer wordende keten (delivery chain) van systemen die nodig is om een cloud service aan de gebruiker te kunnen aanbieden.
‘The last mile’
Wanneer we de situatie bekijken vanuit de eindgebruiker, dan zien we dat een slecht prestatieniveau en het niet beschikbaar zijn van een applicatie in feite hetzelfde is. Waar het probleem zich ook in die delivery chain mag bevinden, het effect is steeds dat de eindgebruiker zijn werk niet naar behoren kan doen. In het slechtst denkbare scenario is zelfs alles in orde in het datacenter, maar worden sommige (of alle) gebruikers toch geconfronteerd met haperingen. Het is voor de eerder genoemde it-manager dus van cruciaal belang dat hij over relevante informatie beschikt over de volledige delivery chain. Heeft hij die gegevens niet beschikbaar, dan is het vrijwel onmogelijk om vast te stellen waar zich eventuele prestatie- en beschikbaarheidsproblemen voordoen. Laat staan dat dit soort problemen kunnen worden opgelost.
Hier komt nog een extra complicatie bij: ‘the last mile'. Werknemers of klanten maken gebruik van een internet service provider (isp) om contact met internet te krijgen. De geografische locatie en zelfs het tijdstip waarop men online is, hebben invloed op het prestatieniveau zoals de eindgebruiker deze zal ervaren – hoe goed alle andere schakels in de delivery chain ook onder controle mogen zijn. Tests die Compuware heeft uitgevoerd, laten bijvoorbeeld zien dat alleen al de geografische afstand tussen de applicatie en de gebruiker een serieuze impact kan hebben op de performance zoals de gebruiker deze ervaart. Responsetijden van zes seconden kunnen op een gegeven moment helaas heel gewoon worden. De kwaliteit van de verbinding die de isp levert, kan hier uiteraard ook een rol bij spelen.
Niet constant
De prestaties van cloud providers zijn niet constant, maar kunnen aanzienlijk variëren gedurende de dag en zijn bovendien afhankelijk van de load die de provider dient te verwerken. Dit staat dus op gespannen voet met de claim van veel cloud-aanbieders dat de cloud ‘rapid elasticity‘ biedt. Ofwel een snelle en flexibele groei of krimp van de verwerkingscapaciteit zonder dat dit gevolgen heeft voor de performance. Ook cloud providers hebben geen onbeperkte hoeveelheden servers in reserve die probleemloos en in realtime bijgeschakeld kunnen worden als de load daar om vraagt. Met andere woorden: wat de buurman doet heeft wel degelijk impact op de performance van onze eigen cloud service.
Traditionele apm-tools zijn niet in staat om deze nieuwe cloud-applicaties goed te beheren. Zij bieden een te smalle kijk op de prestaties van specifieke technische componenten of processen. De enige manier om werkelijk grip op prestaties en beschikbaarheid te krijgen, is door een holistische ofwel allesomvattende blik op de gehele delivery chain. Alleen dan kan een sla worden afgesloten die de it-manager werkelijk rust geeft.
Met alle respect: what’s new? Gebruikers hebben al sinds de tijd van het centrale datacenter moeten leven met hun ‘last mile’. En end-to-end performance metingen zijn ALTIJD al cruciaal geweest om überhaupt iets te kunnen zeggen over performance bij die klant. Dat we al decennia lang ‘performance’ aan de rand van het rekencentrum meten is totaal niets nieuws. Misschien dat cloud-technologie eindelijk de dwang in zich heeft om leveranciers eens op gebruikersniveau te laten meten wat de werkelijke prestatie is…. En misschien dat er nu wat meer besef van de keten komt. maar er verandert niets wezenlijks.
Ik gebruik overigens zelf al heel erg lang een kantoor op afstand, zodat ik gewoon thuis of in Australië door kan werken. Dat heette vroeg ASP of SAAS. Nu heet dat ook cloud terwijl er niets is veranderd.
Misschien dat de juridische aspecten van cloud nog het meest interessant zijn. De techniek en het management houden in ieder geval geen grote verandering in. Een cloud-SLA kan dus volgens mij hooguit in juridische zin nog interessant zijn.
@ JanvanBon,
Ik sluit me volledig aan bij je reactie.
Regelgeving is nog een hot topic. Gelukkig speelt de Europese Commissie daar wel steeds beter op in met haar Cloudstrategie.
Of deze Cloudstrategie een haalbare zaak is, is natuurlijk een heel andere discussie.
@Jan / Ruud:
Eens. En om dan weer de link terug te leggen naar de inleiding van het artikel: met juridische “dingen” is klantvertrouwen dat weg is niet meer terug te halen!
@janvanbon:
Als je de juridische aspecten van een cloud-sla het meest interessant vindt dan zou je bij het opstellen van je sla of indienen van je klacht op een punt uitkomen: nulmeting!
Voordat je als klant met je contract of sla gaat zwaaien moet je eerst je klacht onderbouwen. Daarvoor heb je o.a. apm-tools nodig.
De techniek die in allerlei lagen en aspecten van Cloud nodig is, is juist de uitdaging. Het meten van performance in verschillende componenten binnen Cloud-keten is een voorbeeld waarvoor je de juiste en verschillende tools/technieken nodig hebt. De huidige tools (zoals apm tools)en technieken zijn niet allemaal geschikt voor Cloud! Dit is een terecht opmerking van Winston, vind ik.
Juridische aspecten kunnen op dit moment een hot-topic zijn maar dat is het punt niet. Hiervoor zullen ze na wat vergaderingen en lobbyen in Brussel een oplossing vinden, het komt goed.
Bij cloud komen er nieuwe onderwerpen voor een SLA bij. Wat te denken aan het bijschakelen van server capaciteit binnen de afgesproken tijd. Dit is misschien heel erg gerelateerd tot beschikbaarheid, maar is anders als je het vergelijkt met bestaande diensten. Het vereist meer dynamiek. Het ligt er erg aan wat voor cloud type wordt aangeboden. Op elke type valt een ander soort SLA te definieren. Een publieke cloud zal veel vaker een generieke SLA hebben, terwijl een private cloud meer gecustomized naar de behoefte van de organisatie.
Leveranciers aan serviceorganisaties of-afdelingen verkopen zich maar al te graag als onderdeel van de delivery chain, maar onttrekken zich in de praktijk aan de bijbehorende verantwoordleijkheden. Integraal onderdeel zijn van de keten van de klant vereist een hoge mate van transparantie. En daar zijn ze vaak nog niet aan toe. Het leveren conform de afspraken die de serviceorganisatie met de gebruikersorganisatie heeft kan zo onvoldoende gegarandeerd worden. De situaties waarin dit gebeurt, laten feitelijk zien dat de serviceorganisaties niet in control zijn. Hebben it-managers die hier wakker van liggen dat dan niet aan zichzelf te danken?
Anderzijds kun je je afvragen of de ontwikkeling van clouddiensten (of liever: van clouddienst leveranciers) al een niveau heeft bereikt dat leveranciers in staat stelt die transparantie wel te bieden. Waar nog steeds gesteggeld wordt over de definitie van cloud, de verschillende diensten die via cloud worden geboden en de wijze waarop deze georganiseerd zijn en geleverd worden laten nog de nodige ruimte voor verbetering. Het samenspel tussen serviceorganisaties en dienstenleveranciers en providers (of een combi daarvan) is cruciaal.
Juist omdat er meerdere partijen betrokken kunnen zijn die samen de gehele infra, omgeving en functionaliteit voor een gebruikersorganisatie leveren, is het van belang dat men eenduidig en helder kan aantonen wat er wordt geleverd, tegen welke voorwaarden met welke middelen en kwaliteit en tegen welke garantie. Zo kan beantwoord worden aan de afspraken met de klant, of kan er over die afspraken (opnieuw) onderhandeld worden.
Maar op het moment dat men dat kan aantonen, is de vraag of je dat nog moet willen meten door de keten heen. De eindverantwoordelijke is de serviceorganisatie, omdat deze de partij is die een SLA met de klant heeft en voor die klant het enige aanspreekpunt is. Tooling voldoet in de meeste gevallen uitstekend om aan te tonen dat levering, herstel of wijziging van services is blijven steken op het niveau van de serviceorganisatie of bij leveranciers verderop in de delivery chain. Dat op zichzelf is slechts een gegeven. De vraag is vooral wat je er als serviceorganisatie vervolgens mee doet.
Ik sluit me aan bij de visie van HK. En in aanvulling daarop: het lijkt erop dat de meeste gesprekken bij leveranciers, service organisaties en klanten organisaties gaan over regels, risico’s, garanties, aansprakelijkheid en wat al niet meer.
En dat terwijl er voor een cloud/services leverancier meer dan voldoende mogelijkheden zijn om op een transparante manier te laten zien wat het niveau van zijn dienstverlening is. En dat zonder noemenswaardige risico’s of meerprijs voor diezelfde dienstverlening. Sterker nog – ik heb het vaak genoeg meegemaakt dat de risico’s en kosten substantieel afnemen; juist door die transparantie!
Zo ook de garanties richting een gebruikersorganisatie: ik heb mijn twijfels of die daar nou echt op zitten te wachten. Volgens mij zitten ze meer verlegen om een voorspelbare en betrouwbare dienstverlening. En als er dat even niet in zit, wanneer dan weer wel. Tis juist die transparantie die voor een gevoel van ‘voorspelbaarheid’ en ‘betrouwbaarheid’ gaat zorgen!
Kortom – zoals HK al aangeeft – stel er is vastgesteld dat er ergens een zwakke schakel in de IT/cloud keten zit, wat gaan we er dan mee doen?
Gaan we dan eerst bewijslast verzamelen rondom het antwoord op de vraag “Wie is verantwoordelijk en aansprakelijk?”? Eventueel aangevuld met met napluizen van contracten en SLA’s of er een ontsnapping mogelijk is?
Of we gaan we kijken of we die zwakke schakel een handje kunnen helpen om er uiteindelijk als keten beter op te worden?
Oftewel, welk belang gaan we dienen? Het belang van ‘ikke’? Of het gezamenlijke belang?
Samengevat, mijn inschatting is dat als het zwaartepunt ligt bij het denken in risico’s, verantwoordelijkheid en aansprakelijkheid (lees: contracten, SLA’s en Europese regelgeving) het er in ieder geval niet beter op zal worden – eerder slechter.