In den letzten Jahren haben Webanwendungen stark an Bedeutung gewonnen. Damit wurden viele Service-Anbieter mit dem Problem der richtigen Dimensionierung ihrer Software und Hardware konfrontiert. Start-ups beispielsweise wollen sich für eine relativ kleine Nutzergruppe zunächst keine grossen Hardware-Investitionen leisten. Andererseits können Dienste in kurzer Zeit sehr stark an Nachfrage zulegen. Da immer komplexer werdende Webanwendungen auch eine recht komplex zu wartende Infrastruktur benötigen, stiessen manche Dienste (wie z.B. Twitter) an ihre Grenzen. Eine schnelle Skalierung ist aber kein triviales Problem, betrifft sie doch Hardware, Software, Storage-Lösungen sowie Netzwerkbandbreiten. Dazu kommt, dass manche Dienste stark schwankend ausgelastet sind. Da aber die eigene Infrastruktur immer an der Spitzenlast zu dimensionieren ist, folgen teure Investitionen, besonders an Hardware. Auch die Administration wird sehr komplex und kostspielig. Teure Initial-Investition in Hardware und Bandbreiten stellen für Start-ups mit unklaren Erfolgsaussichten natürlich ein Problem dar.
Selbst wenn man kein Start-up-Unternehmen leitet, ist das Betreiben eigener Hardware unter Berücksichtigung von Skalierbarkeit, Bandbreiten, Ausfallsicherheit, Security usw. alles andere als einfach. Was mit einem kleinen Server beginnt, wächst oft nach einiger Zeit zu einer schweren Belastung – besonders wenn Administration und Wartung grosser IT-Anlagen nicht in der Kernkompetenz der Firma oder der Organisation liegen. Viele IT-Serviceanbieter sind daher immer weniger bereit, sich mit komplexer und fehleranfälliger Hardware zu belasten. Dies ist oft nicht das Kerngeschäft und macht den Betrieb der eigentlichen Services nur schwieriger.
Grafik: So funktioniert Cloud Computing
In diesem Artikel werden Amazons EC2 sowie Googles AppEngine näher diskutiert. Diese beiden bieten einerseits einen guten Überblick über die Bandbreite der momentan verfügbaren Services und sind andererseits die zur Zeit dominierenden Spieler am Markt.
Interessant ist die Entstehungsgeschichte dieser beiden Cloud-Services: Amazon und Google sind bekannte E-Commerce-Anbieter, die gleichzeitig über die Jahre eine leistungsfähige Basis-Infrastruktur zunächst für ihre eigenen Services aufgebaut haben. Daher ist deren Angebot nicht nur von theoretischen Cloud-Computing-Überlegungen getrieben oder «from scratch» entwickelt, sondern eigentlich von der anderen Seite her entstanden: beide benötigen eine mächtige Cloud-Computing-Infrastruktur für ihre eigenen Anwendungen. Diese etablierten Dienste werden nun an andere Kunden «vermietet». Dies hat positive und negative Effekte: Einerseits ist diese Infrastruktur erprobt und leistungsfähig, andererseits ist die Basis proprietär und nur schwer auf andere Anbieter portierbar.
Das Google-Angebot ist eher «monolithisch», bei Amazon können verschiedene Services der «Cloud» auch getrennt verwendet werden, beispielsweise die verschiedenen Storage-Services wie S3.
Das Herz der Amazon-Cloud ist die Möglichkeit, virtuelle Maschinen in der Cloud zu konfigurieren und zu starten. Dies erfolgt über sogenannte Amazon Machine Images, für deren Verwaltung Webservices zur Verfügung gestellt werden. Dabei können innerhalb von Minuten neue virtuelle Server gestartet werden, wenn der Bedarf gegeben ist; ebenso schnell lassen sie sich wieder entfernen.
Amazon bietet auch eine «Bibliothek» von (Linux-) Images für verschiedene Anwendungsfälle an und erleichtert damit die initiale Konfiguration. Man hat bei diesem Dienst eine vollständige Linux-Maschine mit Root Access und kann darauf beliebige Services laufen lassen. Damit unterscheidet sich EC2 deutlich von der Google AppEngine. Dies hat Vor- und Nachteile: Einerseits ist die Flexibilität natürlich sehr hoch, andererseits muss man sich um die Skalierung der eigenen Anwendung auf ganz herkömmliche Weise selbst kümmern. Man kann zwar beliebig viele virtuelle Server in der Cloud starten, aber die Skalierung der Applikationsserver, Load-Balancer, Datenbanken etc. muss man selbst konfigurieren.
Amazon bietet eine Reihe von Services an, die zum Teil sowohl für Anwendungen in der Cloud als auch für externe Anwendungen verwendet werden können. Darunter findet man drei Storage-Module: S3, SimpleDB und Elastic Block Store.
S3 ist vielleicht der bekannteste Storage-Mechanismus: Organisiert in sogenannten «Buckets» kann man Daten («Objekte») eher grober Granularität ablegen und über eine Webservice-API verwalten. S3 verhält sich ähnlich wie ein Remote-Fileserver.
SimpleDB ist eine einfache Datenbank, in der Daten zwar strukturiert, aber ohne explizites Schema abgelegt werden. Daten werden in Datensätzen organisiert, wobei jeder Datensatz über einen Primärschlüssel verfügt sowie über eine Reihe Felder. Felder sind im Gegensatz zu einer relationalen Datenbank nicht von einem bestimmten Datentyp, sondern erlauben das Erfassen von «Listen».
Der Vollständigkeit halber soll auch der Elastic Block Store nicht vergessen werden: Dabei handelt es sich um einen Low-Level-Storage-Mechanismus, in dem man Devices anlegen und auf diese auf Block-Ebene zugreifen kann. Man kann EBS-Devices mit beliebigen File-Systemen formatieren oder als Datenbank-Devices verwenden. Die Abrechnung erfolgt nach Datenmengen und Bandbreiten.
Beim Amazon SimpleQueue Service handelt es sich um eine vergleichsweise einfache, aber skalierbare Message Queue Implementation (vergleiche auch Infoweek-Artikel «Enterprise Middleware mit ActiveMQ» in Ausgabe 14/2007). Mittels Queues können hier Nachrichten zwischen verschiedenen Anwendungen ausgetauscht und somit verschiedene Systeme locker gekoppelt integriert werden.
Das Konzept der Google AppEngine unterscheidet sich deutlich von Amazons EC2. Hier können keine Linux-Images erstellt werden, sondern «nur» Python-Anwendungen. Für Daten muss die Google-Datenbank verwendet werden (dabei handelt es sich um eine einfache, nicht-relationale Datenbank, was das Portieren vieler bestehender Python-Anwendungen nicht ganz einfach macht). Tatsächlich beantwortet die AppEngine nur http-Requests: Wenn ein Request kommt, wird die zugewiesene eigene Python-Methode aufgerufen und der Reply an den Client zurückgesendet (es können auch beliebte Web-Frameworks wie Django eingesetzt werden). Die AppEngine erhöht aber die Anzahl der Prozesse der eigenen Anwendung dynamisch, wenn die Nachfrage steigt. Dasselbe gilt für die Datenbank-Performance.
Auf der einen Seite ist das Google-Angebot also wesentlich unflexibler als die Amazon-Dienste, auf der anderen Seite (und dies ist für viele Anwendungsfälle sicherlich ein grosser Vorteil) «versteckt» Google die Skalierung vor dem Programmierer: Er entwickelt eine Python-Anwendung mit der Google-Database, und Google kümmert sich um die Skalierung. Bei EC2 hingegen muss man sich im Endeffekt selbst um die Skalierung kümmern (Load Balancer ...) sowie eventuell auch um die Datenbankadministration, wenn man SimpleDB oder S3 nicht verwenden will. Das bedeutet, dass man für Anwendungen in der AppEngine wesentlich weniger Administrations-Aufwand und Komplexität hat, dafür aber auch weniger Flexibilität als in EC2.
Für kleinere Anwendungen ist AppEngine frei, aber grundsätzlich ist dies kein Gratis-Service von Google, sondern es wird auch hier je nach Bedarf bezahlt.
Der Fluch der Skalierung?
Nun sollte allerdings nicht vergessen werden, dass Skalieren eventuell auch recht teuer werden kann. Einerseits ist oft nicht leicht vorhersehbar, wie stark ein eigener Service nachgefragt wird (und wie hoch die Kosten daher werden). Betreibt man eine eigene Infrastruktur und wird vielleicht sogar Opfer einer Denial-of-Service-Attacke (DOS) oder eines Programmierfehlers, der beispielsweise unmässig viele Datenbankabfragen absetzt, so stösst man bald an das Limit der eigenen Hardware. Dies mag unerfreulich sein, aber der Schaden bleibt begrenzt.
Ist die Anwendung aber beispielsweise in der AppEngine implementiert, so skaliert Google in grossem Massstab weiter, und man zahlt dann kräftig für den verbrauchten Traffic und Rechenzyklen der DOS-Attacke oder des Programmierfehlers. Hier wird die Zukunft hoffentlich bessere Konfigurationsmöglichkeiten und Diagnose-Tools bieten.
Mit Cloud-Services wie Amazon EC2 und Google AppEngine wird mit Sicherheit ein neues Kapitel in Anwendungsentwicklung und -hosting aufgeschlagen. Ich bin überzeugt davon, dass in einigen Jahren die meisten (Web-) Anwendungen in derartigen Cloud-Services laufen werden. Andererseits muss man sich im klaren darüber sein, dass Serviceanbieter wie Amazon oder Google eine sehr zentrale Position bekommen. Das heisst, man gerät hier doch in eine starke Abhängigkeit von deren Diensten und Konditionen.
Dies ist ein besonderes Problem, weil es noch keine «neutralen» und offenen Standards gibt, die einen Wechsel zwischen Anbietern leicht ermöglichen würden. Es gibt zur Zeit nur eine Handvoll an kommerziellen Anbietern, die man als vertrauenswürdig bezeichnen kann, die aber alle mehr oder weniger proprietäre Angebote haben. Es gibt allerdings erste Open-Source-Projekte wie beispielsweise Eucalyptus: Dieses Projekt versucht, die Amazon-EC2-Interfaces zu implementieren und damit den Wechsel von der Amazon-Plattform hin zu einer Open-Source-Lösung zu ermöglichen.
Die genannten Angebote kann man im Prinzip schon als recht stabil und solid bezeichnen (obwohl Amazon EC2 als Beta und Google AppEngine als Preview bezeichnen), aber es gibt bisher noch wenig Erfahrung damit in der Entwickler-Community. Das Schreiben von skalierenden Anwendungen kann mit Cloud-Services einfacher werden, aber entsprechendes Design ist immer noch notwendig (besonders bei Angeboten wie EC2). Hier sind also sicher noch viele Fragen offen.
