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

Mit CloudFront kann ich nun vor meinen öffentlichen S3 noch ein Content Delivery Network vorschalten, dass automatisch meine Inhalte über alle verfügbaren Standorte synchronisert und bei Requests auf meine Inhalte immer die schnellste Verbindung auswählt. Mehr Details zur neuen CloudFront, dem Content Delivery Network von Amazon gibt’s unter aws.amazon.com/cloudfront/ und im original Wortlaut des Developer-Newsletters.

Dear AWS Customer,

Today, we’re excited to announce the public beta of Amazon CloudFront, a new web service for content delivery. With CloudFront, you can distribute content using a worldwide network of edge locations that provide low latency and high data transfer speeds. CloudFront works seamlessly with other AWS services such as Amazon S3, and like all AWS services, is self-service with no up-front commitments, no long-term contracts and pay-as-you-go pricing. You can sign up for CloudFront – and begin using it today – at aws.amazon.com/cloudfront.

The initial release lets developers and businesses deliver popular, publicly readable content worldwide. CloudFront has a number of exciting features that differ from many traditional methods of content delivery. It:

lets you get started easily there’s no need to contact a sales person or negotiate a contract. Anyone can get started in just minutes with only a credit card.
works seamlessly with Amazon S3 – you can start delivering your files stored in Amazon S3 through CloudFront edge locations in a matter of minutes.
is simple and easy to use – a single API call is all that’s needed to get started delivering your content.
lets you pay only for what you use there are no minimum fees and no long-term commitments.
To Use Amazon CloudFront, all you need to do is store your objects in Amazon S3 (make sure they are publicly readable), then, make a simple API call to register your bucket with CloudFront. This API call will return a new domain name for you to include in your web pages or application. When clients request an object using this domain name, they will be automatically routed to the nearest edge location used by Amazon CloudFront for fast delivery of your content. No negotiations, no upfront fees, and no volume commitments. It’s that simple.

You can learn more about Amazon CloudFront and get started using the service at aws.amazon.com/cloudfront.

Sincerely,
The Amazon CloudFront Team

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.

Dear AWS Developers,

This is a short note to let a subset of our most active developers know about an upcoming limited beta of our newest web service: Amazon SimpleDB, which is a web service for running queries on structured data in real time. This service works in close conjunction with Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Compute Cloud (Amazon EC2), collectively providing the ability to store, process and query data sets in the cloud.

Traditionally, this type of functionality has been accomplished with a clustered relational database that requires a sizable upfront investment, brings more complexity than is typically needed, and often requires a DBA to maintain and administer. In contrast, Amazon SimpleDB is easy to use and provides the core functionality of a database – real-time lookup and simple querying of structured data – without the operational complexity.

Were excited about this upcoming service and wanted to let you know about it as soon as possible. We anticipate beginning the limited beta in the next few weeks.

Seite zum Beta-Projekt bei Amazon: Amazon SimpleDB und Developer Guide.
AWS-Blog: A Place for Everything – Amazon SimpleDB

Eine etwas älteres Video von seinem Vortrag (mit zum Teil überholten Aussagen, siehe hier und hier), welches aber dennoch wirklich ansehenswert ist, gibt es unter: www.loromoar.com.

Jonathan stellt im Slide 34/35 “EC2 for extra capacity” ein optionales Model vor, bei dem für die DB und den Loadbalancer ein Inhouse-Lösung angetrebt wird (Eigens RZ oder klassischer Hoster). Die Gründe dafür deutet er auch schon im Video an (welches dieses Modell noch nicht zum Gegenstand der Diskussion gemacht hatte): EC2 hat kein persistentes Speichermedium. Fällt die Instanz aus, gehen die Daten verloren. Wenn nicht konstant dedumpt und auf S3 gesichert wird, droht Datenverlust.
Ich fürchte jedoch das gerade bei RoR-Anwendungen recht komplexe und viele SQL Abfragen entstehen, so das sich eine erhöhte Latenz zwischen den Application-Servern die unter EC2 laufen und der Datenbank, die inhouse läuft sehr negativ auf die Antwortzeiten auswirken könnte. Ich würde daher lieber die DB@EC2 belassen und das Verlustrisiko von Daten minimieren indem eine Replikation (Slave) in eine oder mehrere EC2 Instanzen oder auch auf einen Slave im eigenen RZ gemacht wird. Der Vorteil dabei ist, dass die Application-Server kürzere Latenzzeiten zur DB haben und der Traffic innerhalb EC2 bleibt und somit auch kostenlos ist. Fällt die Master-DB aus, so kann ein Slave die Aufgabe übernehmen.

