Kolumne

EnterpriseTales: Die Cloud als Allheilmittel

Christian Schulz

© S&S_Media

Die Cloud ist nach wie vor eines der großen Hypethemen. Versprechungen werden gemacht und Hoffnungen geschürt. Doch welche davon löst die Cloud ein? Auch wenn der Begriff der Cloud schon länger verwendet wird, ist die Abgrenzung zwischen den verschiedenen Varianten nicht immer eindeutig. Für diese Kolumne unterscheide ich sie in die nachfolgenden Abschnitte.

Infrastructure as a Service

Die Grundidee von IaaS basiert auf einer vorhandenen (physikalischen) Maschine, die in die Cloud verschoben wird. So wird man innerhalb von Minuten zum stolzen Betreiber einer Cloudlösung. Systemadministratoren können erleichtert aufatmen – die Verantwortung, die Maschine zu betreiben, liegt nun nicht mehr in ihren Händen.

Die virtuelle Maschine in den unterschiedlichsten Hardwareausprägungen und -größen kann einfach und bequem zusammengestellt werden. Aber auch unterschiedliche Laufzeitumgebungen für beispielsweise fertige Java Enterprise, JavaScript und ähnliche Anwendungen werden angeboten. In ihnen muss die Anwendung nur noch deployed werden. Sollten die schon existierenden Umgebungen den Ansprüchen nicht genügen, können auch neue Container, meistens in Form von Docker Image, als Basis hochgeladen werden.

Platform as a Service

Bei PaaS werden die häufig benötigten Komponenten wie Datenbanken, Netzwerkspeicher, Messaging und ähnliches als fertige Lösungen in der Cloud angeboten. Im Gegensatz zur vorherigen Variante muss für diese Managed Services die virtuelle Maschine nicht mehr selbst verwaltet werden. Von der relationalen Datenbank bis hin zu selbst entwickelten Datenbanken der Cloudanbieter werden alle Wünsche ohne großen Aufwand erfüllt. Wer lieber auf NoSQL setzen möchte, findet auch hier ein entsprechendes Angebot. Auch Datenspeicher in nahezu unendlichen Größen, die von überall schnell und einfach zugreifbar sind, können einfach realisiert werden.

Backend as a Service

Fast jede Anwendung steht früher oder später vor der Anforderung, eine Benutzerverwaltung einsetzen zu müssen – warum also nicht auch hier die Cloud einsetzen? BaaS bietet fertige Lösungen für verschiedene Anwendungsszenarien wie Benutzerverwaltung mit einer Single-Sign-on-Unterstützung und OAuth-Integration. Aber auch Push-Benachrichtigungen für mobile Geräte, der Schutz für die eigene Anwendung in Form von beispielsweise einer Web Application Firewall (WAF) oder Analytics können als fertige Lösungen konfiguriert werden. Verschiedene Tools wie gehostete Quellcodeverwaltung bis hin zur Build Pipeline sowie eine in der Cloud gehostete Entwicklungsumgebung (IDE) decken alle Anforderungen der Entwicklungsteams ab.

Function as a Service

FaaS ist eine weitere Variante der Cloud, die hinter dem Hypewort „Serverless“ steht. Die eigene Businesslogik wird in kleine Funktionen aufgeteilt, die dann direkt in der Cloud deployt und ausgeführt werden. Ein eigener Applikationsserver wird dann nicht mehr benötigt. Das Deployment erfolgt mit wenig Aufwand in die entsprechenden Umgebungen. Bei Bedarf werden innerhalb von Millisekunden viele parallele Ausführungen der Funktion gestartet, womit Probleme der Skalierung der Vergangenheit angehören.

Die Cloud als Allheilmittel?

Kein wochenlanges Warten auf eine beantragte Maschine, keine Downtime durch parallele Updateausspielung, Kosten fallen nur an, wenn der Service gebraucht, beliebige Skalierungen durch eine gefühlt endlose Zahl von Maschinen und keine Personalkosten im Hardwarebetrieb – die scheinbar endlosen Möglichkeiten der Cloud lassen die Augen von Entwickler und Management leuchten. Die Cloud als das Allheilmittel für alle Infrastrukturprobleme scheint überzeugend. Doch was ist die Schattenseite der schönen neuen Welt?

Die negativen Aspekte der Cloud sind nicht nur technischer Natur. Es werden viele Bereiche berührt, über die bei der eigenen Infrastruktur nie nachgedacht werden musste.

Zunächst erstmal das leidige Thema mit dem Datenschutz. Sicherlich möchte es niemand mehr hören, doch sobald die eigenen Daten aus dem Rechenzentrum verlagert werden, muss zumindest geprüft werden, welche datenschutzrechtlichen Aspekte betroffen sind. Die verschiedenen Cloudprovider bieten zwar meistens unterschiedliche Regionen an, in denen auch der entsprechende Service gehostet werden kann. Auf diese Weise kann sichergestellt werden, dass die Daten immer in dem Land des betreibenden Unternehmens liegen. Dennoch muss hierbei beachtet werden, dass es unter Umständen Dienste gibt, die nicht in den entsprechenden Regionen vorhanden sind und somit nicht für die eigenen Zwecke eingesetzt werden können bzw. dürfen.

