Blog jetzt nicht mehr auf der AppEngine

Wie neulich schon angedroht, habe ich diesem Blog ein neues Backend spendiert.

Die Google AppEngine kam für mich nicht mehr in Frage, da das neue Pricing nicht dem entsprach, was ich mir vorstellte. Was also als Alternative nehmen?

Wordpress? Das kommt mir nicht auf den Server.
Serendipity? Hmpf.
Movable Type? Weiche von mir Satan!

Außerdem musste das System ein Kriterium erfüllen: Es muss skalieren. Nicht weil ich es brauche, sondern weil ich es kann. Es sollte auch nicht viel kosten, wenn kein Traffic drauf ist. Also musste wieder eine Cloudlösung her. Da blieben also nur Google, Amazon oder Microsoft übrig.

Google AppEngine wollte ich grad loswerden, Microsoft ist mit Azure eher im Business-Bereich tätig. Bleibt nur Amazon übrig.

Eine EC2 mieten? Das ist mit einer Small-Instanz (Micro-Instanz ist zu lahm) und knapp 60-80 Euro im Monat nicht wirklich billig. Und wenn kein Traffic drauf ist, hab ich wieder das Problem wie mit jedem Root-Server: Ich bezahle, ohne dass die Leistung in Anspruch genommen wird. Aber der Heiner erzählte mir vor einigen Jahren mal seine Idee, einfach ein CMS in der S3/Cloudfront zu machen. Gute Idee!

Amazons CDN (Content Delivery Network) Cloudfront ist eine der skalierbarsten Lösungen der Welt. Ja, es gibt noch Akamai und andere CDNs, aber Amazon kam mir grad gelegen.

Wie legt man jetzt ein Blog auf die Cloudfront/S3? Wenn wir mal ehrlich sind, sind Blogs ja doch eine sehr statische Angelegenheit. Man schreibt einen Beitrag, dieser ändert sich nicht wirklich oft und ich lege ihn deshalb statisch ab. Genau wie den Rest der Seite (Impressum, Feed, Sitemap und so weiter). Dafür habe ich mir ein Backend in PHP mit CouchDB geschrieben, welches den Ramsch einfach komplett generiert. Auf einer 500 MhZ-Maschine dauern dabei 2000 Seiten ca. 5 Sekunden in der Generierung. Das ist OK.

Warum CouchDB? Mein Plan ist: Ich baue mir ein EC2-Image, welches beim Hochfahren einfach die Datenbank aus einem geschützten und verschlüsselten S3-Bucket lädt, in /var/lib/couchdb/ legt, ich einen Blogbeitrag schreibe und publishen kann und nach der Generierung die gesamte Datenbank wieder in die S3 lege. Dies hat den Vorteil, dass ich keinen Server brauche, um trotzdem von überall bloggen zu können und dabei keinerlei Kosten verursache, wenn ich mal wieder nur einmal im Monat einen Beitrag schreibe. So eine Instanz würde ca. 10 Cent je Stunde kosten. Das ist weit billiger als jeder Hoster und die gesamte Lösung skaliert nahezu unendlich.

Nun muss ich dazusagen, dass ich auch einfach keine dynamischen Inhalte auf dem Blog habe. Aber wenn man z.B. sein eigenes Kommentarsystem haben möchte, kann man dies natürlich auch machen und dafür habe ich auch eine einfache Lösung rumliegen. Aber bevor ich noch weiter rumschwadroniere, lass ich euch erstmal über Disqus kommentieren und bin gespannt, was ihr darüber denkt.


Kommentare

Nico Lumma

warum einfach, wenn es auch kompliziert geht? :)

Alexander Plavinski

Hast du vor deine Skripte zu veröffentlichen und/oder es detailierter zu beschrieben?

mthie

Sagt der Mensch mit einem der langsamsten Blogs und einer Datenbank, die nur 30 Connections annimmt… :)

mthie

Ich kann es demnaechst gerne mal etwas detaillierter machen :)

Nico Lumma

hey, das ist einfach nur ein ausleseprozess, damit nicht jeder in den genuss meiner texte kommt

Kai-Christian

Ich finde jetzt irgendwie keinen brauchbaren Hinweis auf die sich bei dir akkumulierenden Kosten. Willst du darauf noch einmal eingehen? Danke von der Noob-Fraktion…

Sebastian Michaelsen

Ein Blog komplett aus nem CDN liefern.. Habe ich zumindest noch nicht gehört. Augenscheinlich funktioniert es ja ganz gut.

Danke für den interessanten Einblick.

Sebastian Michaelsen

Da fällt mir ein: TYPO3 kann das übrigens auch. Statische Inhalte generieren und auf nen anderen Server publishen - automatisch. Just sayin.. ^^

Marco Poehler

Das erinnert mich daran: Wir sollten dringend eine Cloud-Session im Rahmen der GTUG machen. Wir nutzen ja auch Amazon S3 / Elastic Map Reduce und da kann man bestimmt ein paar interessante Erfahrungen austauschen. Würde mich auch interessieren wie das andere auf AppEngine-Basis machen.

mthie

Wie du oben lesen kannst, habe ich aus einem bestimmten Grund CouchDB eingesetzt, was Typo3 nicht kann.

mthie

OK, also fuer mich kommen ja nur zwei Preismodelle in Frage:

  • die kostenlose
  • die $9/App/Monat-Variante

Die Kostenlose reicht leider nicht aus und man muss Billing aktivieren, um BLOBs hochladen zu koennen.

Die Billing-Variante: sie kostet $9 im Monat. Diese $9 werden zwar auf den Verbrauch angerechnet, wenn ich sie aber nicht brauche, muessen sie trotzdem bezahlt werden.

Bei der Google I/O 2010 hat Google noch erzaehlt, dass sie ein Preismodell einfuehren wollten, dass man mit $8/App/Monat unlimited Ressourcen hat. Mit $9 im Monat und weniger Ressourcen als vorher empfinde ich das regelrecht frech.

Sebastian Michaelsen

Man möchte auch nicht wirklich mit TYPO3 bloggen (außer ich).

weipah

Ich find es eine schicke Idee mit statischen Seiten zu arbeiten.

Vorallem ist das eben alles sehr performant und nicht überladen mit dynamischen “Content”.

hinnerkhaardt

Unsere statischen Seiten kommen schon länger aus AWS S3. Auslieferung aus dem CDN haben wir nach einer kurzen Testphase durch Auslieferung direkt aus S3 ersetzt.

Generierung läuft bei uns über Jeykll aus einem Git(hub)-Repository. Das passiert momentan noch lokal, wir spielen aber mit dem Gedanken, Github bei einem push eine Notification setzen zu lassen, durch die dann eine Micro-Instanz gestartet wird, die git pullt, Jekyll laufen läßt und bei Erfolg S3 aktualisiert.

Zur Zeit scheitert das noch an dem fehlenden Zusammenspiel von SNS und AS.

Kommentar schreiben

Jeder Kommentar wird vor der Veröffentlichung überprüft.