Permanente Veränderungen, neue Technologien und Methodologien prägen die IT-Welt seit jeher. Eines dieser Themen, die unser Denken und Handeln hinsichtlich Hosting-Lösungen in den vergangenen Jahren nachhaltig beeinflusst haben, ist das Cloud Computing. Unzählige internationale Unternehmen haben in den vergangenen Jahren ihre IT-Infrastruktur von traditionellen Rechenzentren und Inhouse-Serverräumen in die Cloud umgezogen. Aber viele Firmen – besonders in Deutschland – ignorieren diesen globalen Trend bisher. Woran liegt das, und sind die Vorbehalte berechtigt?

Cloud-Anbieter wie beispielsweise Amazon Web Services (AWS), Microsoft Azure oder Google steigern ihre Gewinne in diesem Sektor seit Jahren kontinuierlich und übertreffen sich mit der Einführung neuer Angebote gegenseitig. In Case Studies werden die drei Hauptstrategien des Cloud Computing deutlich: Self-Service Provisioning, Elasticity und Pay per Use.

Zum einen bestimmt der Nutzer von Cloud-Diensten selbst, welche Ressourcen wann und für wie lange benötigt werden. Rechenleistung, Speicher, Festplattenplatz und Netzwerk-Performance sind hierbei nur eine kleine Auswahl von Möglichkeiten, über die Systemadministratoren selbst verfügen können. Die Zusammenstellung von Diensten und Ressourcen erfolgt mit einigen wenigen Mausklicks und wird als Self-Service Provisioning bezeichnet.

Bei traditionellen Hosting-Anbietern mietet man dagegen seine – in der Regel physikalischen – Server mit fester Spezifikation und meistens für einen definierten Zeitraum. Anders die Cloud-Angebote: Bei entsprechender Planung und Konfiguration skaliert sich die Infrastruktur in der Cloud auto­matisch. Dieser automatisierte Prozess (Auto-Scaling) erfolgt nach Bedarf und in kürzester Zeit und wird als Elasticity bezeichnet. Die verwendeten Ressourcen und genutzten Dienste werden hierbei sehr genau kalkuliert und dem Kunden wird nur das in Rechnung gestellt, was wirklich verwendet wurde (Pay per Use).

Trotz dieser Vorteile stellt sich nun die Frage, was Unternehmen davon abhält, ihre Applikation – besonders im Bereich der Webentwicklung – in der Cloud zu hosten. Die folgenden sechs Argumente werden immer wieder von Cloud-Skeptikern angeführt, wenn man sich mit Kunden über einen solchen Schritt unterhält.

Argument eins: »Unser Applikationen benötigen ein sehr spezielles Setup und laufen in der Cloud sicherlich nicht.« Für die meisten Webanwendungen trifft dieses Argument kaum zu. Fast alles, was auf einem herkömmlichen Server läuft, funktioniert auch in einer Cloud-Umgebung. Die typischen Dienste, die eine Webapplikation benötigt, sind ein Web­server (zum Beispiel Apache oder nginx unter Unix/Linux oder IIS unter Windows), ein Datenbankserver (MySQL, PostgreSQL, MS SQL, Oracle et cetera) und die Middleware, die sich um die Ausführung der Applikation kümmert. Letzteres umfasst zum Beispiel PHP, Java, Node.js, ASP et cetera.

Diese Komponenten sind auch in der Cloud verfügbar. Wenn keine fertigen Machine Images existieren, die die Systeme und Software vorinstalliert mitbringen, kann man ein Minimalsystem benutzen und fehlende Pakete einfach nachinstallieren. Schliesslich hat man vollen Zugriff auf den Server, was übrigens bei manchen traditionellen Hosting-Angeboten nicht immer der Fall ist – zumindest nicht bei virtuellen Shared-Server-Lösungen.

Anwendungen, die sehr hardwarenah arbeiten oder bestimmte Kernel-Attribute voraussetzen, können allerdings unter Umständen in die Kategorie spezielles Setup fallen. Ein typisches Beispiel sind VoIP-Anwendungen, die auf dem Session Initiation Protocol (SIP) basieren. Ein entsprechend optimierter Kernel kommt bei SIP-Routern zum Einsatz, der sich speziell für Sprachübertragungen eignet.

Für andere, nicht so unübliche Spezialanwendungen haben viele Cloud-Anbieter allerdings auch entsprechende Angebote in ihrem Portfolio. Neben den Standardservern, die für allgemeine Anwendungsfälle bestens geeignet sind, existieren häufig Systeme, die beispielsweise Compute- oder speicheroptimiert sind. Auch für grafikintensive Anwendungen, NoSQL-Datenbanken, Data Warehouses mit massiver Parallelverarbeitung und anderes gibt es optimierte Systeme in der Cloud.

