4tens

Google hat in der letzten Woche ein neues Mitglied seiner großen Webfamilie vorgestellt. Mit AppEngine gibt Google Entwicklern die Möglichkeit seine Infrastruktur zu nutzen. Sie machen es damit sehr einfach Anwendungen zu Entwickeln und auf ihren Serverfarmen laufen zu lassen, Daten auf Google-Datenbanken zu speichern und sogar das User-Authentifizierungs-System mitzubenutzen.

In diesem Artikel versuche ich, einen groben Überblick zu geben.

AppEngine != EC2+S3

Auf den ersten Blick mag es so erscheinen, als hätten Google ein System wie Amazons EC2 und S3 implementiert. Bei näherer Betrachtung wird aber schnell klar das AppEngine eine andere Ausrichtung hat. Während EC2 dem Kunden nichts von den Möglichkeiten und Schwierigkeiten virtualiserter Server vorenthält, konzentriert sich AE darauf, die Hürden bei der Entwicklung von Webanwendungen zu verringern. Der Benutzer von AE muss sich nicht darum kümmern eine Datenbank oder einen Server aufzusetzen, das Deployment einer Anwendung ist ein einziger Befehl und Statistiken werden automatisch erstellt.
Der große Vorteil von AWS ist die Flexibilität des Systems. Cronjobs, verschiedene Sprachen und alles was auf einer oder x virtualisierten Maschinen laufen kann sind möglich. AE hingegen bietet eine sehr eingeschränkten Funktionsumfang. Eine Sprache, eine Datenbank, HTTP-Request und Response. AE ist simpel und skaliert.

Charakter

AppEngine hat einige Charakteristika, die erwähnt sein wollen.
Die Sprache, in der Anwendungen entwickelt werden ist Python. Google plant weitere Sprachen zur Verfügung zu stellen, vorerst ist aber Python die einzige. Meiner Meinung nach eine sehr gute Wahl, zumal die Idee hinter AppEngine -wie gesagt- ist, ein niederschwelliges Angebot zu sein.
Hierbei ist alledings anzumerken, das einige Veränderungen an der Standard-Library vorgenommen wurden. Vereinfacht dargestellt wurde alle Module entfernt, die auf das Dateisystem oder Sockets zugreifen. Keine urllib! Keine urllib2! Zugriff auf Webresourcen geschieht über Googles eigenes URL Fetch Modul. Diese Einschränkungen sind recht gravierend und machen das portieren von bestehenden Python-Webanwendungen aufwendig. Beim Entwickeln neuer Anwendungen auf AppEngine sollten sie allerdings nicht zu sehr ins Gewicht fallen.

Weiterhin gibt keine relationale Datenbank. Daten werden in Googles selbstentwickelter Datenbank Bigtable abgelegt. Bigtable ist eine schemalose Datenbank für strukturierte Daten. Jeder Datensatz in Bigtable wird durch einen eindeutigen Schlüssel identifiziert und kann verschiedene Felder enthalten. Es gibt eine ganze Reihe Datentypen, von einfachen wie String und Float über Listen bis hin zu komplizierteren wie Geokoordinaten oder Adressen; auch für Google-Nutzer gibt es hier einen eigenen Datentyp. Die Kommunikation mit Bigtable ist in eine API abstrahiert, die das Erstellen von Datenstrukturen sowie das Schreiben und Lesen in die DB vereinfacht.

Ein Codebeispiel sagt in diesem Fall wohl mehr als viele Worte

from google.appengine.ext import db
from google.appengine.api import users

class Pet(db.Model):
    name = db.StringProperty(required=True)
    type = db.StringProperty(required=True, choices=set(["hund", "katze", "maus"]))
    birthdate = db.DateProperty()

pet = Pet(name="Fluffy", type="cat", owner=users.get_current_user())
pet.weight_in_pounds = 2

pet.put()

Hier wird eine Datenstruktur für Haustiere angelegt. Es gibt Felder für Name und Tierart (beschränkt auf eine vorgegebene Auswahl) sowie ein Integer und ein Datumsfeld. Im Feld owner wird ein Google-Account referenziert. Es wird ein Tier namens “Fluffy” angelegt und per .put() in die Datenbank geschoben.
Des weiteren gibt es mit GQL (gesprochen: gequel) eine SQL ähnliche Sprache, mit der Daten aus der Datenbank abgefragt werden. Die Abfrage

