GOOGLES APP ENGINE: OPEN-SOURCE FÜR DIE CLOUD · 2009-10-15 · Ablaufumgebungen für die GAE:...

5
NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-Pdfs? Kontakt: [email protected]! GOOGLES APP ENGINE: OPEN-SOURCE FÜR DIE CLOUD Geschäftsidee konzentrieren. Die Hürden, eine neue Web-Anwendung, ein Google- Gadget oder eine Android-Anwendung zu entwickeln, sind damit deutlich geringer geworden. Hier sieht man die bedeutende Rolle der GAE in Googles Cloud-Strategie: Es soll den Nutzern so einfach wie möglich gemacht werden, eigene Anwendungen zu entwickeln, wodurch die Zahl der Google- Anwender weiter steigt. Erreicht die Applikation eine hohe Verbreitung, ver- dient Google in der Folge an den Kosten für Netzverkehr, CPU und Speicher. Cloud-Computing beim PaaS-Anbieter Software as a Service (SaaS) adressiert aktuell vor allem kleine und mittlere Unternehmen. Die Standardsoftware wird dabei beim SaaS- Anbieter betrieben. Das Unternehmen bezahlt ein nutzungsabhängiges Entgelt. Themen wie Ausfallsicherheit, Skalierbarkeit oder Update werden vom Anbieter umgesetzt. Für die Anbieter ist das SaaS-Modell vor allem im Sinne des LongTail interessant (vgl. [Wid]): Hier sollen Kunden gewonnen werden, die ihre Geschäftsprozesse ansonsten vielleicht mit Excel-Listen oder gar ohne Software umsetzen. Der Betrieb von Services gegen eine nutzungs- oder zeitlich abhängige Gebühr war bisher das dominierende Geschäftsmodell im SaaS-Umfeld. Der Grund hierfür ist klar: SaaS-Anbieter tragen die Investitionskosten für Infrastruktur und Betrieb. Daher war es nur schwer vorstellbar, der Community die eigene Geschäftsidee als Open-Source zur Verfügung zu stellen. Mit der „Google App Engine” (GAE) wird dies nun möglich. Seit einem Jahr bietet Google für kleine und mittlere Web-Anwen- dungen seine Plattform an. Seitdem neben Python auch Java als Plattformsprache unterstützt wird, gewinnt die GAE weiter an Bedeutung. Wie sieht die Architektur von GAE-Anwendungen aus und welche Einschränkungen bestehen? Wie werden Schnittstellen zu anderen Systemen zur Verfügung gestellt? Auf diese und andere Fragen geht der Artikel anhand einer Beispielanwendung ein. mehr zum thema: www.widas.de/gae 26 27 den Google-Servern) betrieben und ausge- führt. Die wichtigsten Vorteile sind: Es muss keine eigene IT-Infrastruktur vorhanden sein und gewartet werden. Die Anwendung kann bei Bedarf (On- Demand) leicht skaliert werden. Es werden optimale Internet-Zu- griffsgeschwindigkeiten angeboten (Nutzung der bewährten Infrastruktur des Cloud-Anbieters). Google bietet den Anwendern einen zunächst kostenlosen Einstieg in die Web- Programmierung – so kann sich der Ent- wickler auf die Umsetzung seiner Google und die Cloud Google Mail, Google Calendar, Google Apps, Google Wave, Android, Chrome und Chrome-OS – kaum ein Quartal vergeht, in dem nicht eine neue Cloud-Technologie oder ein neues Produkt für die Cloud aus dem Hause Google präsentiert wird. Seit einiger Zeit gehört auch die Google App Engine (GAE) zu Googles Cloud-Portfolio (siehe Abb. 1). Mit der GAE können Web- Anwendungen auf der Infrastruktur von Google betrieben werden. Sie zählt zu den so genannten Cloud-Plattformen – Plat- form as a Service (PaaS) (vgl. [Wid]). Beim Cloud-Computing werden eigene Anwendungen auf entfernten Servern (hier schwerpunkt Alexander Elsholz (E-Mail: [email protected]) arbeitet als Senior Consultant bei der WidasConcepts GmbH. Zu seinen Schwer- punkten gehören die Entwicklung von serviceorientierten JEE-Architekturen sowie die Konzeption und die Realisierung von Standardsoftware. Thomas Widmann (E-Mail: [email protected]) ist Geschäftsführer der WidasConcepts GmbH und beschäftigt sich hauptsächlich mit IT-Strategien, IT-Architekturen und Business Process Management. die autoren Abb. 1: GAE in Googles Cloud-Strategie.

Transcript of GOOGLES APP ENGINE: OPEN-SOURCE FÜR DIE CLOUD · 2009-10-15 · Ablaufumgebungen für die GAE:...

NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-Pdfs? Kontakt: [email protected]!

GOOGLES APP ENGINE:OPEN-SOURCE FÜR DIE CLOUD

Geschäftsidee konzentrieren. Die Hürden,eine neue Web-Anwendung, ein Google-Gadget oder eine Android-Anwendung zuentwickeln, sind damit deutlich geringergeworden. Hier sieht man die bedeutendeRolle der GAE in Googles Cloud-Strategie:Es soll den Nutzern so einfach wie möglichgemacht werden, eigene Anwendungen zuentwickeln, wodurch die Zahl der Google-Anwender weiter steigt. Erreicht dieApplikation eine hohe Verbreitung, ver-dient Google in der Folge an den Kosten fürNetzverkehr, CPU und Speicher.

Cloud-Computing beimPaaS-AnbieterSoftware as a Service (SaaS) adressiert aktuellvor allem kleine und mittlere Unternehmen.Die Standardsoftware wird dabei beim SaaS-Anbieter betrieben. Das Unternehmen bezahltein nutzungsabhängiges Entgelt. Themen wieAusfall sicherheit, Skalierbarkeit oder Updatewerden vom Anbieter umgesetzt. Für dieAnbieter ist das SaaS-Modell vor allem imSinne des LongTail interessant (vgl. [Wid]):Hier sollen Kunden gewonnen werden, dieihre Geschäftsprozesse ansonsten vielleichtmit Excel-Listen oder gar ohne Softwareumsetzen.

Der Betrieb von Services gegen eine nutzungs- oder zeitlich abhängige Gebühr warbisher das dominierende Geschäftsmodell im SaaS-Umfeld. Der Grund hierfür istklar: SaaS-Anbieter tragen die Investitionskosten für Infrastruktur und Betrieb.Daher war es nur schwer vorstellbar, der Community die eigene Geschäftsidee alsOpen-Source zur Verfügung zu stellen. Mit der „Google App Engine” (GAE) wird diesnun möglich. Seit einem Jahr bietet Google für kleine und mittlere Web-Anwen -dungen seine Plattform an. Seitdem neben Python auch Java als Platt formspracheunterstützt wird, gewinnt die GAE weiter an Bedeutung. Wie sieht die Architekturvon GAE-Anwendungen aus und welche Einschränkungen bestehen? Wie werdenSchnittstellen zu anderen Systemen zur Verfügung gestellt? Auf diese und andereFragen geht der Artikel anhand einer Beispielanwendung ein.

m e h r z u m t h e m a :www.widas.de/gae

26 27

den Google-Servern) betrieben und ausge-führt. Die wichtigsten Vorteile sind:

■ Es muss keine eigene IT-Infrastrukturvorhanden sein und gewartet werden.

■ Die Anwendung kann bei Bedarf (On-Demand) leicht skaliert werden.

■ Es werden optimale Internet-Zu -griffsgeschwindigkeiten angeboten(Nutzung der bewährten Infrastrukturdes Cloud-Anbieters).

Google bietet den Anwendern einenzunächst kostenlosen Einstieg in die Web-Programmierung – so kann sich der Ent -wickler auf die Umsetzung seiner

Google und die CloudGoogle Mail, Google Calendar, GoogleApps, Google Wave, Android, Chrome undChrome-OS – kaum ein Quartal vergeht, indem nicht eine neue Cloud-Technologieoder ein neues Produkt für die Cloud ausdem Hause Google präsentiert wird. Seiteiniger Zeit gehört auch die Google AppEngine (GAE) zu Googles Cloud-Portfolio(siehe Abb. 1). Mit der GAE können Web-Anwendungen auf der Infrastruktur vonGoogle betrieben werden. Sie zählt zu denso genannten Cloud-Plattformen – Plat -form as a Service (PaaS) (vgl. [Wid]).

Beim Cloud-Computing werden eigeneAnwendungen auf entfernten Servern (hier

schwerpunk t

Alexander Elsholz

(E-Mail: [email protected])

arbeitet als Senior Consultant bei der

WidasConcepts GmbH. Zu seinen Schwer -

punkten gehören die Entwicklung von

serviceorientierten JEE-Architekturen sowie

die Konzeption und die Realisierung von

Standard software.

Thomas Widmann

(E-Mail: [email protected])

ist Geschäftsführer der WidasConcepts

GmbH und beschäftigt sich hauptsächlich

mit IT-Strategien, IT-Architekturen und

Business Process Management.

d i e au toren

Abb. 1: GAE in Googles Cloud-Strategie.

6 / 2 0 0 9

Ähnlich verhält es sich mit PaaS. Auchhier werden vor allem kleine und mittlereUnternehmen adressiert. Dabei geht esnicht um die Miete einer Standardsoftware,sondern um die Entwicklung einer eigenenLösung. Diese kann dann als Individual -software genutzt oder an andere Unter -nehmen als SaaS-Lösung (eventuell alsOpen-Source) weitergegeben werden. Ähn-lich wie bei SaaS wird auch bei PaaS dieVerwendung der Infrastruktur nutzungsab-hängig abgerechnet.

Üblicherweise werden Web-Applika -tionen mit JEE, Technologiekombinationenwie LAMP, dem Microsoft-Stack oder ver-gleichbaren Technologien entwickelt undbei einem klassischen Hoster betrieben. DieVorteile, seine Software bei einem PaaS-Anbieter wie Google zu betreiben, sind:

■ Es ist keine zeitintensive Einrichtungder Plattform erforderlich.

■ Für die Infrastruktur fallen keineWartungsaufwände an.

■ Bei Überlast ist keine Portierung not-wendig, denn die GAE skaliert automa-tisch.

■ Es fallen keine initialen Kosten an,denn Google berechnet Gebühren erstab einer gewissen Nutzungslast, wasein geringeres Risiko bedeutet.

Dem gegenüber steht der Nachteil, dassman den Beschränkungen durch Dritte(d. h. Google) unterliegt und man nichtalles selbst im Griff hat. So werden ersteinfrastrukturelle Entscheidungen von derPlattform getroffen, die sich auf dieAnwendungsarchitektur auswirken. Willman die vielen Vorteile eines PaaS-An -bieters nutzen, seine Anwendung aber

zukünftig mit überschaubarem Aufwandzu anderen Anbietern portieren, muss dieArchitektur mit besonderem Augenmaßentwickelt werden.

Googles App EngineSeit mehr als einem Jahr bietet Google seinePaaS-Lösung zur Entwicklung von Web-Anwendungen an. Eine attraktive Preis -gestaltung und ein für Web-Anwendungenkompletter, zum großen Teil bewährterTechnologie-Stack machen die GAE zu einerinteressanten Alternative (siehe Abb. 2). DieGAE bietet die folgenden Features (vgl.[Goo-a]):

■ Entwicklung von dynamischen Web-Seiten bei Unterstützung der gängigenWeb-Technologien.

■ Bearbeiten persistenter Daten durchAbfragen und Transaktionen.

■ Programmierschnittstellen für Benut -zer verwaltung und Mail-Versand.

■ Lokale Entwicklungs- und Testumge -bung, die die GAE simuliert.

■ Cron-Job-Service, um Aktivitäten zubestimmten Zeiten ausführen zu kön-nen.

Google SandboxAlle GAE-Anwendungen laufen in einerSandbox. Auf der einen Seite kann Googledadurch eine Applikation über mehrereHardwareinstanzen verteilt betreiben, umso die Verfügbarkeits- und die Skalierungs -anforderungen transparent zu erfüllen. Aufder anderen Seite versetzt die Sandbox denEntwickler in die Lage, seine Anwendunglokal zu testen bzw. zu betreiben, da dieAnwendung keine Abhängigkeit zur physi-schen Lokation hat.

Die Sandbox bringt drei wesentlicheEinschränkungen mit sich:

■ Andere Rechner können nur über dievon Google zur Verfügung gestelltenDienste URL fetch service und emailservice angesprochen werden.

■ Die Anwendung darf das Dateisystemnicht benutzen. Für persistente,request-übergreifende Daten müssendie Services DataStore oder MemCacheverwendet werden.

■ Die Anwendung kann ausschließlichüber eine Web-Anfrage oder einenCron-Job angestoßen werden und mussinnerhalb von 30 Sekunden einErgebnis zurück liefern.

Zunächst mögen diese Einschränkungendie Nutzung der GAE in vielen Anwen -ungsbereichen in Frage stellen – bei genau-erer Betrachtung, die wir im Rahmen derBeispielanwendung weiter unten vorneh-men, relativiert sich diese Annahme jedoch.

App Engine ServicesNeben dem App-Engine-Framework, dasdas Abhandeln der Web-Anfragen imple-mentiert, gibt es verschiedene optionaleServices, die dem Entwickler einen techni-schen Teilaspekt der Web-Anwendungabnehmen:

■ DataStore: Mit dem AppEngineDataStore lässt sich die Persistenz derGeschäftsobjekte verwalten. Hierbeihandelt es sich nicht um eine relationa-le Datenbank (weshalb JDBC als APInicht zur Verfügung steht), sondernvom Konzept eher um eine hierarchi-sche Anordnung von Objekten. Nebeneiner Google-API für den Zugriff aufden BigTable-basierten DataStore (vgl.[Cha06]) existiert eine freie Implemen -tierung der gängigen Java-Persistenz-Standards JDO und JPA von [Dat].

■ MemCache: Hierbei handelt es sich umeine Cache-Implementierung vonGoogle, die auch den JSR 107 (JCache)implementiert. Die Cache-Instanz istvon mehreren Applikations instanzenaus zugreifbar. MemCache wird fürtemporäre Daten oder als Performance-Cache für gelesene Objektinstanzen ausdem DataStore genutzt.

■ URLFetch: Mit URLFetch lassen sichandere Anwendungen in die GAE-Web-Anwendung integrieren. Mittels der

schwerpunk tschwerpunk t

Abb. 2: Aufbau der „Google App Engine”.

halten. Oft wird dabei auf Blog-Einträgemit Work-Arounds oder Tutorials verwie-sen.

GAE, Amazon EC2 und AzureHäufig werden GAE und die AmazonElastic Compute Cloud (Amazon EC2) ein-ander gegenübergestellt und hinsichtlichihrer Siegchancen bewertet – aber sind diebeiden Ansätze überhaupt vergleichbar?Der Vergleich der beiden Cloud-Anbieterhinkt bereits hinsichtlich der Zielstellung.Versteht sich Google auf der einen Seite alsPlattformanbieter mit einem einfachenProgrammiermodell für Web-Anwen dun -gen, so bietet Amazon eher seine Infra -struktur – erweitert um viele hinzu buch-bare Dienste – als Service an. Daher gilt:GAE = PaaS, EC2 = HaaS + PaaS-Dienste.

Bezüglich Amazon EC2 soll das keines-wegs geringschätzend klingen, sonderneher die unterschiedlichen Zielsetzungenverdeutlichen:

■ Bei Google kann man einfach Web-Anwendungen erstellen. Dafür mussman im Hinblick auf die Infrastrukturnichts tun, aber sich mit den Ein -schränkungen der Entwicklungsplatt -form arrangieren.

■ Bei Amazon EC2 können ohne großeEinschränkungen beliebige Anwendun -gen gehostet werden. Dafür bleibenBetriebsaspekte, wie beispielsweise dieSkalierung, in der Verantwortung desDienstnutzers.

Anders fällt der Vergleich mit MicrosoftsAzure aus, einem neuen Angebot vonMicrosoft für das Hosting undManagement von Cloud-basierten Anwen -dungen. Die GAE und Azure sind von derZielsetzung her ähnlich – beide bieten demEntwickler bei der Umsetzung seiner fach-lichen Anforderungen ein umfangreichesRahmenwerk.

Microsoft ist spät in die PaaS-Tech -nologie eingestiegen. Dass sich Microsoftüberhaupt dem Cloud-Computing widmet,ist als ein Strategiewechsel zu werten.Dabei fährt Microsoft einen hybridenAnsatz: Die Anwendung soll in der Cloudgenauso implementiert werden und lauffä-hig sein wie auf dem Desktop. Das kommtder Portierbarkeit der Anwendung zugute.Azure beschränkt sich, entgegen der GAE,nicht auf die Entwicklung von Web-Anwendungen, sondern bietet zusätzlich

28 29

setzt. Einige ansehnliche Python-Anwendungen werden mittlerweile beiGoogle gehostet. Die Python Engine istimmer noch ein Vorreiter für dieUmsetzung neuer Services, wie manbeispielsweise bei der Unterstüt zung fürMessaging (vgl. [Goo-f]) sieht.

■ Java Runtime Environment: Im April2009 wurde Google App Engine forJava (GAE/J) als Early Look veröffent-licht. Beschränkt auf zunächst 10.000Accounts, können nun JEE-Web-Anwendungen in der GAE betriebenwerden. Eine lokale Entwicklungs -umge bung und ein Eclipse-Plug-Inerleichtern den Einstieg in die Pro -grammierung mit der GAE. Als ServletContainer wird „Jetty” verwendet.Nicht alle Java-APIs können in GAE/J-Anwendungen verwendet werden (siehe Tabelle 1).

Über die Java-Plattform sind auch andereProgrammiersprachen wie Groovy, Scalaoder JRuby für die Anwendungsentwick -lung mit der GAE nutzbar.

Nicht alle Klassen der Java-Laufzeiten -umge bung (JRE) können für die Ent -wicklung eigener Anwendungen angewen-det werden. Auf einer „White List” stehendiejenigen Klassen, die genutzt werden dür-fen (vgl. [Goo-c]). Das ist auch derHauptgrund, warum einige Java-APIs inder GAE nicht verwendet werden können.In einem Forumsbeitrag (vgl. [Goo-d]) wer-den alle getesteten Frameworks aufgelistetund der Unterstützungsstatus wird festge-

http-Methoden GET, POST, PUT, HEADund DELETE können REST-basierteServices integriert werden.

■ Mailservice: Der Mailservice nutzt dieGoogle-Infrastruktur zum Versendender E-Mails. Ein Zugriff ist über dieJava-Mail-API möglich.

■ User-Service: Google bietet den GAE-Anwendungen seinen User-Service an.Der Nutzer der GAE-Anwendung kannsich mit seinem Google-Account an derAnwendung authentifizieren.

■ Cron-Service: Der Cron-Service, wieaus dem Unix-Umfeld bekannt, ermög-licht das zeitlich gesteuerte Ausführenvon Funktionalität.

■ Image-Service: Eine einfache Bildbear -beitung ist mit dem Image-Service mög-lich. Bilder im png- oder jpg-Formatkönnen skaliert, rotiert, gespiegelt oderin der Größe verändert werden.

Die meisten Services können über Java-Standard-APIs angesprochen werden. Wirddies bei neu entwickelten Services (z. B.Messaging) beibehalten, wirkt sich das sehrpositiv auf die Portierbarkeit von GAE-Anwendungen aus. Derzeit existieren zweiAblaufumgebungen für die GAE:

■ Python Runtime Environment: Pythonwar die erste Host-Sprache, mit derApplikationen für die GAE entwickeltwerden konnten. Mit dem Web-Framework „Django” oder ähnlichenPython-Frameworks werden Applika -tions-Frameworks und -Services umge-

schwerpunk t

NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-Pdfs? Kontakt: [email protected]!

Tabelle 1: Von GAE/J unterstützte Java-APIs.

6 / 2 0 0 9

die Möglichkeit, Web-Services bereitzustel-len, was zweifellos ein großer Vorteil ist.

Geschäftsanwendungen fürdie CloudUm die Tauglichkeit der GAE fürGeschäftsanwendungen zu verifizieren undarchitektonische Vorgaben bzw. Einschrän -kungen zu definieren, haben wir eineBeispielanwendung für die Cloud entwi -ckelt. Hierbei handelt es sich um einBewerber-Portal, das Open-Source und inder Cloud frei verfügbar ist. Eine Doku -mentation sowie eine detaillierte Be -trachtung der Ergebnisse finden Sie aufunserer Web-Seite [Wid].

Generell kann man festhalten, dass manauf Basis der GAE Geschäftsanwendungen

entwickeln kann, die in der Cloud betrie-ben werden, wenn man bekannte Musterzur Abstraktion und flexible Frameworksnutzt. Mit überschaubarem Aufwand sinddiese auch auf eine Standard-JEE-Archi -tektur portierbar.

Die größten Einschränkungen ergebensich beim Arbeiten mit der Persistenz -schicht. Die GAE bietet für die Persistenzden Service DataStore an. DataStore ist einauf BigTable (vgl. [Cha06]) aufbauendesFramework. Google setzt BigTable selbstein, um die riesigen Datenmengen zu ver-walten, die unter anderem bei GoogleMaps, Blogger, Google Earth oder auch beiYoutube anfallen. Zwar existiert eineImplementierung der Schnittstelle für Java-Anwendungen (JPA), jedoch muss man sich

mit Einschränkungen arrangieren, die derSkalierbarkeit geschuldet sind.

Mit dem Beispiel des Bewerberportalszeigen wir, dass auch mittelgroßeGeschäfts anwendungen auf der GAE/J ent-wickelt werden können. Neben den vielenJava-Standard-APIs für Persistenz, E-Mailund Caching sind auch andere Frameworksdirekt auf der GAE lauffähig. Nicht allearchitektonischen Aspekte können derzeitauf der GAE/J umgesetzt werden. So exis -tiert aktuell keine Unterstützung für dieBereitstellung SOAP-basierter Web-Services oder für das Messaging. Geradeam Beispiel Messaging sieht man aber, dassdie Entwicklung der Services für die GAElängst nicht abgeschlossen ist. Für Pythongibt es bereits erste Lösungsvorschläge (vgl.[Goo-f]).

Die GAE/J befindet sich noch im Beta-Status und steht den ersten 10.000 Java-Entwicklern als Early Look erst seit weni-gen Monaten zur Verfügung. Bis zurFreigabe der GAE/J wird das Service-Portfolio noch um weitere Funktionalitätergänzt werden, sodass dem Architektenmehr Freiheiten bei der Zusammenstellungdes Technologie-Stacks bleiben.

GAE, SaaS und Open-SourceIst die GAE/J als PaaS-Anbieter auch fürSaaS-Anwendungen geeignet? Lassen sichso auch Geschäftsmodelle, die auf Open-Source-Software bauen, bereitstellen? Inunserem Artikel „SaaS – Mehr als eineChance” (vgl. [Wid08]) haben wir sechsHerausforderungen identifiziert, die dieAkzeptanz von SaaS beeinflussen:

1. Sicherheit2. Anwendungsintegration3. Nutzung der Daten4. Abhängigkeit von Anbieter und Infra -

struktur5. Unsicherheit bei der Vertragsgestaltung6. Rechtliche Aspekte bei personenbezo-

genen Daten

Die Aspekte 1 bis 4 sind vor allem techni-scher Natur und sollen im Folgenden inBezug auf die GAE/J betrachtet werden.

SicherheitAlle GAE-Applikationen laufen innerhalbder Sandbox und unterliegen dabei derenstrengen Restriktionen. Ein Missbrauch derDaten über den Zugriff auf andere GAE-Anwendungen ist somit ausgeschlossen.

schwerpunk t

Tabelle 2: Amazon EC2, GAE und Azure im Vergleich (vgl. [Hor09]).

ein auf einer SaaS-Open-Source-Lösungbasierendes Geschäftsmodell ist dabeidenkbar. Die Kapazität kann schrittweiseausgebaut und dem Verbrauch an Rechen -leistung angepasst werden.

Der Early Look der GAE/J macht Lustauf mehr. Individualsoftware für kleine undmittlere Unternehmen kann so ohneInvestitionskosten in die Infrastruktur inder Cloud betrieben werden. ■

30 31

struktur, sondern auch die Stabilität derEngine (Sandbox, Framework) und derServices ins Gewicht.

Erst Anfang Juli 2009 gab es einen sechs-stündigen Ausfall der GAE. Aktuell ist dieGAE noch im Beta-Status. Die Stabilitätder Engine wird sich noch deutlich verbes-sern. Der Vorfall im Juli zeigt aber, in wel-che Abhängigkeit man sich bei einem PaaS-Anbieter wie Google gibt. Allerdings ist dieStabilität der Beta-Engine sicher deutlichhöher als die der meisten im Echtbetriebbefindlichen eigengehosteten Geschäftsan -wen dungen.

Aktuell bietet der PaaS-Anbieter Google,im Gegensatz zur Konkurrenz, noch keineService Level Agreements. Von Google sindkeine Aussagen zu diesem Kritikpunkt zubekommen. Es ist festzuhalten, dass dieGAE noch keine offiziell freigegebenePlattform ist, auf der bereits heute ge -schäftskritische Anwendungen implemen-tiert werden können. Will man den Marktfür Geschäftsanwendungen ernsthaft adres-sieren, muss Google in Zukunft in punctoSLAs nachlegen.

FazitDie GAE eignet sich besonders für kleineund mittlere Web-Anwendungen und hathier eine geringe Einstiegshürde hinsicht-lich Entwicklung und vor allem Betrieb.Mit der mächtigen Google-Infrastruktur imRücken lassen sich so eigene Geschäfts -ideen umsetzen und ohne hohe Investi -tionskosten an den Start bringen. Wegender geringen Kosten können dieseAnwendungen den Kunden auch als SaaS-Lösung im Sinne des Long Tail zurVerfügung gestellt werden. Nun könnenauch Anwendergruppen, die aufgrund desgeringen Marktpotenzials für die Herstellervon Standardsoftware eher uninteressantwaren, erreicht werden. Dies können Web-Anwendungen, Android-Apps oderGadgets sein. Viele Einschränkungen derPlattform können durch entsprechendeArchitekturentscheidungen relativiert wer-den. In einem Tutorial kann man dieEntwicklung einer GAE-basierten Anwen -dung erlernen (vgl. [Wid]).

Inzwischen setzen viele bekannte Web-2.0-Firmen wie der KommunikationsdienstTwitter auf PaaS-Angebote wie die GAE.Die Gründung einer neuen Online-Firmawird mit einer solchen Plattform deutlicheinfacher, weil teure Hardware nicht mehrerworben und gewartet werden muss. Auch

Die Applikation kann (und sollte) mit denfür JEE-Web-Anwendungen üblichenSicherheitsmechanismen ausgestattet wer-den. Im Servicebereich können hier auchSpring-Frameworks wie Acegi zum Einsatzkommen. Der spannende Aspekt beimThema Sicherheit ist aber kein technischer– vielmehr geht es um Vertrauen! Nutztman die GAE als Host-Umgebung, mussman dem PaaS-Anbieter vertrauen. Analogzu anderen Hostern, wie z. B. Amazon oderklassischen Rechenzentren oder auch dereigenen IT-Abteilung, besteht hier einDienstleistungsverhältnis. Wie die meistenHost-Anbieter lässt sich auch Google fürMissbrauch oder Verlust nicht in Haftungnehmen. Bei sicherheitskritischen Anwen -dun gen muss – wenn sie denn für die Cloudüberhaupt geeignet sind – frühzeitig einBackup-Konzept in die Architektur inte-griert werden.

AnwendungsintegrationDie GAE erlaubt die Kommunikation mitanderen Systemen ausschließlich über denService URLFetch. Darauf aufbauend wur-den bereits Clients für den Zugriff aufREST (vgl. [Noe09]) oder WS*-basierende(vgl. [Goo-g]) Services entwickelt. Ein -gehende Web service-Aufrufe können mitder aktuellen Version noch nicht umgesetztwerden. Die angesprochenen Entwicklun -gen im Bereich Messaging und WebServiceszeigen hier aber die Richtung auf.

Nutzung der DatenIn der Administrationskonsole sind allevon der GAE-Anwendung persistentgespeicherten Daten zu beauskunften. EineExportfunktionalität existiert aktuell nochnicht. Auch hier ist es nur eine Frage derZeit, bis erste Open-Source-Frameworksdiese Funktionalitätslücke schließen. Bisdahin können die Daten über eigeneServices exportiert werden.

Abhängigkeit von Anbieterund InfrastrukturWird die eigene Anwendung bei einemPaaS-Anbieter wie Google oder Amazonbetrieben, sind alle Nutzer von derStabilität der Infrastruktur des Anbietersabhängig. Eine Instabilität bedeutet einenimmensen Image-Schaden – für PaaS- undSaaS-Anbieter gleichermaßen. Amazon undGoogle haben den Ruf, eine sehr stabileInfrastruktur zu betreiben. Bei der GAEfällt aber nicht nur die technische Infra -

schwerpunk t

NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-Pdfs? Kontakt: [email protected]!

Literatur & Links

[Cha06] F. Chang et al, Bigtable: A Distributed

Storage System for Structured Data, 2006, sie-

he: http://labs.google.com/papers/bigtable.html

[Dat] DataNucleus, Homepage, siehe:

www.datanucleus.org/products/accessplatform/app

engine/support.html

[Goo-a] Google, What is Google App Engine,

siehe: www.code.google.com/appengine/docs/what

isgoogleappengine.html

[Goo-b] Google, Google App Engine – Quotas,

siehe: code.google.com/intl/de-DE/appengine/docs/

quotas.html

[Goo-c] Google, Google App Engine – The JRE

Class White List, siehe: code.google.com/intl/de-

DE/appengine/docs/java/jrewhitelist.html

[Goo-d] Google, Google App Engine for Java,

siehe: www.groups.google.com/group/google-

appengine-java/web/will-it-play-in-app-engine

[Goo-e] Google, Google App Engine, Billing and

Budgeting Resources, siehe: www.code.google.

com/intl/de-DE/appengine/docs/billing.html

[Goo-f] Google App Engine Blog, The new Task

Queue API on Google App Engine siehe:

www.googleappengine.blogspot.com/2009/06/new-

task-queue-api-on-google-app-engine.html

[Goo-g] Google, Force.com Web Service

Connector (WSC) siehe: wwwcode.google.

com/p/sfdc-wsc

[Hor09] T. Horn, Google App Engine (GAE/J),

2009, siehe: www.torsten-horn.de/techdocs/jee-gae

.htm

[Noe09] Noelios Technologies, Restlet in the

cloud with Google App Engine!, 2009, siehe:

http://blog.noelios.com/2009/04/11/restlet-in-the-

cloud-with-google-app-engine

[Wid] WidasConcepts GmbH, Homepage, sie-

he: www.widas.de

[Wid08] T. Widmann, A. Elsholz, SaaS – Mehr

als eine Chance, in: OBJEKTspektrum 5/2008