Platform as a Service

Platform as a Service
Google App Engine und Microsoft Windows Azure
Felix Richter
Matrikel-Nr. 92818
Studiengang: WID, FS 8
10.07.2010
Betreuer: Dipl.-Inf. Andreas Göbel
Blockseminar „Software as a Service, Cloud Computing und aktuelle Entwicklungen“
Lehrstuhl für Datenbanken und Informationssysteme, Institut für Informatik, FSU Jena
Inhalt
1
Einführung ....................................................................................................................................... 1
2
Platform as a Service ....................................................................................................................... 1
3
4
5
6
2.1
Begriffsklärung & Abgrenzung ............................................................................................... 1
2.2
Einordnung im Unternehmenskontext ..................................................................................... 2
Google App Engine ......................................................................................................................... 3
3.1
Überblick ................................................................................................................................. 3
3.2
Komponenten .......................................................................................................................... 3
3.3
App Engine Datastore ............................................................................................................. 3
3.4
Anfragesprachen: GQL & JDOQL .......................................................................................... 4
3.5
Services ................................................................................................................................... 4
Microsoft Azure .............................................................................................................................. 5
4.1
Produktübersicht ...................................................................................................................... 5
4.2
Windows Azure ....................................................................................................................... 6
4.3
AppFabric ................................................................................................................................ 7
4.4
SQL Azure ............................................................................................................................... 7
4.4.1
SQL Azure Database ....................................................................................................... 7
4.4.2
Architektur....................................................................................................................... 8
4.4.3
Vergleich mit dem SQL Server ....................................................................................... 8
Vergleich Google App Engine & Microsoft Azure ......................................................................... 9
5.1
Geschäftsmodell ...................................................................................................................... 9
5.2
Umgebung ............................................................................................................................. 10
5.3
Leistung ................................................................................................................................. 10
5.4
Datenhaltung ......................................................................................................................... 10
Fazit ............................................................................................................................................... 11
6.1
Auswirkungen von PaaS........................................................................................................ 11
6.2
Produktwahl........................................................................................................................... 12
6.3
Ausblick................................................................................................................................. 12
Literaturverzeichnis ................................................................................................................................. ii
i
1 Einführung
Software as a Service (SaaS) ist momentan eines der wichtigsten Themen im IT-Umfeld und wird
oft als die Zukunftstechnologie des 21. Jahrhunderts gesehen. Das Anbieten von Software und
Informationen als Versorgungsgut soll den klassischen Softwareentwicklungsansatz ablösen, bei
dem Anwendungen lokal beim Kunden installiert und betrieben werden. Die vielen Vorteile von
SaaS treten immer mehr hervor und werden durch die ständig steigende Verbreitung von
Breitband-Internetanschlüssen nutzbar gemacht. Nutzer, aber auch Anbieter von SaaS profitieren in
vielerlei Hinsicht von diesem neuen Softwareentwicklungsparadigma.
Allerdings ist gerade das Betreiben von SaaS an das anbieterseitige Vorhalten von
Reservekapazitäten für Spitzenlasten gebunden, so dass für das Unternehmen erhebliche
Investitionskosten entstehen. Dieser Umstand wird durch die Nutzung von IaaS- und PaaSAngeboten umgangen bzw. auf eine weitere Ebene zu einem vorgelagerten Unternehmen
verschoben. So wird die Anwendung und die Entwicklung dieser von den genutzten Rechen- und
Speicherkapazitäten entkoppelt, was verschiedene Vorteile mit sich bringt.
Nach einer Einführung in das Konzept von PaaS und einer kurzen Einordnung, werden im
Folgenden die zwei Größten der zahlreichen Anbieter in diesem Feld mit ihren Produkten
vorgestellt: Google App Engine und Microsoft Azure. Ein direkter Vergleich soll zeigen, in
welchen Bereichen die Stärken und Schwächen der beiden Angebote liegen und für welche
Anwendungsfälle sie in Frage kommen. Abschließend werden neben einer Zusammenfassung die
Auswirkungen des PaaS und des „Everything-as-a-Service“-Ansatzes betrachtet, sowie die
Entscheidungsfindung bei der Auswahl eines Anbieters analysiert.
2 Platform as a Service
2.1 Begriffsklärung & Abgrenzung
Mit dem Begriff „Platform as a Service“ wird das Anbieten einer Entwicklungsplattform auf Basis
von Cloud-Technologien bezeichnet. Typischerweise bestehen Produkte dieser Klasse aus einer
Laufzeit- und einer Entwicklungsumgebung. Dadurch wird dem Kunden – also dem entwickelnden
Unternehmen oder dem freien Entwickler – eine voll funktionsfähige Online-Plattform angeboten,
auf der der gesamte Softwareentwicklungsprozess ablaufen kann.
1
In der „Everything-as-a-Service“-Hierarchie befindet sich PaaS zwischen SaaS und IaaS.
Gegenüber SaaS unterscheidet sich diese Kategorie inbesondere durch die unterschiedliche
Zielgruppe: „die Cloud Services in der PaaS-Schicht richten sich meist […] an Entwickler“
[Bau10]
um SaaS-Produkte herzustellen und zu betreiben. Es werden nicht die Endnutzer
angesprochen, somit ist PaaS ein typischer B2B-Markt – mit Ausnahme privater Entwickler. Im
Vergleich zu IaaS ist herauszustellen, dass Systemressourcen wie CPU-Zeit oder physischer
Speicherplatz nicht durch den Nutzer verwaltet werden, sondern vom Anbieter selbst. Des
Weiteren wird bei PaaS-Produkten die Umgebung weitestgehend vorgegeben, während im IaaSBereich schon auf Betriebssystem- und systemnaher Anwendungsebene relativ viel Einfluss
möglich ist.
Im Folgenden werden zusätzlich diese Bezeichnungen verwendet: „PaaS-Anbieter“ oder nur
„Anbieter“ ist das Unternehmen, das die Ressourcen und damit die Anwendungsumgebung zur
Verfügung stellt. Als „Nachfrager“ wird der Nutzer der angebotenen Produkte bezeichnet, wobei
hier von einem Software entwickelnden Unternehmen ausgegangen wird. „SaaS-Anbieter“ ist ein
Nachfrager-Unternehmen, das die entwickelte Software Dritten am Markt anbietet.
2.2 Einordnung im Unternehmenskontext
PaaS kann für ein Nachfrager-Unternehmen grundsätzlich für zwei Zwecke eingesetzt werden. Es
kann auf dieser Basis Software für den Eigenbedarf oder aber für die Erstellung von eigenen
Produkten entwickelt werden.
Im
ersten
Fall
werden
typischerweise
lokale
Installationen
von
Verwaltungs-
oder
Kommunikationssoftware ersetzt oder ergänzt durch Cloud-basierte Anwendungen. Dies können
komplexe ERP-Systeme, aber auch relativ einfache Software wie Instant-Messenging-Dienste sein.
Wichtig ist, dass die Anwendungen nicht in einer Private Cloud, sondern in der Public Cloud des
Anbieters laufen und damit die Vor- und Nachteile typischer SaaS-Angebote teilen.
Als zweiten Anwendungsfall kommen SaaS-Anbieter in Betracht. Diese greifen auf die Ressourcen
des PaaS-Anbieters zurück statt selbst Kapazitäten zur Verfügung zu stellen. Somit beschränkt sich
das Unternehmen auf die Erstellung und Verwaltung der eigenen Anwendung und überlässt die
vorgelagerten Administrationstätigkeiten dem PaaS-Anbieter. Dies beeinflusst neben der Kostenund Personalstruktur auch den Softwareentwicklungsprozess, der nun schlanker gestaltet und durch
kürzere Entwicklungszyklen verbessert werden kann.
2
3 Google App Engine
3.1 Überblick
Google, als Betreiber von umfangreichen SaaS-Lösungen wie den Google Apps, hat in seinen
zahlreichen Rechenzentren eine sehr gut ausgebaute, performante Infrastruktur für die
Bereitstellung von Daten und Rechenkapazität aufgebaut. Diese Ressourcen stellt Google seit 2008
Entwicklern zur Verfügung, die auf der App-Engine-Plattform selbst Applikationen erstellen und
betreiben können. Google selbst beschreibt Applikationen auf der App Engine als „easy to build,
easy to maintain, and easy to scale […]“ [Goo10] .
3.2 Komponenten
Google App Engine besteht grundsätzlich aus vier Komponenten. Eine Java und Python
unterstützende Entwicklungs- und Laufzeitumgebung, den auf BigTable basierenden Datastore,
AppScale als Eucalyptus-basiertes lokal installierbares Programming Environment, sowie eine
Reihe von Services zur Erweiterung der Applikationen. Im Folgenden werden der Datastore und
die Services näher betrachtet.
3.3 App Engine Datastore
Der Datastore basiert auf Googles eigens entwickelter Datenbank BigTable. Damit steht eine hoch
performante und flexible Möglichkeit der Datenhaltung zur Verfügung. Implementierungsdetails
sollen in dieser Arbeit nicht thematisiert werden. Wichtig für Entwickler sind in diesem
Zusammenhang die logischen Aspekte von BigTable.
Eine zentrale Funktionalität sind Entity Groups, die eine Art Wald darstellen. Mit Vater- und KindDefinitionen (PARENT und ANCESTOR) können Beziehungen zwischen Entitäten abgebildet
werden. Dies bringt einige Besonderheiten mit, beispielsweise wird beim Speichern einer Entität
die gesamte damit verbundene Entity Group automatisch gespeichert. Außerdem können nur
Entitäten einer Entity Group innerhalb einer Transaktion bearbeitet werden [Goo10] .
Der Datastore nutzt Indextabellen als eine Art Anfragencache. Diese sind keine üblichen Indexe,
wie sie aus relationalen DBMSen bekannt sind, sondern einfache Tabellen, die Anfrageergebnisse
speichern. Sie enthalten die geforderten Projektionsspalten, sowie in WHERE-Bedingungen
auftretende Spalten.
3
Auch Transaktionen werden vom Datastore unterstützt, wobei innerhalb der Transaktion
vollständige Serialisierbarkeit gewährleistet wird. Google verwendet einen Commit mit zwei
Meilensteinen: Im ersten Schritt werden Entitäten geprüft und festgeschrieben, im zweiten Schritt
dann die oben erwähnten Indexe [Max08]
[Goo10] . Im Datastore wird dabei Optimistic
Concurrency Control genutzt, also vollständig auf Sperren verzichtet und am Transaktionsende
geprüft, ob Konflikte aufgetreten sind.
3.4 Anfragesprachen: GQL & JDOQL
In der Anwendung wird der Datastore mit deskriptiven Anfragesprachen angesteuert. Bei Nutzung
der Java-Umgebung steht JDOQL zur Verfügung. Wird Python verwendet, kann auf Googles GQL
zurückgegriffen werden.
JDOQL ist eine in Java eingebundene Sprache, die fundamentale Konstrukte wie Filter, Sortierung
und Cursor unterstützt. Aufgrund der Struktur von BigTable können allerdings keine verteilten
Anfragen, Joins und Aggregatfunktionen verwendet werden. Die Befehle können in SQL-ähnlicher
Form im so genannten „String Style“ oder über vorhandene Java-Funktionen des Persistence
Managers im „Method Style“ kodiert werden.
Wird vom Entwickler GQL gewählt, steht ihm ebenfalls eine SQL-ähnliche Sprache zur
Verfügung. Es wird die typische „SELECT-FROM-WHERE“-Form verwendet, so dass bei
erfahrenen SQL-Entwicklern kein großer Einarbeitungsaufwand zu erwarten ist. Wie auch bei
JDOQL werden keine Joins bzw. verteilte Anfragen unterstützt. Zur Abbildung der Entity Groups
(vgl. Abschnitt 3.3) sind PARENT- und ANCESTOR-Klauseln zum Verweis auf Gruppenelemente
vorhanden. Insbesondere sind auch rekursive und geschachtelte Verweise auf ANCESTORS
möglich, um komplexere Anfragen abzubilden.
3.5 Services
Google stellt innerhalb seiner App Engine-Plattform einige Services bereit, um dem Entwickler die
Arbeit zu vereinfachen und Schnittstellen bereitzustellen. Es ist so möglich, auf Googles eigene
Anwendungen, aber auch auf weitere Ressourcen innerhalb und außerhalb der Plattform
zuzugreifen.
Über Google Accounts und die Mail-Integration können Entwickler auf die zentralen
Identifizierungs- und eMail-Dienste von Google zugreifen und diese in ihre eigenen Anwendungen
integrieren. Gerade bei Applikationen, die eine komplexe Nutzerverwaltung erfordern, besteht
deshalb großes Potential zur Vereinfachung.
4
Um innerhalb einer Anwendung Daten einfacher und schneller zu verwalten, stehen die Dienste
Memcache und Blobstore zur Verfügung. Letzterer ist zu diesem Zeitpunkt noch als
experimentelles Feature angegeben, die Dateigröße für BLOBs ist mit maximal 1 Megabyte noch
sehr gering gewählt. Der Memcache stellt einen temporären Speicher dar, der zur sehr schnellen
Verarbeitung von großen Datenmengen genutzt werden kann. Gerade datenintensive Anwendungen
im Web 2.0-Umfeld können davon profitieren.
Da die App Engine-Plattform nur Webapplikationen unterstützt und damit keine permanent
laufenden Prozesse vorhanden sind, muss zur Ausführung von Tasks ohne Nutzeranfrage auf Cron
Jobs zurückgegriffen werden. Zusätzlich stellt Google für die Python-Umgebung Task Queues
bereit, die eine ähnliche Funktionalität bieten. Durchzuführende Aufgaben werden dabei als Web
Hooks dargestellt. Auch die Task Queues sind momentan noch als experimentelles Feature gelistet.
Ein weiterer wichtiger Service ist URL Fetch, das zur Verbindung mit entfernten Webservices
genutzt werden kann. Dabei können im Java- oder Python-Code mit einfachen fetch-Befehlen
HTTP-Requests an reguläre URLs Daten von Webseiten oder Service-Endpunkten abgefragt
werden. Dabei können übliche Methoden wie POST und GET verwendet werden.
4 Microsoft Azure
4.1 Produktübersicht
Microsoft ist mit seiner Azure-Plattform erst spät in das PaaS-Geschäft eingestiegen, bietet aber
bereits jetzt ein umfangreiches Produkt an. Grundsätzlich handelt es sich bei Azure um ein
klassisches PaaS-Angebot, das in einer Public Cloud gehostet wird. Im Vergleich zu anderen
Angeboten sticht jedoch die Einbindung von lokalen bzw. weiteren Anwendungen und Services
hervor. Dadurch können Entwickler sehr gut an vorhandene Systeme angepasste Software erstellen.
Im Gegensatz zu Googles App Engine werden nicht nur reine Webapplikationen als Endprodukt
gesehen, sondern komplexe Systeme aus lokalen und cloudbasierten Anwendungen sowie
verteilten Daten ermöglicht. Microsoft nimmt dafür eine Teilung der Plattform in drei zentrale
Bereiche vor: die Ausführungslogik, die Datenhaltung und eine Kommunikationskomponente. Sie
können als unabhängige Bestandteile eines flexiblen Gesamtsystems angesehen werden, sind also
einzeln oder kombiniert einsetzbar.
5
Die Trennung in drei Bereiche spiegelt sich auch in den Komponenten des Produkts wider. Wie
auch bei Googles App Engine gibt es eine Entwicklungs- und Laufzeitumgebung (Windows Azure)
und eine Datenbankanbindung (SQL Azure). Hinzu kommt mit AppFabric eine Komponente, die
es
ermöglicht Verbindungen
zwischen
verschiedenen Applikationen
über
Webservices
herzustellen.
4.2 Windows Azure
Als Entwicklungs- und Laufzeitumgebung stellt Microsoft mit Windows Azure eine sehr flexible
Plattform bereit. Basierend auf Windows Server-Technologie steht dem Entwickler eine vertraute
Umgebung
zur
Verfügung,
Programmiersprachen
die
unterstützt
insbesondere den
werden.
Somit
Vorteil
können
hat,
dass
alle
Webanwendungen
Windowsmit
PHP,
WCF/Silverlight und ASP.NET entwickelt werden, sowie reguläre Anwendungssoftware mit C++,
Java, .NET etc.
Applikationen können dabei als Web Role oder Worker Role ausgeführt werden. Eine Web Role
bezeichnet eine typische Webapplikation, die nur auf User-Requests reagieren kann und keine
permanente Ausführung beinhaltet. Für Anwendungen, die genau diese Funktionalität benötigen,
können mit den Worker Roles Hintergrundprozesse gestartet werden, um beispielsweise
komplexere Berechnungen als Ergänzung zur Webanwendung zu ermöglichen.
Neben SQL Azure stehen in Windows Azure noch weitere Storage Services zur Verfügung, um
etwa während der Laufzeit Daten zwischen Applikationen auszutauschen oder als Speicherort für
Daten, die kein relationales System erfordern. Zu diesem Zeitpunkt stehen drei Services zur
Verfügung: BLOBs, Tables und Queues. Im BLOB-Speicher können bis zu 50gb große Dateien
abgelegt werden. Tabellen bestehen aus einfachen Entitäten mit zugeordneten Attributen. Es steht
keine Datenbankfunktionalität im engeren Sinne bereit, sondern es handelt sich um reine Tabellen
ohne weitere Verknüpfungen. Queues sind einfache Listen bzw. Warteschlangen, die
typischerweise für den Datenaustausch zwischen Web und Worker Roles oder als Speicher für
abzuarbeitende Daten genutzt werden [Cha08] .
Zur Konfiguration und Überwachung von Windows Azure und den Storage Services können
webbasierte Anwendungen von Microsoft genutzt werden. Sie sind jeweils an Hosting- und
Storage-Accounts gebunden.
6
4.3 AppFabric
Um verteilte Anwendungen im Web zu verbinden, werden typischerweise Webservice-Endpunkte
verwendet. Diese zu managen und über NATs oder Firewalls hinweg zu verknüpfen ist oft eine
nicht unwesentliche Hürde. Genau an diesem Punkt setzt Microsoft mit der AppFabric an. Dieser
Service dient als Plattform zur Verwaltung von Webservices unterschiedlicher Herkunft. So
können lokale und cloudbasierte Anwendungen miteinander oder jeweils untereinander verbunden
werden.
Erster Hauptbestandteil der AppFabric ist der Service Bus, der das Management von Verbindungen
übernimmt. Durch eine zentrale Anmeldung der Services können diese leicht untereinander
gefunden werden und eine Verbindung aufbauen. Daneben steht mit der Access Control ein Service
zur Verwaltung von User-Identitäten zur Verfügung. Auf Basis von REST- und SOA-Nachrichten
können so Anmeldeinformationen in verteilten Applikationen genutzt werden.
4.4 SQL Azure
Unter SQL Azure versteht Microsoft ein Bündel von Datenbank-Services, das nicht nur ein
relationales DBMS bereit hält, sondern zusätzlich Data Warehousing, Synchronisierung und
Reporting ermöglichen soll. Abgesehen von SQL Azure Database als RDBMS sind alle weiteren
Komponenten jedoch noch in der Entwicklungsphase.
4.4.1
SQL Azure Database
Als relationales DBMS setzt Microsoft auf die Technologie des SQL Servers. Darauf aufbauend
und mit einigen Einschränkungen können Entwickler mit der SQL Azure Database also auf
bewährte Technik zurückgreifen. Im Gegensatz zur Verwendung eines SQL Servers wird bei SQL
Azure Database von der physischen Datenhaltung und der physischen Administration abstrahiert.
Das bedeutet, dass sich Microsoft in diesem Bereich um die Konfiguration und Optimierung
kümmert, jedoch dadurch ein DBA auch keinen Einfluss auf die Darstellung der Datenbank auf
Dateiebene hat.
„SQL Azure bietet die üblichen Funktionalitäten eines RDBMS wie Tabellen, Views, Joins, Stored
Procedures etc.“ [Dat10] . Als Sprache wird wie beim SQL Server TransactSQL verwendet.
Microsoft gibt an, dass bereits für den SQL Server implementierte Anwendungen auch auf der SQL
Azure Database funktionieren. Dies ist allerdings kritisch zu betrachten, da aufgrund einiger
Einschränkungen im TransactSQL mit viel Anpassungsarbeit zu rechnen ist oder eine Migration
unmöglich sein kann.
7
4.4.2
Architektur
Jeder Nutzer von Microsoft Azure erhält einen Storage-Account, der wiederum mehrere SQL
Azure-Accounts enthalten kann. Diesen ist jeweils genau ein SQL Azure Server zugeordnet, der
selbst „eine logische Gruppierung einer oder mehrerer Datenbanken“ [Dat10] ist. SQL Azure
Server sind genau einem Microsoft-Rechenzentrum zugeordnet und können physisch auf mehreren
Rechnern laufen – sie sind also virtualisiert. Die geografische Position der Server bzw. des
genutzten Rechenzentrums kann jeweils einzeln durch den Nutzer festgelegt werden, was
insbesondere bei weltweit verteilten Applikationen Sinn macht.
Die Replikation der Server und Datenbanken erfolgt automatisch durch Microsoft. Um zu
skalieren, muss durch den Nutzer manuell oder in einer Anwendung eine neue Datenbank angelegt
und partitioniert werden oder entsprechend entfernt werden. Bei einer Maximalgröße von 10
Gigabyte pro Datenbank ist dies bei datenintensiven Anwendungen nicht unproblematisch.
Microsoft hat allerdings angekündigt, künftig auch bis zu 50 Gigabyte-Datenbanken anzubieten
[Zan10] .
Der Zugriff zur Datenbank erfolgt wie beim SQL Server über Tabular Data Stream-Endpunkte.
Somit können bestehende Schnittstellen wie ODBC oder ADO.NET verwendet werden. Die
Verbindung ist zwangsweise SSL-verschlüsselt.
4.4.3
Vergleich mit dem SQL Server
Da die SQL Azure Database auf dem SQL Server aufbaut, sind große Teile der Funktionalität
identisch. Jedoch sind aufgrund des Anwendungsgebiets und der speziellen Architektur einige
Features entfernt und andere hinzugefügt worden.
Insbesondere durch Automatisierung von Adminstrationsaufgaben wird dem DBA einiges an
Arbeit abgenommen. Unter anderem werden das Loadbalancing und die Replikation vollkommen
automatisch verwaltet. Dabei wird durch Microsoft ein transparenter Fail-Over bei Ausfall eines
Servers gewährleistet. Horizontal skalieren bzw. partitionieren muss der Nutzer hingegen über das
Webinterface bzw. über eigene Anwendungen selbst.
Funktionen, die im Vergleich zum SQL Server nicht implementiert wurden bzw. nicht zugänglich
sind, sind unter anderem jegliche Dateisystem-bezogenen Elemente wie die Verwaltung von
Filegroups oder physische DDL-Elemente. Hier gehen jedoch auch einige Tuning-Möglichkeiten
verloren, die beim SQL Server noch möglich sind. Weiterhin fehlen Analyse- und ReportingServices, die durch eigenständige Komponenten im SQL Azure-Paket ersetzt werden.
8
Betrachtet man die gemeinsame Anfrage TransactSQL, so muss bei der SQL Azure Database auf
verteilte Transaktionen, Geo-Datenverarbeitung, ein CLR und globale temporäre Tabellen
verzichtet werden. Außerdem wurden aus einigen Befehlen mit Bezug auf das Dateisystem
Parameter entfernt. Die Ausführung dieser Befehle ist weiterhin möglich, jedoch wird bei Nutzung
der betroffenen Parameter eine Warnung ausgegeben.
Zusammenfassend kann man die SQL Azure Database als auf Webanwendungen zugeschnittenen
SQL Server bezeichnen, der im Cloud-Betrieb deutliche Vereinfachungen mit sich bringt. Da
einige Funktionen noch nicht implementiert wurden, muss vor der Entwicklung auf diesem System
geklärt werden, ob alle Anforderungen erfüllt werden können. Jedoch werden „in zukünftigen
Versionen […] Bereiche, die zum Funktionsumfang eines SQL Server gehören, ergänzt […]“
[Dat10] . Es wurde inzwischen angekündigt, dass auch Geo-Daten unterstützt werden sollen
[Zan10] .
5 Vergleich Google App Engine & Microsoft Azure
Nachdem nun beide Produkte ausführlich betrachtet wurden, soll ein direkter Vergleich zeigen, in
welchen Bereichen Stärken und Schwächen der Angebote liegen.
5.1 Geschäftsmodell
Google bietet seine App Engine als Basisvariante kostenfrei an, wobei auch mit den damit
verbundenen Einschränkungen bezüglich der nutzbaren Kapazitäten bereits komplexere
Anwendungen entwickelt und betrieben werden können. Abgesehen von einem kostenlosen
Einführungsangebot wird es von Microsofts Azure keine frei verfügbare Version geben. Gerade
private Entwickler werden sich daher eher für Googles Lösung entscheiden, zumindest bei der
Kostenbetrachtung.
Azure bietet mit seiner sehr flexiblen und mit vielen Komponenten bestückten Umgebung sehr viel
Potential für unterschiedlichste Anwendungsfälle, so dass eine breite Masse an entwickelnden
Unternehmen angesprochen werden kann. Insbesondere wegen der Einbindung lokaler Ressourcen
und der getrennten Nutzbarkeit von Anwendungen und Daten können verschiedenste Szenarien
abgedeckt werden. Googles App Engine hingegen ist eher auf datenintensive und hoch performante
Web 2.0-Anwendungen ausgelegt und bietet hierfür sehr gute technische Voraussetzungen.
9
5.2 Umgebung
Mit der ausschließlichen Unterstützung von Python und Java schränkt Google das Portfolio an
Programmiersprachen in der App Engine stark ein. Es zeigt sich wieder die relativ starke
Ausrichtung auf reine Webanwendungen. Microsoft punktet durch die Verfügbarkeit einer ganzen
Palette von Sprachen von .NET über ASP.NET bis C#.
Eng verbunden mit dem Sprachangebot ist auch der Verwendungszweck der Plattform im Sinne
des Anwendungstyps. Unter Azure können ohne weiteres Hintergrundprozesse verwendet werden
und echte Anwendungsprogramme laufen. So ist es möglich, Daten auch ohne User-Interaktion zu
verarbeiten bzw. aufzubereiten. In der App Engine müssen dafür Cron Jobs genutzt werden, was
eher als Workaround gesehen werden sollte und die Funktionalität der Worker Roles in Azure nicht
abbilden kann.
Durch die Einbindung von bestehenden Services und Apps ist es bei Googles App Engine möglich,
für viele Webanwendungen wichtige Funktionen wie eMail-Verwaltung oder globale
Nutzeridentitäten direkt auf Plattformebene zu nutzen. Microsoft hat bereits angekündigt,
Sharepoint- und SQL Server stärker anzubinden, jedoch ist dann mit zusätzlichen Kosten zu
rechnen.
5.3 Leistung
Im Bereich Anwendungsperformance bietet Googles App Engine mit Memcache einen
hochperformanten temporären Datenspeicher, der die Verarbeitung großer Datenmengen in
Webanwendungen ermöglicht. Unter Azure steht momentan nur der ASP.NET Cache zur
Verfügung.
Die Skalierbarkeit bezüglich der Rechenkapazität läuft auf der App Engine vollautomatisch, muss
unter Azure manuell bzw. über eigene Anwendungslogik realisiert werden. Neue Web- bzw.
Worker Roles müssen angelegt und gestartet oder entsprechend heruntergefahren werden.
5.4 Datenhaltung
Die Performance bei der Datenhaltung unterscheidet sich unter Azure je nach verwendetem Storage
Service. Beim relationalen DBMS SQL Azure Database dürfte sie vergleichbar mit einem SQL
Server sein. Google nutzt seine eigene BigTable-Technologie und kann dadurch sehr hohe
Performance erreichen und ist insbesondere durch die automatische Partitionierung schnell
skalierbar.
10
In Sachen Flexibilität hat wiederum Microsoft das bessere Angebot. Durch das Bereitstellen
mehrerer Storage Services, die unterschiedlichste Aufgaben erfüllen können, ist dem Entwickler
eine Reihe von möglichen Anwendungsfeldern eröffnet. Google bietet bisher offiziell nur den
Datastore an.
6 Fazit
6.1 Auswirkungen von PaaS
Mit dem PaaS-Ansatz sind für verschiedene Interessengruppen Konsequenzen verbunden. Direkt
betroffen sind SaaS-Entwickler und SaaS-entwickelnde Unternehmen, aber auch Endkunden
profitieren indirekt von PaaS.
Unternehmen, die SaaS-Produkte entwickeln und betreiben, können durch die Nutzung von PaaSAngeboten in hohem Maße Fixkosten einsparen. Insbesondere Investitionen in eigene
Serverlandschaften und damit große Mengen an Hard- und Software werden deutlich verringert. Im
Extremfall kann vollständig auf Serveranschaffungen verzichtet werden.
Zu bemerken ist dabei, dass nicht nur die Laufzeit- sondern teilweise auch die
Entwicklungsumgebung in einer Public Cloud laufen. Damit entfallen dementsprechend auch
Kosten für im Unternehmen genutzte Entwicklungsmaschinen, sowie deren Administration.
Letzteres trifft gleichermaßen auf Produktionsserver zu – gerade hier können zusätzlich auch
variable Kosten verringert werden.
Ein weiterer Punkt ist das nicht mehr nötige Vorhalten von Rechenkapazität durch den SaaSAnbieter. Durch die Auslagerung in die Cloud und das damit verbundene Ressourcenpooling wird
das Auftreten von Spitzenlasten auf PaaS-Anbieterseite abgepuffert, so dass im betrachteten
Gesamtsystem eine bessere Ressourcennutzung zu erwarten ist. Für das Nachfrager-Unternehmen
ist also durch die Verbrauchsabhängigkeit bezüglich des Ressourcenangebots ein erheblicher
Vorteil zu sehen.
Für Entwickler selbst kommen bei PaaS durch die Abstraktion von der physischen Ebene mehrere
Vorteile zum Tragen. Da Entwicklungs- und Laufzeitumgebung typischerweise identisch sind,
entfällt das Betreiben einer oder mehrerer dedizierter Testmaschinen sowie die Beachtung von
verschiedenen Laufzeitumgebungen, wie es in der klassischen Anwendungsprogrammierung in
hohem Maß nötig ist. Der Entwickler hat die „Sicherheit, dass die Umgebungen identisch sind und
die eben getestete Version sich auch im Livesystem exakt identisch verhält, weil das Live-System
absolut identisch ist“ [Clo10] .
11
Ein weiterer Vorteil, der durch den SaaS-Ansatz allgemein entsteht, ist die Ausführung über den
Browser. So ist es leicht möglich, Betriebssystem-unabhängige Software zu entwickeln und so
selbst mobile Geräte wie Smartphones als Client nutzbar zu machen, ohne dafür gesonderte
Softwareprodukte zu entwickeln.
6.2 Produktwahl
Die Entscheidung für ein spezielles PaaS-Angebot hängt vor allem von den Anforderungen an die
Entwicklungsumgebung
ab.
Insbesondere
die
verfügbaren
Programmiersprachen
und
Datenhaltungsmöglichkeiten können dabei entscheidend sein. Während einige Produkte eine sehr
eingeschränkte Auswahl in beiden Punkten haben, weisen andere wesentlich mehr Flexibilität auf.
Auch das Anwendungsgebiet spielt bei der Auswahl eines Anbieters eine wichtige Rolle. Während
es beim Betrieb einer sehr großen Web 2.0-Plattform größtenteils auf die extrem schnelle
Bereitstellung verteilter Daten ankommt, können bei der Nutzung von ERP-Software als SaaS
flexible Schnittstellen und umfangreiche Services sowie hohe Konsistenzanforderungen
Schlüsselfaktoren sein. Auch die anfallenden Kosten können sich in ihrer Struktur drastisch
unterscheiden. So hängt es vom Nutzungsverhalten und dem Anwendungstyp ab, ob eher
Datenbankanfragen oder Rechenzeit den Großteil der Last ausmachen. Dies ist durch den
Entscheider abzuschätzen und anhand der Preisgestaltung der Anbieter zu bewerten.
6.3 Ausblick
Im Zuge der fortschreitenden Service-Orientierung wird die Anzahl und Vielfalt von SaaSLösungen weiter zunehmen. Mit PaaS-Angeboten wird es Unternehmen ermöglicht, ohne größere
Investitionen selbst SaaS zu entwickeln und zu betreiben. Dies wird die Verbreitung von SaaS
sicherlich noch verstärken.
Ein Trend, der sich abzeichnet, ist die immer größere Automatisierung von Verwaltungs- und
Administrationsaufgaben. So können sich Entwickler auf das Wesentliche konzentrieren: ihre
Applikation.
12
Literaturverzeichnis
[Zan10] Adam, Zane. 2010. Delivering new features for SQL Azure today. [Online] 25. 06 2010.
[Zitat vom: 08. 07 2010.] http://blogs.msdn.com/b/zaneadam/archive/2010/06/26/delivering-newfeatures-for-sql-azure-today.aspx.
[Bau10] Baun, Christian, et al. 2010. Cloud Computing - Web-basierte dynamische IT-Services. s.l. :
Springer, 2010.
[Cha08] Chappell, David. 2008. Introducing the Azure Services Platform. 2008.
[Clo10] CloudControl. 2010. Kein Lean Startup ohne Platform as a Service. [Online] 26. 04 2010.
[Zitat vom: 21. 06 2010.] http://cloudcontrol.de/lean-startup-platform-as-a-service/.
[Goo10] Google. Google Code. [Online] [Zitat vom: 10. 06 2010.] http://code.google.com/intl/deDE/appengine/docs/.
[Max08] Ross, Max. 2008. Transaction Isolation in App Engine. [Online] 13. 5 2008. [Zitat vom: 10.
6 2010.] http://code.google.com/intl/de-DE/appengine/articles/transaction_isolation.html.
[Dat10] Sirtl, Holger. 2010. Daten frei für SQL Azure. database pro. 2010, 1.
ii