Argument zwei: »Wir brauchen die Cloud nicht – unsere Applikationen laufen bereits auf virtuellen Servern. Mehr bietet Cloud Computing doch auch nicht.«

Virtualisierung ist nicht neu. Lösungen wie Xen, VMware, Jails unter FreeBSD und nicht zuletzt VirtualBox existieren schon seit vielen Jahren. Cloud Computing nutzt Virtualisierung in ihrer Bestform: Eine Vielzahl (virtueller) Maschinen nutzt die Ressourcen und Leistung von mehreren Servern in einem riesigen Umfang.

Die Cloud bietet jedoch weit mehr als nur geteilte Rechenleistung. Nicht zuletzt durch die Grösse der Infrastruktur, die sich bei ­einigen Anbietern über mehrere Rechenzentren erstreckt, kann nahezu unbegrenzter Speicherplatz sehr kostengünstig angeboten werden. Dienste und Lösungen, die teilweise auf mehreren Kontinenten verteilt sind (zum Beispiel Content Delivery Networks oder Domain Name Services), ergänzen das Angebot.

Für Anwender, die bisher nicht über das entsprechende Know-how verfügten, um CDNs, Load Balancer, dezentrale Datenbanksysteme und ähnliche Dienste selbst zu implemen­tieren, eröffnen sich durch solche Services neue Möglichkeiten. Insbesondere in Kombination machen diese Dienste eine normale Website weitaus ausfallsicherer und performanter.

Dank des zuvor erwähnten Self-Service-Provisioning-Konzepts können solche Komponenten nun mit ein paar Mausklicks aktiviert und konfiguriert werden und stehen unmittelbar zur Verfügung. Diese Dienste laufen auch in virtuellen Umgebungen und profitieren somit von der Flexibilität und Kostentransparenz von Services, die in der Cloud betrieben werden. Ich werde im Lauf dieses Artikels noch etwas genauer auf diesen Punkt eingehen.

Es sollte ausserdem beachtet werden, dass die Cloud-Anbieter anstreben, die Konfiguration und den Betrieb dieser Dienste so einfach wie möglich zu machen. Das geschieht ­natürlich auch im eigenen Interesse, damit die Kunden diese jederzeit problemlos nutzen können.

Argument drei: »Wenn sämtliche Dienste auf Virtualisierung basieren, ist das Risiko, dass unsere Mission-Critical Application ausfällt, doch viel höher.«

Der Begriff Virtualisierung ruft bei vielen ein schlechtes Gefühl hervor, wenn es um Zuverlässigkeit und Verfügbarkeit geht. Nicht selten wird infrage gestellt, ob man einer vollständigen Virtualisierung auf allen Ebenen vertrauen kann. Eine repräsentative Studie der Techconsult GmbH aus dem Jahr 2016 hat ergeben, dass besonders grosse Unternehmen in Deutschland Vorbehalte gegen die Nutzung von Cloud-Diensten haben.

Dabei räumten allerdings 43 Prozent der Befragten ein, dass es sich bei ihren Einschätzungen eher um ein Bauchgefühl handelt. Der Cloud-Anbieter ist primär für die Verfügbarkeit der physikalischen Infrastruktur verantwortlich. Das schliesst zum Beispiel eine redundante Stromversorgung, Internetanbindung, Kühlsysteme, Brand- und Zugangsschutz, Sicherheitssysteme et cetera ein.

Allerdings kann Hardware ausfallen. Das passiert in traditionellen Rechenzentren genauso wie in Serverräumen, die sich im eigenen Firmengebäude befinden. Hardware fällt auch bei Cloud-Anbietern aus. Allerdings ist hier die Wahrscheinlichkeit sehr hoch, dass die Nutzer von Cloud-Diensten einen Hardwaredefekt gar nicht mitbekommen, da ihre Server und andere Komponenten ohne Unterbrechung und im vollen Funktionsumfang weiterlaufen.

Da die darunterliegende Infrastruktur auf verteilten Systemen läuft, ist eine vollständige Redundanz garantiert. Ein Server ist nicht auf einer einzigen physikalischen Festplatte installiert, sondern (vereinfacht ausgedrückt) über mehrere virtuelle Partitionen und mehrere physikalische Server verteilt. Aufgrund der Architektur des Cloud-Hostings hat ein Ausfall einer oder mehrerer Hardwarekomponenten – oder eines ganzen Servers – keine Auswirkungen auf den Betrieb.

