Verteilte Systeme - Cloud Computing

Cloud Computing: Services auf Wolken

Cloud Computing erlaubt die Bereitstellung und Nutzung von IT-Infrastruktur, von Plattformen und von Anwendungen aller Art als elektronisch verfügbare Dienste, die von verschiedenen Anbietern im Internet erbracht werden. Cloud-Ressourcen werden in der Regel virtualisiert: Der Cloud-Nutzer hat dadurch stets eine wunschgemäße, beliebige Sicht auf Ressourcen. Cloud-Angebote sind darüber hinaus dynamisch skalierbar: ein zusätzlicher oder geringerer Ressourcen-Bedarf kann schnell und ohne großen Aufwand automatisch geregelt werden. Cloud Computing folgt den Ideen des Utility Computing, d.h. es wird immer die aktuell verbrauchte Menge an Ressourcen zur Verfügung gestellt und abgerechnet. Dadurch ist eine wirtschaftliche Bedeutung entstanden; signifikante Kostenersparnisse sowie neue Geschäftsmodelle werden mit dem Cloud Computing verbunden (vergleiche [I3]).

Einführung und Definition: Vom Mainframe zur Cloud

Mit Cloud Computing erzielt ein Konzept seinen Durchbruch, das viele Trends und Technologien in sich aufnimmt und zu einer neuen Qualität verschmilzt. Die Geschichte der IT ist seit Anbeginn gekennzeichnet durch ein Wechselspiel von zentralen und dezentralen Kräften. Dabei wurde die räumliche Verteilung bzw. Anordnung von Rechenleistung durch technologische und ökonomische Rahmenbedingungen determiniert. Jeder Evolutionsschritt in der IT-Industrie erhielt durch ein vorherrschendes IT-Modell – auch „Computing Paradigma“ genannt – seine Prägung. Die Paradigmen erwachsen aus den technologischen und ökonomischen Rahmenbedingungen für die Rechen- und Netzleistung.

Die Entstehung des Phänomens Cloud Computing ist eng verknüpft mit:

• der enormen Steigerung der Rechenleistung
• der flächendeckenden Verfügbarkeit höherer Bandbreiten
• den Virtualisierungstechnologien

Als eine Synthese von IT- und Telekommunikations-Leistungen führt Cloud Computing dazu, dass – vereinfacht dargestellt – jegliche Leistung als Service erhältlich wird. Cloud Computing repräsentiert somit den Gedanken von „Services aus dem Netz“.

Die Entwicklungsschritte des Phänomens Cloud Computing werden im Folgenden kurz skizziert:

1. Großrechner (Mainframes): Am Anfang stand der Großrechner. Durch ihn wurde Rechenleistung an zentraler Stelle bereitgestellt. Die transaktionsorientierten Anwendungssysteme boten im Wesentlichen nur punktuell stattfindende Benutzerinteraktionen. Stapel- (Batch)-Verarbeitung war ein weiteres Kennzeichen ebenso wie die räumliche Nähe zum Anwender.
2. Personal Computer und Client/Server Prinzip: In den 80er Jahren rückte der vergleichsweise kleine und bürotaugliche Personal Computer (Client) in den Fokus. In Verbindung mit zentralen Servern wurde so das IT-Modell der leistungsfähigeren und flexibleren Client/Server-Systeme möglich. Hier war die Rechenleistung verteilt, je nach Funktion beim zentralen Server oder auch lokal auf dem Client beim Anwender. Das PC-Paradigma ist durch eine extreme Nähe zum Anwender (Einzelplatz-Anwender) sowie durch eine starke Dezentralisierung gekennzeichnet. Die Dezentralisierung und die damit verbundene Individualisierung erklären den Erfolg dieses Konzeptes.
3. Internet Die nächste große Welle brach in den 90er Jahren mit der Einführung des Internets an. Es entstanden wieder stärker zentralisierte Webanwendungen. Dieses IT-Modell hat den Vorzug, dass die Aktualisierung der Software an zentraler Stelle erfolgt. Die eigentliche Anwendungslogik liegt auf den Web-Servern; die Rechnerleistung des Clients wird nur noch für die Benutzerschnittstelle benötigt. Das Internet-Paradigma ermöglicht die räumliche Trennung der Rechenleistung vom Anwender und vereint zentrale wie dezentrale Aspekte.
4. Web2.0 und SOA: Seit der Jahrtausendwende befindet sich die IT-Industrie in der Transformation in eine Serviceorientierte IT-Welt. Web 2.0 lässt sich im Prinzip ebenfalls unter dem Begriff Service fassen, geht es doch hier um kommunikative Aspekte des Webs mit starker Betonung von spontaner Interaktion. Die Konzepte der Web-Anwendungen wurden zunehmend auf Geschäftsanwendungen übertragen. Web 2.0-Technologien, die auf globale Zusammenarbeit von Anwendern bei der Informationsverarbeitung setzen, halten weiter Einzug in den Unternehmen. Das gilt auch für service-orientierte Architekturen (SOA). Im Zentrum stehen hier die Komposition von Services sowie deren systematische Verknüpfung mit Anwendungen und anderen Services. Die Bündelung von IT-Anforderungen zu Services im Sinne von Service-orientierten Architekturen (SOA) verleiht der Unternehmens-IT ein hohes Maß an Agilität: Sie erlaubt es, einzelne Services voneinander zu entkoppeln und in Abhängigkeit von den Erfordernisse der Anwender flexibel neu zu kombinieren. Die lose Koppelung von Services erlaubt es, den Ort der Ausführung zu ändern, solange die Regeln für einen Service-Aufruf beibehalten werden. Damit können Software-Services an Dienstleister ausgelagert werden.
   

