Managed hosting door True

De kijk van Van Eijk: 'Help, Amazon werkte niet'

Peter van Eijk

Peter van Eijk is onafhankelijk adviseur (www.digitalinfrastructures.nl).

Vorige week was er een flink probleem met een deel van Amazon’s EC2 hostingdienst. Verschillende bedrijven hebben een groot deel van hun online dienstverlening meer dan 24 uur stil moeten leggen. Daaronder waren social media sites, zoals FourSquare. Betekent dit nu dat cloud computing bij nader inzien toch geen goed idee is?

Wat er werkelijk aan de hand was kunnen we van buiten niet goed zien, maar we kunnen wel een idee hebben. Volgens Amazon was een ‘netwerkprobleem' voor de beheersoftware aanleiding om mirrors opnieuw op te bouwen. Mirrors zijn schaduwkopieën van de ‘virtuele harde schijven' van EC2-klanten. Alleen, doordat er zoveel mirrors tegelijk opgebouwd moesten worden, kwam de EC2-locatie enorm veel capaciteit tekort in het netwerk. Dat ziet er voor de beheersoftware uit als een netwerkstoring, waardoor er nog meer mirrors moesten worden gerepareerd. Dit lawine-effect loopt snel uit de hand.

Dit is gewoon een ontwerpfout van Amazon EC2. Een hersteloperatie als deze is een verzoek dat resources kost. Als je operatie zo vergaand is geautomatiseerd als die van Amazon moet je zulke verzoeken kunnen uitstellen, anders werkt je capaciteitmanagement niet.

Maar was Amazon nu de enige met een ontwerpfout? De getroffen bedrijven hebben blijkbaar niet goed nagedacht over hun risk management. Want ze hebben eigenlijk hun hele business op een enkel rekencentrum gebouwd. En je moet een cloud provider eigenlijk zien als een rekencentrum. En ook al is het nog zo redundant gebouwd, ontwerpfouten als deze blijven een ' single point of failure'. Sommige van dit soort bedrijven hebben een maandelijkse Amazon-rekening van boven de honderdduizend dollar. Dan moet je je toch wel een beetje risk management kunnen permitteren? Zo moeilijk is dat nu ook weer niet, voor honderden andere EC2-klanten werkte de ‘fail-over' prima.

En niet in de cloud werken is ook geen oplossing. Een van de getroffen bedrijven gaf tandenknarsend toe: 'We kunnen wel met onze vinger naar Amazon wijzen, maar zonder Amazon waren we niet geweest waar we nu zijn.'

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Kwestie van prioriteiten instellen welk systeem en applicatie eerst weer op mag komen op het moment dat er heel veel down gaat. Is dus inderdaad een design fout. Beter een aantal systemen/applicaties een klein beetje buiten de SLA op brengen is beter dan een sneeuwbal effect. Maar ja, je kan natuurlijk ook (zoals altijd) het netwerk de schuld geven, bewijs het tegendeel maar.

Amazon heeft hun datacenter al op verschillende continenten staan, en ongetwijfeld zijn er op ieder content al meerdere datacenters. Dus bedrijven die op amazon werken hebben per definitie al redundant uitgebrachte datacenters. Da's juist een van de voordelen van cloud-computing boven het zelf huren van een server.
Volgens mij is offline gaan door software/configuratie- of in het algemeen menselijke fouten vrijwel onvermijdelijk. Ieder (groot) bedrijf heeft daar ooit wel eens last van gehad, toevallig zie ik in deze nieuwsbrief de Rabobank al langskomen.
Amazon heeft hetzelfde probleem als een vliegtuigmaatschappij wanneer een vliegtuig crasht: zo'n ongeluk maakt in een keer heel veel slachtoffers, waardoor het meteen wereldnieuws wordt. Dit terwijl er dagelijks honderden verkeersdoden zijn, die ieder hoogstens een regionaal nieuwsbericht opleveren.
Net zo goed zijn er dagelijks vermoedelijk honderden outages van verschillende sites die een eigen (gehuurde) server hebben, dit komt alleen niet in het nieuws.
Gelukkig zal zowel een vliegtuigmaatschappij als (hopelijk) Amazon er dan wel alles aan doen om tot de bodem uit te zoeken wat de oorzaak is en hiervan te leren.

Deze fouten zijn cruciaal en noodzakelijk voor een robuust systeem. Doordat het optrad kunnen er maatregelen gemaakt worden die dit probleem in de toekomst kan voorkomen.

Dit is hetzelfde nu als (computer) virussen. Als er nooit een succesvol virus is wordt er geen beveiliging gebouwd. Als er dan ineens een goed virus komt, dan is iedereen meteen slachtoffer. Door al die virussen door de jaren heen worden er steeds betere beveiligingen hiervoor gemaakt.

Cloud Computing - ofwel Internet Computing wordt zodoende steeds beter en robuuster. Zonder dit soort problemen duurt het alleen maar langer voordat het goed is.


@Henri: Leren door vallen en weer op te staan, maar dan wel op kosten van de klant, uiteraard. :-)