Neben dem Datenschutz müssen auch immer die rechtlichen und vertraglichen Rahmenbedingungen beachtet werden, da es in der Regel nicht gewünscht ist, dass Dritte Zugriff auf die eigenen Daten haben. Vor diesem Hintergrund sollten die umfangreichen Nutzungsbedingungen von den unterschiedlichen Services aufmerksam studiert werden.

Damit einher geht der nächste Punkt: der Kontrollverlust. Durch das Auslagern in die Cloud, hat die eigene IT-Abteilung nicht mehr die Herrschaft über die eingesetzten Ressourcen und Prozesse. Diese liegt nun in den Händen des Cloudbetreibers und in dessen Automatisierungslösung. Verschiedene Vorfälle zeigen, dass es in der Cloud nicht immer einfach ist, die Kontrolle zu behalten. Plötzlich sind firmeninterne Dokumente, Datenbanken und andere Ressourcen für die ganze Welt öffentlich. Ein aktuelles Beispiel ist der Datenverlust einer bekannten Hotelkette. Häufig handelt es sich dabei um Konfigurationsfehler. Diese können meistens auf fehlende Schulungen zurückgeführt werden. Die eigene IT-Abteilung wird gerne nur mit minimalen Mitteln ausgebildet und soll anschließend in der Lage sein, ein hochkomplexes Cloudumfeld zu managen. Fehler und Sicherheitsprobleme sind automatisch vorprogrammiert.

Auch der cloudeigene Support bietet nicht immer eine adäquate Lösung für die vorhandenen Probleme. Häufig wird man im Stich gelassen. Zum Beispiel wird empfohlen, die Symptome mit mehr Hardware (Geld) zu lösen, anstatt das zugrunde liegende Problem herauszufinden und anzugehen.

Die Cloud als Kostensenker

Häufig wird bei der Einführung der Cloud eine Kostensenkung beim Personal und dem Betrieb versprochen. Aus dem oben Beschriebenen geht allerdings hervor, dass durch eine Cloudeinführung zunächst einmal höhere Kosten entstehen, z. B. durch notwendige Schulungen der eigenen Mitarbeiter.

Auch das Versprechen des Senkens der Personalkosten muss differenziert betrachtet werden. Zum einen erzeugt man durch solch eine Aussage Unruhe in den eigenen Reihen. Die gesamte Betriebsabteilung muss auf einmal um ihren Job bangen, weil z. B. Updates für die Betriebssysteme und Datenbanken automatisch eingespielt werden und sie somit überflüssig werden. Tatsächlich werden Teile des Berufs durch den Wechsel in die Cloud obsolet, da die Aufgaben dort bereits abgedeckt sind. Allerdings darf hier die Gefahr des Wissensabgangs nicht unterschätzt werden. Nur, weil die Cloud heute läuft, heißt das nicht, dass das morgen auch noch der Fall sein wird. Eigenes Administrationspersonal, das das grundlegende System kennt, selbst, wenn es in der Cloud läuft, kann goldwert sein. Auch durch den bereits erwähnten häufig schlechten Anbietersupport ist eigenes Personal, das sich in die Materie einarbeitet, sinnvoll.

Selbst die versprochene Senkung der Betriebskosten durch die Cloudeinführung ist nicht immer so einfach zu erzielen, wie erwartet. Hierzu müssen die Preismodelle genau studiert werden, da sie sich zwischen den verschiedenen Services häufig unterscheiden. Es gibt meistens ein Freikontingent oder einen kleineren Nutzungsumfang, der schnell verbraucht ist. Danach können die Kosten aber schnell in die Höhe schießen. Zum Beispiel sind virtuelle Maschinen mit kleiner Hardwareausstattung sehr günstig, durch die Verwendung größerer Maschinen können die entstehenden Kosten schnell die Kosten eines eigenen Rechenzentrums übersteigen.

Teilweise verstecken sich auch in den Standardeinstellungen schon Kostentreiber, die erst bei der Monatsabrechnung auffallen, falls diese überhaupt überprüft wird. Bei der automatischen Skalierung sollte z. B. immer mit Vorsicht gehandelt werden. Sie wird gerne standardmäßig zu großzügig erweitert. Eine falsch eingestellte Skalierung für die Datenbank, und schon läuft ein ganzes Cluster, das auch bezahlt werden muss. Die Bezahlung erfolgt natürlich pro verwendete Instanz.

Die Kosten stellen noch ein weiteres Problem dar, falls der Rahmen der hinterlegten Kreditkarte überschritten wird. Denn dann ist die eigene Software, die in der Cloud betrieben wird, innerhalb von Minuten nicht mehr erreichbar. Die Betreiber fahren Instanzen, die sie nicht berechnen können, automatisiert herunter. Niemand möchte mit seinem Produktivsystem einen Totalausfall haben, nur weil der Verfügungsrahmen erschöpft ist.

Nicht nur fehlende Geldmittel können das Produktivsystem in der Cloud lahmlegen. Immer wieder gibt es Berichte, dass Accounts (scheinbar willkürlich) gesperrt werden. Damit werden auch alle gekauften Dienstleistungen automatisch suspendiert.

