Platform as a Service

Cloud Computing Architektur

Platform as a Service (PaaS) ist die zur Verfügungstellung einer Computer Plattform in der Cloud für Webanwendungsentwickler. PaaS Angebote bieten eine schnell einsetzbare Laufzeitumgebung für Webanwendungen mit geringem administrativen Aufwand und ohne Anschaffung der darunterliegenden Hard- und Software. Sie unterstützen den gesamten Softwarelebenszyklus vom Design, der Entwicklung, dem Test, der Auslieferung bis hin zum Betrieb der Webanwendungen über das Internet.^[1][2][3] Platform as a Service ist ein Teil von Everything as a Service.

Einige Angebote beinhalten auch Dienste zur Teamkollaboration, Versionierung, Monitoring und Sicherheit oder Middleware Dienste zum Speichern von Daten oder zur Kommunikation zwischen Anwendungen. PaaS Angebote bauen auf einer skalierbaren Infrastruktur (IaaS) von Speicher und Rechenleistung auf und können somit auch skalieren. Aufbauend auf einer PaaS Umgebung können Software as a Service (SaaS) Angebote entstehen. Somit ist PaaS die mittlere Schicht im Cloud Stack.^[1][2][3]

Bedeutung

Zwischen Oktober 2009 und Oktober 2010 haben mehr als 100 PaaS Anbieter den Markt betreten.^[1] Sie treten an um ihren Kunden möglichst viele administrative Aufgaben abzunehmen, Skalierbarkeit und Hochverfügbarkeit zu ermöglichen^[4], Fixkosten zu senken, Gesamtkosten zu senken, mehr Flexibilität zu geben, sowie eine schnelle Anwendungsentwicklung und einen schnellen Markteintritt zu ermöglichen.^[2][5] Damit wird es den Kunden ermöglicht, sich mehr auf die eigentliche Entwicklung von Geschäftsanwendungen zu konzentrieren, statt sich um Frameworks, Middleware, oder den Betrieb von skalierbaren, zuverlässigen und kosteneffizienten Rechenzentren zu kümmern.

Momentan werden PaaS Angebote nur von „leading-edge users“ genutzt, da „mainstream users“ den aktuellen PaaS Angeboten noch skeptisch gegenüber stehen. Gartner sieht die mehr visionären Independent Software Vendors (ISVs) als Schlüssel für die Akzeptanz des PaaS Modells, da diese ihre Anwendungen über die Cloud anbieten werden. Erst durch diese SaaS Angebote wird die Cloud auch für andere IT Projekte attraktiv.^[2]

Im Jahr 2009 hatte das Thema Cloud Computing insgesamt einen Höhepunkt auf der Gartner Hypekurve.^[6] Es gab viele Enttäuschungen über die Leistungsfähigkeit des Cloud Computings, aber auch positive Auswirkungen. In Japan haben bereits große Unternehmen damit begonnen PaaS Angebote wie Force.com zu nutzen um Kundenanwendungen ortstransparent, an eine Vielzahl von Nutzern zu bringen. Dabei hat sich herausgestellt, dass sich PaaS Angebote momentan nur für in sich abgeschlossene Anwendungen eignen, die keine komplexe Datenverarbeitung und kein komplexes Anwendungsdesign benötigen. Die Daten, die diese Anwendungen benötigen, werden meist noch über einen ETL Prozess aus den eigenen Rechenzentren der Unternehmen bezogen, da sie zusammen mit anderen benötigten Anwendungen noch nicht in der Cloud verfügbar sind.^[2]

Abgrenzung zu IaaS und SaaS

Eine Abgrenzung von PaaS zu IaaS Angeboten ist schwer, da viele PaaS Angebote die Dienste von darunterliegenden IaaS Angeboten nutzen und nur bündeln.^[7] Allerdings bieten die meisten PaaS Angebote keinen direkten Zugriff auf das Betriebssystem und die angebotenen PaaS Dienste sind nur über APIs ansprechbar. Die Konfiguration von PaaS Diensten kann sowohl über eine Weboberfläche, als auch selbst wieder über eine API vorgenommen werden. Der Nutzer einer PaaS Umgebung muss sich nicht um das Betriebssystem, die Middleware und Laufzeitumgebung für seine Anwendung kümmern, wie es bei IaaS Angeboten der Fall ist.^[8]

