Vor einer ganzen Weile berichtete ich über den PaaS-Anbieter Heroku, der sein Portfolio an Programmiersprachen mittlerweile deutlich erweitert hat. Bis vor nicht allzu langer Zeit fehlte aber noch ein vergleichbarer Anbieter für das Deployment von PHP-Anwendungen. Verwunderlich gerade deswegen, weil PHP nach wie vor zu den beliebtesten Programmiersprachen im weltweiten Netz gehört und einige sehr bekannte Systeme in PHP entwickelt wurden.

Diese Lücke füllt nun der Anbieter PHP Fog, welcher, genau wie Heroku auf das Deployment von Anwendungen über das Versionierungstool Git setzt. Das verspricht eine äußerst einfache Handhabung und ist deutlich zeitgemäßer als das sonst übliche Deployment über FTP. Allein schon in Sachen Geschwindigkeit steckt Git die Datenübertragung via FTP locker in die Tasche. Vor einiger Zeit meldete ich mich dann bei PHP Fog an und begann, ein wenig zu experimentieren. Vorbildlich ist, dass man gängige PHP-Anwendungen per One-Click-Installer installieren kann. Dazu gehört unter anderem auch das äußerst beliebte CMS WordPress. In der Anfangsphase aber war eine bei PHP Fog abgelegte WordPress-Installation aber nahezu unbrauchbar, da man keine beschreibbaren Verzeichnisse einrichten konnte und somit viele Funktionen von WordPress nicht nutzbar waren. Updates scheiterten, die Installation von Plugins oder der Upload von Dateien war unmöglich. Der einzige Ausweg war, die WordPress-Installation lokal zu warten und die Änderungen per Git zu deployen. Problematisch war aber natürlich hier, dass Einträge in der lokalen Datenbank nicht auf der Infrastruktur von PHP Fog landeten. Die Anfangsphase war kurzum ziemlich enttäuschend. Ständige Downtimes und ein erfolgreicher, groß angelegter Hackerangriff trübten den Ersteindruck weiter. Mittlerweile ist der Service deutlich gereift und die oben genannten Kritikpunkte sind allesamt eliminiert worden. Dennoch reicht der Bedienungskomfort leider nach wie vor nicht an den von Heroku ran. Lokale Änderungen an Theme-Dateien bspw. kann man leider nicht zurück auf den eigenen Rechner bekommen, da die Versionierung nur in eine Richtung funktioniert. Gleiches gilt für hochgeladene Dateien, beispielsweise Fotos. Diese nachträglich auf den eigenen Rechner zu bekommen, bspw. um einen Anbieterwechsel durchzuführen ist nicht möglich, wenigstens nicht ohne Umwege über WordPress-Plugins, die das erlauben. Dieser Nachteil existiert natürlich auch bei Heroku, nur bringt jede Rails-basierte Anwendung einen integrierten Webserver mit und verfügt im Regelfall über mehrere Datenbanken (Production, Development, Test), sodass man Änderungen an der Anwendungsstruktur ohne Probleme lokal vornehmen und auch gleich testen kann. Die Schuld ist hier also nicht bei PHP Fog zu suchen, sondern vielmehr bei der Struktur von PHP-Anwendungen. Ohne eine lokale Installation eines Webservers und einer MySQL-Datenbank ist eine solche Arbeitsweise nicht möglich. In Sachen Simplizität schlägt Rails hier PHP ganz bequem. Die Idee, das Deployment von PHP-Anwendungen über das effiziente und einfach zu bedienende Git vorzunehmen ist gut, leider scheitert die Benutzbarkeit in der Praxis an dem doch recht angestaubten Konzept von PHP-Anwendungen. Heroku verbietet das Schreiben in das Dateisystem des Anbieters einfach, um genau solchen Problemen vorzubeugen. Rails-Anwendungen spielen da im Regelfall auch problemfrei mit, und man bindet Storage über Services wie Amazons S3 an. Bei PHP Fog ist das Schreiben ins Dateisystem (leider) ohne weiteres möglich. Dortige Änderungen lassen sich aber nicht reflektieren. Meine Idee wäre, dass man im Backend von PHP Fog einen Button finden sollte, der auf der entfernten Maschine eine git add .; git commit -am ‘Kommentar’ ausführt und man dann mittels git pull die Änderungen auf seine eigene Maschine bekommt. Ich werde wohl mal ein Support-Ticket einreichen …

Die Cloud, das Buzzword des letzten Jahres, ist in aller Munde. Und hat auch schon erste Federn lassen müssen. Was die Cloud eigentlich kennzeichnet, ist nahezu grenzenlose Skalierbarkeit. Wenn es nach den Befürwortern der Cloud geht, bucht niemand mehr physikalische Maschinen, sondern Speicherplatz, RAM, Rechenleistung in dem Umfang, den er benötigt. Wird zwischenzeitlich mal mehr gebraucht, dreht man kurz an der entsprechenden Schraube und zahlt eben für die Zeit ein wenig mehr. Es gibt unheimlich viele Anbieter, gerade Amazon, eigentlich Interneteinzelhändler, hat in diesem Bereich von sich reden gemacht. Amazon bietet alles denkbare an Cloud-Dienstleistungen an, was man sich nur so vorstellen kann. Genau das ist dem Wikileaks-Projekt zum Verhängnis geworden, weil der Anbieter somit auch am einzigen Hebel sitzt. Legt er den um, ist Feierabend. Amazon bietet zwar eine recht große Produktpalette an, alles abdecken tun sie dann aber auch nicht.

