Die Cloud wird seit ein paar Jahren als Lösung für alle erdenklichen Anliegen heutiger Entwickler gepriesen. So sehr, dass der Begriff einige Zeit beinahe Gefahr lief, als reines Buzzword belächelt zu werden. Dabei ist es in der Tat so, dass Cloud Computing viele interessante Vorteile bieten kann, besonders im Bereich Hosting: Cloud Hosting bietet gegenüber kassischem Hosting die Möglichkeit, die Infrastruktur einfacher, rascher und kostengünstiger zu skalieren und so an aktuelle, möglicherweise kurzfristige, Bedürfnisse anzupassen. Außerdem fällt der Aufwand weg, sich selbst um die Wartung der Server und deren Aufrüstung mit neuen Technologien zu kümmern.

Ein Schieberegler in Kombination mit der Kreditkarte: So einfach lässt sich bei PHP Fog die Serverleistung innerhalb von Minuten beinahe ins Unendliche erhöhen.

Die Hürde, sich selbst an Cloud Hosting heran zu wagen, liegt erfreulich tief. Bei allen Anbietern lassen sich innerhalb weniger Minuten eigene Serverkapazitäten bereitstellen. Damit es in der Praxis auch wirklich klappt, tut man jedoch gut daran, sich den Eigenheiten und Einschränkungen von Cloud Hosting bewusst zu werden. Eine Betrachtung anhand des Beispiels von Cloud Hosting mit PHP soll zeigen, wo die möglichen Stolpersteine liegen und wie diese erfolgreich umgangen werden. Im Grundsatz gelten die Hinweise dabei auch für andere Sprachen und Frameworks.

Dass sich Cloud Hosting durchaus von traditionellem Hosting unterscheidet, zeigt sich bereits darin, wie die Daten auf den Server gelangen: Dies funktioniert nicht per FTP, sondern ausschließlich über einen Push per Git. Es ist also zugleich ein Argument dafür, auch bei kleineren Projekten eine professionelle Versionsverwaltung einzusetzen. Der Aufwand dafür ist gering, der Nutzen groß und die Handhabung dank grafischen Oberflächen wie Tower [1] auch für Benutzer geeignet, die die Kommandozeile scheuen.

Die Zugriffsrechte für den Upload werden pro Rechner über SSH-Keys gewährt. Auch deren Erstellung ist nicht annährend so kompliziert wie es scheint. Zudem erklärt jeder Anbieter den Vorgang mehr oder weniger ausführlich [2].

Da beim Cloud Hosting die Notwendigkeit, sich um die physische Infrastruktur zu kümmern, entfällt, entgeht einem gleichzeitig auch das Wissen, wo die eigenen Daten denn nun genau liegen. Load Balancing, also das Verteilen von Anfragen auf verschiedene Server, und die Skalierung der Kapazität führen dazu, dass zwei aufeinanderfolgende Anfragen eines Besuchers mit großer Wahrscheinlichkeit auch auf zwei verschiedenen Servern landen. Ein „Shared State“, also ein Bereich, auf den jede Anfrage zugreifen kann, existiert nicht. Stattdessen ist auf jedem Server immer nur verfügbar, was auch mit dem Git Repository übertragen wurde.

Auslagern und zentralisieren ist somit angesagt. Betroffen davon sind vor allem temporäre Daten wie Sessions und User-Uploads.

Zum Auslagern von Session-Daten bietet PHP einen einfachen, hauseigenen Weg über die Funktion session_set_save_handler(). Damit können eigene Funktionen angesprochen werden, um beispielsweise eine Session zu eröffnen, zu schließen oder Daten innerhalb dieser zu lesen und zu schreiben. In diesen Funktionen wiederum können die Daten dann mit einer Datenbank verwaltet werden, auf die jeder Server Zugriff hat. Aus diesem Grund gibt es vorgefertigte Klassen [3], die mit wenigen Zeilen den gewünschten Effekt erzielen lassen.

$SessionHandler = new SessionHandler();
$SessionHandler->setDBData('host', 'user', 'password', 'database');
$SessionHandler->setDBTable('table');
session_set_save_handler(array($SessionHandler, 'open'),
	array($SessionHandler, 'close'),
	array($SessionHandler, 'read'),
	array($SessionHandler, 'write'),
	array($SessionHandler, 'destroy'),
	array($SessionHandler, 'gc'));
session_start();