Das Argument den Loadbalancer Inhouse zu nehmen ist, dass beim Ausfall des EC2 basierten Loadbalancers eine neue IP zugewiesen wird und es somit zur vorübergehenden Unerreichbarkeit kommen kann, wenn DNS-Server die Updates nicht rasch genug verarbeiten. Steht der Loadbalancer hingegen im eigenen RZ oder beim klassischen Hoster habe ich eine statische IP und kann das Problem (eher) umgehen, so dass keine DNS-Update erforderlich wird.
Aber man erkauft sich diesen Vorteil zum einen durch mehr Latenzzeit: der Loadbalancer muss nun alle Requests erst an die weit entfernten EC2 Instanzen weiterreichen und auf deren Antwort warten. Der Weg von den Clients zum Loadbalaner kommt in diesem Fall dann noch hinzu. Hier kann es sich dann schon lohnen über eine Proxy/Cash-Lösung nachzudenken. Was aber ebenfalls noch zu berücksichtigen ist: Ich habe nun zwei mal den Traffic zu bezahlen: Einmal zwischen EC2 und dem Loadbalancer und hinzu dann noch der Traffic zwischen dem Loadbalancer und den Clients.

Also auf den ersten Blick würde ich den Loadbalancer doch lieber auch bei EC2 einsetzen…

Ein recht radikaler aber genialer Ansatz ist der Verzicht auf einen dedizierten Loadbalancer.

Lei Zhu beschreibt in seinem Aritkel wie man das Problem mit der dynamischen IP lösen kann indem man ganz auf einen Loadbalancer verzichtet und das Konzept und die Aufgabe des Loadbalancers gleich auf den Client überträgt: Client-Side Loadbalancing!

Zum Slide:

| View | Upload your own

United States

Storage
$0.15 per GB-Month of storage used

Data Transfer
$0.10 per GB – all data transfer in
$0.18 per GB – first 10 TB / month data transfer out
$0.16 per GB – next 40 TB / month data transfer out
$0.13 per GB – data transfer out / month over 50 TB

Requests
$0.01 per 1,000 PUT or LIST requests
$0.01 per 10,000 GET and all other requests*
* No charge for delete requests

Europe

Storage
$0.18 per GB-Month of storage used

Data Transfer
$0.10 per GB – all data transfer in

$0.18 per GB – first 10 TB / month data transfer out
$0.16 per GB – next 40 TB / month data transfer out
$0.13 per GB – data transfer out / month over 50 TB

Requests
$0.012 per 1,000 PUT or LIST requests
$0.012 per 10,000 GET and all other requests*
* No charge for delete requests

Zwar sind die die Preise etwas höher als S3 in den USA, aber wenn man plant statischen Content via public buckets verfügbar zu machen, so ist S3 mit Standbein in Europa diesen Aufpreis ganz sicher wert.

Für die Verwendung mit EC2 bleibt S3 USA natürlich attraktiver, da es nicht nur schneller sein dürfte sondern hier auch der Traffic zwischen EC2 und S3 USA kostenfrei ist. Traffic zwischen EC2 und S3 Europa hingegen ist kostenpflichtig.

Damit wird greifbar, was ich mir schon länger wünsche: EC2 auch in Europa.

Auf einer Debian (oder auch Ubuntu) basierten Linux Distribution erfolgt die Installation mit:

Das Verwenden der yml Datei wurde erst in einer späten Version von s3sync hinzugefügt. Es erspart das Setzen der Umgebungsvariablen bevor das s3sync Script aufgerufen wird.

Ein Beispiel für ein SSL_CERT_FILE wird im Readme von s3sync gegeben.

Besitzer, Gruppe und Rechte bleiben mit s3sync erhalten. Leider gehen mir aber die Timestamps verloren.

Weiterführende Dokumentation gibt es hier. In diesem Beispiel wird auch gezeigt wie man s3sync auf einer ec2 Instanz einsetzt.

Jeder Benutzer kann bis zu 100 Buckets erstellen. Da die Buckets bei öffentlichen Dateien als Teil der URL erscheinen sollte man sich hier sprechende und kurze Namen überlegen (sofern diese noch frei sind). Jedes Bucket kann man wie ein logisches Laufwerk betrachten. Daher ist es auch möglich in unterschiedlichen Buckets unterschiedliche Inhalte/Strukturen zu verwenden. Es spricht also nichts dagegen mit einem S3 Benutzerkonto JungleDisk oder andere S3 basierte Tools und S3Sync parallel in getrennten Buckets zu verwenden.

Während der Evaluierungsphase habe ich neben s3cmd.rb auch S3Fox verwendet um den Inhalt meiner mit s3sync.rb gefüllten Buckets zu kontrollieren. Wie auch bei rsync schätze ich den Vorteil, dass ich die erstellten Backups - anders als bei tar oder Duplicity - direkt betrachten, kontrollieren und nutzen kann. Da jede Datei in einem Key/Blob abgelegt wird, kann man leicht einzelne Dateien restaurieren oder über die S3 ACL öffentlich zugänglich machen. Leider hat S3Fox Probleme die von s3sync gefüllten Buckets darzustellen. Im s3sync Readme (Changelog) gibt der Autor dazu folgenden Hinweis:

In the case of commands of the form:
s3sync -r somedir somebucket:
The root directory node in s3 was being stored as "somedir/" instead of "somedir"
which caused restores to mess up when you say:
s3sync -r somebucket: restoredir
The fix to this, by coincidence, actually makes s3fox work even *less* well with
s3sync. I really need to build my own xul+javascript s3 GUI some day.

Anstatt von S3Fox nutze ich nun den Mac OS X S3 Browser.

Alternativen zu S3Sync?
Für umfangreichere Backups mag der s3sync Ansatz weniger geeignet sein, denn aufgrund der Architektur von S3 muss s3sync für jede Datei einen Request an S3 senden, was viel Bandbreite und Zeit verbrauchen kann.

Aus diesem Grund wäre eigentlich Duplicity die bessere Wahl um umfangreiche Datenmengen bzw. viele Dateien auf S3 zu sichern. Duplicity verfolgt einen ganz anderen Ansatz und ist damit in der Lage sehr bandbreitenschonend Backups zu erstellen. Seit der Version 0.4.3.RC9 (2007/07/09) unterstützt Duplicity auch S3 nativ als Backend.
Für mein Vorhaben ist Duplicity jedoch weniger geeigent, da die gesicherten Dateien nicht mehr im "direkten" Zugriff in S3 verfügbar sind sondern in encrypted und signierten Archiven abgelegt werden. Da inkrementell gesichert wird, wird der erforderliche Speicherplatz immer größer da Archive nicht gelöscht werden können solange nicht eine erneute Vollständige Sicherung gemacht wird. Eine vollständige Sicherung auf S3 verbraucht jedoch wieder enorme Bandbreite / Traffic und Zeit. Und immer nur inkrementell zu sichern erscheint mir auch nicht ratsam.

Bestrebungen S3 über ein Filesystem nutzbar zu machen (S3/Fuse, JungleDisk u.a.) um dieses dann per rsync nutzen zu können erscheinen mir aber auch nicht vielversprechend, da die S3 API nur sehr grundlegende Funktionen bereitstellt (z.b. kein Seek in einem Blob; ändert sich ein Blob, so muss er komplett neu hochgeladen werden), so dass die Vorteile von rsync hier nicht ausgespielt werden können.

Allerdings wäre S3/fuse natürlich eine KillerApp. Insbesondere auch für EC2 um so ein persistentes Filesystem zu erhalten.