Um PaaS Angebote von SaaS Angeboten abzugrenzen kann die Zielgruppe herangezogen werden. SaaS Anwendungen sind in der Regel explizit für Endanwender gedacht, besitzen eine graphische Benutzungsschnittstelle und können auf IaaS oder PaaS Angeboten aufbauen. Dahingegen sind PaaS Angebote für Entwickler gedacht und bieten ihnen eine Entwicklungsumgebung sowie einen Container für ihre Anwendungen und weitere Middleware-Dienste an. Entwickler können somit ihre gesamte Anwendungen in eine PaaS Umgebung verteilen. Der Zugriff auf diese Middleware-Dienste geschieht über APIs.

Es existieren allerdings auch SaaS Angebote wie Google Docs^[9], die Entwicklern Schnittstellen zur Verfügung stellen, diese sind allerdings meist dafür gedacht die SaaS Anwendung zu erweitern oder mit ihr zu kommunizieren (siehe Add-on PaaS). Auch SaaS Anwendungen ohne graphische Benutzerschnittstelle sind denkbar aber nicht weit verbreitet.

Typen

Application PaaS (aPaaS) / Stand Alone Umgebungen

Unter aPaaS versteht man eine Cloud Umgebung zum Erstellen und Betreiben von Geschäftsanwendungen, die durch eine graphische Benutzungsschnittstelle oder durch eine Programmierschnittstelle (API) Anwendern zur Verfügung gestellt wird. Ein Beispiel wäre eine Webanwendung zum Verwalten von Terminen welche in der Google App Engine laufen könnte.^[2]

Integration and Governance PaaS (iPaaS)

Im Gegensatz dazu steht iPaaS als Cloud Umgebung zum Vermitteln zwischen heterogenen Cloud-basierten Anwendungen durch Interoperabilität, Integration und Governance. Ein Beispiel wäre ein Adapter der verschiedene Cloud Dienste wie auch On Premise Dienste verbindet und dies wiederum als Cloud Dienst anbietet ohne dabei zwangsläufig eine graphische Benutzungsschnittstelle zur Verfügung zu stellen. iPaas soll dabei die bisherige Integrations-Middleware ablösen und gemäß dem Cloud Paradigma hochskalierbar sein. Ein erster Anbieter solcher Lösungen ist Mule iON.^[10][2]

Add-on Entwicklungsumgebungen

Add-on Entwicklungsumgebungen erlauben es bestehende Software as a Service (SaaS) Anwendungen anzupassen. Dies geschieht ähnlich wie die Anpassung von zum Beispiel Microsoft Word oder Lotus Notes durch Makrosprachen oder von außen durch von der SaaS Anwendung zur Verfügung gestellte APIs. PaaS Entwickler benötigen hierzu meist Zugriff auf die SaaS Anwendung selbst über ein Abo oder eine kostenlose Entwicklerlizenz.

Reine Anwendungsbereitstellung

Einige PaaS Angebote unterstützen nicht die Entwicklung, das Debugger oder Testen von Anwendungen, sondern bieten nur den Betrieb von Anwendungen in einer skalierbaren Umgebung und zum Beispiel Sicherheitsdienste an.

Offenes PaaS

Bei offnen PaaS Angeboten wird dem Entwickler keine Programmiersprache, kein Datenbanksystem und auch kein Betriebssystem oder Server vorgegeben.^[11][12]

Aufbau, Eigenschaften und Besonderheiten

Laufzeit- und Entwicklungsumgebung

Mit der Unterteilung von PaaS in Entwicklungs- und Ausführungsumgebung soll ermöglicht werden sich auf eine Entwicklungsumgebung, wie zum Beispiel Django^[13], festzulegen aber bei der Wahl der Ausführungsumgebung flexibel zu sein und hier auch zwischen Anbietern zu wechseln.^[14]

Um eine hohe Ausfallsicherheit zu erreichen, müssen von jeder Anwendung mindestens zwei Instanzen laufen, damit im Falle eines Fehlers bei einer Instanz die andere Instanz übernehmen kann.^[15] Da Anwendungen in PaaS Umgebungen in der Regel sowohl Rechendienste, wie auch Datendienste und andere Middleware Dienste benötigen, ist zu beachten dass beim Ausfall eines der genutzten Dienste auch die Verfügbarkeit des Gesamtsystems darunter leiden kann. Die Anbieter versprechen in ihren SLAs in der Regel nur eine Verfügbarkeit von 99,5 %, 99,9 % oder 99,95 % für jeden einzelnen Dienst, nicht aber für alle Dienste zusammen. Bei anbieterseitigen Verletzungen der SLAs werden meist nur Gutschriften zwischen 10 % und 25 % auf die Monatsrechnung erstattet.^{[15][16][17][18]}

