Platform as a Service
Werbung
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