Web 2.0 und SOA basieren auf der räumlichen Trennung von Rechenleistung und Nutzung. Sie beinhalten einerseits starke zentrale Elemente, unterstützen und ermöglichen andererseits dezentrale Architekturen.

1. Mobilität und Verschmelzung von Geschäfts- und Privatwelt: Ein weiteres wichtiges Innovationsfeld, das im Zusammenhang mit Services zu sehen ist, sind die künftigen Entwicklungen der Endgeräte und Client-Systeme. Während hier der klassische Desktop-PC an Bedeutung verliert, wenden sich die Anwender in wachsendem Maße neuartigen Endgeräten zu – vom Smartphone über Spielkonsolen, Mediacenter, Laptop bis zum Web-Terminal. Die Herausforderung lautet hier Integration. Das bedeutet beispielsweise im Geschäftsumfeld, dass die Nutzer auf ihre E-Mails, Termine und Adressen vom Laptop, Smartphone oder Terminal aus zugreifen wollen.

Auch die Ansprüche der Konsumenten steigen; sie verlangen nach einheitlicher Bedienung aller Geräte und zunehmend auch nach zentralisierter Datenhaltung – in idealer Weise im Web –, sowie einfachem Management ihrer Benutzerkonten und Identitäten im Netz. In der modernen Arbeitswelt geht es primär um Zugriffe auf die richtigen Informationen zur richtigen Zeit in einer zunehmend mobilen Umgebung. Der Anwender benötigt Online/Offline-Arbeitsmöglichkeiten ohne Unterbrechung, wobei rollenbasierte Zugriffsrechte notwendig sind. Privat- und Geschäftswelt verschmelzen und beeinflussen sich gegenseitig. Auch aus Konsumentensicht gewinnen Services an Bedeutung. Im „Digital Lifestyle“ steht der PC nicht mehr im Mittelpunkt, sondern konkurriert mit anderen digitalen Endgeräten, wobei der Anwender einerseits die Synchronisation von privaten und geschäftlichen Informationen über verschiedene Endgeräte hinweg fordert, andererseits eine komfortable und intuitive Bedienung erwartet. Der Trend zur Mobilität bedingt die Trennung von Rechenleistung und Nutzung, denn die mobilen Endgeräte sind vergleichsweise ressourcenarm.

Trends und Geschäftsmodelle

Die Geschäftsmodelle von Cloud Computing-Anbietern stützen sich zurzeit vor allem auf ökonomische Optimierungsaspekte in der Produktion und die hochgradige Automatisierung von Dienstleistungsabläufen. Die Grundlage für erfolgreiche Geschäftsmodelle bilden partnerschaftliche Beziehungsgeflechte auf der Basis von Vertrauen in Netzwerken. Denn Teilleistungen von Cloud Services können aus unterschiedlichen Clouds bereitgestellt und bezogen werden. Damit steigen die Anforderungen an die Beherrschbarkeit und Orchestrierbarkeit unterschiedlichster Applikationen und Infrastruktur. Aus technischer Sicht wird die Integration durch Web-Standards einfacher, hingegen steigt die Komplexität hinsichtlich Prozessintegration und Service-Management. Die klassischen Systemintegratoren und IT-Beratungshäuser werden deswegen weiter gefordert sein, wenn auch nicht mehr für alle Arten von IT-Dienstleistungen und nicht in gleichem Maße.

Durch die deutlich reduzierten Einstiegskosten für die Verwendung einer professionellen IT-Infrastruktur in der Cloud eine Vielzahl von kleinen, innovativen Unternehmen, die mit minimaler Kapitalbindung und mit flexiblen Betriebskosten neue IT-Dienstleistungsangebote auf den Markt bringen können. Es entsteht so ein Cloud Computing-Ökosystem von IT-Dienstleistungsanbietern (vgl. dazu auch das z.Zt. rapide Wachstum von sog. App-Stores auf dem Mobilfunkmarkt). Anbieter fördern solche Ökosysteme, indem sie einfach zu verwendende Basis-IT-Leistungen und Middleware-Komponenten als Web-Services zur Verfügung stellen. Durch diese Ökosysteme werden auch neue Dienstleistungen wie z.B. Service Brokering und Service Aggregation, Vertrauens- und Reputationsbewertungen erforderlich.

Den Ausgangspunkt für die Ausbildung tragfähiger Cloud Computing-Business-Modelle bildet die grundsätzliche Cloud Computing-Struktur mit den Elementen „Software as a Service“ (SaaS), „Plattform as a Service“ (PaaS) und „Infrastructure as a Service“ (IaaS).

Für den Bereich SaaS ergeben sich Geschäftsmodell-Varianten auf der Basis reiner SaaS-Lösungen mit eigenständigen Architekturen. Darüber hinaus gibt es die Möglichkeit, bestehende Lizenzmodelle für Softwareprodukte in ein SaaS-Modell zu überführen oder hybride Lösungen anzubieten.

Bei „Plattform as a Service (PaaS)“ finden sich Geschäftsmodell Ausprägungen basierend auf den Leistungsentwicklungsstufen Softwareentwicklung und Bereitstellung, Software-Ablaufumgebung und einer „Full Scope Plattform as a Service“, die beide Aspekte abdeckt. In der Praxis zeigt sich, dass auch SaaS-Applikationsanbieter zusätzlich in ihrem Geschäftsmodell zumindest einige Funktionalitäten einer Softwarebereitstellungs-Plattform integrieren. Andere Geschäftsmodell-Varianten konzentrieren sich u.a. auf abgeschlossene logische Einheiten, wie z.B. Mailing- und Collaboration-Plattformen. Einige Anbieter gehen bereits dazu über, größere, geschäftskritische Anwendungen aus der Public Cloud auch in einer privaten, abgesicherten Cloud anzubieten. Sämtliche PaaS Lösungen unterstützen - in unterschiedlichem Maße – die Integration von SaaS-Applikationen via Cloud-fähiger Entwicklungsumgebung in die darunter liegende Infrastruktur. Es handelt sich in der größten Ausprägung um umfangreiche Middleware-Komponenten.

Ein weiterer Aspekt von PaaS wird zu weiteren Geschäftsmodell- Varianten führen: für eine verbrauchsabhängige Abrechnung sind Funktionalitäten wie Messung, Überwachung (Monitoring) und Rechnungsstellung unverzichtbar. Diese entscheiden darüber, wie stark ausgeprägt die verbrauchsabhängige Bezahlung ist.

Die neue Art von Applikationen

Während man immer noch auf fundamental neue Applikation wartet die durch das Cloud Computing entstehen, existieren doch heute schon mehrere wichtige Klassen von Applikationen, welche durch das Cloud Computing attraktiver werden und weiter zu dem Momentum beitragen, welches neue Dienste produzieren wird. Als Jim Gray die technologischen Trends im Jahr 2003 untersuchte [P1] kam er zu dem Schluss, dass es aus ökonomischer Sicht notwendig ist, Daten nahe der Applikation zu speichern, denn die Kosten für Wide-Area-Networking fallen langsamer und bleiben verhältnismäßig hoch verglichen mit anderen Hardware Kosten in der IT. Obwohl sich die Hardware Kosten seit dem verändert haben, die Idee seines „Breakeven Points“ ist immer noch aktuell. Grays Einsichten sind immer noch ein guter Ausgangspunkt, um zu untersuchen, welche Art von Applikationen gute Möglichkeiten anbieten, um Cloud Computing weiter voranzutreiben.

Tim O’Reilly glaubt, dass „die Zukunft jenen Services gehört, welche in Echtzeit mit Informationen Antworten die entweder von den Usern selbst oder von Sensoren zur Verfügung gestellt werden.“ (siehe [P2]). Solche Services würden vorzüglich innerhalb einer Cloud implementiert und aufgestellt werden, nicht nur, weil diese hoch verfügbar sein müssen, sondern auch, weil derlei Dienste in der Regel auf großen Datenmengen basieren die wiederum am bequemsten in einem großen Datenzentrum gespeichert werden. Dies gilt besonders für Services die mehrere Datenquellen und Services miteinander kombinieren, wie z.B. Mashups. Obwohl nicht alle mobile Endgeräte zu 100% online sind, muss dies kein Hindernis für Cloud Services sein, denn dieses Problem wurde bereits adressiert und effektive Lösungen wurden entwickelt (z.B. Google gears).

Obwohl Cloud Computing meist mit interaktiven SaaS in Verbindung gebracht wird, eröffnet es auch einzigartige Möglichkeiten für paralleles Batch-Processing und Analyseaufgaben welche Terabytes an Daten durchforsten und Stunden brauchen um abgearbeitet zu werden. Solange ausreichend Parallelitäten in der Datenstruktur vorkommen, können die neuen kosteneffizienten Möglichkeiten einer Cloud, hunderte von Computern kurze Zeit miteinander zu verbinden, billiger und effektiver sein, als wenige Computer für lange Zeit zu beschäftigen. Peter Harkins hat z.B. bei der Washington Post 200 EC2 (Amazon Computing Service) Instanzen (gleich 1.407 Serverstunden) benutzt, um 17.481 Seiten von Hillary Clintons Reisedokumenten in ein freundlicheres WWW Format zu bringen und das 9 Stunden nachdem diese veröffentlicht wurden (siehe [P3]). Programmabstraktionsmechanismen wie Googles MapReduce [P5] oder dessen Opensource Gegenstück Hadoop [P4] erlaubt es Programmierern solche Aufgaben zu formulieren und gleichzeitig die Komplexität der Choreographie zu verstecken die entsteht, wenn man über hunderte von Cloud Computing Rechnern verstreute Aufgaben parallel zueinander ausführt.

Tatschlich ergreift die Firma Cloudera (siehe [P6]) die Gelegenheit, genau in diesem Bereich ein Geschäftsmodell aufzubauen. Um auf Grays Kosten/Nutzen Analyse zurückzukommen, muss man die Kosten für das Speichern von großen Datenmengen in Datenzentren abwägen gegen die höhere Geschwindigkeit der Datenanalyse. Das Geschäftsmodell der Amazon Web Services hat genau diese Rechnung im Sinn. Datenanalyse rückt immer mehr ins Zentrum. Während früher die großen Datenbankanbieter sich auf Transaktionsmanagement konzentrierten, wird das in diesen Tagen immer weniger wichtig. Ein immer größerer Anteil an Rechenressourcen wird dafür aufgewendet um Kundenverhalten, Produktionsketten, Kaufverhalten und Produktranking zu verstehen.

Während das Volumen an Datentransaktionen immer langsamer wächst steigt der Bedarf an Entscheidungshilfen basierend auf gespeicherten Informationen rapide an. Das verschiebt auch die Gewichtung beim Datenprocessing von Transaktionsmanagement Richtung Businessanalyse. Und letzteres ist die Erweiterung von rechenintensiven Desktopapplikationen. Die aktuellen Versionen von Mathematik-Software wie MatLab oder Mathematica können Cloud Computing einsetzen um komplexe rechenintensive Evaluationen durchzuführen. Andere Desktopapplikationen können in gleicher Weise von dieser unkomplizierten Ausdehnung in die Cloud profitieren. Wie bereits gesagt ist hier der Vergleich von Kosten die durch das Rechnen in der Cloud entstehen plus der Kosten des Übertragens der Daten in und aus der Cloud mit der Zeitersparnis durch die Benutzung der Cloud. Simulationen oder symbolische Mathematik bei denen Unmengen an Datenrecords bearbeitet werden sind ein anderes Beispiel. Das Modell hier ist die Speicherung der Daten und die Berechnung in der Cloud und der Präsentation der Ergebnisse am Rechner des Benutzers. Dabei muss eine entsprechende Bandbreite für die Kommunikation von Desktop in die Cloud und vice versa gegeben sein. Offline Rendering oder 3D Animationen sind ein weiteres Beispiel. Bei einer kompakten Beschreibung der Objekte und der Bestimmung der Beleuchtungscharakteristiken wird das rendern einer 3D Szene zu einem extrem parallelisierbarem Prozess mit einem hohen Rechenzeit zu Datenvolumen Verhältnis.

Der Einsatz anderer Applikationen, welche eigentlich gute Kandidaten für die Parallelität und Elastizität der Cloud wären, wird durch deren Datenübertragungskosten und den unumstößlichen Grenzen bezüglich Übertragungszeiten und -Verzögerungen vereitelt. Z.B.: Während die Datenanalysen um Langzeitprognosen für finanzielle Entscheidungen ein typisches Szenario für die Cloud abgeben, erfordert der Handel an der Börse eine Aktualität der Ergebnisse oft sogar im Millisekundenbereich. Das kann die Cloud zur Zeit nicht bieten. Solange die Übertragungskosten und Übertragungsverzögerungen nicht gesenkt werden können, sind solche Applikationen keine Kandidaten für Cloud Computing (vergleiche [I3]).

Utility Computing