Programmiermodell

Das Programmiermodell in der Cloud ist vergleichbar mit Enterprise Anwendungen (Cluster aus Application Servern mit Load Balancer), da beide skalierbar und ausfallsicher sein müssen. Um also skalierbare Anwendungen in der Cloud betreiben zu können, müsse diese auf Asynchronität und Zustandslosigkeit setzen. Ansonsten erreicht man lediglich ein Hosting in einer Cloud-Umgebung ohne gute Skalierbarkeit und Ausfallsicherheit.

Das Windows Azure Programmiermodell verlangt zum Beispiel drei Dinge um die garantierte Skalier- und Ausfallsicherheit zu gewährleisten. Erstens muss eine Anwendung in eine oder mehrere logische Rollen unterteilt werden, zweitens müssen mehrere Instanzen einer Rolle gleichzeitig laufen und drittens muss die Anwendung sich auch noch korrekt verhalten, wenn eine Instanz einer Rolle abstürzt. Zusätzlich darf die Anwendung keinen Zustand speichern, da der Load Balancer im Gegensatz zu zum Beispiel Amazons Elastic Beanstalk keine Sticky Sessions/Cookies verwendet.

Veränderungen am Betriebssystem müssen, sofern sie überhaupt möglich sind, bei jedem Start einer Instanz vorgenommen werden und Daten, wenn sie lokal gespeichert werden können, sind in der Regel nicht für alle Instanzen verfügbar und können beim Neustart einer Instanz verloren gehen. Um die Kommunikation zwischen Instanzen zu ermöglichen, muss in der Regel auf eine Message Queuing System gesetzt werden, welche zum Teil sogar eine at-least-once Semantik verfolgen müssen und somit die Verarbeitung der Messages idem potent sein muss.

Beim Aufbau einer PaaS Umgebung können also in der Regel bestehende Enterprise Programmiermodelle wie JEE oder .NET verwendet werden, jedoch muss sich der Entwickler eventuell auf Änderungen einstellen wenn er bisher noch keine skalierbaren Anwendungen entwickelt hat.

Entwicklungsprozess

Der Entwicklungsprozess ändert sich kaum im Vergleich zur Anwendungsentwicklung für Application Server, wie zum Beispiel JEE. Anwendungen werden lokal spezifiziert, entworfen, entwickelt, getestet, paketiert und schließlich in die Cloud Plattform deployed. Viele Anbieter wie Google App Engine, Windows Azure oder Amazons Elastic Beanstalk erlauben es mehrere verschiedene Versionen der gleichen Anwendung parallel laufen zu lassen um so zum Beispiel eine Live-, Stage- und Testumgebungen anzubieten und damit auch eine Rollback-Möglichkeit zu einer früheren Version zu ermöglichen. Die großen Anbieter bringen auch direkte Unterstützung für IDEs mit um die Anwendungen direkt aus der IDE in die Cloud Umgebung zu deployen.

Ein PaaS Anbieter muss also dafür sorgen, alle Versionen einer Anwendung zu speichern und kann zusätzlich über eine IDE Komfortfunktionen anbieten um die Anwendungen leicht aus der IDE heraus zu verteilen.

Der Aufwand um eine On Premise Lösung so in die Cloud zu portieren, dass sie dort auch skaliert, kann abhängig vom verwendeten Programmiermodell von wenigen Stunden bis zur kompletten Neuentwicklung reichen.

Um den Aufwand bei beschränkt benötigter Skalierbarkeit zu minimieren gibt es Multi-Tenancy Patterns^[19][20] die zum Beispiel nicht mandantenfähige Anwendungen mit geringem Aufwand mandantenfähig macht, allerdings unter der Prämisse eingeschränkter Skalierbarkeit.

Laufzeitumgebung

Die Laufzeitumgebung einer PaaS Umgebung kann über APIs oder eine Weboberfläche konfiguriert werden. So können zum Beispiel Anwendungen gestartet und beendet oder die maximale und minimale Anzahl an Instanzen festgelegt werden. Auch das Monitoring und die damit verbundene Autoskalierbarkeit der Anwendungen kann über APIs oder eine Weboberfläche erfolgen.

Einige Laufzeitumgebungen wie JEE in der Google App Engine bieten nur eine Teilmenge der eigentlichen Laufzeitumgebungen um die Skalierbarkeit und Ausfallsicherheit zu gewährleisten. So ist es zum Beispiel in der Google App Engine nicht erlaubt Java Threads zu starten oder direkt auf das Datei- oder Betriebssystem zuzugreifen. Diese Einschränkungen werden meist durch separate APIs ausgeglichen um die Funktionen dennoch anzubieten aber die Skalierbarkeit und Ausfallsicherheit nicht zu gefährden. Auch können über solche APIs Quotas wie für HTTP Requests oder E-Mail Versand durchgesetzt werden, welche die Stabilität der Laufzeitumgebung garantieren. Einige Anbieter bieten noch zusätzliche APIs für Dienste wie Memcache oder Bildverarbeitung an. Gebündelt werde alle anbieterspezifischen APIs zusammen mit den Laufzeitumgebungen in SDKs.

Der Nachteil dieser Anpassungen der Laufzeitumgebungen ist eine erschwerte Portierbarkeit, da die zusätzlichen Dienste nicht anbieterübergreifend über einheitliche APIs verfügbar sind. Es gibt zwar Standardisierungsgremien wie openstack^[21] und Occi^[22] jedoch fokussieren diese ihre Arbeit mehr auf die Standardisierung der Management und Speicher APIs und nicht auf die Anwendungscontainer.

Persistenz

Fast jede Anwendung muss Daten speichern, allerdings kann dies in Cloud Umgebungen nicht auf der Festplatte der Laufzeitumgebung passieren, da Laufzeitumgebungen ausgeschaltet und die Anwendung auf einer anderen Laufzeitumgebung neu gestartet werden können muss. Daher bieten die meisten PaaS Anbieter verschiedene Persistenzmöglichkeiten als Dienst über eine API an. Verschiedene Dienste wie BLOB-Speicher, SQL-Datenbanken, NoSQL-Datenbanken, hochverfügbare Caches oder Memcache-Server gehören somit zum Angebot der großen PaaS Anbieter.^[23][24][25]

Die meisten Persistenzdienste der PaaS Anbieter bauen nicht auf relationalen Datenbanken auf, da diese nach dem CAP-Theorem nur zwei der drei Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz gleichzeitig erfüllen können, um den Skalierbarkeitsanforderungen zu genügen.^[26] In der Cloud haben sich damit vor allem Key-Value Stores beziehungsweise schemalose NoSQL-Datenbanken etabliert, welche wesentlich besser skalieren, da sie die ACID Kriterien nicht voll einhalten müssen.^[27]

Da viele Kunden dennoch SQL-Datenbanken für die einfache Anwendungsmigration in die Cloud verlangen, werden mittlerweile auch diese angeboten, jedoch mit einer schlechteren Performance als die Key-Value Stores. Auch die BLOB-Speicher der PaaS Anbieter, wie der S3 Dienst von Amazon, nutzen in der Regel keine Standardsoftware oder -protokolle, sondern verfügen über eine anbieterabhängige API. Um die Portierbarkeit der Anwendungen von einem zum nächsten PaaS Anbieter zu erleichtern wird im Java Umfeld oft die JPA oder JDO API von den einzelnen Anbieter für ihre Datenbanken implementiert.

Nebenläufigkeit und Kommunikation zwischen Anwendungsinstanzen

Damit die Antwortzeit von Anwendungen für den Endnutzer immer akzeptabel ist, brauchen einige Anwendungen für größere Berechnungen die Möglichkeit diese asynchron zu starten. In Cloud Umgebungen kann jedoch jederzeit eine Anwendungsinstanz heruntergefahren werden und somit kann die Berechnung vor der Beendung abgebrochen werden. Außerdem bietet zum Beispiel die Google App Engine keine Möglichkeit neue Threads in seiner Anwendungen zu starten^[28] um die Stabilität der Google App Engine nicht zu gefährden.

