CLOUD COMPUTING: PROVIDER UNTER DER LUPE

Amazon, Google oder Microsoft – Wer hat die richtige Anwendungsarchitektur für Cloud Computing?

Cloud Services von Amazon richtig verstehen

Kommerzielle Cloud Provider bieten sehr unterschiedliche technologische Plattformen an. Unternehmen sollten genau die Vor- und Nachteile kennen, um zu entscheiden, auf welcher Cloud sie Ressourcen einkaufen wollen.

Bislang existieren drei Architekturmodelle:

• Traditionelle Architektur

• Asynchrone Applikationsarchitektur (Informationsverarbeitung)

• Synchrone Applikationsarchitektur

Cloud-Environments bieten unterschiedliche Mechanismen, um Anwendungen zu implementieren. Die Amazon Elastic Compute Cloud (EC2) beispielsweise stellt virtuelle Machinen zu Verfügung, in die jede Art von Software installiert werden kann. Der Entwickler muss dann selbst dafür sorgen, dass die Anwendung skalierbar bleibt.

Im Gegensatz dazu bieten die Clouds von Google und Microsoft jeweils eine Programmierumgebung, (Google Aps, ein komponentenbasiertes Framework und Microsofts Azure Services Platform, ein .NET-basiertes Framework) die transparent die Skalierbarkeit einer Anwendung bereitstellt. Allerdings schränken diese Frameworks die Freiheit bei der Wahl der Anwendungsarchitektur ein.

Grundüberlegungen

Daten und Applikationen: Im ersten Schritt muss festgelegt werden, welche bestehenden Anwendungen und Datenquellen innerhalb einer Cloudlösung laufen sollen. Meistens befinden sie sich innerhalb des Rechenzentrums eines Unternehmens. Deshalb muss die Cloud-basierte Lösung Zugriff auf diese Anwendungen und Datenquellen haben. Die beste Lösung in diesem Fall ist es, sie als Service zur Verfügung zu stellen, die remote aufrufbar sind. Trotzt des herrschenden SOA-Eifers haben viele Anwendungen aber noch kein Service-Frontend. Und Workarounds wie Screen Scraping sind nicht besonders elegant, erhöhen die Komplexität der Anwendung und neigen zu Fehleranfälligkeit.

Backup: Im Rahmen einer Infrastructure as a Service (Iaas) wie sie Amazon anbietet, ist es zwar möglich, traditionelle SQL-Datenbanken laufen zu lasen, dennoch müssen Backups durchgeführt werden. Da sich aber Daten und SQL Server an verschiedenen Orten befinden können, funktionieren die üblichen Backup-Mechanismen nicht. Amazons Simple Storage Service (S3) ist in der Lage, Systemdaten für ein Recovery per Backupfunktionen der Systemdatenbank selbst zu speichern. Bei einem Recovery kann die Anwendung per Snapshot gesichert werden.

Obwohl Amazon die Daten des S3-Systems intern repliziert, sollte sich ein Unternehmen nicht blind auf diese Funktionalität verlassen. Einige Startups bieten in der Zwischenzeit entsprechende Backup-Lösungen an. Amazon selbst hat mit Amazon Elastic Block Storage (EBS) eine Lösung geschaffen, die Systemdaten ohne S3 sichern kann. Wird eine Datenbank auf EBS installiert, wird sie über das Amazon interne Backup gesichert. EBS ist allerdings nicht in der Lage Backups von bestimmten Zeitpunkten zu erstellen. Dies muss ein Anwender entweder manuell machen oder mit Zusatzlösungen.