Home Cloud Cloudketens: niet elke vernieuwing is vooruitgang

Cloudketens: niet elke vernieuwing is vooruitgang

7

Je kiest ervoor om in de Wolken te gaan vanwege variabele kosten en capaciteit en daardoor ook vaak kortere doorlooptijden. Maar niet alles is wat het lijkt, de claim ‘zelfde functionaliteit tegen lagere kosten’ kan nog wel eens aardig tegenvallen. In een eerdere column zagen we al boemerang-effecten bij IaaS, en nu zien we voorbeelden van de Application Service Provider-wereld.

Recentelijk bijvoorbeeld, onderhandelde ik met een SaaS cloudvendor die weliswaar 99.99% uptime garandeerde, doch slechts voor een deel van zijn 3-tier applicatie volledig redundante datacentra had. Nu is de SLA bepalend en niet de interne oplossing ervoor. Maar toch, op uitleg hoe ze dit aantal negens-achter-de-komma menen te kunnen waarmaken in het geval van de spreekwoordelijke lawine of vliegtuigcrash of brand nabij het single-datacenter-of-failure zit ik nog steeds te wachten. En nog een leuke: wij wilden graag de gangbare loadtest voor langdurige piekbelasting draaien, op een test-omgeving los van de normale productie. Test-slots voor onze eigen datapartitie waren inderdaad te boeken, maar ‘integratie met de realtime financiële datafeed was niet mogelijk, want dat zou de productie verstoren; en in een gesimuleerde datafeed is nog niet geïnvesteerd’. Je raadt het al, die datafeed is een essentieel onderdeel van de applicatieketen dus ook hier kunnen we de nodige korrels zout leggen op de geclaimde SLA.

Vandaar dat we maar weer eens een paar deuren intrappen. Of die geheel ‘open’ zijn danwel toch nieuwe inzichten opleveren is aan jou. Ten eerste: stel gedetailleerde SLA’s (Service Level Agreements) op en leg de nadruk op het WAT, dus de score. Het HOE, met bijvoorbeeld hot standby of cold standby of zelfs het voor websites gangbare active-active loadbalancing, is aan de vendor; doch enig boerenverstand gebruiken om denkfouten zoals het bovengenoemde single-datacenter-of-failure te vinden kan geen kwaad.
Ten tweede: specificeer niet alleen je productiesituatie, maar ook je testwensen. Zaken zoals responstijd en piekbelasting wil je immers liever meten zonder de productie te storen.
En ten derde: ga er niet te makkelijk van uit dat je gebruikers in ruil voor al die mooie cloud-extra’s functionaliteitsverlies zullen accepteren vergeleken met de huidige in-house situatie. Niet zozeer de dimensie van oud-pakket (in huis) versus SaaS-standaardfuncties, daar zullen voor bijvoorbeeld SalesForce of SAP of Oracle of Microsoft cloudfuncties wel voldoende vergelijkingen gemaakt zijn. Maar eerder de technische dimensie. Single SignOn bijvoorbeeld is standaard in de meeste eigen datacentra, maar om dit aan de praat te krijgen met een SaaS-applicatie vereist inspanning bij onze IT-staf én de ASP. En de gebruikerservaring wordt mede bepaald door de responstijd, en die is bij SaaS inclusief soms hinderlijke latency. Investeer, test en vergelijk appels met appels…

Bottom line: bewaak de keten alsof het een interne applicatie was en je kunt je nog steeds een verantwoordelijk totaal-leverancier van de IT-functies noemen!

Erik de Ruijter

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here