Cloud Platforms / PaaS

Thomas Bachmann
Kleiststraße 21, 70197 Stuttgart info@thobach.de

Abstract. Platform as a Service (PaaS) is a dominant field in cloud computing. It helps organizations to reduce their costs for developing and operating applications and enables them to rapidly develop new applications without the need of buying hardware, operating system licenses or middleware components. PaaS offers a cheap entry point for ISVs to create, operate, distribute and manage their software over the Internet. This term paper introduces the offers of three big PaaS providers, explains what PaaS can be used for and what is different to on premise application hosting. Keywords: PaaS, Cloud Platforms, Windows Azure, Google App Engine, Amazon Elastic Beanstalk, Development, Programming Model, Runtime Environment, Persistence, Concurrency, Application Access, Multi-Tenancy

1 Einführung
Diese Seminararbeit über Platform as a Service (PaaS) ist im Rahmen des Cloud Computing Hauptseminars im Sommersemester 2011 an der Universität Stuttgart entstanden und bietet einen Überblick über das Thema PaaS. Zuerst wird dazu das Thema motiviert und genauer definiert, danach folgt ein Marktüberblick und der Plattformgedanke sowie die einzelnen Plattformbestandteile werden kurz betrachtet. Hier wird besonders auf die Unterschiede gegenüber der Anwendungsentwicklung für Application Server Bezug genommen. Zum Schluss folgt eine Zusammenfassung und eine kurze Bewertung mit einem Ausblick auf das Thema PaaS. 1.1 Motivation Zwischen Oktober 2009 und Oktober 2010 haben mehr als 100 PaaS Anbieter den Markt betreten [7]. Sie treten an um ihren Kunden möglichst viele administrative Aufgaben abzunehmen, Skalierbarkeit und Hochverfügbarkeit zu ermöglichen [31], Fixkosten zu senken, Gesamtkosten zu senken, mehr Flexibilität zu geben, sowie eine schnelle Anwendungsentwicklung und einen schnellen Markteintritt zu ermöglichen [8], [26]. 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.

1

1.2 Definitionen Der Begriff Platform as a Service (PaaS) umspannt einen weiten Bereich im Cloud Computing Spektrum. PaaS Angebote bauen auf einer skalierbaren Infrastruktur (IaaS) von Speicher und Rechenleistung auf um Mehrwertdienste anzubieten. [7] Anhand dieser Mehrwertdienste können auch weitere SaaS Angebote entstehen. Somit ist PaaS die mittlere Schicht im Cloud Stack, wie Abbildung 1 zeigt. [8]
Cloud  Anwendungen  
•  Software  as  a  Service  (SaaS)  

Cloud  Plattformen  
•  Platform  as  a  Service  (PaaS)  

Cloud  Infrastruktur  
•  Infrastructure  as  a  Service  (IaaS)  

Abbildung 1 Cloud Stack Die angebotenen Dienste sind vor allem Bündelungen von MiddlewareTechnologien wie Application Server, Datenbankmanagement-Systeme, Portale, Integrationsplattformen oder BPM-Tools. Diese werden über APIs an Entwickler zur Verfügung gestellt. Es werden aber auch Entwicklungsumgebungen für die Erstellung von (Web-)Anwendungen, programmierbare Rechenplattformen oder große Datenspeicher zur Verfügung gestellt. Dabei werden alle Schritte vom „Design, der Entwicklung, dem Test, Deployment bis hin zum Hosting von Anwendungen“ unterstützt und auch zusätzliche Dienste wie „Teamkollaboration, Sicherheit, Monitoring, Versionierung oder Instrumentierung von Anwendungen“ angeboten. [7], [8], [9] Gartner unterteilt PaaS Angebote nach den zugehörigen Projekttypen in Application PaaS (aPaaS) und Integration and Governance PaaS (iPaaS). Unter aPaaS versteht man eine „comprehensive cloud environment for building and hosting business applications exposed through user interfaces and programmatic, SOA-style interfaces“ wie zum Beispiel eine Webanwendung zum Verwalten von Terminen welche in der Google App Engine laufen könnte. Im Gegensatz dazu steht iPaaS als „comprehensive cloud environment for facilitating the intermediation between application services via interoperability, integration and governance of heterogeneous cloud-based (as well as on-premises-based) services and applications“ wie zum Beispiel Adapter die verschiedene Cloud Dienste wie auch On Premise Dienste verbinden und dies wiederum als Cloud Dienst anbieten 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. [4], [8] Es existiert auch eine Unterteilung von PaaS in Entwicklungs- und Ausführungsumgebung. Damit soll ermöglicht werden sich auf eine Entwicklungsumgebung, wie zum Beispiel Django [6], festzulegen aber bei der Wahl der Ausführungsumgebung flexibel zu sein und hier auch zwischen Anbietern zu wechseln. [10] In dieser Seminararbeit werden die Begriffe PaaS Dienst und Cloud Plattform synonym verwendet.

