I really enjoyed listening to Dr. Werner Vogels. Dr. Vogels is Vice President & Chief Technology Officer at Amazon.com where he is responsible for driving the company’s technology vision, which is to continuously enhance the innovation on behalf of Amazon’s customers at a global scale.
This vision is why I have moved to EC2/S3 in 2007. I guess, I’ve finally become an Amazon AWS fan boy.

Even if audio is a bit out of sync, it’s worth to listening this long session.
As a developer from the bottom of my heart I like especially this quote: “There is no value in being a system administrator. You do not build a better product by being a better server maintainer.” This is so true, but I wonder how EC2 can free me from typical administration tasks. I still have to maintain my virtual server instances with the whole LAMP stack. Plus I have to think about how to scale horizontally (what to do when I need more virtual server instances).
In contradiction to Amzon’s EC2, Google’s AppEngine promises to free me from doing the admin tasks (no OS/LAMP Stack to maintain) and to solve the scale problem (no Database Replication to set up). AppEngine scales out of the box – the downside is, that it offers a very limited runtime just for you app.
True, a single EC2 instance doesn’t scale out of the box but it also doesn’t limit you in doing what you want to do on your virtual server. With EC2 I have to solve the scaling on my own. For this price I got more freedom.
I’m exited to use and learn about EC2/S3/Storefront each day but I also hope that Google’s AppEngine will offer a wider range of runtime environments in the future. t’s an interesting Cloud-Year 2009! #buzzword

Ich habe zu wenig Zeit um in das interessante Thema tiefer einzusteigen – aber hier dennoch ein paar lesenswerte Artikel (etwas iPhone-lastig):

Über die Schwachtstellen des T-mobile Android G1: zZ kein Syncing, Keyboard, Hardware, T-Mobile Tarife und mehr.

Aus Entwickler-Sicht sehr interessant der Vergleich zum “kontrollierten” AppStore vs. dem unreguliertem Andorid Market Place.

Und ebenfalls interessant: http://gizmodo.com/5053441/giz-explains-whats-good-and-bad-about-developing-for-android-and-iphone

Aus Benutzersicht ist das iPhone zZ noch das deutlich rundere Paket. Zumal wenn man auf dem Desktop OS X einsetzt, drängt sich das iPhone geradezu auf. Allerding sieht es aus Entwicklersicht ganz anders aus: wenn man nicht in das geregelte (geschlossene) System von Apple eintauchen will (und Objective C nicht einsetzen mag), bleibt nur der Android.

Ich vermute, dass Android zum Start kein Renner wird und sich womöglich ähnlich schwer tun wird wie Linux den Desktop zu erobern. Aber immerhin hat das iPhone nun einen mächtigen Gegenspieler (mit sehr starken Konzepten) und die OpenSource Entwickerkommunity hat endlich ein SDK 1.0 für Android. Es wird spannend…

Es entlastet mich als Entwickler von all diesen adminstrativen Tasks die ich überlicherweise beim LAMP Stack habe. Es macht quasi den Administrator in mir arbeitslos und schenkt dem Entwickler in mir die frei gewordene Zeit um mich auf die Anwendung zu konzentrieren.

Teil 1 – Vorstellung der Google App Engine Preview:

Ab 2:50 stellt Kevin Gibbs die Vorteile der App Engine gegenüber dem klassischen LAMP Stack vor. Ich frage mich aber, ob die App Engine mir auch die Flexibelität des LAMP Stacks gibt – aber das kann zZ nicht beurteilt werden, da die App Engine ja zZ. nur ein Preview ist.

Mit Google App Engine kann ich die selbe Infrastruktur nutzen wie Google. Das ist analog wie bei Amazon mit S3, EC2 und SimpleDataService. Bei Amazon nutze ich jedoch virtuelle Server-Images mit EC2 und bin daher viel Flexibler als mit der Google App Engine (die als Sandbox doch sehr restriktiv ist). Ich habe bei EC2 aber halt auch den Mehraufwand, dass ich meine virtuellen Serverinstanzen selbst aufbauen (linux, apache, mysql, php order anderes) warten muss und ausgefallene Instanzen erkennen und ersetzten muss – ich muss dort Lösungen entwicklen für persistente Filesysteme (via integration von S3) und Lösungen entwicklen für persistene Datenbanken (SimpleDataService). All das ist bei Googles App Engine deutlich einfacher weil bereits in einem Gesamtframework integriert. Bei Amazon habe ich zwar mehr Freiheiten (mit meinen virtuellen Server Instanzen kann ich quasi alles anstellen und bin nicht nur auf das Hosting von WebApps beschränkt) – komme aber, wenn ich eine vergleichbare Skallierbarkeit mein Web App wie bei Google App Engine entwicklen möchte, zu den gleichen Restriktionen die die App Engine hat (kein Schreiben in lokales Filesystem, keine relationale Datenbank wie mySQL etc.).
Google App Engine erscheint also als idealer “out of the box” Hoster für Django Apps. Sicher wird die App Engine auch bald für Ruby on Rails verfügbar sein, da die Frameworks sehr ähnlich sind und sich RoR für Googles App Engine geradezu aufdrängt.

Teil 2 – eine einfache Demo.
Die Original-Demo von Campfire ist wegen der geringen Auflösung nicht zu gebrauchen. Hier eine bessere Version mit dem gleichen Inhalt:

Teil 3 – Betrachtung der 5 Komponenten des App Engine Stacks:

1) scalable serving infrastructure
2) python runtime and libraries
3) SDK
4) web-based admin console
5) scalable datastore

Interessant ist hier der Teil wo erklärt wird, wie die Skallierbarkeit umgesetzt wird. Man braucht eine Alternative zu klassischen relationalen Datenbanken (wie z.B. mySQL) die es erlaubt besser zu skallieren. Googles Big-Table und GQL sind die Komponenten, die für die App Engine den DataStore übernehen und so die Skallierbarkeit “out of the box” mit sich bringen.

Bei EC2 von Amazon kann ich natürlich auch weiterhin eigene mySQL Server einsetzen – aber wenn ich wirklich gross skalieren will, brauche ich auch etwas, das besser skalliert als mySQL. Hierfür stellt mir Amazon via SimpleDB eine vergleichbare Technologie breit. Aber ich muss das bei Amazon alles irgendwie erst unter einen Hut bringen und selbst managen (EC2, S3, SimpleDB, Integration RoR, Skallierung via virtueller Instanzen in Abhängigkeit der Last usw.) . All das gebe ich bei Google App Engine an Google ab – und zahle dafür natürlich den Preis, dass ich nicht so flexibel bin wie bei EC2.

Die Umstellung von relationalen Datenbank auf BigTable/GQL bzw. SimpeDB bei Amazon sehe ich zZ. als die größte Hürde für Apps die bereits mit Django oder RoR entwickelt wurden.

Teil 4 – Python Entwickler und Google Software Engineer Guido van Rossum spricht über Goolge App Engine:

Als Entwickler teile ich seine Begeisterung für das Projekt – und als Sprache wünsche ich mir neben Python natürlich Ruby.

Teil 5 – Google Product Manager Pete Koomen demonstriert App Engine’s web-basierte admin console:

Hier muss sich zeigen, ob man die gleiche Flexibelität bekommen, die man hat, wenn man seine Logs selbst vorliegen hat (die kann ich per AWStats, SawMill usw. auswerten). Aber auch hier gibt es natürlich vereinfachungen: Wenn ich meinen eigenen Cluster von WWW-Servern fahre muss ich die Logs zusammenführen bevor ich sie auswerten kann.
Auch fällt mir zZ die Vorstellung schwer, dass ich meinen Web-Server nicht mehr selbst konfigurieren kann.
Als lokale Datensicherung für den DataStore (BigTable oder SimpleDB) wird es sicher auch ein Dump und eine Restore-Möglichkeit geben – denn irgendwie möchte man seine Daten ja auch lokal gesichert wissen. All das sind Punkte die man erst in der Praxis kennen lernen muss – aber von den Möglichkeiten, die Google mir mit der App Engine in die Hand legt bin ich total begeistert. Ich wünsche ich hätte ein 48-Stunden Tag, damit ich mich (neben meiner normalen Arbeit) damit beschäftigen könnte…

Teil 6 – Google Product Manager Paul McDonald zeigt einige Demo Anwendungen:

Last but not least habe ich noch dieses Video gefunden:
Dion Almaer von Google bringt es auf den Punkt, wenn er App Engine mit Amazon EC2, S3 und SimpleDB vergleicht. Ausserdem macht er grosse Hoffnung auf ein rasches Erscheinen von RoR via App Engine, da er selbst ein RoR Fan ist. Absolut sehenswert dieses Interview:

On the train ride between Brussels and London, I got the chance to interview Dion Almaer, of Google, regarding the recently announced Google App Engine cloud computing product.

Einen leicht verständlichen Artikel zu Google App Engine und die möglichen Strategien von Goolge habe ich bei taz.de gefunden.

Brian Berliner beschreibt es in seinem Blog ganz treffend:

Amazon Web Services gives you the logs and asks you to build yourself a cabin. Amazon Web Services lets you change that cabin into a chateaux or a lodge, but you’ve got to wield the hammer.
Google App Engine gives you a log cabin and asks you to move in, invite your friends, and start to party. When the party gets too big, Google App Engine builds you a bigger cabin, chateaux, or lodge. You keep partying.

I believe the simplest approach wins.

Und genau in diesem Moment wo sehr viele Entwickler von Apple mehr als verstört wurden, kommt Google mit einem frühen Ausblick auf das SDK zum Android und zeigt uns das Eldorado: http://code.google.com/android/

Neben eine appetitanregendem Video werden auch gleich 10 Millionen US$ für einen Entwickler-Wettbewerb ausgeschrieben um Anreize zu schaffen für die erste vollständig offene und freie Mobile Plattform zu entwickeln.

Deutlich mehr in die Tiefe geht Google Analytics, was für AdWords Benutzer kostenlos zur Verfügung gestellt wird (früher auch nur, wenn man von Google einen Einladungscode angefordert hatte – inzwischen scheint Google genügend Kapazitäten zu haben und bietet allen Benutzern mit einem Google-Konto diesen Dienst kostenlos an). Hier haben sich die Google-Entwickler richtig ausgetobt und bieten wahrscheinlich alles, was man sich von einem Analyse-Tool wünscht: angefangen z.B. bei den Klassikern “beliebteste Inhalte”, “Tiefe oder Länge des Besuchs” bis hin zu “Besuchertreue” und “definierte Trichternavigation”. Aber auch die Integration mit AdWords wird geboten, so dass Conversation Tracking und CPC-Analysen direkt in Analytics ermöglicht werden.

Eine großartige Idee finde ich das “Website Overlay” was mir die Site anzeigt und dort zu den anklickbaren Elementen eine Statistik einblendet, so dass ich quasi die Hauptpfade der Besucher rasch erfassen kann und so ggf. das Layout der Site daraufhin anpassen kann. Alles in allem ist Google-Analytics also Wert es sich mal genauer anzuschauen denn ich glaube es ist für Entscheider und Webmaster ein sehr wertvolles Tool.

Einziger Wehrmutstropfen ist die geringe Aktualisierungsrate von Google Analytics – die Berichte werden laut FAQ nur einmal täglich aufgefrischt – wie schön wäre es, wenn hier die bei StatCounter gebotene Echtzeitauswertung Einzug finden würde.

Viel Spaß beim Auswerten.