Jede Applikation braucht Computation- oder Rechenmodell, ein Speichermodell und, auch wenn diese nur auf triviale Weise verteilt sein sollte, ein Kommunikationsmodell. Das statistische Multiplexing, welche notwendig ist, um Elastizität und den Eindruck einer schier unbegrenzten Kapazität an Ressourcen zu vermitteln erfordert, dass diese Ressourcen virtualisiert werden. Dadurch werden die Implementation dessen, wie diese gemultiplexed und verteilt werden vom Programmierer verborgen. Verschiedene Utility Computing Angebote sollten deswegen diesbezüglich unterschieden werden, basierend auf dem Grad an Abstraktion der dem Programmierer präsentiert wird und den Möglichkeiten Ressourcen zu managen.

Amazons EC2 Service ist an einem Ende des Spektrums. Eine EC2 Instanz sieht etwa so aus wie ein Stück Hardware und Benutzer können quasi den gesamten Software Stack kontrollieren, vom Kernel-Layer aufwärts. Die angebotene API ist dabei eher „schlank“, ein paar Duzend API Aufrufe, um die virtualisierte Hardware anzufordern und zu konfigurieren. Es gibt a priori keine Einschränkungen bezüglich der Applikationen die auf einer EC2 Instanz laufen können. Das untere Ende der Virtualisierung, die bloßen CPU Zyklen und die IP Konvektivität erlauben den Entwicklern welchen Code auch immer zu implementieren. Dadurch wird es für Amazon allerdings sehr schwierig, automatische Skalierbarkeit und Failover zu gewährleisten, denn die Funktionalität und Steuerung die man braucht, um Replikation und andere State-Management Abzudecken sind stark abhängig von der Applikation selbst. Deshalb bietet Amazon Web Services eine Reihe von High-Level Managed Services an, darunter mehrere verschiedene Speicher und Persistenzmanagement Dienste in Verbindung mit EC2, z.B. SimpleDB. Allerdings haben diese Zusatzservices eine hohe Verzögerung beim Aufruf und bestehen aus nicht standardisierten APIs und werden deswegen nicht so intensiv verwendet wie Angebote der Amazon Web Services.

Am anderen Ende des Spektrums, quasi als Gegenthese zu den Amazon Webservices, sind applikationsorientierte Plattformen, wie die Google AppEngine oder Force.com, eine SalesForce Business-Software Entwicklungsplattform. AppEngine ist ausschließlich auf traditionelle Web-Applikationen ausgerichtet welche eine strenge Trennung zwischen Stateless Computation Tier und Statefull Storagetier erzwingt (siehe 3-Tier Architektur).

Außerdem wird von AppEngine Applikationen erwartet, dass sie Request-Response orientiert aufgebaut sind und dass die CPU Zeit die sie verbrauchen streng rationiert und auf die Request Verarbeitung aufgeteilt wird. Das eindrucksvolle automatische Skalieren, die Hochverfügbarkeitsmechanismen und der proprietäre Datenspeichermechanismus MegaStore (verwendet Google BigTable, zum verteilten Speichern strukturierter Datensätze), welche allen AppEngine Applikationen zur Verfügung stehen, basieren alle auf den eben genannten Einschränkungen. AppEngine (im Gegensatz zu EC2) ist nicht geeignet, um beliebige Applikationen umzusetzen. Auf ähnliche Weise wurde Force.com entwickelt, um Business Applikationen zu unterstützen, die die salesforce.com Datenbank verwenden und nichts anderes.

Microsofts Azure nun liegt in der Mitte des Spektrums zwischen Flexibilität und Programmierkomfort. Azure Applikationen verwenden die .Net Bibliotheken und werden für die Common Language Runtime (CLR) kompiliert, die programmiersprachenunabhängige Laufzeitumgebung für .Net. Das System unterstützt das Programmieren beliebiger Applikationen eher als die Fertigstellung von Programmen die einer bestimmten Kategorie angehören. Wie bei .Net können sich die nutzer die Programmiersprache aussuchen, nicht aber das Betriebssystem, auf dem die Programme laufen sollen. Die Bibliotheken bieten einen gewissen Grad an automatischer Netzwerkkonfiguration und Failover und Skalierbarkeit an, sie fordern vom Entwickler aber auf deklarative Weise die Eigenschaften der Applikation anzugeben, um dies erreihen zu können. Azure steht in der Mitte zwischen den virtuellen Maschinen von Amazons EC2 und der applikationsspeziefischen Umgebung von Googles AppEngine.

Die Tabelle unten fasst die bisher dargestellten Eigenschaften zusammen. Die Diskrepanz zwischen skalierbarem Datenspeicher basierend auf einer (proprietären) API und dem Funktionsreichtum von SQL bleibt ein offener Punkt und eine Streitfrage der Forschung. Amazon hat zwar damit begonnen Oracle Datenbanken auf Ihren Webservice System anzubieten, allerdings ist dies aus ökonomischer lizenzpolitischer Sicht kein Modell das gut zum Cloud Computing passt.

Nun, welches der eben vorgestellten Modelle wird das Rennen machen? Diese Frage kann man analog zu der Situation bei Programmiersprachen und Frameworks betrachten. Low-level Sprachen wie C oder gar Assembler erlauben die Kontrolle und enge Kommunikation mit dem „blanken Metall“, der Hardware, aber wenn der Entwickler eine Webapplikation schreiben soll, dann sind die Mechanismen von Socket Management, Anfragenverteilung und so weiter nur sehr mühsam zu Kodieren, selbst dann wenn gute Bibliotheken zu Verfügung stehen. Am anderen Ende der Skala stehen dann High-Level Frameworks wie Ruby on Rails, diese machen solche Mechanismen transparent für Entwickler sind aber nur dann von Nutzen, wenn die Applikation der Request-Response Abstraktion und anderen Regeln von Rails entspricht. Für jegliche Abweichung vom Üblichen muss man tief ins Framework abtauchen und die Aufgaben sind nur sehr schwer oder überhaupt nicht zu kodieren. Kein Ruby Entwickler würde die Überlegenheit von C für den Einsatz auf bestimmten Gebieten anzweifeln, gleiches gilt auch für C Programmierer. Die Antwort auf unsere eben gestellte Frage sollte also lauten, dass es für bestimmt Einsatzgebiete bestimmte Utility Computing Systeme gibt, die für die eben gestellte Aufgabe optimal sind. Alle haben Ihre Vorteile, abhängig vom Problem das bearbeitet werden soll.

Die Analogie der Computersprachen kann man fortführen: So wie High-Level Sprachen mit Hilfe von Low-Level Sprechen implementiert werden, können stark verwaltete automatisierte Plattformen auf kaum verwalteten manuell steuerbaren Plattformen laufen. Z.B. könnte AppEngine auf Azure oder EC2 implementiert und deployed werden und Azure könnte man auf EC2 aufsetzen. Natürliche stellen AppEngine und Azure jeweils viele proprietäre Funktionalitäten zur Verfügung, welche man dann auf der jeweils unterliegenden Plattform nachprogrammieren müsste, eine komplexe („ehrerfüllende“ ;-) Aufgabe.

Tab. 2: Vergleich von Utility Systemen (Quelle [I3])

	Amazon Web Services	Google AppEngine	Microsoft Azure
Rechen-modell, Virtual Machine (VM)	X86 CPU Instruktionen (ISA) via Xen VM, a Virtual Machine Monitor for CPU Instruktionsets, Skalierbarkeit ist möglich, aber die Entwickler müssen die „Maschinerie“ dafür selbst schreiben oder Plattformen wie RightScale benutzen	Eine vorgegebene Programmstruktur und ein API Framework. Vom Programmierer in Python geschriebene Handler. Alle persistenten Daten sind in MegaStore außerhalb des Python Interpreters gespeichert, in MegaStore (Indizierte Datenrecords) Hoch und runter skalierbar für Rechenressourcen und Datenspeicher, mit Failover für Server und Netzwerk, konform zur 3-Tier Middleware Architektur	Microsoft Common Language Runtime CLR VM. Abstrakter Zwischencode im .net Managed Environment. Die Maschinen können provisioniert werden basierend auf deklarativen Statements, z.B.: Angaben darüber welche Rollen repliziert werden können; load balancing geschieht automatisch
Speichermodell	Unterstützt eine Reihe von Modellen, von Block Store (EBS) bin hin zu Augmented Key/Blob Store (SimpleDB), abhängig davon ist das automatische Skalieren, kein Skalieren oder Verteilen bei EBS bis hin zu vollautomatischen Methoden bei SimplDB oder S3. Gleiches gilt für die Zusicherung für Datenkonsistenz. Die APIs sind standardisiert wie bei EBS, oder proprietär.	MegaStore/BigTable	SQL Datenservice, eine reduzierte Version von SQL Server, oder Azure Storage Service
Netzwerkmodell	Eine deklarative Spezifikation der IP Leveltopologie, Security Groups bestimmen, welche Knoten Kommunizieren können, Availability Zones abstrahieren unabhängige Netzwerk up und downtimes, Dynamische („elastische“) IP Adressen gewähren durchgehend routbare Netzwerknamen	Fixe Topologie um die 3-Tier Architektur abzubilden Hoch und Runter Skalieren geschieht automatisch und ist transparent für den Programmierer	Automatisch basierend auf den vom Programmierer deklarativ erstellen Konfigurationen bezüglich Application-Components (Rollenvergabe)

