Google App Engine selbst gemacht

[Leonidas]

Hallo,

Letztens wurde das auf dem Usertreffen gestreift, und ich überlege mal darüber etwas zu erzählen, daher fasse ich hier mal meine Gedanken dazu zusammen:

Inzwischen kennt fast jeder die Google App Engine (GAE). Nun interessiert mich persönlich ein Hosting meiner Applikationen dort herzlich wenig, aber die Technik dahinter ist vergleichsweise interessant. Einer der Kritikpunkte daran war, dass es durch die GAE einen Vendor Lock-In geben wird. Jedoch so stark ist dieser Lock-In gar nicht gegeben, wenn man mal AppDrop anschaut kann man durchaus etwas halbwegs kompatibles schaffen. Das größte Problem was ich bei AppDrop sehe ist die Skalierbarkeit. Es läuft zwar in Amazons EC2, aber nutzt eine Flat-File-"Datenbank" und ist generell eher als Proof-of-Concept zu sehen.

Was mich da ein wenig wundert ist, warum sie nicht gleich die SimpleDB verwendet haben, die ja bei Amazon sowieso verfügbar ist.

Nachdem man ja AppDrop entweder forken kann oder sich so etwas selbst baut, kommt dann noch die Frage der Datenbank, die nicht teil des SDKs ist. CouchDB könnte da eine Möglichkeit sein, wobei man mit Hypertable wohl näher an BigTable dran ist. Leider wollte Hypertable bei mir pertout nicht kompilieren, da CMake die BerkeleyDB nicht mochte. Auch sieht das mit Python-Bindings zumindest Momentan eher schwach aus. Jedoch kann Hypertable analog zu BigTable und dem Google File System auch auf ein verteiltes Dateisystem zugreifen, namentlich Kosmos und das HDFS, Hadoop Distributed File System. Und damit wären wir bei Hadoop.

Hadoop scheint einen etwas größeren Rahmen als Hypertable aufzuspannen, so enthält es neben HDFS auch noch noch eine MapReduce-Implementation und mit HBase eine Alternative zu BigTable. Somit ist es direkte Konkurrenz zu Google und es ist nicht sonderlich verwunderlich dass der weltgrößte Hadoop-Cluster bei Yahoo steht. Sehr nett ist, dass man HBase gleich nach dem entpacken fast sofort starten kann (ist noch etwas hakelig, aber bei Version 0.2 sieht man über sowas schon mal hinweg).

Auf HBase kann man auf mehrere Arten zugreifen, für Python-Programmierer sind REST (also via HTTP-Requests und mit XML-Antwort, also ähnlich wie CouchDB) oder Thrift interessant. Thrift ist bisher recht unbekannt, ist aber eine Library die RPC zwischen verschiedenen Sprachen ermöglicht. Im Prinzip ist es ähnlich zu den Protocol Buffers, deren FOSS-Version zumindest momentan kein RPC unterstützt. Diese Ähnlichkeit ist nicht verwunderlich, da Thrift ursprünglich von Facebook von ehemaligen Google-Leuten geschrieben wurde. Gut versteckt findet man dann auch Python-Bindings, die man zusammen mit den Thrift-Dateien die HBase mitbringt zu Python-Code generiert (ja, Code-Generation ist hässlich, aber so funktioniert Thift momentan für alle unterstützten Sprachen) den man dann importieren kann und mit dem man dann auf HBase schneller als mittels REST zugreifen kann.

Insgesamt hat mich momentan HBase von der Performance nicht überzeugen können, aber ich gabe zu dass ich erstens noch wenig damit gemacht habe und zweitens Hadoop für etwas größere Dienste ausgelegt ist, wo man Datenbanken clustert und wo relationale Datenbanken an ihre Grenzen stoßen. Nichtsdestotrotz ist es recht interessant und wert, im Auge bahalten zu werden.

Hmm, ich denke dass es schon auch irgendwie nett wäre, ein Cluster aufzusetzen und die GAE mit den vorhandenen Werkzeugen zu kopieren.

[sma]

Aus meiner Sicht hat die GAE zwei Vorteile: Google betreibt und skaliert die Anwendung und Single Sign On per Google Account, den Google ebenfalls verwaltet. Beide Vorteile verschwinden, wenn man seine Anwendung selbst hosten will. Der im Vergleich zu einer eigenen (relationalen) Datenbank primitive DataStore ist IMHO einzig der Preis, den man für die beiden Vorteile zahlen muss, aber nicht unbedingt ein erstrebenswertes Feature, das man für eine eigene Lösung nachbauen muss.

Das AppDrop nicht die SimpleDB benutzt ist wohl der angestrebten Kompatibilität geschuldet. AFAIK betreiben die einfach das SDK auf EC2-Instanzen, werden also eine mieserable Performance aufgrund der DataStore-Simulation aus dem SDK haben. SimpleDB scheint mir zu unterschiedlich, als dass man dies als Backend für einen DataStore nutzen könnte.

Allgemein denke ich aber zur Zeit, dass der Preis für Skalierbarkeit für die meisten Anwendungen, die eh nicht in diese Bereiche kommen werden, zu groß ist und das man "traditionell" besser fährt. Ein bisschen fühlt sich das so an, als wenn man gleich in Assembler beginnt, für den Fall, dass man mit seinem Programm erfolgreich ist und die optimale Performance haben will.