Werden Dienstleistungen in der Cloud genutzt, müssen die Nutzungsbestimmungen der Cloud beachtet werden. Diese umfassen auch den Inhalt der in die Cloud geladenen Daten. Sollte hier ein Verstoß festgestellt werden, kann der Account ohne Vorwarnung gesperrt werden. Für den Käufer der Dienstleistungen haben fehlerhafte Überwachungen des Inhalts oder fehlende Sorgfalt beim Lesen von Nutzungsbestimmungen schwerwiegende Konsequenzen. Im Gegensatz dazu schaltet sich das eigene Rechenzentrum nicht automatisch aus, falls es tatsächlich mal versehentlich nicht erlaubter Inhalt auf die Server geschafft hat.

Komplexität wider Erwarten

Durch das komplexe Cloudumfeld entstehen noch andere Probleme, die in der eigenen Infrastruktur eher selten bzw. in einer anderen Art auftreten können. Beispielsweise sind die einzelnen Services meistens durch ein umfangreiches Rechtemanagement zu konfigurieren. Das soll ermöglichen, dass die Anwendung A, die den Service A benötigt, nicht auf den Bereich der Anwendung B im Service A zugreifen kann. Gerade bei scheinbar einfachen Aufgaben wie dem Erstellen einer Lambdafunktion kann man hier schnell mit einer Vielzahl von Problemen mit den Rechten konfrontiert sein, wenn die Lambdafunktion weitere Services benötigt. Durch die häufig riesige Auswahl entsteht zudem schnell eine Überforderung. Es geht eigentlich um einen kleinen und einfachen Service – aber welche der Umsetzungsmöglichkeiten soll nun gewählt werden?

Ist dann die Entscheidung getroffen und ein Service wurde gegen ein bestimmtes API des Cloudanbieters entwickelt, kommt es nicht selten zu Änderungen eben dieses API, die leider auch nicht immer der semantischen Versionierung folgen und somit unvorhersehbare Probleme auslösen. Häufig stellt man dann im Nachhinein fest, dass der ausgewählte Cloud-Service doch nicht (mehr) für den geplanten Zweck geeignet ist. Es bleibt einem nichts anderes übrig, als die eigene Anwendung auf einen neuen Service zu migrieren.

Ein weiteres Problem mit den Cloud-Services, gerade im Bereich der Datenbanken und anderen Managed Services, besteht darin, dass Cloudanbieter ihre eigenen Anpassungen vornehmen, damit sie besser laufen. Ein Beispiel dafür ist Elasticsearch, das bei manchen Anbietern so stark verbogen worden ist, dass wichtige Funktionalitäten zur Analyse von Problemen fehlen.

Die Anpassungen der Cloudanbieter führen zu einem weiteren Problem: Gibt es eine neue Version einer Software, die als Managed Service angeboten wird, so benötigt der Cloudanbieter einige Zeit, um seine Anpassungen an der neuen Version vorzunehmen. Es kann also einige Zeit vergehen, bis eine neue Version auch in der Cloud zur Verfügung steht.

Neben der schwierigen Entscheidung für einen Cloud-Service besteht noch das Problem des sogenannten Vendor Lock. Die APIs der Cloudanbieter sind häufig proprietär. Hat man seine Anwendung erst einmal gegen eine solche API entwickelt, kann sie nicht ohne Weiteres zu einem anderen Anbieter verlagert werden. Eine Migration verursacht dann wieder Kosten, die eigentlich mit der Cloud vermieden werden sollten.

Fazit

Auch wenn der letzte Abschnitt das vielleicht suggeriert, ist die Cloud nicht per se schlecht, sie muss allerdings richtig eingesetzt werden. Dazu ist es immer sinnvoll, wenn man als Unternehmen aus der Erfahrung anderer lernt, um nicht in die gleichen Fallstricke zu tappen. Bei jedem einzelnen Service sollte geprüft werden, ob, wann und in welcher Variante er in die Cloud migriert wird. Auf keinen Fall sollte man seine Anwendung nur deshalb in die Cloud bringen, weil das eben heute jeder so macht.

Stattdessen sollten gezielt Anwendungsfälle gesucht werden, in denen die Cloud eine wirklich sinnvolle Erweiterung zu der vorhandenen Infrastruktur bietet, z. B. Szenarien, in denen kurzfristig viel Rechenpower benötigt wird, die den Rest der Zeit aber brachliegt, wie etwa ein monatlicher Rechnungslauf. In jedem Fall sollte man schrittweise beginnen, die Cloud in die eigene Landschaft zu integrieren.

Geschrieben von
Christian Schulz
Christian Schulz
Christian Schulz ist Enterprise Developer bei der OPEN KNOWLEDGE GmbH in Oldenburg. Er verfügt über mehrjährige Erfahrung als Entwickler im Enterprise- und SPA-Umfeld. Zu seinen Interessenschwerpunkten gehören API-Design und -Dokumentation via Swagger, das SPA Framework Angular sowie Continuous Integration.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: