Platform as a Service

PaaS ist eine Weiterleitung auf diesen Artikel. Zu Bedeutungen des Namens siehe Paas.

Cloud-Computing-Architektur

Als Platform as a Service (PaaS) bezeichnet man eine Dienstleistung, die in der Cloud eine Computer-Plattform für Entwickler von Webanwendungen zur Verfügung stellt. Dabei kann es sich sowohl um schnell einsetzbare Laufzeitumgebungen (typischerweise für Webanwendungen), aber auch um Entwicklungsumgebungen handeln, die mit geringem administrativem Aufwand und ohne Anschaffung der darunterliegenden Hardware und Software genutzt werden können. Sie unterstützen den gesamten Software-Lebenszyklus vom Design über die Entwicklung, den Test, die 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 umfassen auch Dienste zur kollaborativen Arbeit und Versionierung, zum Monitoring und für die Sicherheit oder Middleware-Dienste zum Speichern von Daten oder für die Kommunikation zwischen Anwendungen. PaaS-Angebote bauen auf einer skalierbaren Infrastruktur (IaaS) von Speicher und Rechenleistung auf und können somit ebenfalls 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 und Gesamtkosten zu senken, die Anwender flexibler zu machen und um eine schnelle Anwendungsentwicklung und einen baldigen Markteintritt zu ermöglichen.^[2][5] Damit wird es den Kunden ermöglicht, sich mehr auf die eigentliche Entwicklung von Geschäftsanwendungen zu konzentrieren, anstatt 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, die „mainstream users“ stehen ihnen noch skeptisch gegenüber. 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 einer großen Zahl von Nutzern Kundenanwendungen ortstransparent zur Verfügung stellen zu können. 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 erfordern. Die Daten, die diese Anwendungen benötigen, werden meist noch über einen ETL-Prozess aus den eigenen Rechenzentren der Unternehmen bezogen, da sie noch nicht in der Cloud verfügbar sind.^[2]

Abgrenzung zu IaaS und SaaS

Eine Abgrenzung von PaaS- zu IaaS-Angeboten ist schwierig, da viele PaaS-Anbieter darunter liegende IaaS-Angebote nutzen und bündeln.^[7] Allerdings lassen die meisten PaaS-Angebote keinen direkten Zugriff auf das Betriebssystem zu, die 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 erfolgen. 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- von SaaS-Angeboten abgrenzen zu können, zieht man am besten die Zielgruppe heran. SaaS-Anwendungen sind in der Regel explizit für Endanwender gedacht, besitzen eine graphische Bedienoberfläche 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 gesamten Anwendungen in eine PaaS-Umgebung verteilen. Der Zugriff auf diese Middleware-Dienste geschieht über APIs.

Es existieren allerdings auch SaaS-Angebote wie Google Drive,^[9] die Entwicklern Schnittstellen zur Verfügung stellen. Sie sind allerdings zumeist dafür gedacht, die SaaS-Anwendung zu erweitern oder mit ihr zu kommunizieren (siehe Add-on-PaaS). Es existieren auch SaaS-Anwendungen ohne graphische Bedienoberfläche, sie sind 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-Premises-Dienste verbindet und dies wiederum als Cloud-Dienst anbietet, ohne dabei zwangsläufig eine graphische Bedienoberfläche zur Verfügung zu stellen. iPaas soll dabei die bisherige Integrations-Middleware ablösen und gemäß dem Cloud-Paradigma hochskalierbar sein. Anbieter solcher Lösungen sind bspw. Zapier, Integromat (Celonis), Lobster_data, MuleSoft, Jitterbit, Outsystems, Scheer PAS, Workato uvm.^[10][11]

Add-on-Entwicklungsumgebungen

Add-on-Entwicklungsumgebungen erlauben es, bestehende Software-as-a-Service-Anwendungen anzupassen. Das Vorgehen ist ähnlich wie beispielsweise die Anpassung von Microsoft Word oder Lotus Notes durch Makrosprachen oder von außen durch APIs, die von der SaaS-Anwendung zur Verfügung gestellt werden. PaaS-Entwickler benötigen hierzu meist Zugriff auf die SaaS-Anwendung selbst, entweder über ein Abo oder eine kostenlose Entwicklerlizenz.

Reine Anwendungsbereitstellung

Einige PaaS-Angebote unterstützen nicht die Entwicklung, das Debuggen oder Testen von Anwendungen, sondern bieten nur den Betrieb von Anwendungen in einer skalierbaren Umgebung und darüber hinaus etwa Sicherheitsdienste an.

