Mehr über ec2

Cluster, Fail-Over, High-Availabilty waren vor ein paar Jahren noch amüsante Begriffe, die mit zwei, drei Servern abgetan wurden. Heutzutage haben wir aber andere Dimensionen erreicht. Es beschränkt sich nicht mehr nur auf den Bankenbereich, dass existenzimmanente Applikationen einfach funktionieren müssen. Viel mehr Unternehmen sind im Schwitzkasten der IT, sind abhängig von Verfügbarkeit.

Was passiert, wenn hunderttausend Anfragen gleichzeitig auf einen Server prasseln? Er stirbt. Danke, Sun! Für OpenSolaris! Danke, Sun für Niagara-Server! Selbst eine X4200 ist ein Geschenk des Himmels. Aber eine solche Last kann ein Server nicht mehr aushalten. Aber will ich wirklich die extremen Peaks dauerhaft bezahlen müssen? Diese Anforderungen müssen über andere Mittel abgewickelt werden.

Amazon tritt mit ec2 auf den Plan (verdammt, ich kaufe mittlerweile alles bei Amazon, jetzt auch Server). Und ebenfalls interessant: S3 und SQS. Google mit AppEngine ebenfalls. IBM auch. Auch Sun hat in bekannter Manier den Markt früh mit network.com erkannt und, naja, man hat ja einen Ruf zu verlieren,  falsch eingeschätzt.

Das Thema ist Cloud Computing.

Wie kann ich schnell und flexibel von einem Server zu hunderten skalieren?

AWS ist eine mögliche Antwort. Nur Amazon ist nur ein Teil. Gut und schön, wenn ich schnell mehrere hundert Server hochziehen kann. Was aber wenn Daten ausgetauscht werden müssen?

Datenbank? Die wird schnell zum Bottleneck. Denn welche bezahlbare Datenbanklösung kann linear skalieren? Und das auch noch in einem EC2 Umfeld? Postgres? Nope. MySQL? Nope (abgesehen davon, dass ich’s immer noch nicht für eine Datenbank halte). Oracle? Ähm, bezahlbar war auch ein Stichwort.

Was also ist die Lösung?

Die Daten müssen nach vorne gepushed werden. Aus der Datenbank in die Wolke. Die Kunst ist, die Datenbankzugriffe zu minimieren und lesende Operationen aus einem Cache oder einem Datenspace zu holen.

Details? Eine Beispielarchitektur folgt in Kürze. Watch this space :)