Enkele weken geleden presenteerde Amazon voor het eerst gedetailleerde cijfers over de cloud services. Dit lokte uiteenlopende reacties uit, hoewel omzet en groei zich positief ontwikkelen. Het bleek voor insiders en analisten erg lastig de cijfers met die van de concurrentie te vergelijken. Dat komt primair omdat iedere aanbieder van clouddiensten eigen definities hanteert.
Het uitblijven van uniforme begrippen en definities heeft niet alleen impact op bovengenoemde groepen. Ook de klant wordt het lastig gemaakt het aanbod echt te kunnen doorgronden. Op het moment dat hij voor het eerst in aanraking komt met het begrip cloud services is de kans groot dat het overkomt als bladeren in de accessoire lijst voor een nieuwe auto. Veel aanbod en onderlinge afhankelijkheden die schreeuwen om meer uitleg, al was het maar om te voorkomen dat het budget ruim wordt overschreden en hij door de bomen het bos niet meer ziet. Dat zelfde risico is er bij cloud services: er is dus goede uitleg vereist.
Neem als voorbeeld disaster recover as a service (DRaaS). Een typische dienst die cloudproviders aanbieden. Achter dit begrip gaat meer schuil dan op het eerste gezicht duidelijk wordt, niet in de laatste plaats omdat de behoefte per klant verschilt. Waar het voor de één voldoende is een complete kopie van de on premise situatie achter de hand te hebben, wil een ander dit misschien ook nog eens in meerdere fysieke gescheiden datacenters ondergebracht hebben. Over de eisen die aan data en applicaties in dit model worden gesteld, lopen de wensen ook sterk uiteen. DRaaS is dus op zich al een container begrip. Nog interessanter wordt het als we kijken naar DRaaS in de praktijk. Welk deel moet managed zijn en welke eisen worden aan het leverende team van de cloudprovider gesteld? Dergelijke variabelen in de dienstverlening maakt het lastig om een service als DRaaS te vergelijken bij verschillende cloudproviders.
Maar ook een klant, die voor een specifieke, van te voren gedefinieerde, set van cloud services op zoek is naar een leverancier zal ervaren dat die zoektocht lastiger kan zijn dan vooraf ingeschat. Dat heeft alles te maken met het afbakenen van diensten. In de regels is de cloud provider slechts een onderdeel van de gehele dienstverlening die de klant zelf aanbiedt. Het duidelijk kunnen aangeven waar de grens tussen klant en provider ligt, is niets minder dan een essentiële voorwaarde voor succesvolle ondersteuning van de cloud provider naar klant en van klant richting de eindklant. Uniforme begrippen en heldere definities zijn hier dus gewenst.
Er is echter ook een andere aspect dat een rol speelt bij het afnemen van clouddiensten en waaraan de klant serieus aandacht moet besteden. Vooraf moet duidelijk zijn of de cloud provider geen overlappende diensten op bijvoorbeeld het gebied van beheer aanbiedt. Als dat wel het geval is, kan de situatie ontstaan dat klanten de cloud provider als een concurrent beschouwen. De negatieve impact die dit kan hebben op de dienstverlening moet om elke prijs worden voorkomen.
Het risico dat overlap van diensten betekent en waarom dit tegen elke prijs vermeden moet worden, zal duidelijk zijn. Binnen elke cloudarchitectuur is het even slecht als het handhaven van een single point of failure. De overeenkomst tussen de twee is overigens dat beide te voorkomen zijn door allereerst een heldere propositie, gevolgd door een serieuze bespreking van die propositie en tenslotte regelmatig controle of de gewenste en afgesproken helderheid aanwezig blijft.
Binnen die context van helder taalgebruik en controle is veel onduidelijkheid, over de omvang en impact van cloud services, te elimineren. Vergelijk het met de functie die illustraties en online-configurators hebben voor het kiezen van auto accessoires.
Kwestie van als klant zijnde de opmerking durven maken. ‘U dingt niet meer mee vanwege de onduidelijke manier waarop u uw producten presenteert terwijl wij om specifiek deze definities gevraagd hebben.’
En ga dan desnoods met een aantal partijen om tafel zitten om die definities algemeen bruikbaar te maken.