Dafür, dass es am Anfang einen sehr großen Hype gab und jeder (auch ich) unbedingt einen Testaccount haben wollte, hört man jetzt eigentlich recht wenig und auch die Anzahl der Anwendungen scheint mir nicht wirklich groß und bemerkenswert zu sein.

Stefan

[Leonidas]

Aus meiner Sicht hat die GAE zwei Vorteile: Google betreibt und skaliert die Anwendung und Single Sign On per Google Account, den Google ebenfalls verwaltet. Beide Vorteile verschwinden, wenn man seine Anwendung selbst hosten will.

GAE selbst nachbauen ist für Einzelpersonen sicherlich wenig nützlich, ich denke dass ist eher interessant für Hoster. HDFS wird auch erst bei vielen Nodes sinnvoll. Denn auch heute hat kaum jemand ein Rack bei sich stehen, weil er einen Root-Server will. Das SSO kann dann der Hoster selbst übernehmen, was natürlich für die User weniger praktisch ist, aber vielleicht öffnet Google auch die API und wird zum Identity Provider.

Das AppDrop nicht die SimpleDB benutzt ist wohl der angestrebten Kompatibilität geschuldet. AFAIK betreiben die einfach das SDK auf EC2-Instanzen, werden also eine mieserable Performance aufgrund der DataStore-Simulation aus dem SDK haben.

Ich habe mal das Video angesehen und AppDrop ist eine Rails-Applikation die GAE-Apps verwalten kann, also eigentlich etwas wenig erwähnenswertes. Und sie ist ziemlich kaputt

Um GAE jetzt abschließend zu bewerten ist es meiner Meinung nach noch zu früh. Sie kann Python einen ziemlichen Push geben, da sie das Deployment in das Niveau von PHP bringt: Daten hochladen und fertig. Falls dazu dann Bücher herausgegeben werden könnten sicher auch nicht Python-Programmierer sich damit befassen. Aber wir werden sehen ob da noch was kommt.

[sma]

GAE selbst nachbauen ist für Einzelpersonen sicherlich wenig nützlich, ich denke dass ist eher interessant für Hoster.

Jepp. Aber dann soll auch der darüber nachdenken, wie :) Und es wäre natürlich wieder ein vendor-lockin, wenn er nicht eine standardisierte Lösung hat, die es mir erlaubt, meine Anwendung umzuziehen.

vielleicht öffnet Google auch die API und wird zum Identity Provider.

Es wundert mich sowieso, warum Google nicht schon längst OpenID-Provider für die Accounts spielt. Yahoo war da schneller.

Update: Es gibt http://openid-provider.appspot.com/, aber das wirkt irgendwie nicht offiziell. Scheint eine GAE-Beispielanwendung zu sein.

Um GAE jetzt abschließend zu bewerten ist es meiner Meinung nach noch zu früh. Sie kann Python einen ziemlichen Push geben, da sie das Deployment in das Niveau von PHP bringt:

Das mit dem Push ist richtig und hat z.B. dazu geführt, dass sie mehr Leute bei mir in der Firma für Python interessiert haben. Das kombiniert mit Jython und dem anstehenden Release von Python 3.0 sollte der Sprache verdiente Aufmerksamkeit bescheren.

Google hat zwar versprochen, auch andere Sprachen zu unterstützen, aber wie bei anderen Projekten haben sie es nicht verstanden, ihren Hype zu nutzen und er ist verpufft. Ob und wann da Ruby (1239 Stimmen), Java (1941), PHP (1340), usw. (1474+) unterstützt werden, ist mir unklar.


Stefan

[N@sty]

Für mich ist der gesamte Cloud-Aufbau eher eine geschickte Werbekampagne als das non plus ultra Feature. Welche Webseite braucht das schon? - nicht mal die grösten Seiten wie flickr und co. ( http://highscalability.com/ ). BigTable ruiniert nur unnötig die Performance und hat eine SEHR gewöhnungsbedürftige Syntax. Hätte Google lieber eine MySQL DB dazugegeben. Das einzig gute ist das vielleicht Python dadurch endlich mal seinen längst verdienten Hype bekommt.

[Leonidas]

MySQL, ja pfui. Besser dann gleich eine echte Datenbank dazulegen

[sma]

BigTable ruiniert nur unnötig die Performance und hat eine SEHR gewöhnungsbedürftige Syntax. Hätte Google lieber eine MySQL DB

Ein relationales Datenbank-System kann prinzipbedingt nicht so skaliert werden, wie Googles Lösung. Das wäre also keine Alternative. Und damit auch nicht "unnötig." Skalierbare Anwendungen zu schreiben ist einfach schwieriger.

IMHO hilft es, aus den imperativen Denkmustern zu kommen, indem man auch andere Programmierspachen benutzt. Erlang oder Clojure sind da zwei interessante Kandidaten - oder Haskell, wenn man statische Typsysteme liebt. Diese passenden jetzt nicht mit der GAE zusammen, aber vielleicht gibt es ja noch weitere Anbieter.

Ansonsten: Die Cloud kommt und da im Web jede Anwendung prinzipiell für jeden Anwender verfügbar ist, kann man (theoretisch) sehr schnell Millionen von Anwendern haben. Man schaue sich nur mal an, welchen Erfolg einige Facebook-Anwendungen hatten und haben. Wer für Zig Millionen an Usern plant (und nicht nur ein paar (zehn)tausend, für den kann die App Engine interessant sein.

Stefan