Die Verfügbarkeit in der Cloud hat allerdings auch ihre Grenzen. Wenn etwa ein komplettes Rechenzentrum ausfällt, sind alle Kunden betroffen, deren Applikationen nur in diesem Rechenzentrum laufen. Hier würden verteilte Systeme und Load Balancer die Verfügbarkeit aufrechterhalten. Fallen mehrere Rechenzentren in einer Region zeitgleich aus, bleiben nur Webapplikationen erreichbar, die auf mehreren geografisch getrennten Systemen, zum Beispiel in Europa und in den USA, parallel betrieben werden.

Ein solcher gravierender Ausfall kann durch eine Natur­katastrophe auf einem Kontinent ausgelöst werden. Die Verfügbarkeit ist also letztendlich eine Frage der Anforderung und des Budgets. Der Punkt ist allerdings, dass die Cloud hierfür funktionierende Strategien bereitstellt und zumindest die grossen Cloud-Anbieter dieses ohne grosse Aufwände ermöglichen.

Argument vier: »Das Budget für die Nutzung von Diensten in der Cloud kann schwanken und ist nicht absehbar.« Das stimmt – zumindest zu einem Teil. Und das kann positiv wie auch negativ bewertet werden. Wie bereits zuvor erwähnt, beruht Cloud Computing auf dem Pay-per-Use-Prinzip. Es werden nur die Dienste und Ressourcen berechnet, die wirklich genutzt werden – und das meist minuten- oder stundengenau.

Wenn das Entwickler-Team urplötzlich zehn Server benötigt, um zu testen, ob die neu entwickelte Applikation auch gemäss der Spezifikation die Last ordentlich auf mehrere Instanzen verteilt, muss keine Hardware bestellt oder für solche Situationen bereitgehalten werden. Die Server werden einfach in der Cloud hochgefahren und nach Abschluss der Tests wieder stillgelegt. Nur die Ressourcen, die während dieser Zeit wirklich genutzt wurden, werden berechnet, nicht mehr und nicht weniger. Ein anderes gutes Beispiel sind Kampagnen und saisonbedingte Aktionen. Online-Shops, deren Zugriffszahlen jedes Jahr zum Weihnachtsgeschäft signifikant ansteigen, aber den Rest des Jahres eher eine wesentlich niedri­gere Auslastung aufweisen, profitieren von der relativ einfachen Skalierbarkeit in der Cloud.

Ähnliches gilt für Marketing-Kampagnen, wie zum Beispiel TV-Spots, Werbevideos oder regelmässige Newsletter, die besondere Angebote avancieren und einen Ansturm auf die Website oder den Online-Shop zur Folge haben können. Nicht selten resultiert dieses in einer Überlastung des Web- oder Datenbankservers, wenn auf ein statisches Hosting gesetzt wurde und die Infrastruktur nicht automatisch skaliert.

Ein Nachteil der automatischen Skalierung liegt aber ebenfalls klar auf der Hand: Die Höhe der Kosten kann von Rechnung zu Rechnung stark variieren. Hier hilft nur eine gute Budgetplanung und Werkzeuge, die einen dabei unterstützen, die Kosten im Auge zu behalten.

Zwei Lösungen, die beispielsweise Amazon Web Services (AWS) anbietet, sind der Kostenkalkulator und automatische Benachrichtigungen. AWS hat eine riesige Produktpalette an Diensten mit ganz unterschiedlichen Kosten und Berechnungen. Einige Dienste werden nach angefallener Datenmenge oder IO-Requests berechnet, andere haben einen Festpreis pro Stunde, Tag oder Monat.

Besonders für AWS-Neulinge kann eine Kostenschätzung sehr schwierig sein. Der Kostenkalkulator von AWS erlaubt es, die Dienste zu selektieren, die man zu nutzen plant. Basierend auf den eingegebenen Daten werden dann die Kosten ermittelt und übersichtlich dargestellt.

Eine weitere sinnvolle Funktion bei AWS ist die Benachrichtigungsfunktion: Über den Dienst CloudWatch lassen sich bestimmte Werte konfigurieren, die stets überwacht werden. Das kann die CPU-Auslastung bei virtuellen Servern, aber auch der aktuell belegte Speicherplatz oder das angefallene Datenvolumen sein. Werden zuvor eingestellte Schwellenwerte erreicht oder überschritten, können Aktionen ausgelöst werden.

Bei der CPU-Auslastung wäre das typischerweise das Starten eines weiteren Servers, um die Last zu verteilen. Einer dieser Werte kann allerdings auch die aktuelle Höhe der nächsten Rechnung sein. Anstatt beim Überschreiten eines bestimmten Betrags einen Server hoch- oder herunterzufahren, kann hier das Versenden einer E-Mail als auszuführende Aktion konfiguriert werden.

Vereinfacht ausgedrückt bedeutet dies, dass man sich automatisch per E-Mail benachrichtigen lassen kann, wenn die monatlichen Kosten eine bestimmte Höhe erreicht haben und das Budget zu sprengen drohen.

Es versteht sich von selbst, dass sich durch solche Massnahmen schwankende Rechnungskosten nicht vermeiden lassen, aber sie helfen bei der Budgetplanung ungemein.

Argument fünf: »Es handelt sich ja um keine dedizierte Hardware – andere Kunden, die dieselbe Hardware nutzen, kommen doch sicherlich irgendwie an unsere Daten.«

In der Tat birgt Virtualisierung ein gewisses Sicherheits­risiko. Die zuvor erwähnte Studie der Techconsult GmbH hat ermittelt, dass die Befragten vor allem Angst vor unberechtigtem Zugriff haben und sich Sorgen um die Datensicherheit machen. Allerdings sind sämtliche Dienste in Container gekapselt, inklusive eines dedizierten Kernels, was zu einem besseren Sicherheitskonzept führt, als es bei einigen traditio­nellen Hostern zu finden ist. Dort teilen sich nicht selten mehrere Kunden einen Server, und lediglich die konfigurierten Benutzerberechtigungen verhindern, dass ein Kunde auf Verzeichnisse anderer Kunden zugreifen kann.

Auf der einen Seite vertreten einige Sicherheitsexperten die Meinung, dass die Datensicherheit gesteigert wird, wenn Daten zentral gespeichert, anstatt (wie in der Cloud) auf mehrere Systeme verteilt werden. Auf der anderen Seite gibt es Argumente, dass Cloud-Anbieter über hochqualifizierte Teams verfügen, die sich um nichts anderes kümmern als um Sicherheit. Diesen Luxus haben die meisten traditionellen Hoster nicht – ganz zu schweigen von Unternehmen, die ihre Server selbst hosten.

Ich persönlich stufe das Sicherheitsrisiko der Software, die auf dem Virtualisierung-Stack betrieben wird, in der Regel als weitaus höher ein als die theoretische Möglichkeit, dass die Virtualisierungs-Software ein Problem enthält, die es einem Angreifer ermöglicht, aus seinem Container auszubrechen. Dabei denke ich zum Beispiel an die unzähligen WordPress-Websites, die niemand pflegt und die gravierende ungepatchte Sicherheitslücken aufweisen. Diese und viele andere Systeme stellen ein viel leichteres Ziel für Angreifer dar.

Generell ausschliessen kann man allerdings nicht, dass es irgendwann jemand schafft, auch die Sicherheit der Container auszuhebeln.

Grosse Cloud-Anbieter wie AWS haben ein striktes Shared-Responsibility-Modell. Wie der Name bereits suggeriert, wird hier die Verantwortlichkeit für den sicheren Betrieb zwischen dem Kunden und dem Cloud-Anbieter geteilt. Die physikalische Infrastruktur liegt in der Verantwortung des Anbieters, der Betrieb der Software auf der In­frastruktur beim Kunden. Das heisst zum Beispiel, dass der Kunde selbst dafür sorgen muss, dass auf seinen Servern Sicherheits-Updates eingespielt werden, die Firewall richtig konfiguriert ist und SSL/TLS in Online-Shops zum Einsatz kommt.

Der Anbieter wiederum kümmert sich um eventuelle Zertifizierungen und Testierungen. Bei AWS sind das unter anderem C5 vom Bundesamt für Sicherheit in der Informationstechnik (BSI), PCI DSS, ISO 9001 und diverse weitere Zertifikate.

Argument sechs: »Wer hilft uns, wenn etwas nicht wie erwartet funktioniert?«

Das Thema Support ist mit Vorsicht zu betrachten. Ähnlich wie bei der zuvor erwähnten Sicherheit existiert hier ebenfalls eine gemeinsame beziehungsweise geteilte Verantwortlichkeit zwischen dem Kunden und dem Cloud-Anbieter.

Für alles, was in der Cloud betrieben wird, ist der Kunde selbst verantwortlich. Praktisch bedeutet das, dass der Anbieter nicht weiterhelfen kann, wenn die Website plötzlich nicht mehr richtig funktioniert oder man die Zugangsdaten zur eigenen WordPress- oder TYPO3-Instanz vergessen hat. Kein Mitarbeiter des Cloud-Anbieters wird sich per SSH auf dem Server anmelden und helfen, die Konfiguration des Webservers zu analysieren und gegebenenfalls zu korrigieren.