pets = db.GqlQuery(“SELECT * FROM Pet WHERE pet.owner = :1″, users.get_current_user())

gibt beispielsweise ein Query-objekt mit den Haustieren des gerade angemeldeten Google-Benutzers zurück. Diese Query kann weiter gefiltert werden oder man kann per pets.fetch(3) die ersten 3 Tiere in einer Liste erhalten.

Da Bigtable darauf ausgelegt ist im Google-Maßstab zu Skalieren, ist sie nicht darauf optimiert einzelne Abfragen möglichst schnell auszuführen, sondern darauf auch unter größter Last und bei großen Datenmengen gleichbleibende Performance zu bringen. Es ist also angebracht auf Entwicklerseite etwas umzudenken. Zum Beispiel ist es geschickt Daten stark zu denormalisieren oder Funktionen, wie z.B. Summenbildung, die RDMSe normalerweise on-the-fly anbieten beim Abspeichern der Daten zu erledigen und im Datensatz zu hinterlegen.

Auch gibt es in AE keine Entsprechung zu einer Session. Wenn Daten über mehrere HTTP-Requests persisitert werden sollen, muss dies über die Datenbank geschehen. Alledings bietet die Datastore Engine die Möglichkeit dynamisch Felder zu einem Datensatz hinzuzufügen.

SDK

Das Entwickeln von AE-Anwendungen läuft über ein SDK, das die AE-Infrastruktur lokal Simuliert. Das SKD gibt es für Linux, Mac und Windows und man kann es sich auch herunterladen ohne einen AppEngine-Account zu haben. Beinhaltet sind unter anderem, ein Entwicklungs-Server, lokaler Datastorage und simulierte User-Anmeldungen.
Eine Anwendung besteht im einfachsten Fall aus einer yaml -Konfigurationsdatei und einer Python-Datei. In der Konfiguration (app.yaml) werden die AppEngine-ID und die Version der Anwendung eingetragen und über Regular-Expressions festgelegt welche Skripte für welche URLs verantworlich sind.

Deployment

Wenn man eine Anwendung mit dem SDK entwickelt und getestet hat lässt sie sich mit dem Befehl:

appcfg.py update myapp/

im Web auf den Google-Servern veröffentlichen. Wobei myapp/ der Pfad, ist unterhalb dem die lokalen Skripte liegen. Die Anwendung ist nun unter http://my-app-id.appspot.com/ zu erreichen.
Unkomplizierter kann ich es mir kaum vorstellen.

Es gibt ein Admin-Interface für AE-Apps (Dashboard) über das Statistiken und Anwendungs-Logs angeschaut werden können. Hier gibt es ein Interface zum Betrachten und editieren der Datenbank-Inhalte sowie die Möglichkeit Mitarbeiter für kollaboratives Entwickeln einer Anwendung festzulegen. Ein weiteres schönes Feature ist die Versionsverwaltung. Wenn man seine Anwendung in der app.yaml versioniert hat kann man nun mit einem Klick aussuchen welche Version Live gehen soll.

Das System für das Deployment von Anwendungen, sehe ich als ein großes Plus für AppEngine.

Django

Eine der überraschenderen Enthüllungen im Rahmen des Releases von AppEngine ist, das die Möglichkeit besteht das Framework Django zu benutzen. Im Prinzip sollte jedes Python-Webframework, das sich an den WSGI-Standard hält unter AppEngine laufen, aber das AE-Team scheint sich auf Django zu konzentrieren. Beim SDK ist die Version v0.96.1 mit inbegriffen.
Die Community um das Django-Project ist natürlich in hellem Aufrur. Zum einen auf Grund der “Adelung” durch google und der neuen Möglichkeiten. Zum anderen gibt es aber auch viel Enttäuschung, da beim näheren hinsehen schnell klar wird das Django unter AppEngine stark eingeschränkt läuft.
Als wichtigster Punkt (neben weiteren) ist aufzuführen, das der ORM nicht mehr verwendet werden kann, da Bigtable keine relationale Datenbank ist. Dies führt natürlich dazu das Djangos eingebautes Administrations-Interface und die meisten der third-party-apps, die Django nicht zuletzt so attraktiv machen, nicht funktionieren.