Um die Ausführung von asynchronen Berechnungen zu garantieren oder diese überhaupt zu ermöglichen bieten die meisten PaaS Anbieter eine Messaging Infrastruktur an. Die Google App Engine erlaubt das Anstoßen asynchroner Aufgaben zum Beispiel mittels der Dienste Scheduled Tasks und Task Queue.^[29] Bei Amazon gibt es dazu den Amazon Simple Queue Service^[30] und bei Windows Azure die Queue Service API aus den Windows Azure Storage Services.^[31] Obwohl Windows Azure und Amazons Elastic Beanstalk es erlauben neue Threads zu starten, empfiehlt es sich Message Queues aus den oben genannten Gründen zu verwenden um eine bessere Skalierbarkeit zu erreichen.

Zugriffsschicht

Der Zugriff auf Anwendungen in der Cloud geschieht über das Internet oder unternehmensintern auch über das Intranet.^[32] Dabei spielen vor allem Web- und Netzwerk-Protokolle wie HTTP/S und TCP/IP eine Rolle, aber auch Protokolle für Spezialanwendungsfälle wie XMPP oder WebSocket werden zum Teil unterstützt.

Die bedeutendste Rolle spielt hier das HTTP Protokoll, da auf Anwendungen die in eine PaaS Umgebung deployed werden, in der Regel per HTTP zugegriffen wird. Das HTTP Protokoll wurde als Zugriffsprotokoll für Ressourcen im Internet geschaffen und eignet es sich somit auch für Cloud-Anwendungen. Protokolleigenschaften wie Zustandslosigkeit und Caching unterstützen eine skalierbare Infrastruktur, so kann ein Load Balancer HTTP Anfragen an entsprechende Instanzen der Anwendungen zustandslos weiterleiten^[33] oder ein CDN die Ressourcen nah an den Nutzer bringen.^[34][35]

Um die Cloud-Umgebungen stabil zu halten, wird auch hier wieder von einigen Anbietern der Netzwerkzugriff aus Anwendungen heraus eingeschränkt und über anbieterabhängige APIs in einer kontrollierten Art und Weise wieder zur Verfügung gestellt.^[36][37] Die Google App Engine erlaubt zum Beispiel keine freie Netzwerkkommunikation, hierfür muss eine API von Google genutzt werden, die HTTP/S (URL Fetch), XMPP und WebSocket (Channel) unterstützt.^[38]

Um die Sicherheit von Anwendungen zu erhöhen erlauben es Anbieter wie Amazon gängige Firewall-Einstellungen, wie Black- oder Whitelisting von IP-Adressbereichen oder TCP/UDP-Port Beschränkung, zu tätigen. Somit kann der Zugriff auf eine Anwendung sicherer und auf das eigene Unternehmen eingeschränkt werden. Auch IPsec VPN gesicherte Verbindungen zwischen der Public Cloud und der On Premise Infrastruktur sind zum Beispiel mit Amazons Virtual Private Cloud Dienst möglich.^[39]

Außerdem gibt es Dienste wie Windows Azure Connect (beta) um die direkte Kommunikation zwischen Public Cloud und On Premise Diensten über das IP Protokoll zu ermöglichen. So kann zum Beispiel eine Public Cloud Anwendung auf eine On Premise Datenbank oder On Premise Active Directory zugreifen.^[40]

Mandantenfähigkeit (Multi-Tenancy)

Da nicht nur einzelne Firmen ihre innerbetrieblichen Anwendungen in die Cloud auslagern, sondern auch ISVs bei neuen Anwendungen gern auf Cloud Plattformen zurückgreifen, werden Mittel benötigt um Mandantenfähigkeit zu ermöglichen.

Dabei können Mandanten sitzungsabhängig- oder sitzungsunabhängig einzelnen Anwendungsinstanzen zugeordnet werden (Multiple Instances Multi-Tenancy) oder aber der Anwendung ist bewusst, dass sie mehrere Mandanten bedient (Native Multi-Tenancy), dann kann der Request von irgendeiner, nicht vorher festgelegte Anwendungsinstanz, verarbeitet werden. Die Art der Mandantenbedienung hat große Auswirkungen auf die Skalierbarkeit und es spielen auch Aspekte wie Datensicherheit, Performance Isolation, Verfügbarkeit, SLAs oder Anwendungskonfigurationen eine große Rolle. Die Daten der einzelnen Mandanten dürfen nicht vermischt werden, die Performance sollte auf alle Mandanten gleich verteilt werden und trotzdem soll jeder Mandant seine Anwendung individuell konfigurieren können.^[19][20]