Eventuelle Software-Updates sind Sachen des Kunden. Das Einspielen einer neuen PHP-, WordPress- oder Magento-Version muss man ebenso selbst vornehmen wie ein Server-Upgrade. Aus eigener Erfahrung kann ich allerdings berichten, dass sich Kunden der Unterstützung von Cloud-Anbietern sicher sein können, wenn es um die Architektur einer Hosting-Lösung geht. Bei der Planung, wie einzelne Dienste am besten eingesetzt und kombiniert werden können oder welche Produkte am besten für bestimmte Anwendungsfälle geeignet sind, bieten die meisten Anbieter professionelle Unterstützung an – und das meistens kostenlos.

Sicher ist bereits deutlich geworden, dass ich zur ProCloud-Fraktion gehöre, da bisher sämtliche Argumente entkräftet wurden. Ich möchte allerdings klarstellen, dass die Cloud nicht für jeden Anwendungsfall geeignet ist. Auch hierfür möchte ich zwei Beispiele aufführen.

Zum einen stellt eine fehlende Interoperabilität zwischen verschiedenen Cloud-Anbietern ein Problem dar, wenn man eine existierende Infrastruktur von einem Anbieter zu einem anderen migrieren möchte. Die Anbieter sind zum jetzigen Zeitpunkt untereinander nicht kompatibel, und daher ist ein automatischer Umzug nicht möglich. Selbstverständlich hat man in der Regel vollen Zugriff auf die eigenen Daten und Server. Daher können diese exportiert und woanders wieder hergestellt werden. Jedoch ist dies ein manueller Prozess, und dieser darf in Abhängigkeit von der Grösse und Komplexität der eigenen ­Infrastruktur nicht unterschätzt werden.

Erste Ansätze für die Einhaltung gemeinsamer Standards gibt es allerdings. So hat AWS beispielsweise Ende 2016 angekündigt, an einer VMware-Unterstützung zu arbeiten. Ob es hiermit möglich sein wird, vorhandene VMware-Images ohne Weiteres zu AWS zu verschieben (oder von AWS zu einem anderen Cloud-Hoster), bleibt abzuwarten.

Zum anderen ist die fehlende Unterstützung bei allem, was in der Cloud läuft, ein weiterer wichtiger Punkt. Für einige Webagenturen kann die Tatsache, dass die Cloud-Anbieter ihren Support auf die Infrastruktur beschränken, einen ganz gravierenden Nachteil darstellen. Unternehmen, die über keine Ressourcen zur Administration der Systeme und Komponenten verfügen, sollten sich sehr gut überlegen, wer sich um die Pflege kümmern soll.

Das Angebot einiger traditioneller Hoster (besonders kleinerer beziehungsweise spezialisierter Anbieter) beinhaltet Hilfe auf Applikationsebene, zum Beispiel für TYPO3 CMS, Joomla, Drupal und so weiter. Wer auf diese Art Unterstützung angewiesen ist, sollte sich gut überlegen, ob ein Hosting in der Cloud für ihn geeignet ist.

Letztendlich kommt es auf den Einzelfall an, ob sich der Schritt in die Cloud lohnt. Viele typische Argumente von Skeptikern sind meiner Erfahrung nach nicht gerechtfertigt, und die meisten Webapplikationen profitieren von den vielen Vorteilen, die Cloud Services bieten.

Selbstverständlich muss auch die Architektur der jeweiligen Applikationen diese Vorteile unterstützen. Beispielsweise läuft nicht jedes Content-Management-System standardmässig auf verteilten Systemen. Das heisst aber nicht, dass eine Website grundsätzlich nicht auch in einer Cloud-Umgebung lauffähig ist. In den meisten Fällen ist ein Hosting problemlos möglich, und die Cloud bietet wesentlich mehr Flexibilität beim Setup als die traditionellen Hoster. Welche zusätzlichen Cloud Services dann wirklich genutzt werden können, hängt ebenfalls von der Applikation ab.

Wer bisher noch gar keine Erfahrungen mit Cloud-Hosting gemacht hat, sollte es einfach einmal ausprobieren und eine Testumgebung aufsetzen. Wie zuvor beschrieben kann diese jederzeit wieder gelöscht werden. Da hierbei nur das berechnet wird, was und wie lange genutzt wurde, fallen in den meisten Fällen nur geringe Cent-Beträge an.

Abschliessend möchte ich allerdings noch darauf hinweisen, dass der Schwerpunkt dieses Artikels auf dem Webhosting in der Cloud liegt. Andere Anwendungsbereiche müssen separat auf ihre Cloud-Eignung hin betrachtet werden.