Die Top 10 Probleme und deren Lösungen

Folgende sind die Top 10 Probleme des Cloud Computing:

1. Verfügbarkeit der Services

LÖSUNG: Benutzen von mehreren Cloud Computing Providern. Benutzung von Elastizität (Multiplexing etc,) um z.B. DDOS Attacken abzuwehren.

2. Data Lock-In: Wenn man Daten einmal in bestimmter Form für einen bestimmten Service abgelegt hat, dann wird es schwer den Service oder den Provider zu wechseln, da andere Services zwar das gleiche tun aber Ihre Daten anders strukturieren, man wäre dann einem Service Provider ausgeliefert. Siehe Microsoft Office vs. Rest der Welt Problem.
   
   LÖSUNG: APIs müssen standardisiert werden. Kompatible Software muss produziert werden, um „Surge Computing“ das problemlose Wechseln zwischen privaten und öffentlichen Clouds zu ermöglichen

3. Datengeheimnis und Validierung

LÖSUNG: Der Einsatz von Verschlüsselung, VLANs und Firewalls. Um nationales Recht gültig zu machen sollte ein geographischer Datenspeichermechanismus zum Einsatz kommen (Gegenbeispiel: Das Google Data Center in Panama, Warum dort?)

4. Engpässe bei der Datenübertragung, in Bezug auf Geschwindigkeit und Kosten
   LÖSUNG: Große Backups und Archivdaten können via Post auf Disks verschickt werden. Die Wide Area Network Kosten sollten reduziert werden und LAN Switches mit hoher Übertragunsrate sollten angeschafft werden.

5. Unbestimmte Leistungszusicherungen, es kann nicht immer genau gesagt werden, wie schnell die Konten in der Cloud brauchen, um ein Ergebnis zurückzuschicken.
   LÖSUNG: Die virtuellen Maschinen sollten verbessert werden; Flash Memory sollte eingesetzt werden, die Scheduling Mechanismen der VMs müssen optimiert werden.

6. Fehlende skalierbare Datenspeicherung
   LÖSUNG: Diese Funktion muss noch entwickelt werden

7. Hohe Wahrscheinlichkeit von Fehlern in sehr großen verteilten Systemen.
   LÖSUNG: Ein Debugger muss entwickelt werden der verteilte VMs beobachten kann und selbst darauf aufbaut.

8. Schnelles Skalieren
   LÖSUNG: Ein Auto-Skalierer muss entwickelt werden, der Machine Learning einsetzt.

9. „Reputation Fate Sharing“, „Ist der Ruf erst ruiniert...“, Wie kann man einen schlechten Ruf in der Cloud wieder loswerden, z.B. wenn man dynamische IPs bekommt, die auf einer Blacklist sind, oder was wenn man in einem Subnetz in dem auch ein Spam-Computer ist.
   LÖSUNG: „Reputation-Guarding“, Reputationsüberwachung sollte ähnlich wie bei eMailing eingesetzt werden.

10. Software Lizenzierung
    LÖSUNG: Pay-for-use Lizenzen oder Bulk-Use Lizenzen

Die Wolke von Morgen

Eine lang geträumte Vision von Computern als Gebrauchsgegenstand nimmt langsam Form an. Die Flexibilität eines solchen Gebrauchsgegenstandes entspricht dem Bedarf, Business Services dem Kunden direkt über das Internet anzubieten. Früher brauchte es Jahre, um ein Geschäft auf mehrere Millionen Kunden wachsen zu lassen, heutzutage kann das in wenigen Monaten geschehen (vergleiche [I3]).

Für Cloud Provider besteht nun die Möglichkeit, riesige Datenzentren für Bedarfs-Computing, Datenspeichern und Netzwerken anzubieten, basierend auf einem Pay-as-you-Go Modell. Und das mit Kosten die geringer sind als die für mittelgroße Datenzentren. Man kann Gewinn machen kann indem man mit statistischem Multiplexen über große Kundengruppen hinweg die Ressourcen optimal einsetzen kann. Für die Kunden bietet die Cloud den Vorteil, dass man nicht in teure Hardware und Datenzentren investieren muss, zumal man dessen Service nur gelegentlich benötigt. Zu anderen Zeiten würde dann die eigene IT nur Kosten erzeugen, ohne Verwendung zu finden. Selbst große Unternehmen wie Zeitungen (Washington Post), die Filmindustrie (Pixar) oder große Universitäten nutzen bereits diese Möglichkeit. Firmen wie Suchmaschinen Provider können ihr Geschäft erweitern und mit der Masse an Kunden bei niedrigen Gewinnmarchen Profit erzielen. Außerdem haben derlei Unternehmen ohnehin bereits die Erfahrung und die notwendige Hardware für Ihr Kerngeschäft. Warum diese Services also nicht auch für Kunden öffnen.