PaaS Anbieter wie Google reagieren hierauf zum Beispiel mit Namensräumen. So kann jeder Mandant eine Subdomain als Namensraum zugewiesen bekommen. Danach ist nur noch der Zugriff auf mit diesem Namensraum verbundene Objekte des Datastore, Memcaches oder der Task Queue zugelassen. Somit ist auf einer höheren Ebene, als der Anwendung an sich, sichergestellt, dass keine Kunde Zugriff auf die Daten anderer Kunden erhält.^[41] Alternativ kann auch auf verschiedene Patterns^[19][20] zurückgegriffen werden.

Weitere Probleme, die eine Cloud Plattform lösen soll ist das gleichzeitige Betreiben mehrerer Versionen einer Anwendung. Dies ist zum Einen beim Entwickeln von Anwendungen von Vorteil um Tests wie Regressionstests durchzuführen, es bietet eine Möglichkeit zum Rollback, falls im Live-Betrieb nach der Umstellung auf die neuste Version Fehler auftreten und es bietet Mandanten die Möglichkeit selbst zu bestimmen, wann sie auf eine neue Version umsteigen wollen.

Kosten

Der Betrieb einer kleinen Webanwendung mit einer Recheninstanz, 15 GB ein- und 15 GB ausgehendem Traffic und 1 GB Speicher kostet bei Anbietern wie Google, Amazon oder Microsoft zwischen US$ 38 und US$ 65 im Monat.^[42][43][44]

Kritik

Eine Unterstützung in Form von technischen Anleitungen oder gar Tools zur Migration von On Premise Anwendungen zu PaaS Anwendungen haben die meisten Anbieter nicht im Programm. Sie bieten lediglich Tools um Daten in die Cloud zu im- und exportieren und virtuelle Maschinen Images in die Cloud zu laden. Dies allein lässt die Anwendungen an sich aber noch nicht skalieren, sondern ist eher mit einer Remote Hosting Lösung vergleichbar.

Die großen PaaS Anbieter bieten alle grundlegende Funktionen um einfache Webanwendungen in der Cloud laufen zu lassen. Professioneller Support wird auch von vielen Diensten angeboten, wenn auch zum Teil in einer Beta-Phase. Die generelle Datenschutz-Problematik beim Cloud Computing wird von den Diensten für deutsche Unternehmen jedoch nicht angegangen, da die Daten nicht in deutschen Rechenzentren liegen^[45][46][47], was für viele Unternehmen wichtig ist.^[48]

Vorsicht gilt bei einigen Diensten, die zwar angeben PaaS Angebote zu haben, wo aber im Endeffekt nur ein Off Premise Hosting ohne Skalierbarkeit dahintersteckt.^[49][50]

Verweise

Siehe auch

• Everything as a Service
• Software as a Service
• Infrastructure as a Service
• Cloud Computing
• Microsoft Windows Azure
• Google App Engine
• Amazon Elastic Beanstalk
• Force.com (Salesforce)

Weblinks

• http://www.slideshare.net/thobach/cloud-platforms-paas deutsche Präsentation zum Thema PaaS mit Marktüberblick

Einzelnachweise

