Ook bij cloud computing dient een beheerder nog steeds non-stop aanwezig te zijn om voorkombare fouten te voorkomen. “Voor ict-beschikbaarheid bestaan al ongeveer 20 jaar best practices”, zegt Jorge Noa, CTO bij cloud-consultancy Hyperstratus. “Cloud computing kan het makkelijker maken om die best practices in de praktijk te brengen. Maar je moet het nog wel doen.”

Vooral recent zijn allerlei vragen opgeworpen over de veiligheid van cloud computing. De volgende drie beheerfouten zullen ongetwijfeld nog vaak worden gemaakt, en zullen het vertrouwen in de cloud niet altijd even goed doen. Bovendien is deze lijst (helaas) verre van compleet.

Veel voorbeelden hebben direct betrekking op Amazon, en wel om twee redenen. “Amazon is veruit de grootste cloud-leverancier in de markt”, noemt Noa de eerste reden. De tweede reden is dat het vooral fouten met Amazons EC2-cloud zijn die de pijn blootleggen, omdat de klant het had kunnen voorkomen door van tevoren iets beter na te denken.

Geen onderscheid maken tussen verschillende vormen

Het eerste foutje is algemeen. Het is erg aanlokkelijk om cloud computing te zien als 'ict uit de kraan'. Maar anders dan de dienstverlening van de kraan (er komt water uit, met dikwijls de keus tussen warm of koud), kan cloud computing allerlei vormen aannemen waarbij de verantwoordelijkheden voor de klant anders liggen. “Je kunt het ruwweg onderbrengen in drie niveau's, die oplopend meer werk uit handen nemen”, schetst Noa, aanvullend met de opmerking dat er nog veel tussenvormen zijn en dat de terminologie per leverancier kan verschillen.

“Je hebt infrastructure-as-a-service, platform-as-a-service en uiteindelijk software-as-a-service”, somt Noa op. Daarbij is het zaak dat je in de gaten hebt wat je precies als dienst krijgt, en wat je zelf moet regelen. Amazon EC2 (infrastructure) werkt anders dan Googles ontwikkelcloud (platform). “Infrastructure-as-a-service biedt alleen een raamwerk voor diensten die je zelf in moet vullen. Dat betekent ook dat je zaken als disaster recovery en load balancing zelf moet regelen.” Helaas denken veel afnemers nog steeds dat de leverancier dat uit zichzelf regelt, met alle gevolgen van dien.

Geen redundantie inbouwen

De afgelopen Amazoncrash was zeker niet de eerste. Hoewel Amazon klanten belooft dat dienstverlening bij problemen direct wordt omgezet naar een nieuwe beschikbaarheidszone, kan het gebeuren dat een hele regio eruit ligt.

Zo lag de cloud-ict van Heroku, een ontwikkelbedrijf die zijn diensten van Amazon afneemt, er ondanks een beschikbaarheidsplan afgelopen zomer uit omdat ze één detail waren vergeten. Alle redundante diensten waren ondergebracht binnen één regio, waardoor ze alsnog problemen hadden.

Dat is ongeveer wat vele klanten bij de recente crash ook is overkomen, dus de les lijkt nog niet helemaal geleerd te zijn.

Monitoring van de clouddienst afnemen... maar via dezelfde clouddienst

Als een cloudinfrastructuur eruit ligt, wil het maar al te vaak gebeuren dat de beheerder niet weet wat er aan de hand is. Waarom? Omdat hij de beheerapplicatie had afgenomen via dezelfde cloud-infrastructuur.

Dat is ietwat onhandig. Een voorbeeld dat Noa noemt is Rightscale, die beheerdiensten aanbiedt. “Rightscale zat zelf op Amazon, en was tijdens de crash onbereikbaar”, zegt Noa. “Rightscale was er vroeg bij, namelijk sinds de tijd tijd dat Amazon EC2 alleen nog gebaseerd was aan de Oostkust van de VS.” Door de wet van de remmende voorsprong was Rightscale nog niet 'uitgebreid' naar andere beschikbaarheidsregionen.

Juist die oostkust-regio lag er de vorige storing uit. “Dus de applicatie die veel beheerders gebruikten om hun cloud mee te monitoren en te controleren, was tijdens de storing zelf niet bruikbaar.” Veel beheerders wisten volgens Noa daardoor niet wat er aan de hand was. Maar, eerlijk is eerlijk: beheerders wisten in ieder geval direct dat het probleem bij Amazon algemeen lag, niet bij de specifieke verbinding naar hun toe.