Deswegen würden Software Entwickler gut daran tun, ihre Systeme der nächsten Generation in die Cloud zu geben, dort kann man über hunderte oder gar tausende von virtuellen Maschinen skalieren, während man sich sonst mit nur einer Maschine begnügen müsste.

Applikationen der Zukunft werden wahrscheinlich aus einem Teil bestehen, der auf einem Client (Desktop, Mobile, etc.) läuft, und einem Teil, der in der Cloud ausgeführt wird. Der Cloud-Teil muss beides, schnell hoch und runter skalieren können, was zu einer neuen Anforderung für Software Systeme werden wird. Der Client Teil muss auch dann noch nutzbar sein, wenn keine Verbindung zu Cloud besteht. Zu Zeit ist das für viele Web2.0 Applikationen leider nicht der Fall. Außerdem muss derlei Software ein Pay-for-Use Lizenzmodell anbieten, um den Notwendigkeiten der Cloud gerecht zu werden.

Bei der Infrastruktursoftware oder Middleware muss man sich dessen bewusst sein, dass sie in Zukunft nicht mehr auf „blankem Metall“, also auf Hardware, sondern in virtuellen Maschinen ausgeführt wird. Außerdem muss die Vergebührungsfunktionalität von Beginn an mit eingeplant und eingebaut werden. Das Retrofit eines Accounting-Systems wäre sehr komplex und fehleranfällig. Die Hardware wird in Zukunft nicht mehr aus Single-Racks bestehen, sondern aus einem skalierbaren Container der viele Racks aufnehmen kann.

„Green Computing“ ist nicht nur deswegen ein Hype dieser Tage weil man der Umwelt etwas gutes tun will, sondern auch, weil die großen Cloud Provider Kosten sparen und Gewinn maximieren wollen. Dabei spielt die Reduzierung des Energieverbrauch der großen Serverfarmen eine wichtige Rolle. Zu guter letzt müssen auch noch Bandbreiten erhöht und Übertragungskosten reduziert werden. Das gilt für WAN/Internet Router genauso wie für die Datenzentrum internen Switches.

Zum Abschluss nun eine kleine Fragerunde darüber, was in den nächsten fünf Jahren im Bereich Cloud Computing geschehen wird.

Veränderungen bei Technologie und Pricing: Wie werden die Vergebührungseinheiten für die komplexen Services aussehen? Wie will man die Nutzung der vielen verschiedenen Ressourcen nachverfolgen? Die Anzahl der Kerne pro Chip wird mit der Zeit weiter ansteigen und sich wohl alle 2 bis 4 Jahre verdoppeln. Der Flash Speicher ist eine weitere Möglichkeit einen weiteren schnellen Speicherlayer in der klassischen Hierarchie einzuziehen. Wie kann man das mit welchen Einheiten Vergebühren? Werden Technologie oder Geschäftsideen die Bandbreitenvergebührung mehr beeinflussen? Letzteres erfährt zur Zeit die niedrigste Innovationsrate.

Auf der Virtualisierungsebene: Wird Cloud Computing nun von low-level Virtual Maschinen wie Amazons EC2, von medium-level Sprachen und Systemen wie Microsofts Azure, oder von high-level Installationen wie Googles AppEngine dominiert? Werden die Value Addes Service Provider der unabhängigen Firmen wie RightScale, Heroku oder EngineYard im Zeitalter des Utility Computing überleben, oder werden die erfolgreichen Services in Zukunft von den Cloud Providern zur Verfügung gestellt. Wenn man sich auf einen einzelnen Virtualisierungslayer einigen könnte, würden mehrere Firmen dann mit dem gleichen Standard arbeiten? Wird es ähnlich wie bei den Netzwerkprovidern zu einem Billigpreiskampf kommen, oder wird man durch die Differenzierung der eigenen Services und Service Qualität Gewinn machen können?

Fragen zum Verständnis

Beantworten sie aus Ihrer Sicht folgende Fragen:

1. Wie werden die Vergebührungseinheiten für die komplexen Services aussehen? Wie will man die Nutzung der vielen verschiedenen Ressourcen nachverfolgen?
2. Werden Technologie oder Geschäftsideen die Bandbreitenvergebührung mehr beeinflussen? (In positivem und negativem Sinn)
3. Wird Cloud Computing nun von low-level Virtual Maschinen wie Amazons EC2, von medium-level Sprachen und Systemen wie Microsofts Azure, oder von high-level Installationen wie Googles AppEngine dominiert?
4. Wird es im Cloud Computing zu einem Billigpreiskampf kommen, oder wird man durch die Differenzierung der eigenen Services und Service Qualität Gewinn machen können?