Wer beispielsweise Rails-Anwendungen in der Cloud laufen lassen möchte, ist auf andere Dienstleister angewiesen. In den letzten Jahren hat sich ein Anbieter namens Heroku einen Namen in der Community gemacht. Erst kürzlich wurde Heroku von salesforce.com, einem großen Anbieter von Geschäftsanwendungen, für rund 212 Mio. US-$ aufgekauft.

Heroku hat ein für den Entwickler sehr effizient zu nutzendes und einfaches Deployment-Verfahren entwickelt, welches komplett Git- und Rake-gestützt ist. Der Rails-Entwickler muss sich also nicht mit der Administration und Konfiguration von Webservern herumärgern. Ein Vorteil gegenüber den klassischen Rails-Hostern, von denen es ohnehin relativ wenige gibt ist, dass man nicht auf die vom Hoster installierten Ruby-Gem-Versionen angewiesen ist, sondern seine eigenen Versionen spezifizieren kann, wie man es von seiner Entwicklungsmaschine her kennt.

Wer reine Rails-3-Anwendungen deployen möchte, hat seine Anwendung binnen weniger Minuten online:

sudo gem install heroku
git init
heroku create
git add .
git commit -a -m 'first deployment commit to Heroku'
git push heroku master
heroku rake db:migrate
heroku open

Das war es schon. Die Anwendung sollte online sein und sich im Browser geöffnet haben.

Bei Rails-2-Anwendungen gestaltet sich das Deployment etwas schwieriger, aber auch nicht viel. Bevor man die oben erwähnte Befehlskette anschubsen kann, muss erst einmal eine Datei namens .gems erstellt werden. In dieser müssen dann alle erforderlichen Gems, ggf. inklusive Versionsnummer notiert werden. Beispiel:

rails --version 2.3.5
i18n --version 0.4.2
rack --version 1.0.1

Erst dann darf deployed werden. Neben den oben erwähnten Möglichkeiten gibt es aber noch viele weitere, die allesamt auf den wirklich tollen Support- und Dokumentations-Seiten von Heroku dokumentiert sind. So kann man, sofern man bereits lokal PostgreSQL verwendet, seinen kompletten Datenbankinhalt mittels heroku db:push in die Anwendung bei Heroku pushen. PostgreSQL ist übrigens die einzige Datenbank, die von Heroku angeboten wird. Laut Heroku deswegen, weil sie dort die optimale Kombination zwischen Zuverlässigkeit, Datenintegrität und Geschwindigkeit sehen. Ein Statement, das ich durchaus unterschreiben kann. Das heroku-Gem ist äußerst mächtig und bietet einem Zugriff auf sämtliche installierbare Add-Ons (s.u.), auf die Logs und noch vieles mehr. Eine Studie der Dokumentation ist empfehlenswert.

Ab sofort kann dann direkt in den Anwendungscontainer bei Heroku deployed werden, indem man ein ganz reguläres Git-Commit erstellt. Einfacher geht es kaum noch.

Nachdem die erste Version der Anwendung deployed wurde, kann man sie um einige tolle, teilweise auch kostenlos nutzbare Add-Ons erweitern. Dazu gehören nützliche Erweiterungen wie CNAME-Einträge für die Anwendung (damit man sie auch unter einer eigenen (Sub-)Domain betreiben kann), Jasondb, MongoDB und CouchDB für die NoSQL-Anhänger unter uns, Exception-Tracker, Echtzeitsuche, New Relic, SMS-Gateways, automatisierte Datenbankbackups, etc. Manche kosten gar nichts, manche nur wenig Geld, andere wiederum sind recht teuer (wobei teuer mal wieder relativ ist). Dolle ins Geld geht ein SSL-Zertifikat, da solche Zertifikate weiterhin IP-basiert sind, was bei einem Cloud-basierten Dienst natürlich recht finster werden kann.

Apropos Kosten: jeder kann bei Heroku beliebig viele Anwendungen hosten lassen, die auch erst mal nichts kosten, in der Leistungsfähigkeit aber arg eingeschränkt sind. Benötigt man mehr Ressourcen, muss man in die Tasche greifen, ab ca. 36 US-$ (0,05 $-Cent pro Stunde) monatlich geht es los. Dabei unterteilt Heroku in Dynos und Worker. Dynos beschleunigen das Frontend, Worker die Hintergrundprozesse der Rails-Anwendung. Der Maximalausbau liegt bei 24 Dynos und 24 Workern, wofür dann aber auch 2,35 US-$ pro Stunde, oder umgerechnet rund 1.700 US-$ monatlich anfallen. Die Performancestufe dürfte aber auch „gehobenen“ Ansprüchen genügen.