Django kann also auf AppEngine bei weitem nicht so glänzen wie auf LAMP.

Wenn man sich AppEngine anschaut und bereits mit Django vertraut ist wird einem allerdings auffallen, das das Web-Framework an vielen Stellen Pate gestanden haben mag.
Das Templating-System wurde unverändert von Django übernommen. Das Mapping zwischen URLs und Skripten in der app.yaml läuft wie bei Django über Regular-Expressions. Der Django URL-Mapper ist deutlich leistungsfähiger, kann aber Problemlos verwendet werden.

Bei Abfragen der Datenbank wird bei AE ein GqlQuery -Objekt zurueckgegeben, welches dem Django equivalent QuerySet nahekommt.

Die Datenbank API ist Djangos ORM erstaunlich ähnlich. Zum Vergleich die Modelle aus Djangos offiziellem Tutorial für beide Systeme (von mir leicht angepasst):

Hier die Version für AppEngine (von Shabda Raaj):

from google.appengine.ext import db

class Poll(db.Model):
    question = db.StringProperty()
    created_on = db.DateTimeProperty(auto_now_add = 1)
    created_by = db.UserProperty()

class Choice(db.Model):
    poll = db.ReferenceProperty(Poll)
    choice = db.StringProperty()
    votes = db.IntegerProperty(default = 0)

und im Django ORM Original:

from django.db import models
from django.contrib.auth.models import User

class Poll(models.Model):
    question = models.CharField(max_length=200)
    created_on = models.DateTimeField(auto_now_add=True)
    created_by = models.ForeignKey(User)

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.CharField(max_length=200)
    votes = models.IntegerField()

Community

Die Reaktion in der Developer-Community ist recht heftig. Die 10.000 ersten Invites gingen weg wie warme Semmeln. Es sind bereits über 700 Blog-Postings zum Thema veröffentlicht worden (davon sind allerdings recht wenige auf deutsch und bis jetzt noch keiner von mir ).
Auf appgallery, der freiwilligen, zentralen Registrierung für Apps sind über 100 Anwendungen registriert. Es gibt bereits einige Open-Source-Projekte, die sich mit AppEngine befassen. In der Google Group gibt es über 2000 Beiträge.
Im Issue Tracker sind uber 200 Tickets angelegt worden, von denen sind einige (wenige) vom Team bereits bearbeited worden, viele noch offen und in einigen ist Chaos und Flamewar ausgebrochen.

Es gibt Anzeichen dafür, das das Team das Feedback ernstnimmt und in der weiteren Entwicklung darauf eingehen möchte. Ein häufig bemängeltes Thema war z.B. schnell nach dem Release das Problem, das man sich mit der Entscheidung, eine Anwendung auf der neuen Plattform zu Programmieren, stark vom grossen G abhängig macht. (Als Beispiel ein Post von Tim O’Reilly). Worauf das AppEngine Team schnell mit der Ankündigung eines Daten Im- und Export-features reagiert hat und die Community nach ihren Vorstellungen fragt.
(Das löst natuerlich das Problem nicht, das AppEngine-Code nicht (ohne weiteres) auf einer anderen Platform läuft.)

Fazit

AppEngine ist eine äusserst vielversprechende Erweiterung der Web-(2.0 wenn man so will)-Landschaft. Google versucht hier anscheinend eine Art Blogger für Web-Anwendungen zu schaffen, bei dem der User sich nur noch um den tatsächlichen Content kümmern muss. Content wäre hier natürlich Quellcode. Die Schwelle mal schnell eine Webanwendung zu entwickeln und zu sehen ob es funktioniert oder Geld bringt ist so sehr niedrig, da wenig bis nichts ausser Arbeitszeit investiert werden muss und der Aufwand, die Anwendung zu betreiben und zu administrieren, minimal ist.

Ob AE ein Erfolg wird muss sich noch zeigen. Ich denke es wird stark davon abhängen wie Google auf die Bedürfnisse der Entwickler von Anwendungen eingehen kann und in welche Richtung die Entwicklung gehen wird.

Zum Beispiel könnte man sich vorstellen, das sich Google AppEngine als den zukünftigen Kleister zwischen seinen zahllosen anderern Webprodukten vorstellt, von denen viele bereits per Python angesrochen werden können.

Tags: AppEngine, Google