Zur Speicherung anderer kurzlebiger Daten ist je nach Cloud-Hosting-Anbieter auch die Nutzung von Memcached [4] möglich. Memcached erlaubt es, Daten bis zu einer Größe von einem Megabyte serverübergreifend und damit unabhängig vom Aufruf zur Verfügung zu stellen. Wird diese Möglichkeit vom Anbieter der Wahl nicht unterstützt, führt allerdings kein Weg an einer Speicherung in der Datenbank oder auf einem externen Speicherdienst vorbei. Auf keinen Fall geeignet ist das Anlegen von temporären Dateien, die im Datei-System gespeichert werden, da auch diese nur auf einem Server zur Verfügung stehen.

Ebenfalls zentral abzulegen sind sämtliche Dateien, die während des Betriebs der Website erstellt werden und anschließend dauerhaft zur Verfügung stehen sollen. Ein klassisches Beispiel sind Datei-Uploads durch Nutzer. Mit üblichen Upload-Methoden würde eine derartige Datei nur auf genau dem Server zur Verfügung stehen, der den Upload entgegengenommen hat. Als Auslagerungsort kann bei Verwendung der NoSQL-Datenbank MongoDB die Datei per GridFS [5] direkt in der Datenbank abgelegt werden.

Ansonsten bietet sich das Ablegen auf dafür spezialisierten Cloud-Diensten an. Amazon AWS bietet mit seinem Simple Storage Service S3 [6] eine weitverbreitete und äußerst kostengünstige (in vielen Fällen sogar kostenfreie) Lösung, die sich dank bestehender Klassen [7] einfach mit PHP implementieren lässt.

Die hochgeladene Datei ist anschließend wahlweise über eine öffentliche URL zugänglich oder kann im geschützen Modus wiederum über die Schnittstelle gelesen werden. Verschiedene FTP-Clients oder spezialisierte Apps wie 3Hub [8] erlauben den Zugriff auf S3 auch über eine grafische Oberfläche, was die Verwaltung der dort enthaltenen Daten erleichtert.

$s3 = new S3('amazon_aws_key', 'amazon_aws_secret');
$s3->putObjectFile($fileToUpload, $bucketNameOnS3, $filenameOnS3);

Anbieter von Cloud Hosting sind Spezialisten. Ihre Kompetenz besteht darin, eine stabile Umgebung zu bieten, die den Betrieb und die Skalierung von Webapplikationen auf dem gewünschten Framework zuverlässig erledigt. Die Folge ist, dass einige Dienstleistungen, die man sonst von Hosting-Anbietern gewohnt ist, nicht immer zur Verfügung stehen. Das ist in erster Linie ein aktuelles Problem, da viele Anbieter aufgrund der Neuheit dieses Geschäfts noch in den Kinderschuhen stecken. Es ist daher nötig und oftmals ohnehin sinnvoll, gewisse Anwendungen auf weitere Dienste auszulagern, die sich wiederum auf den entsprechenden Service spezialisiert haben.

Ein Beispiel ist der Domain Name Server (DNS), der den Weg von der URL zum Server zeigt. Heute ist man gewohnt, dass der Hosting-Anbieter diesen Service bietet (sofern es nicht bereits der Domain-Registrator tut). Nicht so beim Cloud Hosting. Alternativen wie ZoneEdit [9] oder abermals Amazon springen hier in die Bresche. Bei Amazon kann der Besucher einer Website über deren DNS-Dienst Route 53 [10] an den richtigen Server geleitet werden. Als grafische Oberfläche bietet sich ergänzend interstate53.com [11] zur webbasierten und unkomplizierten Datenverwaltung an.

interstate53.com macht die Bearbeitung von auf Amazon Route 53 verwalteten DNS-Zonen sehr einfach.

Viele Webanwendungen kommen nicht darum herum, terminierte Aufgaben unabhängig von Benutzeraktionen auszuführen. In der Regel werden dazu Cronjobs eingesetzt – ein weiterer Service, der bei heutigem Cloud Hosting Einschränkungen unterliegt. So kann etwa bei cloudControl ein Cronjob maximal stündlich ausgeführt werden, bei deren amerikanischen Kollegen PHP Fog wird komplett auf eine Auslagerung solcher Dienste hingewiesen.

Abhilfe schaffen Drittanbieter wie EasyCron [12] oder MyWebCron [13], über die durch einfach gehaltene Web-Interfaces der Aufruf gewünschter URLs terminiert wird. Die Einschränkungen gegenüber echten Cronjobs sind allerdings beträchtlich: So müssen bei Verwendung dieser Dienste die auszuführenden Skripts öffentlich aufrufbar sein und die Ausführungszeit ist begrenzt durch potentielle Server- und Verbindungs-Timeouts. Letzteres kann unter Umständen durch den Einsatz von so genannten Workers abgefangen werden, die Arbeitsprozesse abarbeiten, ohne die eigentlichen Hauptprozesse zu belasten. Hierbei muss im Vorfeld beachtet werden, ob der gewünschte Cloud-Hosting-Dienstleister diese Funktionalität im Angebot führt.