1. ↑ ^{a b c} G. Raines und L. Pizette. Platform as a Service: A 2010 Marketplace Analysis. 2010-10, http://www.mitre.org/work/tech_papers/2010/10_4138/cloud_platform_service_paas.pdf, Abrufdatum: 2. Juni 2012
2. ↑ ^{a b c d e f g} Y. V. Natis, T. Jones, B. J. Lheureux, K. Iijima, E. Knipp und D. M. Smith. Predicts 2011: Platform as a Service: The Architectural Center of the Cloud. Gartner, 24. November 2010
3. ↑ ^{a b} M. Fouquet, H. Niedermayer und G. Carle. Cloud Computing for the Masses. 1. Dezember 2009
4. ↑ B. Lobaugh. Deploying a Java application to Windows Azure with Command-line Ant. Microsoft, 17. Februar 2011, http://java.interoperabilitybridges.com/articles/deploying-a-java-application-to-windows-azure-with-command-line-ant, Abrufdatum: 2. Juni 2011
5. ↑ K. Friedmann. Cloud Computing in Deutschland: Der Markt für Cloud-Services wird sich bis Ende 2011 verdoppeln. 3. August 2010, http://www.cio.de/dynamicit/management_strategie/2226947/index3.html, Abrufdatum: 2. Juni 2011
6. ↑ unbekannt. Cloud Hype at Height: Gartner. Cloud Computing Journal, 17. August 2009, http://cloudcomputing.sys-con.com/node/1067894, Abrufdatum: 6. Mai 2011
7. ↑ unbekannt. AWS Elastic Beanstalk (beta). http://aws.amazon.com/elasticbeanstalk/, Amazon, 2010, Abrufdatum: 2. Juni 2011
8. ↑ W. Tonninger. Die Cloud-Gretchen-Frage: IaaS oder PaaS?. 25. Februar 2011, http://businessreadyblog.wordpress.com/2011/02/25/die-cloud-gretchen-frage-iaas-oder-paas/, Abrufdatum: 2. Juni 2011
9. ↑ unbekannt. Willkommen bei Google Text & Tabellen. Google, 2011, http://docs.google.com, Abrufdatum: 3. Juni 2011
10. ↑ unbekannt. iPaaS: Integration for the Cloud Era. MuleSoft, 2011, http://www.mulesoft.com/ipaas-integration-platform-as-a-service, Abrufdatum: 3. Juni 2011
11. ↑ Open Platform as a Service
12. ↑ AppScale: Open Source Platform
13. ↑ unbekannt. Django | The Web framework for perfectionists with deadlines. 2011, https://www.djangoproject.com/, Abrufdatum: 3. Juni 2011
14. ↑ A. Lenk, M. Klems, J. Nimis, S. Tai und T. Sandholm. What’s Inside the Cloud? An Architectural Map of the Cloud Landscape. ICSE’09 Workshop, 23. März 2009
15. ↑ ^{a b} http://www.microsoft.com/windowsazure/sla/
16. ↑ http://aws.amazon.com/ec2-sla/
17. ↑ http://aws.amazon.com/de/s3-sla/
18. ↑ http://code.google.com/intl/de-DE/appengine/sla.html
19. ↑ ^{a b c} Chang Jie Guo, Wei Sun, Ying Huang, Zhi Hu Wang und Bo Gao. A Framework for Native Multi-Tenancy Application Development and Management. cec-eee, pp.551-558, The 9th IEEE International Conference on E-Commerce Technology and The 4th IEEE International Conference on Enterprise Computing, E-Commerce and E-Services (CEC-EEE 2007), 2007
20. ↑ ^{a b c} R. Mietzner, T. Unger, R. Titze und F. Leymann. Combining Different Multi-Tenancy Patterns in Service-Oriented Applications.
21. ↑ unbekannt. StartingPage – Wiki. openstack, 30. Mai 2011, http://wiki.openstack.org/, Abrufdatum: 5. Juni 2011
22. ↑ unbekannt. Open Cloud Computing Interface | Open Standard | Open Community. 2011, Abrufdatum: 5. Juni 2011
23. ↑ unbekannt. App Engine Java Overview - Google App Engine - Google Code. 2011, http://code.google.com/intl/de-DE/appengine/docs/java/overview.html, Abrufdatum: 5. Juni 2011
24. ↑ unbekannt. Amazon Web Services (Deutsch). 2011, http://aws.amazon.com/de/, Abrufdatum: 5. Juni 2011
25. ↑ unbekannt. Windows Azure Platform Features. Microsoft, 2011, http://www.microsoft.com/windowsazure/features/, Abrufdatum: 5. Juni 2011
26. ↑ N. Lynch und S. Gilbert. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, Volume 33 Issue 2 (2002), Seite 51-59
27. ↑ A. Carter. The CAP Theorem as it Applies to Contemporary NoSQL Storage Systems. 5. April 2011, http://www.andrewjonascarter.com/files/ResearchPaper_Databases.pdf, Abrufdatum: 5. Juni 2011
28. ↑ unbekannt. The Java Servlet Environment. Google, 2011, http://code.google.com/intl/de-DE/appengine/docs/java/runtime.html#The_Sandbox, Abrufdatum: 2. Juni 2011
29. ↑ unbekannt. Task Queue Java API Overview - Google App Engine - Google Code. 2011, http://code.google.com/intl/de-DE/appengine/docs/java/taskqueue/overview.html, Abrufdatum: 2. Juni 2011
30. ↑ unbekannt. Amazon Simple Queue Service (Amazon SQS). Amazon, 2010, http://aws.amazon.com/de/sqs/, Abrufdatum: 2. Juni 2011
31. ↑ unbekannt. Queue Service API. Microsoft, 2011, http://msdn.microsoft.com/en-us/library/dd179363.aspx, Abrufdatum: 2. Juni 2011
32. ↑ C. Baun, M. Kunze, J. Nimis und S. Tai. Cloud Computing: Web-basierte dynamische IT-Services.
33. ↑ unbekannt. Elastic Load Balancing. Amazon, 2011, http://aws.amazon.com/elasticloadbalancing/, Abrufdatum: 2. Juni 2011
34. ↑ unbekannt. Windows Azure CDN. Microsoft, 2011, http://msdn.microsoft.com/en-us/gg405416, Abrufdatum: 2. Juni 2011
35. ↑ R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach und T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. 1999-06, http://tools.ietf.org/html/rfc2616, Abrufdatum: 2. Juni 2011
36. ↑ unbekannt. The Java Servlet Environment. Google, 2011, http://code.google.com/intl/de-DE/appengine/docs/java/runtime.html#The_Sandbox, Abrufdatum: 2. Juni 2011
37. ↑ unbekannt. Quotas - Google App Engine - Google Code. Google, 2011, http://code.google.com/intl/de-DE/appengine/docs/quotas.html#Billable_Quotas_and_Fixed_Quotas, Abrufdatum: 2. Juni 2011
38. ↑ unbekannt. Java Service APIs. 2011, http://code.google.com/intl/de-DE/appengine/docs/java/apis.html, Abrufdatum: 2. Juni 2011
39. ↑ unbekannt. Amazon Elastic Compute Cloud (Amazon EC2). 2011, http://aws.amazon.com/de/ec2/, Abrufdatum: 5. Juni 2011
40. ↑ unbekannt. Windows Azure Virtual Network | Windows Azure Platform. 2011, http://www.microsoft.com/windowsazure/virtualnetwork/, Abrufdatum: 5. Juni 2011
41. ↑ unbekannt. Overview of Multitenancy and the Namespaces Java API - Google App Engine - Google Code. Google, 2011, http://code.google.com/intl/de-DE/appengine/docs/java/multitenancy/overview.html, Abrufdatum: 2. Juni 2011
42. ↑ unbekannt. Developer's Guide - Google App Engine - Google Code. Google, 2011, http://code.google.com/intl/de-DE/appengine/docs/, Abrufdatum: 2. Juni 2011
43. ↑ unbekannt. Windows Azure Platform Consumption. Microsoft, 2011, http://www.microsoft.com/windowsazure/offers/popup/popup.aspx?lang=en&locale=en-us&offer=MS-AZR-0003P, Abrufdatum: 2. Juni 2011
44. ↑ unbekannt. AWS Elastic Beanstalk (beta). http://aws.amazon.com/elasticbeanstalk/, Amazon, 2010, Abrufdatum: 2. Juni 2011
45. ↑ R. Blackwell. Azure Northern Europe is Dublin and Western Europe is Amsterdam. 12. April 2011, http://www.robblackwell.org.uk/2011/04/12/azure-northern-europe-is-dublin-and-western-europe-is-amsterdam.html, Abrufdatum: 2. Juni 2011
46. ↑ unbekannt. Amazon Web Services: Service Health Dashboard. http://status.aws.amazon.com/, Abrufdatum: 2. Juni 2011
47. ↑ unbekannt. Issue 193 - googleappengine - Country-specific Storage - Google App Engine - Google Project Hosting. http://code.google.com/p/googleappengine/issues/detail?id=193, Abrufdatum: 2. Juni 2011
48. ↑ K. Friedmann. Cloud Computing in Deutschland: Der Markt für Cloud-Services wird sich bis Ende 2011 verdoppeln. 3. August 2010, http://www.cio.de/dynamicit/management_strategie/2226947/index3.html, Abrufdatum: 2. Juni 2011
49. ↑ Y. V. Natis, T. Jones, B. J. Lheureux, K. Iijima, E. Knipp und D. M. Smith. Predicts 2011: Platform as a Service: The Architectural Center of the Cloud. Gartner, 24. November 2010
50. ↑ D. Chappell. THE WINDOWS AZURE PROGRAMMING MODEL. Microsoft, 2010-10, http://www.microsoft.com/windowsazure/Whitepapers/ProgrammingModel/default.aspx, Abrufdatum: 2. Juni 2011