Offenes PaaS

Bei offenen PaaS-Angeboten werden dem Entwickler weder Programmiersprache noch Datenbanksystem, Betriebssystem oder Server vorgegeben.^[12]

Aufbau, Eigenschaften und Besonderheiten

Laufzeit- und Entwicklungsumgebung

Mit der Unterteilung von PaaS in Entwicklungs- und Ausführungsumgebung soll dem Entwickler 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 wechseln zu können.^[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 übernehmen kann.^[15] Da Anwendungen in PaaS-Umgebungen in der Regel sowohl Rechen- wie auch Daten- und andere Middleware-Dienste benötigen, ist zu beachten, dass beim Ausfall von einem der genutzten Dienste auch die Verfügbarkeit des Gesamtsystems leiden kann. Die Anbieter versprechen in ihren SLAs in der Regel nur eine Verfügbarkeit von 99,5, 99,9 oder 99,95 Prozent 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 Prozent 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, das ohne gute Skalierbarkeit und Ausfallsicherheit auskommen muss.

Das Windows-Azure-Programmiermodell verlangt zum Beispiel drei Voraussetzungen, die erfüllt sein müssen, um die 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 beispielsweise 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 ein Message Queuing System gesetzt werden, das zum Teil sogar eine At-least-once-Semantik verfolgen muss, somit muss die Verarbeitung der Messages idempotent sein.

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

Entwicklungsprozess

Der Entwicklungsprozess unterscheidet sich nicht groß von der Anwendungsentwicklung für Application Server, wie zum Beispiel JEE. Anwendungen werden lokal spezifiziert, entworfen, entwickelt, getestet, paketiert und schließlich in die Cloud-Plattform übertragen. Viele Anbieter wie Google App Engine, Microsoft Azure oder Amazons Elastic Beanstalk erlauben es, mehrere Versionen der gleichen Anwendung parallel laufen zu lassen, um so zum Beispiel Live-, Stage- und Testumgebungen anzubieten und damit auch ein Rollback 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 übertragen.

Ein PaaS-Anbieter muss also dafür sorgen, dass alle Versionen einer Anwendung gespeichert werden, und kann zusätzlich IDE-Komfortfunktionen anbieten, um die Anwendungen aus der IDE heraus zu verteilen.

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

Um den Aufwand zu minimieren, wenn lediglich eine geringe Skalierbarkeit benötigt wird, gibt es Multi-Tenancy-Patterns,^[19][20] die zum Beispiel nicht-mandantenfähige Anwendungen mit geringem Aufwand mandantenfähig machen, allerdings für den Preis einer eingeschränkten 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 etwa 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 memcached 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 Open Cloud Computing Interface (Occi).^[22] Sie fokussieren ihre Arbeit jedoch mehr auf die Standardisierung der Management- und Speicher-APIs als auf die Anwendungscontainer.

Persistenz

Fast jede Anwendung muss Daten speichern, allerdings kann dies in Cloud-Umgebungen nicht auf der Festplatte der Laufzeitumgebung passieren, da die Laufzeitumgebungen ausgeschaltet und die Anwendungen auf anderen Laufzeitumgebungen neu gestartet werden können müssen. 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 Service 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 vollständig 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 für die 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, sie asynchron zu starten. In Cloud-Umgebungen kann jedoch jederzeit eine Anwendungsinstanz heruntergefahren werden. Somit kann die Berechnung vor der Beendung abgebrochen werden. Außerdem bietet zum Beispiel die Google App Engine keine Möglichkeit, neue Threads in seinen Anwendungen zu starten^[28]. Auf diese Weise soll verhindert werden, dass die Stabilität der Google App Engine gefährdet wird.

Um die Ausführung von asynchronen Berechnungen zu garantieren oder diese überhaupt zu ermöglichen, haben die meisten PaaS-Anbieter eine Messaging-Infrastruktur im Programm. 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 Microsoft Azure die Queue-Service-API aus den Microsoft Azure Storage Services.^[31] Obwohl Microsoft Azure und Amazons Elastic Beanstalk es erlauben, neue Threads zu starten, empfiehlt es sich, aus den oben genannten Gründen Message Queues 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 kommt dem HTTP-Protokoll zu, da auf Anwendungen, die in eine PaaS-Umgebung übertragen werden, in der Regel per HTTP zugegriffen wird. Das HTTP-Protokoll wurde als Zugriffsprotokoll für Ressourcen im Internet geschaffen und eignet 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.^[28][36] 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.^[37]

Um die Sicherheit von Anwendungen zu erhöhen, erlauben 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 per IPsec VPN gesicherte Verbindungen zwischen der Public Cloud und der On-Premises-Infrastruktur sind zum Beispiel mit Amazons Virtual-Private-Cloud-Dienst möglich.^[38]

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

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 eine Mandantenfähigkeit zu ermöglichen.

Dabei können Mandanten sitzungsabhängig oder -unabhä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, vorher nicht festgelegten Anwendungsinstanz verarbeitet werden. Die Art der Mandantenbedienung hat große Auswirkungen auf die Skalierbarkeit. Zudem 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.^[40] Alternativ kann auch auf verschiedene Patterns^[19][20] zurückgegriffen werden.

Ein weiteres Problem, das eine Cloud-Plattform lösen soll, ist das gleichzeitige Betreiben mehrerer Versionen einer Anwendung. Das ist zum einen beim Entwickeln von Anwendungen von Vorteil, um Tests wie Regressionstests durchzuführen. Es bietet dann eine Möglichkeit zum Rollback, falls im Live-Betrieb nach der Umstellung auf die neuste Version Fehler auftreten, und es gibt 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.^[7][41][42]

Kritik

Eine Unterstützung in Form von technischen Anleitungen oder gar Tools zur Migration von On-Premises- zu PaaS-Anwendungen haben die meisten Anbieter nicht im Programm. Sie bieten lediglich Tools an, um Daten in die Cloud zu importieren und exportieren und virtuelle Maschinen-Images in die Cloud zu laden. Das 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, zum Teil befinden sich diese Angebote allerdings noch 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,^[43][44][45] was für viele Unternehmen wichtig ist.^[5]

Vorsicht ist geboten bei einigen Diensten, die zwar angeben, PaaS-Angebote zu haben, die mit diesem Begriff jedoch ein Off-Premises-Hosting ohne Skalierbarkeit bezeichnen.^[2][46]

Anbieter

Es gibt etliche Anbieter von öffentlichen und privaten PaaS-Angeboten, die sich mehr oder weniger unterscheiden. Alle bieten Applikation-Hosting und eine Entwicklungsumgebung, gemeinsam mit Integration-Services, an.^[47]

Öffentliche und private PaaS-Angebote umfassen:

• Amazon Web Services (AWS)
• Dimension Data Public Cloud und Dimension Data Private Cloud
• Google Cloud Platform
• IBM Cloud
• Microsoft Azure
• Salesforce App Cloud
• SAP Cloud Platform
• Swisscom Application Cloud
• Open Telekom Cloud (T-Systems)

Weblinks

• PaaS-Providers.com, Platform-as-a-Service-Marktüberblick.
• deutsche Präsentation zum Thema PaaS mit Marktüberblick
• 4CaaSt – EU-Forschungsprojekt zur Erstellung einer erweiterten PaaS-Cloud-Plattform, Archiv (Memento vom 9. Juni 2017 im Internet Archive)

Einzelnachweise

1. G. Raines, L. Pizette: Platform as a Service: A 2010 Marketplace Analysis. 2010-10, mitre.org (PDF) abgerufen am 2. Juni 2012
2. Y. V. Natis, T. Jones, B. J. Lheureux, K. Iijima, E. Knipp, D. M. Smith. Predicts 2011: Platform as a Service: The Architectural Center of the Cloud. Gartner, 24. November 2010
3. M. Fouquet, H. Niedermayer, 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, interoperabilitybridges.com (Memento vom 25. April 2017 im Internet Archive) abgerufen am 2. Juni 2011
5. K. Friedmann: Cloud Computing in Deutschland: Der Markt für Cloud-Services wird sich bis Ende 2011 verdoppeln. (Memento vom 10. September 2012 im Internet Archive) cio.de, 3. August 2010; abgerufen am 2. Juni 2011
6. Cloud Hype at Height: Gartner. In: Cloud Computing Journal, 17. August 2009, cloudcomputing.sys-con.com (Memento vom 25. April 2017 im Internet Archive) abgerufen am 6. Mai 2011
7. AWS Elastic Beanstalk (beta). aws.amazon.com Amazon, 2010; abgerufen am 2. Juni 2011
8. W. Tonninger: Die Cloud-Gretchen-Frage: IaaS oder PaaS? 25. Februar 2011, businessreadyblog.wordpress.com abgerufen am 2. Juni 2011
9. Willkommen bei Google Drive. Google, 2011, drive.google.com abgerufen am 26. April 2012
10. iPaaS: Integration for the Cloud Era. MuleSoft, 2011, mulesoft.com abgerufen am 3. Juni 2011
11. iPaaS Software 2020. Abgerufen am 26. November 2020. 
12. Open Platform as a Service
13. Django – The Web framework for perfectionists with deadlines. 2011, djangoproject.com abgerufen am 3. Juni 2011
14. A. Lenk, M. Klems, J. Nimis, S. Tai, T. Sandholm: What’s Inside the Cloud? An Architectural Map of the Cloud Landscape. ICSE’09 Workshop, 23. März 2009
15. microsoft.com
16. aws.amazon.com
17. aws.amazon.com
18. code.google.com (Memento vom 16. Januar 2012 im Internet Archive)
19. 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. R. Mietzner, T. Unger, R. Titze und F. Leymann. Combining Different Multi-Tenancy Patterns in Service-Oriented Applications.
21. StartingPage, 30. Mai 2011, wiki.openstack.org abgerufen am 5. Juni 2011
22. Open Cloud Computing Interface – Open Standard – Open Community. 2011, abgerufen am 5. Juni 2011
23. App Engine Java Overview - Google App Engine. (Memento vom 25. Februar 2012 im Internet Archive) Google Code; abgerufen am 5. Juni 2011
24. Amazon Web Services. 2011 (deutsch), aws.amazon.com abgerufen am 5. Juni 2011
25. Windows Azure Platform Features. Microsoft, 2011, microsoft.com abgerufen am 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, github.com (PDF); abgerufen am 5. Juni 2011
28. The Java Servlet Environment. (Memento vom 13. Mai 2010 im Internet Archive) code.google.com; abgerufen am 2. Juni 2011
29. Task Queue Java API Overview - Google App Engine. (Memento vom 7. März 2010 im Internet Archive) code.google.com; abgerufen am 2. Juni 2011
30. Amazon Simple Queue Service (Amazon SQS). Amazon, 2010, aws.amazon.com abgerufen am 2. Juni 2011
31. Queue Service API. Microsoft, 2011, msdn.microsoft.com abgerufen am 2. Juni 2011
32. C. Baun, M. Kunze, J. Nimis und S. Tai. Cloud Computing: Web-basierte dynamische IT-Services.
33. Elastic Load Balancing. Amazon, 2011, aws.amazon.com abgerufen am 2. Juni 2011
34. Windows Azure CDN. (Memento vom 18. April 2012 im Internet Archive) Microsoft MDN; abgerufen am 2. Juni 2011
35. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1. Juni 1999 (englisch).
36. Quotas - Google App Engine. (Memento vom 27. Februar 2012 im Internet Archive) Google Code; abgerufen am 2. Juni 2011
37. Java Service APIs (Memento vom 24. August 2011 im Internet Archive) Google Code; abgerufen am 2. Juni 2011
38. Amazon Elastic Compute Cloud (Amazon EC2). 2011, aws.amazon.com abgerufen am 5. Juni 2011
39. Windows Azure Virtual Network – Windows Azure Platform. 2011, microsoft.com abgerufen am 5. Juni 2011
40. Overview of Multitenancy and the Namespaces Java API - Google App Engine. (Memento vom 22. August 2011 im Internet Archive) Google Code; abgerufen am 2. Juni 2011
41. Developer’s Guide - Google App Engine. (Memento vom 19. Februar 2012 im Internet Archive) Google Code; abgerufen am 2. Juni 2011
42. Windows Azure Platform Consumption. Microsoft, 2011, microsoft.com abgerufen am 2. Juni 2011
43. R. Blackwell: Azure Northern Europe is Dublin and Western Europe is Amsterdam. 12. April 2011, robblackwell.org.uk abgerufen am 2. Juni 2011
44. Amazon Web Services: Service Health Dashboard. status.aws.amazon.com (Memento des Originals vom 20. April 2008 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/status.aws.amazon.com abgerufen am: 2. Juni 2011
45. Issue 193. googleappengine - Country-specific Storage - Google App Engine. code.google.com Google Project Hosting; abgerufen am 2. Juni 2011
46. D. Chappell: The Windows Azure Programming Model. Microsoft, 2010-10, microsoft.com abgerufen am 2. Juni 2011
47. John R. Rymer: Enterprise Public Cloud Platforms, Q4 2014. (Memento des Originals vom 1. Oktober 2015 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.forrester.com In: Forrester, 29. Dezember 2014