2

1.2 Bedeutung Momentan werden PaaS Angebote nur von „leading-edge users“ genutzt, da „mainstream users“ den aktuellen PaaS Angeboten noch skeptisch gegenüber stehen. [8] 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. [8]

Abbildung 2 Hypekurve der kommenden Technologien, 2009 [11] Im Jahr 2009 hatte das Thema Cloud Computing insgesamt einen Höhepunkt auf der Gartner Hypekurve, wie in Abbildung 2 zu sehen ist. 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 aPaaS Angebote wie Force.com zu nutzen um Kundenanwendungen ortstransparent, an eine Vielzahl von Nutzern zu bringen. Dabei hat sich herausgestellt, dass sich aPaaS 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. [8]

3

1.3 Abgrenzung

Abbildung 3 Gegenüberstellung von traditioneller IT und den verschiedenen Cloud Layern [13] Eine Abgrenzung von PaaS zu IaaS Angeboten ist schwer, da viele PaaS Angebote die Dienste von darunterliegenden IaaS Angeboten nutzen und nur bündeln [14]. 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, wie Abbildung 3 zeigt, nicht um das Betriebssystem, die Middleware und Laufzeitumgebung für seine Anwendung kümmern, wie es bei IaaS Angeboten der Fall ist [13]. 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 deployen. Der Zugriff auf diese Middleware-Dienste geschieht über APIs. Es existieren allerdings auch SaaS Angebote wie Google Docs [28], die Entwicklern Schnittstellen zur Verfügung stellen, diese sind allerdings meist dafür gedacht die SaaS Anwendung zu erweitern oder mit ihr zu kommunizieren. Auch SaaS Anwendungen ohne graphische Benutzerschnittstelle sind denkbar aber nicht weit verbreitet. Diese Seminararbeit konzentriert sich auf PaaS Angebote für die Programmiersprache Java, da der Autor hier die meisten Erfahrungen hat, der Umfang der Arbeit für weitere Programmiersprachen nicht ausreicht und Java eine wichtige Rolle in großen Unternehmen spielt.

4

2 Marktüberblick
Der Cloud Computing Markt wird sehr stark von der Industrie und einzelnen Anbietern geprägt. Daher wird zuerst in einem Marktüberblick der aktuelle Stand an PaaS Angeboten dargestellt.
Anbieter (PaaS Produkt) / Dienst Amazon (Elastic Beanstalk) Google (App Engine) Microsoft (Azure) Speicher & CDN1 S3, EBS, CloudFront Rechenleistung Datenbank Netzwerk Integration, MW

EC2, Elastic MapReduce

RDS, SimpleDB

Blobstore

Google App Engine, Backends Azure Compute (Web Role, Worker Role, VM Role)

App Engine Datastore

Elastic Load Balancing, Elastic Auto Scaling URL Fetch

SQS, SNS, SES

Azure Storage, Azure CDN, Azure AppFabric

SQL Azure

Azure Virtual Network

Google Accounts, Scheduled Tasks, Task Queues Azure AppFabric

Tabelle 1 Überblick über PaaS Dienste einzelner Anbieter Für den Marktüberblick wurden die Anbieter Amazon, Google und Microsoft herausgegriffen, da sie einen großen Marktanteil und eine große Marktmacht haben [38]. Tabelle 1 zeigt die Dienste dieser drei PaaS Anbieter im Vergleich. Auf salesforce mit ihrem VMforce Produkt [37] trifft dies zwar auch zu, allerdings hat dieser Anbieter einen ganz anderen Ansatz. Anwendungen die in der salesforce Cloud laufen können nur die salesforce Datenbank benutzen und sind fest in die force.com Plattform integriert [39]. Es geht also vielmehr darum die SaaS Lösung von salesforce mit eigenen Anwendungen zu erweitern, als eigenständige Anwendungen in der Cloud laufen zu lassen. Salesforce ist eigentlich ein SaaS Unternehmen mit Geschäftsanwendungen für CRM und Vertrieb. [40] Erst durch die Kooperation mit VMware entstand ein das PaaS Angebot VMforce mit der engen Bindung an die bestehenden SaaS Anwendungen [41]. Aber auch neben VMforce besteht bei salesforce mit Appforce die Möglichkeit Anwendungen durch die Definition von Workflows, Datenbankschemata und GUI Masken zu erstellen, alles mit wenig oder gar keinem Programmieraufwand [42]. 2.1 Windows Azure Microsoft veröffentlichte im Februar 2010 ihre Windows Azure Platform. Dazu das cloudbasierte Betriebssystem Windows Azure und der Datenbankdienst SQL Azure [15].

1

CDN: Content Delivery/Distribution Network, ein mit dem Internet verbundenes Netzwerk um Webinhalten möglichst schnell an den Konsumenten auszuliefern.

5

Windows Azure unterteilt sich nochmal in Compute, Storage, AppFabric, Virtual Network, CDN und Marketplace. Compute stellt drei sogenannte Rollen zur Verfügung: Web Role als Container für Webanwendungen, Worker Role für unter anderem nebenläufige oder rechenintensive Aufgaben und die VM Role (beta) welche „user-provided Windows Server 2008 R2 image[s]“ in der Cloud hosten. Storage erlaubt das Speichern von Daten in Blobs, Tabellen oder Queues und AppFabric stellt Infrastrukturdienste wie einen Service Bus, Access Control, Caching, Integration und Composite App für verteilte Anwendungen zur Verfügung. [16] Der Betrieb einer kleinen Webanwendung2 kostet rund $ 40 pro Monat. [17] Durch die VM Role erlaubt es Microsoft eigene Windows Server Images in ihren Rechenzentren laufen zu lassen und damit bisherige On Premise Lösungen in der Cloud laufen zu lassen. Allerdings ist man hier auf dieses eine Betriebssystem festgelegt. Die Web Role erlaubt es Anwendungen in einer Vielzahl von Programmiersprachen (.NET (C# and Visual Basic), C++, PHP, Ruby, Python, Java [22]) zu deployen. Abgestimmt ist die Windows Azure Platform allerdings auf das .Net Framework und Visual Studio. [16] Es gibt zwar eine Eclipse-Integration, allerdings nur für Windows [31]. Microsoft bietet außerdem ihre Infrastruktur auch als Appliance an, um sich eine Windows Azure private Cloud im eigenen Rechenzentrum aufzubauen. [27] Im Vergleich zur Google App Engine und Amazons Elastic Beanstalk unterstützt Microsoft die meisten Programmiersprachen und hat ein auffallendes Rollensystem. Um allerdings eine Java Servlet Anwendung zu deployen kann man nicht einfach eine WAR Datei hochladen, sondern man muss die eigene Anwendung inklusive einem Tomcat Application Server in eine Worker Role verpacken und deployen [3]. 2.2 Google App Engine (GAE, beta) [29] Die Google App Engine wurde im April 2008 als Beta vorgestellt [19]. Es bietet einen eingeschränkten [20] Java Servlet Container und die Möglichkeit Python und Go Programme laufen zu lassen. Als Dienste werden ein Datastore (schemalos), Blobstore, Channel (socket), Multitenancy (via Namespaces), OAuth, Users (Google Accounts), URL Fetch, Mail, Memcache, Image Manipulation, XMPP, Scheduled Tasks und Task Queues angeboten. Aktuell ist die GAE immernoch im Beta-Stadium und bietet einen Business Dienst mit SLAs, anderem Pricing-Modell und 1:1 Support im „Preview“-Stadium an. Der Betrieb einer kleinen Webanwendung3 kostet rund $ 65 pro Monat. Es existieren auch freie Implementierungen der GAE namens AppScale und TyphoonAE. Diese Software benutzt Open Source Anwendungen um alle Dienste der GAE Laufzeitumgebung nachzubilden. Diese Nachbildung kann dann selbst wiederum auf IaaS Angeboten wie Amazons EC2 betrieben werden. AppScale zum Beispiel benutzt als Load Balancer NGINX, haproxy und eine Ruby on Rails
2 3

1x Compute (Extra small instance), 1 GB Storage, 15 GB Traffic eingehend, 15 GB Traffic ausgehend [17] 1 x App Engine Instanz (6,5h pro Tag inklusive), 1 GB Speicher (inklusive), 15 GB Traffic eingehend (1 GB inklusive), 15 GB ausgehend (1 GB inklusive)

6

Oberfläche, als Application Server ein modifiziertes GAE SDK und als Datenbanken werden unter anderen HBase, MySQL Cluster oder MongoDB unterstützt. Die alternative Implementierung TyphoonAE benutzt zum Beispiel einen Apache2 HTTP Server in Verbindung mit NGINX und FastCGI, memcached als Memcache Backend, RabbitMQ und ejabberd für die Task Queue und Messaging API. [21], [30] Eine Besonderheit der GAE im Vergleich zu Windows Azure und Amazons Elastic Beanstalk sind sogenannte harte Quotas. Diese gestatten es zum Beispiel nicht mehr als 32.000 HTTP Aufrufe pro Minute zu triggern oder mehr als 5.100 E-MailEmpfänger pro Minute zu kontaktieren. Diese Quotas lassen sich nur auf manuelle Anfrage erhöhen. Es ist auch nicht möglich wie bei Amazons Elastic Beanstalk sich auf die GAE per ssh einzuloggen und sie zu konfigurieren. Anwendungen können lediglich per API deployed, konfiguriert und kontrolliert werden. 2.3 Amazon Elastic Beanstalk (beta) [14] Amazon startete seinen Virtual Machine (EC2)- und Online Speicherdienst (S3) im Jahr 2006 und fügte nach und nach weitere Dienste wie SimpleDB oder Simple Queue Service hinzu. Im Januar 2011 wurden die vorhanden Dienste „Amazon EC2, Amazon S3, Amazon Simple Notification Service, Elastic Load Balancing, and AutoScaling“ zu AWS Elastic Beanstalk (beta) zusammengeführt und bilden damit ein PaaS Angebot allerdings nur für Java. Die Anwendungen können als WAR in einen Apache Tomcat deployed werden. Der Betrieb einer kleinen Webanwendung4 kostet laut Amazon rund $ 38 pro Monat. Die Besonderheit bei Elastic Beanstalk im Vergleich zur GAE oder Windows Azure ist die Möglichkeit die Images auszutauschen und sich direkt auf die virtuellen Maschinen einzuloggen und sie damit zu kontrollieren. Beim Upload einer Anwendung wird jede neue Version im S3 Dienst gespeichert und es findet eine automatische Allokation der benötigen Ressourcen wie EC2 Instanzen und Load Balancer statt. Wenn die Leistung einer EC2 Instanz nicht mehr alle Benutzer in ausreichender Geschwindigkeit bedienen kann, wird automatisch eine weitere EC2 Instanz hochgefahren und die Anfragen werden gleichmäßig verteilt. 2.4 Kritik Die drei vorgestellten „großen“ PaaS Anbieter bieten alle grundlegende Funktionen um einfache Webanwendungen in der Cloud laufen zu lassen. Professioneller Support wird auch von allen drei Diensten angeboten, jedoch ist GAE hier noch in der Beta-Phase. Die generelle Datenschutz-Problematik beim Cloud Computing wird von den Diensten für deutsche Unternehmen jedoch nicht

4

1x Amazon EC2 t1.micro instance, 1x Elastic Load Balancer + 15 GB Data Processing, 8 GB Elastic Block Store volume, 1 GB Storage (S3), 15 GB Traffic eingehend, 15 GB Traffic ausgehend [14]

7

angegangen, da die Daten nicht in deutschen Rechenzentren liegen [23], [24], [25] was für viele Unternehmen wichtig ist [26]. Vorsicht gilt bei einigen Diensten, die zwar angeben PaaS Angebote zu haben, wo aber im Endeffekt nur ein Off Premise osting ohne Skalierbarkeit dahintersteckt [8, Seite 11], [32].

3 Plattformgedanke und -bestandteile
Im folgenden Abschnitt wird das Programmiermodell und die Laufzeitumgebung von Cloud Plattformen mit ihren einzelnen Bestandteilen beschrieben. Dabei wird sowohl die Anwendungsentwickler-, Plattformanbieter- als auch die Endanwendersicht betrachtet. 3.1 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 Amazons Elastic Beanstalk keine Sticky Sessions/Cookies verwendet. Veränderungen am Betriebssystem müssen bei jedem Start einer Instanz einer Rolle vorgenommen werden und Daten die lokal gespeichert werden, sind nicht für alle Instanzen verfügbar und können beim Neustart einer Instanz verloren gehen. Um die Kommunikation zwischen Rollen zu ermöglichen, muss auf eine Message Queuing System gesetzt werden, wobei dies eine at-least-once Semantik verfolgt und somit die Verarbeitung der Messages idem potent sein muss. [31] 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. 3.2 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

8

schließlich in die Cloud Plattform deployed. Viele Anbieter wie GAE, 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 deployen. 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. 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. Die allein lässt die Anwendungen an sich aber noch nicht skalieren, sondern ist eher mit einer Remote Hosting Lösung vergleichbar. Um den Aufwand bei beschränkt benötigter Skalierbarkeit zu minimieren gibt es Multi-Tenancy Patterns [49], [1] die zum Beispiel nicht mandantenfähige Anwendungen mit geringem Aufwand mandantenfähig macht, allerdings unter der Prämisse eingeschränkter Skalierbarkeit.

3.3 Laufzeitumgebung Die Laufzeitumgebung 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 GAE bieten nur eine Teilmenge der eigentlichen Laufzeitumgebungen um die Skalierbarkeit und Ausfallsicherheit zu gewährleisten. So ist es zum Beispiel in der GAE 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 einer erschwerte Portierbarkeit, da die zusätzlichen Dienste nicht anbieterübergreifend über einheitliche APIs verfügbar sind. Es gibt zwar Standardisierungsgremien wie

9

openstack [18] und Occi [51] jedoch fokussieren diese ihre Arbeit mehr auf die Standardisierung der Management und Speicher APIs und nicht auf die Anwendungscontainer. Aus Endanwendersicht hat das andere Programmiermodell und die andere Laufzeitumgebung in der Regel keinen Einfluss. Ein PaaS Anbieter muss sich Gedanken über eine möglich Einschränkung der zu Grunde liegenden Laufzeitumgebungen wie JEE oder .Net Application Servern machen um seine Stabilität zu gewährleisten, denn der Versand von zu vielen E-Mails in einer Zeiteinheit oder zu viele Netzwerkanfragen einer einzelnen Anwendung können enorme Beeinträchtigungen auf die Antwortzeiten der anderen laufenden Anwendungen haben, denn gerade die ein- und ausgehende Netzwerkbandbreite ist immer begrenzt. 3.4 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. [52], [53], [54] 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 [55]. 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 [56]. 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. 3.5 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

10

Beendung abgebrochen werden. Außerdem bietet zum Beispiel die GAE keine Möglichkeit neue Threads in seiner Anwendungen zu starten [20] um die Stabilität der GAE 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 GAE erlaubt das Anstoßen asynchroner Aufgaben zum Beispiel mittels der Dienste Scheduled Tasks und Task Queue [35]. Bei Amazon gibt es dazu den Amazon Simple Queue Service [36] und bei Windows Azure die Queue Service API aus den Windows Azure Storage Services [33]. Obwohl Windows Azure und Amazon’s 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. 3.6 Zugriffsschicht Der Zugriff auf Anwendungen in der Cloud geschieht über das Internet oder unternehmensintern auch über das Intranet [43, Seite 1-4]. 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 Web Socket 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 [46] oder ein CDN die Ressourcen nah an den Nutzer bringen [47]. [45] 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. [48] [20] Die GAE erlaubt zum Beispiel keine freie Netzwerkkommunikation, hierfür muss eine API von Google genutzt werden, die HTTP/S (URL Fetch), XMPP und Web Socket (Channel) unterstützt. [44] 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. [58] 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. [57]

11

3.7 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 (engl. Multi-Tenancy) 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 MultiTenancy), 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. [49], [1] 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. [50] Alternativ kann auch auf verschiedene Patterns aus [49], [1] 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.

4 Zusammenfassung und Ausblick
Abschließend folgt eine Zusammenfassung und ein Ausblick auf das Thema PaaS. 4.1 Zusammenfassung PaaS Anbieter ermöglichen eine schnelle und kostengünstige Entwicklung von Webanwendungen, die dabei noch dynamisch skalierbar und hochverfügbar ist. Der Aufbau einer PaaS Infrastruktur ähnelt einem weit überdimensionierten konventionellen Cluster von Application Servern mit einem Load Balancer und einem gut skalierbaren Datenbank Backend, wie aus den OpenSource Projekten TyphoonAE und AppScale ersichtlich ist. Hinzu kommt noch ein Monitoring verbunden mit Autoskalierbarkeit zur dynamischen Ressourcenbereitstellung sowohl nach oben als

12

auch nach unten und einige Management APIs. Neu aus Entwicklersicht ist, dass man keine Infrastruktur bereitstellen, betreiben und warten muss. Somit wird der Administrationsaufwand gesenkt, ein Pay-as-you-go Bezahlmodell ermöglicht und die Einstiegsbarrieren und Entwicklungszeit für neue Softwareprojekte gesenkt. Viele Anbieter nutzen existierende und etablierte Software um eine PaaS Umgebung aufzubauen und fügen ein Monitoring samt Deployment-Automatisierung und eine Weboberfläche samt APIs zum administrieren der Umgebung hinzu. Weiterhin werden meist anbieterspezifische Datenspeicher- und Datenbanklösungen zur Verfügung gestellt. Für Unternehmen, die keine rechtlichen Probleme mit PaaS Diensten sehen und keine Verfügbarkeit von mehr als 99,9% ihrer Anwendungen benötigen, lohnt es sich Anwendungen in die Cloud zu deployen, wenn sie von der flexiblen Ressourcennutzung Gebrauch machen können und keine besonderen Anforderungen an die Application Server Auswahl und Konfiguration haben. Auch vor der Anschaffung neuer Hardware sollte überlegt werden, ob bestehende oder neue Anwendungen nicht in eine PaaS Umgebung migriert werden können. Komplexe Anwendungen lassen sich in der Regel nicht in eine PaaS Umgebung migrieren, da sie weit mehr als einen Application Server samt Datenbankanbindung benötigen und meist auch eine wichtige Anwendungen für das Unternehmen darstellen, dessen Kontrolle man noch nicht aufgeben will. Wenn nur technisch gesehen eine PaaS Umgebung nicht ausreicht, lohnt es sich auch zu evaluieren ob eine IaaS Struktur genug Freiraum gibt, allerdings sind hiermit wieder wesentlich mehr Verwaltungsaufgaben verbunden. 4.2 Ausblick Die PaaS Technologien scheinen bei einigen großen Anbietern wie Amazon und Microsoft bereits ausgereift und sind dennoch zum Teil in der Beta-Phase. Andere kleinere oder jüngere Anbieter können die Versprechen von hoher Skalierbarkeit noch nicht halten. Auch für den deutschen Mittelstand sind die bisherigen Angebote kaum ausreichend. Dies steht und fällt schon mit dem Mangel an deutschen Rechenzentren und deutschem Gerichtsstand. [2] Für viele Unternehmen spielt die Portierbarkeit von PaaS Anwendungen eine große Rolle um bei günstigeren Konditionen oder verlorenem Vertrauen zur Konkurrenz zu wechseln. So ist ein Wechsel zum Beispiel von der Google App Engine zu Amazons Elastic Beanstalk Angebot aus eigener Erfahrung mit vertretbarem Aufwand möglich, da beide Angebote auf dem JEE Servlet Container aufbauen, auch wenn die GAE hier einige Einschränkungen hat. Microsoft hingegen erschwert mit ihrem zusätzlichen Rollen-Konzept die Portierbarkeit. Bei einer JEE Anwendung müsste der Tomcat Application Server zum Beispiel mit in eine Worker Role gepackt und mit ausgeliefert werden. Dies hat dann nur noch wenig mit PaaS zu tun. [3] Probleme wie diese zeigen, dass es einen Bedarf an Standardisierungen auch im PaaS Bereich gibt. Die großen Anbieter zeigen daran aktuell allerdings wenig Interesse. Vor allem die anbieterabhängigen APIs und SDKs bedürfen einer Standardisierung um das Vendor Lock-In zu minimieren.

13

Größere Unternehmen und Unternehmen mit sehr sensiblen Kundendaten werden versuchen ihre eigenen Rechenzentren weiter zu virtualisieren und darauf eigene Cloud Lösungen aufzubauen um weiter die volle Kontrolle über ihre Infrastruktur zu haben.

Quellen
[1] 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 (CECEEE 2007), 2007 [2] P. Marwan. Cloud Computing: Die meisten Anbieter sind noch nicht so weit. ZDNet.de, 2010-04-14, http://www.zdnet.de/it_business_hintergrund_cloud_computing_die_meisten_anbieter_si nd_noch_nicht_so_weit_story-11000006-41530450-1.htm, Abrufdatum: 2011-06-02 [3] cesardl. Developing and Deploying Java-Tomcat apps into Windows Azure. Microsoft, 2010-09-12, http://blogs.msdn.com/b/cesardelatorre/archive/2010/09/12/developing-anddeploying-java-tomcat-apps-into-windows-azure.aspx, Abrufdatum: 2011-06-02 [4] unbekannt. iPaaS: Integration for the Cloud Era. MuleSoft, 2011, http://www.mulesoft.com/ipaas-integration-platform-as-a-service, Abrufdatum: 2011-0603 [5] I. Foster, C. Kesselman, J. Nick und S. Tuecke. The Physiology of the Grid: an Open Grid Services Architecture for Distributed Systems Integration. Technical report, Global Grid Forum, 2002 [6] unbekannt. Django | The Web framework for perfectionists with deadlines. 2011, https://www.djangoproject.com/, Abrufdatum: 2011-06-03 [7] 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: 2011-06-02 [8] 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, 2010-11-24 [9] M. Fouquet, H. Niedermayer und G. Carle. Cloud Computing for the Masses. 2009-12-01

[10] 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, 2009-03-23

14

[11] unbekannt. Cloud Hype at Height: Gartner. Cloud Computing Journal, 2009-08-17, http://cloudcomputing.sys-con.com/node/1067894, Abrufdatum: 2011-05-06 [12]. unbekannt. Gartner Magic Quadrant Leader. Savvis Inc, 2011, http://www.savvis.com/en-US/Advantages/Pages/Gartner-Magic-Quadrant-Leader.aspx, Abrufdatum: 2011-06-02 [13] W. Tonninger. Die Cloud-Gretchen-Frage: IaaS oder PaaS?. 2011-02-25, http://businessreadyblog.wordpress.com/2011/02/25/die-cloud-gretchen-frage-iaas-oderpaas/, Abrufdatum: 2011-06-02 [14] unbekannt. AWS Elastic Beanstalk (beta). http://aws.amazon.com/elasticbeanstalk/, Amazon, 2010, Abrufdatum: 2011-06-02 [15] unbekannt. Windows Azure Platform Now Generally Available in 21 Countries. Microsoft, 2011-02-01, http://blogs.msdn.com/b/windowsazure/archive/2010/02/01/windows-azure-platformnow-generally-available-in-21-countries.aspx, Abrufdatum: 2011-06-02 [16] D. Chappell. Introducing the Windows Azure Platform. 2010-10, http://www.microsoft.com/windowsazure/Whitepapers/introducingwindowsazureplatfor m/default.aspx, Abrufdatum: 2011-06-02 [17] unbekannt. Windows Azure Platform Consumption. Microsoft, 2011, http://www.microsoft.com/windowsazure/offers/popup/popup.aspx?lang=en&locale=enus&offer=MS-AZR-0003P, Abrufdatum: 2011-06-02 [18] unbekannt. StartingPage – Wiki. openstack, 2011-05-30, http://wiki.openstack.org/, Abrufdatum: 2011-06-05 [19] P. McDonald. Introducing Google App Engine + our new blog. 2008-04-07, http://googleappengine.blogspot.com/2008/04/introducing-google-app-engine-ournew.html, Abrufdatum: 2011-06-02 [20] unbekannt. The Java Servlet Environment. Google, 2011, http://code.google.com/intl/deDE/appengine/docs/java/runtime.html#The_Sandbox, Abrufdatum: 2011-06-02 [21] unbekannt. appscale: Open Source Platform for Google AppEngine Apps. http://code.google.com/p/appscale/, Abrufdatum: 2011-06-02 [22] unbekannt. Windows Azure Platform and Interoperability. http://www.microsoft.com/windowsazure/interop/, Abrufdatum: 2011-06-02 [23] R. Blackwell. Azure Northern Europe is Dublin and Western Europe is Amsterdam. 2011-04-12, http://www.robblackwell.org.uk/2011/04/12/azure-northern-europe-isdublin-and-western-europe-is-amsterdam.html, Abrufdatum: 2011-06-02

15

[24] unbekannt. Amazon Web Services: Service Health Dashboard. http://status.aws.amazon.com/, Abrufdatum: 2011-06-02 [25] unbekannt. Issue 193 - googleappengine - Country-specific Storage - Google App Engine - Google Project Hosting. http://code.google.com/p/googleappengine/issues/detail?id=193, Abrufdatum: 2011-0602 [26] K. Friedmann. Cloud Computing in Deutschland: Der Markt für Cloud-Services wird sich bis Ende 2011 verdoppeln. 2010-08-03, http://www.cio.de/dynamicit/management_strategie/2226947/index3.html, Abrufdatum: 2011-06-02 [27] unbekannt. Windows Azure Platform Appliance. Microsoft, 2011, http://www.microsoft.com/windowsazure/appliance/, Abrufdatum: 2011-06-02 [28] unbekannt. Willkommen bei Google Text & Tabellen. Google, 2011, http://docs.google.com, Abrufdatum: 2011-06-03 [29] unbekannt. Developer's Guide - Google App Engine - Google Code. Google, 2011, http://code.google.com/intl/de-DE/appengine/docs/, Abrufdatum: 2011-06-02 [30] unbekannt. typhoonae: Typhoon App Engine. 2011, http://code.google.com/p/typhoonae/, Abrufdatum: 2011-06-02 [31] B. Lobaugh. Deploying a Java application to Windows Azure with Command-line Ant. Microsoft, 2011-02-17, http://java.interoperabilitybridges.com/articles/deploying-a-javaapplication-to-windows-azure-with-command-line-ant, Abrufdatum: 2011-06-02 [32] D. Chappell. THE WINDOWS AZURE PROGRAMMING MODEL. Microsoft, 201010, http://www.microsoft.com/windowsazure/Whitepapers/ProgrammingModel/default.aspx, Abrufdatum: 2011-06-02 [33] unbekannt. Queue Service API. Microsoft, 2011, http://msdn.microsoft.com/enus/library/dd179363.aspx, Abrufdatum: 2011-06-02 [35] 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: 2011-06-02 [36] unbekannt. Amazon Simple Queue Service (Amazon SQS). Amazon, 2010, http://aws.amazon.com/de/sqs/, Abrufdatum: 2011-06-02 [37] unbekannt. VMforce - The fastest way to build enterprise Java apps - salesforce.com. salesforce.com, 2011, http://www.salesforce.com/platform/vmforce/, Abrufdatum: 201106-02

16

[38] S. Janata und C. Velten. Cloud Computing: Die wichtigsten Cloud-Anbieter im Vergleich. 2010-07-01, http://www.tecchannel.de/server/cloud_computing/2029069/die_wichtigsten_cloud_com puting_laas_saas_anbieter_im_vergleich/, Abrufdatum: 2011-06-02 [39] H. Gottipati. VMforce - Another Cloud Computing Solution for Java. 2010-04-28, Weblogic Journal, http://weblogic.sys-con.com/node/1372920, Abrufdatum: 2011-06-02 [40] unbekannt. Salesforce.com. 2011-05-12, http://de.wikipedia.org/wiki/Salesforce.com, Abrufdatum: 2011-06-02 [41] unbekannt. VMforce. http://www.vmforce.com/, 2011, Abrufdatum: 2011-06-02 [42] unbekannt. Force.com-Produkte - salesforce.com Deutschland. 2011, http://www.salesforce.com/de/platform/products.jsp, Abrufdatum: 2011-06-02 [43] C. Baun, M. Kunze, J. Nimis und S. Tai. Cloud Computing: Web-basierte dynamische ITServices. [44] unbekannt. Java Service APIs. 2011, http://code.google.com/intl/deDE/appengine/docs/java/apis.html, Abrufdatum: 2011-06-02 [45] 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: 2011-06-02 [46] unbekannt. Elastic Load Balancing. Amazon, 2011, http://aws.amazon.com/elasticloadbalancing/, Abrufdatum: 2011-06-02 [47] unbekannt. Windows Azure CDN. Microsoft, 2011, http://msdn.microsoft.com/enus/gg405416, Abrufdatum: 2011-06-02 [48] unbekannt. Quotas - Google App Engine - Google Code. Google, 2011, http://code.google.com/intl/deDE/appengine/docs/quotas.html#Billable_Quotas_and_Fixed_Quotas, Abrufdatum: 2011-06-02 [49] R. Mietzner, T. Unger, R. Titze und F. Leymann. Combining Different Multi-Tenancy Patterns in Service-Oriented Applications. [50] unbekannt. Overview of Multitenancy and the Namespaces Java API - Google App Engine - Google Code. Google, 2011, http://code.google.com/intl/deDE/appengine/docs/java/multitenancy/overview.html, Abrufdatum: 2011-06-02 [51] unbekannt. Open Cloud Computing Interface | Open Standard | Open Community. 2011, Abrufdatum: 2011-06-05

17

[52] unbekannt. App Engine Java Overview - Google App Engine - Google Code. 2011, http://code.google.com/intl/de-DE/appengine/docs/java/overview.html, Abrufdatum: 2011-06-05 [53] unbekannt. Amazon Web Services (Deutsch). 2011, http://aws.amazon.com/de/, Abrufdatum: 2011-06-05 [54] unbekannt. Windows Azure Platform Features. Microsoft, 2011, http://www.microsoft.com/windowsazure/features/, Abrufdatum: 2011-06-05 [55] 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 [56] A. Carter. The CAP Theorem as it Applies to Contemporary NoSQL Storage Systems. 2011-04-05, http://www.andrewjonascarter.com/files/ResearchPaper_Databases.pdf, Abrufdatum: 2011-06-05 [57] unbekannt. Windows Azure Virtual Network | Windows Azure Platform. 2011, http://www.microsoft.com/windowsazure/virtualnetwork/, Abrufdatum: 2011-06-05 [58] unbekannt. Amazon Elastic Compute Cloud (Amazon EC2). 2011, http://aws.amazon.com/de/ec2/, Abrufdatum: 2011-06-05

18

Sign up to vote on this title
UsefulNot useful