@Technicus : Exact! Net zoals jij fouten maakt en ervaring op doet bij het bedrijf (of opdrachtgever) waar je werkt, op kosten van het bedrijf. Of zeg je na iedere fout of leermoment; "hou maar van mijn salaris in".

Je hebt een overeenkomst met AWS, komen zij die niet na, dan heb je recht op een overeengekomen vergoeding, of je hebt eventueel een rechtzaak. Zo is het balletje weer rond.

Maar de wereld is inderdaad vooruit gegaan met vallen en opstaan en daar is voor diverse partijen aan bijgedragen. Gelukkig dat niet bij iedere fout de "schuldige" moet betalen. Dan had nooit iemand meer iets nieuws geprobeerd. Stap uit die Matrix!

Als eerste ben ik niet tegen cloud computing, het is een "nieuw" produkt dat in een behoefte voorziet.
Echter toont dit opnieuw aan dat het produkt nog niet rijp is, het volgt daarmee een tendens om onrijpe produkten op de markt te brengen.
Wat van Eijk zegt is natuurlijk typische verkooppraat, samengevat "de klant moet aan riskmanagement doen, en het zijn eigen schuld als gegevens verloren gaan".
Zo is cloudcomputing niet verkocht meneer van Eijk, het is verkocht als het kalf met de gouden horens. Je legt alle varantwoording bij de (cloud-)leverancier en hebt geen zorgen, dat was toch wat al te mooi om waar te zijn blijkt nu.

@Jan : Sorry dat ik altijd op jou moet reageren, het is sterker dan mij :-)

Over producten die "rijp" zijn : When you're green, you grow. When you're ripe, you rot

Innovatieve producten en diensten zijn per defenitie niet rijp, wachten daarop betekent dat je geen onderscheidend vermogen hebt, of deze ergens anders uit moet halen.

Daarnaast moet je het falen in perspectief plaatsen. Was het episch falen? Nee. Het geval van AWS ging over onverwacht gedrag in een nog niet bedacht scenario. Dat scenario is nu bekend en worden maatregelen op genomen. Was het een compleet falen? Nee. Bedrijven die hun zaakjes goed op orde hadden bij AWS bleven gewoon in de lucht. Voor sommige bedrijven was het onwetendheid, voor andere bedrijven was het een kosten baten analyse. Het was goedkoop en het had een risico. Dat risico hadden ze af kunnen kopen en dat is niet gebeurd.

Het is dus geen cloud falen, in tegendeel!

Daarbij blijf je hangen in de "verkooppraat" cliché. Als je je verdiept in AWS dan zie je dat het *geen* overdreven beloften doet, dat het gewoon beschrijft wat het doet, en wat ze doen doen ze ook nog eens ongelofelijk goed met een support waar veel bedrijven van kunnen leren.

Verkooppraat is gewoon suggestieve onzin en moet per geval bekeken worden. Je scheert alles over een kam. Leuk om te lezen, maar snijd geen hout.

Het spijt me Henry, lees de artikelen in de internationale pers, dan kom je niet met opmerkingen als "Het is dus geen cloud falen, in tegendeel!".

Het principe van de cloudcomputing zoals die door amazon aangeboden werd heeft gefaald. Als klant heb ik gemerkt hoe amazon met zijn eigen cloud problemen had/heeft, bij het zoeken naar artikelen knalde regelmatig de browser eruit, dat was pas na invoering van cloudcomputing. Natuurlijk, de wet van remmende voorsprong, wie later in deze techniek gestapt is heeft het waarschijnlijk makkelijker.

Wat heet een cliche, de verkoper prijst aan en heeft te vaak niet voldoende achtergrondkennis, de techneuten mogen dan invoeren wat hij verkocht heeft, daar zit de cliche.
Al sinds vele jaren gaat dat regelmatig fout.
Computable staat vol met artikelen die dit tonen. Hoeveel produkten worden er tegenwoordig niet in de markt geplaatst die feitelijk het beta-stadium nog niet gepasseerd zijn? Bijvoorbeeld Vista.

Ik raad mijn klanten aan, nooit of te nimmer een versie te kiezen die op .0 eindigt, wacht liever op .2 dan werkt het tenminste.
Wie als eerste instapt neemt een groot risiko, dat kun je je veroorloven als je een grote afdeling hebt met specialisten, niet als je alleen een dienst afneemt en zelf de kennis niet hebt. Zo wordt "cloudcomputing" echter vaak verkocht, "u hoeft zich geen zorgen te maken wij regelen alles".
Dat klopt, inklusief de crash en het gegevensverlies.

@Jan: Ja, ik voel toch een beetje dat er een tendens is gezet door de jaren heen.

Als een piloot faalt of als een auto faalt, dan komen er onderzoeken. Als de computer of een netwerk van computer faalt, dan accepteert men dat.

Het is normaal om betaproducten op de markt te zetten en de consument als tester te gebruiken.

@Technicus: het gaat om budget bij het testen en dat is er niet genoeg dan het in de markt te doen. geld geld geld. daar is altijd een tekort aan in het kapitalistische marktmechanisme.

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.