Der AWS-Ausfall und seine Folgen

Amazon - Vorreiter in Sachen Cloud-Computing - hatte gestern einen Ausfall in einem Rechenzentrum. Was genau passiert ist, möchte ich hier nicht erläutern, da es dbzgl. bereits andere Newsmeldungen gibt.

Mich interessieren eher die Folgen. Es war zu lesen, dass diverse Dienste wie Foursquare und Livefyre ausgefallen waren und ich frage mich da doch direkt: Was haben die Jungs an Cloud nicht verstanden? Cloud heißt ja nicht nur, dass man mal eben kurz skalieren kann (obwohl das schon einer der größten Faktoren ist). Nein, es heißt auch, dass man seine Infrastruktur ohne große Anschaffungskosten weltweit gut verteilen kann. Warum sollte also Foursquare für uns in Europa ausfallen, wenn es hier doch auch ein AWS-Rechenzentrum gibt? Und selbst wenn es ausfällt, ja dann kann man dies dank diverser von Amazon angebotener Lösungen in andere RZs verteilen. Ohne große Mehrkosten.

Natürlich ist für diese verteilte Lösung ein bisschen mehr Aufwand notwendig, denn man kann ein Image für das US-EAST-RZ nicht im US-WEST-RZ oder EU-RZ verwenden. Alternativ kann man aber dank Automatisierung die Erstellung dieser Images für alle Rechenzentren erstellen.

Was ich aber eher glaube: Die Anwendungen sind nicht Cloud-fähig. Viele Anwendungen werden einfach blind programmiert, ohne das Wachstum zu bedenken. Würde man Foursquare auf alle Rechenzentren verteilen, wäre es sinnvoll, auch in allen RZs wegen der schnelleren Anbindung entsprechende Datenbank-Server zu positionieren. Diese widerum müssten sich untereinander synchronisieren. Diese Synchronisierung ist zwar ein gelöstes, aber leider sehr komplexes Thema, worum sich viele Webentwickler gerne drücken. Ich auch. Deswegen benutze ich die Google App Engine, weil sich die Google-Entwickler schon um dieses Problem gekümmert haben. Aber natürlich gibt es auch die Möglichkeiten der Datenbanken, die es zu nutzen gilt. Da wäre zum Einen CouchDB zu erwähnen, die solche Probleme auch bereits gelöst haben und die für den Einsatz in der Cloud äußerst gut geeignet sind.

Aber viele sind eben faul - und für diese Leute ist die Cloud nicht verteilt, sondern ein Rechenzentrum was schneller wachsen kann, als der übliche Hoster. Über diese Schwelle muss man springen, damit Cloud nicht einfach nur ein Spielzeugbegriff wird.


Kommentare

s0enke

Uhm. Naja faul würde ich nicht sagen. Meistens wächst man schneller als man denkt, da gibts dann andere Probleme als den “relativ” unwahrscheinlichen GAU-Fall. Ist ja auch ne Risikoentscheidung (mal nen Tag down vs. sehr komplexe verteilte Systeme (Stichwort: CAP theorem) bzw auch eine (Opportunitäts-)Kostenentscheidung. Son Spare-Datacenter kostet ja auch Geld.

PAAS Provider wie Heroku oder PHPFog sollten da natürlich eher ne Disaster Recovery (DR) strategie haben als foursquare oder sonstwas. Dass DIE keine Strategie hatten, finde ich schon ziemlich fail, weil es deren Core-Business ist.

Dass dir mit der GAE natürlich die Verteilung auf mehrere POPs abgenommen wird, ist aber auch bei dir eine Risiko- und Kostenentscheidung. Denn GAE ist vendor-lock-in (PAAS). Nutzt man nur IAAS, kann man es besser abstrahieren (zB ist der Wechsel auf eine andere Cloud mit den richtigen Tools (config-management) “recht” einfach, hat aber weniger Disneyland.

Sollte man mal ausführlicher diskutieren :-)

Heiner Wolf

Das war ja nicht nur ein Ausfall, was mal passieren kann, sondern angeblich sind mehrere Availability Zones ausgefallen. Das darf nicht passieren.

Es gibt ja Trends, dass man Daten nicht mehr auf Platten schreibt, sondern in verteilen Rechenzentren nur im Speicher behält weil schneller und genauso sicher. Es kann immer mal in einem RZ der Strom ausfallen, aber die Daten bleiben erhalten, weil sie noch an 2 anderen Standorten sind. So zumindest die Theorie. Die Theorie kann man sich jetzt stecken. Availability Zones bei AWS leisten nicht das was sie behaupten. Der Traum ist ausgeträumt. Lang lebe die feste Platte.

Kommentar schreiben

Jeder Kommentar wird vor der Veröffentlichung überprüft.