Ebenfalls nicht im Programm der Cloud-Hoster findet man E-Mail-Dienstleistungen. Die eigenen, zur gehosteten Domain gehörenden E-Mail-Konten lassen sich aber zuverlässig über Google Apps [14] verwalten; hier stehen alle von Gmail bekannten Möglichkeiten zur Verfügung. Mit bis zu zehn Nutzerkonten ist der Dienst sogar kostenlos nutzbar. Da sich beliebig viele Nutzer- und Domain-Aliasse hinzufügen lassen, kann man den Dienst bei Bedarf weit ausreizen, bis man in den kostenpflichtigen Bereich rutscht.

E-Mails, die von der eigenen Webapplikation beim Versenden von Zugangsdaten, Bestellbestätigungen etc. erstellt werden, können auch bei Cloud-Hostern über die in der Programmiersprache vorhandenen Mailfunktionen wie mail() verschickt werden. Besser ist es jedoch, auch für solche „Transaktions-Mails“ spezialisierte Zusatzdienstleister wie SendGrid [15], Postmark [16] oder Amazon Simple Email Service [17] zu nutzen. Der Vorteil dieser Anbieter liegt darin, dass man sich als E-Mail-Absender per DNS über SPF- und DomainKey/DKIM-Records identifizieren lassen kann. Dadurch steigt die Zuverlässigkeit beträchtlich, auf dem Weg zum gewünschten Empfänger nicht als Spam eingestuft zu werden. Zusätzlich helfen Übersichten über die Anzahl versendeter E-Mails sowie Informationen zu zurückgewiesenen oder vom Empfänger als Spam markierten Nachrichten, allfällige Probleme innerhalb der eigenen Anwendung ausfindig zu machen.

Postmark zeigt übersichtlich die Anzahl verschickter Transaktions-E-Mails und lässt auf einen Blick erkennen, ob Zustellungsprobleme aufgetreten sind.

Wie bereits gesehen, unterscheiden sich die Cloud-Hosting-Anbieter in verschiedenen Aspekten. Da jedes Projekt andere Bedürfnisse hat, lohnt es sich, die wichtigsten Dienstleister aus eigener Optik zu prüfen. In die engere Auswahl fallen aktuell wohl der deutsche Anbieter cloudControl, die in Portland (Oregon, USA) beheimateten Jungs von PHP Fog und Orchestra.io aus Irland. Besonders zu beachten ist dabei, ob die gewünschte Datenbank unterstützt wird, wie die Preisgestaltung und die Verrechnung von Zusatzdiensten aussieht, wie und wann Supportleistungen angeboten werden und welche Informationen zu geplanten Ausbauten vorhanden sind. Konkrete, individuelle Anforderungen, etwa der Einsatz von Cronjobs, SSL-Verschlüsselung, die Verwendung mehrerer Domains oder Memcached sollten ebenfalls im Voraus geprüft werden, um böse Überraschungen zu vermeiden.

Im Auge zu behalten ist auch der Cloud-Hosting-Platzhirsch Heroku, der als Plattform für Ruby On Rails und Node.js bekannt wurde. Seit kurzer Zeit wird dort auch Cloud Hosting für PHP unterstützt, was aus einer Zusammenarbeit mit Facebook für Anwendungen innerhalb des sozialen Netzwerks entstand. Es dürfte somit nur noch eine Frage der Zeit sein, bis diese Möglichkeit auch für Projekte außerhalb von Facebook zur Verfügung steht.

Lohnt sich der Aufwand, Projekte für ein Hosting in der Cloud anzupassen? Wenn das Bedürfnis nach Skalierbarkeit vorhanden ist oder ein Projekt neu aufgebaut wird, auf jeden Fall. Denn sämtliche Anpassungen haben nicht spezifisch etwas mit Cloud Hosting zu tun, sondern mit der Tatsache, dass die Webanwendung verteilt über mehrere Server laufen kann. Der Unterschied besteht darin, dass diese Möglichkeit früher Firmen mit großem Budget vorbehalten war, heute hingegen auch kleine Start-Ups und Projekte von Beginn an für den großen Erfolg gewappnet sein können. Umso schöner, wenn dann die Technologie bereits mitspielt und man sich anderen Anliegen widmen kann.