Damit ist aber noch nicht Schluss, denn eine dedizierte Datenbank ist bei dem Preis noch nicht inklusive. Kostenlos gibt es 5 MB Shared Database, für 20 US-$ monatlich 20 GB Shared Database. Wer gern eine dedizierte Datenbank hätte, muss bspw. für den kleinsten Tarif Ronin 200 US-$ monatlich berappen. Dafür erhält er 16 gleichzeitige Verbindungen, 1,7 GB RAM und 1 computing unit. Für 6.400 US-$ gibt es 400 Verbindungen, 68 GB RAM und 26 computing units. Wer’s braucht…

Herokus Dateisystem ist read-only, Dateiuploads lassen sich also nicht realisieren. Hierzu kann/sollte man, auch laut Heroku-Dokumentation, auf Anbieter wie Amazon S3 ausweichen. Für Rails-Anwendungen gibt es diverse Möglichkeiten, Uploads zu Amazons S3 (Simple Storage Service) aus der Anwendung heraus zu realisieren. Namentlich erwähnt werden Attachment-Fu und Paperclip. Eine persönliche Präferenz kann ich hier abgeben, ich hab mit beiden noch nicht gearbeitet. Heroku empfiehlt im Übrigen generell, große Dateien, die die Applikation zum Download bereitstellen soll, aus Performancegründen zu S3 oder ähnlichen Services auszulagern, weil das Dateisystem von Heroku nicht für derartige Anwendungszwecke konzipiert und optimiert wurde.

Um die Performanceunterschiede messen zu können, habe ich eine Installation von Redmine bei Heroku vorgenommen. Das Deployen dieser Anwendung ist leider nicht total trivial, die einzelnen Schritte habe ich deswegen in einem Gist (welcher auch noch mal ganz unten eingebettet ist) niedergeschrieben.

Zum Ergebnis meiner Benchmarks, gemessen auf einer Projektübersichtsseite mit ab -c 50 -n 200:

1. 1 Dyno (kostenlos): 7,98 Requests pro Sekunde
2. 2 Dynos: 13,15 Requests pro Sekunde
3. 3 Dynos: 18,46 Requests pro Sekunde
4. 10 Dynos: 53,46 Requests pro Sekunde
5. 24 Dynos: 84,14 Requests pro Sekunde
6. 1 Worker: 7,64 Requests pro Sekunde
7. 2 Worker: 7,74 Requests pro Sekunde

Die Anzahl der Worker wirkt sich also in keiner Weise auf die Anwendungsperformance aus, die Anzahl der Dynos hingegen beträchtlich. Den größten Gewinn (prozentual gesehen) bekommt man hier, wenn man von dem einen kostenlosen Dyno auf einen zweiten, kostenpflichtigen aufrüstet. Die monatlichen Kosten liegen mit diesem bei rund 36 US-$, also umgerechnet in etwa 27 €. Eigentlich nicht zu viel verlangt, man darf nur nicht vergessen, dass in diesem Preis noch kein Storage und nur 5 MB an Datenbankplatz inklusive ist.

Zum Vergleich: mein nicht optimierter Root-Server (Athlon64 X2 6.400+, 4 GB RAM, OpenVZ) liefert rund 10,5 Requests pro Sekunde. Den muss ich natürlich selbst administrieren, warten, etc. Und das Deployment ist auch längst nicht so bequem bzw. müsste erst mal von mir auf diesen Bequemlichkeitslevel gebracht werden.

Heroku bietet für einen akzeptablen Preis einen wirklich tollen und performanten sowie äußerst flexiblen Service an. Für den Rails-Entwickler, der keine Lust hat, sich mit der Einrichtung und Administration eines Rails-fähigen Webservers rumzuschlagen und ggf. auftretende Probleme zu beheben ist Heroku aus meiner Sicht optimal. Zumal man hier nicht gleich einen zweiten Server hinzu kaufen muss, nur weil die Anwendung an ein oder zwei Stunden am Tag mal mehr Ressourcen braucht, als es die eigene Hardware zulässt. Die Anmeldung kostet nichts und das Deployen der eigenen (oder fremden) Anwendung genau so wenig. Einem Versuch steht also nichts im Wege. Viel Spaß dabei.

Ihr sucht nach einer guten, überall verfügbaren GTD (Getting Things Done)-Applikation? Hört auf zu suchen. Ich habe soeben auf meinem Server die sehr gute Web-Applikation Tracks installiert und für die Allgemeinheit freigegeben. Der Login erfolgt über OpenID, es geht also kaum unkomplizierter. Jeder, der beispielsweise einen Google- oder Yahoo-Account besitzt, hat auch eine OpenID. Derzeit ist die Applikation nur in englischer Sprache verfügbar, aber das Entwickler-Team arbeitet an einer lokalisierten Fassung. Ich werde die deutsche Fassung zur Verfügung stellen, sobald sie fertig ist.

Gehosted wird die Applikation mit Ubuntu 10.04 x64, als Application-Server für diese Rails-Anwendung verwende ich Unicorn.

Und nun, viel Erfolg und Spaß beim Selbst-Management. Zur Startseite geht es hier entlang. Die Mobil-Version (bspw. für iPhone und iPod touch) gibt es hier.