Muss ich in die Cloud?

Cloud Computing ist aktuell in aller Munde und wer nicht bei drei in der Cloud ist hat angeblich schon verloren. Doch was ist eigentlich diese Cloud und welchen Vorteil bietet Cloud Computing?

In diesem Beitrag kläre ich zunächst was Cloud Computing ist. Anschließend beschreibe ich die Vor- und Nachteile der verschiedenen Servicemodelle. Insbesondere dieser Teil bietet eine gute Möglichkeit mehr über meine Sicht- und Herangehensweise in der Beratung zu erfahren. Kurzangebundene können - wie immer - direkt zum Fazit springen.

Was ist Cloud Computing

Wie bei vielen modernen IT-Trends üblich gibt es auch für den Begriff Cloud Computing keine allgemeingültig anerkannte Definition. Allerdings fällt es mir bei diesem Thema leicht, mich den Ausführungen und der Definition des Bundesamt für Sicherheit in der Informationstechnik (BSI):

Cloud Computing bezeichnet das dynamisch an den Bedarf angepasste Anbieten, Nutzen und Abrechnen von IT-Dienstleistungen über ein Netz. Angebot und Nutzung dieser Dienstleistungen erfolgen dabei ausschließlich über definierte technische Schnittstellen und Protokolle. Die Spannbreite der im Rahmen von Cloud Computing angebotenen Dienstleistungen umfasst das komplette Spektrum der Informationstechnik und beinhaltet unter anderem Infrastruktur (z. B. Rechenleistung, Speicherplatz), Plattformen und Software.

Im Gegensatz zu beispielsweise KI ist diese Definition schon deutlich greifbarer. Trotzdem ist die Spannbreite von Infrastruktur über Plattformen bis hin zu Software sehr breit und heterogen. Die Servicemodelle IaaS, PaaS und SaaS beziehen sich auf eben diese drei Ebenen und ermöglichen damit etwas einfachere Erklärungen.

Infrastructure as a Service (IaaS)

IaaS-Angebote sind Dienstleistungen die das Cloud-Pendant zu klassischen Infrastrukturkomponenten bieten. Im Zeitalter vor der Cloud mussten Komponenten ausgewählt werden. Je nachdem wie viel Rechenleistung benötigt wurde, musste beispielsweise ein entsprechender Prozessor ausgewählt werden. Dazu die notwendige Menge an Arbeitsspeicher und je nach Speicherplatzbedarf die entsprechenden Speichermedien. Ab entsprechenden Größenordnungen passte dies nicht alles in einen Server, sondern musste auf mehrere Server verteilt werden. Dabei entstand gegebenfalls ein Mehrbedarf an Leistung, welcher durch mehr Komponenten ausgeglichen werden musst. Sobald alles im Rechenzentrum verbaut und angeschlossen war, waren die Veränderungsmöglichkeiten sehr gering. Demgegenüber standen hohe Investitions- und Kapitalkosten.

Im Cloud Computing werden nun die Leistungen dieser Komponenten dynamisch gebucht. Statt einen Prozessor auszuwählen, wird eine bestimmte Menge Rechenleistung gebucht und entsprechend des Buchungszeitraums abgerechnet. Statt hoher Investitions- und Kapitalkosten entstehen lediglich laufende Kosten in Höhe der tatsächlich gebuchten Leistungen. Dabei wird pro Stunde bis hin zu auf die Sekunde genau abgerechnet.

Der Kostenvorteil für den Kunden ergibt sich zunächst aus der größeren Flexibilität. Es müssen weniger Ressourcen für Lastspitzen vorgehalten werden, da diese im Falle des Falles einfach dynamisch dazu gebucht werden können. Gleichzeitig werden Kosten durch Fehlplanungen verringert. Ein Rechenzentrum, welches gebaut ist, ist bis zum Abschreibungsende “gebucht”. Gleiches gilt für den installierten Server, das Storage und alle anderen physischen Infrastrukturkomponenten. Sich nach unten zu verkalkulieren ist meist noch kritischer, da man physische Infrastrukur nicht mal eben aus dem Boden stampft. Die unausweichliche Überlastung geht in der Regel auch mit einem Umsatzausfall einher.

Um Leistungen so flexibel buchen zu können, kommen in der Regel (Ausnahmen wie Bare Metal Clouds bestätigen diese Regel) Virtualisierungstechnologien zum Einsatz. Die vorhandenen physischen Ressourcen werden damit zu einem Pool zusammen gefasst. Aus diesem können die benötigten Mengen jedem Kunden dynamisch zugewiesen werden. Tatsächlich fällt Rechenleistung jedoch nicht, wie manch einer beim Namen Cloud hofft, vom Himmel, sondern muss physisch vorgehalten werden, um dynamisch zugewiesen zu werden. Die Leistungsreserven wandern somit nur vom Kunden zum Cloud Anbieter. Erst mit einer gewissen Größe und der damit einhergehenden Diversität in den Leistungsprofilen der Kunden, kann der Anbieter ähnlich einer Versicherung bei gleichbleibender Verfügbarkeit die durchschnittlichen Leistungsreserven pro Kunde reduzieren. Trotzdem muss der Cloud Anbieter die Kosten für diese Leistungsreserven in die Preise für seine Leistungen einkalkulieren. Die reine Rechenleistung kostet damit in der Regel mehr. Der Kunde kann einen Kostenvorteil nur realisieren, wenn sein Lastprofil eine entsprechende Dynamik aufweist und er auch technisch in der Lage ist seine gebuchte Leistung entsprechend flexibel anzupassen.

Virtualisierung bringt allerdings nicht nur größere Flexibilität. In der Regel werden beispielsweise keine kompletten Prozessoren “vermietet”, sondern jedem Kunden werden einzelne Kerne eines Prozessors zugewiesen. Mitunter beeinflusst die Auslastung eines Prozessorkerne, aber auch die Performance der anderen Kerne. Im Cloud Computing ist dieses Phänomen als “noisy neighbor” bekannt. Hinzu kommt, dass die Virtualisierungslösung in solch einer Konstallation viel höhere Sicherheitsgarantien erfüllen muss, als beispielsweise in einer dedizierten Umgebung. Es ist ein Unterschied ob ich, wie in einer dedizierten Umgebung, eigene Workloads voneinander isoliere, um den “blast radius” einer Sicherheitslücke zu verringern oder Workloads potentiell verfeindeter Benutzer voneinaner isolieren muss. Vor allem sind die Folgen einer Sicherheitslücke deutlich verherender.

Die Discounter unter den Cloud Anbieter gehen auf diesem Weg noch einen Schritt weiter. Durch umfangreichere Virtualisierung werden den Kunden nicht mehr logische Prozessorkerne zugewiesen, sondern komplett virtuelle. Da Prozessoren sehr viel Zeit im Leerlauf verbringen, können so mehr Prozessorkerne vermietet werden, als physisch zur Verfügung stehen. Indem den virtuellen Prozessorkernen die Zeit im Leerlauf “geklaut” wird, reicht die Rechenleistung eines logischen Prozessorkernes für mehrere virtuelle. Das Problem der “noisy neighbors” tritt in diesem Fall noch deutlicher auf.

Der Bereich IaaS umfasst virtuelle Server und Block Storage Angebote. Mitunter kommen entsprechende Netzwerkleistungen hinzu, um diese Ressourcen in einem privaten Netzwerk zu verknüpfen. Einen Server oder ein Storage 1-zu-1 aus dem Rechenzentrum in die Cloud zu migrieren führt erst einmal zu einer Kostensteigerung, da die reine Leistung teurer ist. Die häufig angepriesenen Kostenersparnisse lassen sich meist nur erzielen, wenn die Flexibilität einer Cloud-Umgebung auch genutzt wird. Sinnvoll ist dies in der Regel nur bei einer entsprechenden Dynamik in der Lastkurve. Grundvoraussetzung ist allerdings, dass die Anwendung skalierbar ist und trotz schwankender Ressourcen zuverlässig betrieben werden kann. Hinzu kommt, dass auch die Skalierung selbst geregelt sein muss, sei es statisch nach Zeitplan oder dynamisch anhand von Kennzahlen oder ähnlichem. All dies muss implementiert werden und bedeutet entsprechende Investitionen.

Platform as a Service (PaaS)

PaaS-Angebote bilden die Ebene zwischen IaaS und SaaS. Dabei handelt es sich nicht mehr um reine Infrastruktur sondern schon um Dienste, allerdings noch nicht um “fertige Anwendungen”. Man spricht auch von Laufzeit- und Entwicklungsumgebungen. Diese Angebote richten sich demnach an Entwickler und nicht an Endanwender. Viele Managed Service Angebote sind auf dieser Ebene einzuordnen.

Während im IaaS-Bereich ein virtueller Server gebucht wird, auf welchem der Kunde dann beispielsweise seine Datenbank installiert und verwaltet, wird im PaaS-Bereich die entsprechende Datenbank als Service gebucht. Für den Kunden entfallen der Installations- und Wartungsaufwand. Auch die Abrechnungsmetriken können damit spezifischer werden. Während im IaaS-Bereich die gebuchte Rechenleistung abgerechnet wird, kann ein Datenbank-Angebot im PaaS-Bereich beispielsweise nach verbrauchtem Speicherplatz und der Anzahl der Datenbankabfragen abgerechnet werden. Nach welchen Metriken genau abgerechnet ist und wie dynamisch das Angebot skaliert wird, hängt natürlich vom Anbieter und der Reife des Produktes ab.

Für einen Anbieter, welcher viele Instanzen des selben Datenbanksystems oder anderer Dienste verwaltet, lohnt es sich eher administrative Aufgaben zu automatisieren. Damit realisiert er einen Kostenvorteil, den er an die Kunden weitergeben kann. Je ausgereifter das Produkt, desto dynamischer kann es auf die notwendigen Ressourcen zugreifen. Entsprechend größer sind die Kostenvorteile, welche sich bei einer dynamischen Lastkurve zusätzlich ergeben können. Analog zum IaaS-Bereich gilt dabei, dass auch eine Cloud-Datenbank nicht vom Himmel fällt. Es braucht weiterhin ein Datenbanksystem und entsprechende Hardware auf der dieses ausgeführt wird. Das PaaS-Angebot ist lediglich eine Abstraktionsebene auf der die damit verbundenen Aufgaben vom Anbieter für den Kunden übernommen werden.

Eben diese Abstraktion hat mitunter Folgen, welche aus meiner Perspektive ein Nachteil darstellen können. Eine Abstraktionsebene stellt immer auch eine Schnittstelle zu den darunterliegenden Schichten bereit. Auch wenn Schnittstellen durchaus technisch eindeutig sind, so ist die Intention der Autoren menschlich. Entsprechend kann die Dokumentation noch so ausführlich sein und die Schnittstelle selbst noch so idiotensicher, die Erfahrung zeigt, dass sich immer jemand findet, der die Schnittstelle anders nutzt als geplant. Mitunter ist dann auch das Ergebnis anders als geplant und der Jackpot ist, wenn dies erst weit in den produktiven Betrieb hinein sichtbar wird.

Viele Anforderungen lassen sich in der Informatik auf Standardprobleme oder eine Kombination dieser zurückführen. Zu diesen gibt es Standardalgorithmen, welche die Problemstellung lösen. Deren Komplexität kann, genauso wie bei jedem anderen Algorithmus, in Abhängigkeit der Eingabe beschrieben werden. Dadurch kann der Zusammenhang zwischen Lastkurve und Ressourcenverbrauch abgeschätzt werden. Mitunter kann man Probleme eher rechen- oder eher speicherlastig lösen. Da beide Ressourcen unterschiedliche Kosten je Einheit verursachen, ist die kosteneffiziente Lösung ein Optimierungsproblem. Die Frage ist, welchen Teil diese Problems man im Vorhinein lösen kann und welchen erst durch nachträgliche Änderungen.

Für die vorgelagerte Lösung braucht es Kompetenz und Erfahrung. Mit der Auslagerung an einen PaaS-Anbieter gibt es für die entsprechenden Mitarbeiter in ihrem Kompetenzbereich meist keine Aufgaben mehr. Schnell werden sie nur noch als Kostenfaktor gesehen. Je mehr beim Cloud-Anbieter zusammen geklickt werden kann, desto weniger wird sich mit den grundlegenden Zusammenhängen beschäftigt. Genau durch diese braucht es jedoch, um Fehler und Kostenexplosionen im Vorhinein vermeiden.

Mir wurde es mitunter schon als erfolgreiche Lernerfahrung verkauft, wenn offensichtlich relationale Problemstellungen in einer dokumentenorientierten Datenbank umgesetzt wurden, bis die Limits dieser Technologie völlig gesprengt wurden und noch einmal komplett von vorne begonnen wurde. Dieses Mal mit einer relationalen Datenbank. Dokumentenorientierte Datenbanken waren zu diesem Zeitpunkt der neue heiße Scheiß. Hätte man sich mit den Konzepten hinter beiden Datenbanktechnologien beschäftigt, hätte man sich mit wenigen Stunden Recherche viele Wochen nutzlosen Entwicklungsaufwand sparen können.

Mitunter regiert auch komplett das Controlling. Probleme werden mit Technologien gelöst die gerade hip sind. Statt vorneweg zu recherchieren, klickt man sich lieber im Nachhinein beim Cloud-Anbieter des Vertrauens die nächste Technologie. Was vom Controlling nicht wegen zu hoher Kosten rausgekickt wird, bleibt bestehen. Wenn das Controlling doch etwas sagt, wird die entsprechende Komponenten einfach in kleinere Teile zerlegt und auf unterschiedliche Budgets aufgeteilt. Natürlich ist dies sehr überspitzt dargestellt, aber leider nicht völlig aus der Luft gegriffen. In der Softwareentwicklung gilt, je später ein Fehler korrigiert wird, desto exponentiell teurer wird die Korrektur. Je mehr Erfahrung ich auslagere, desto anfälliger werde ich für Fehlentscheidungen, gerade bei grundlegenden Fragen zu Beginn eines Projektes. Natürlich kann ich das Ganze als Agilität verkaufen, aber “Korrektur unserer Fehlentscheidungen aus dem vorletzten Sprint” ist keine User-Story. Wenn der Benutzer stattdessen mehr Performance wünscht klingt das schon viel besser. Auch hier gilt: Agilität ist wichtig, aber die Balance muss stimmen. Genauso wie Autos nicht bei Höchstgeschwindigkeit am effizientesten sind, ist Geschwindigkeit nicht alles bei der Agilität.

Der Bereich PaaS umfasst vor allem Laufzeit- und Entwicklungsumgebungen sowie die dazugehörigen Dienste. Zielgruppe sind vor allem Entwickler, nicht Endkunden. Durch die Auslagerung wiederkehrender Wartungsaufwände können Kosten gespart werden. Teilweise geht mit der Realisierung dieser Vorteile ein Verlust an Erfahrung und Kompetenz einher, der mittelfristig zum Wettbewerbsnachteil werden kann. Weiterhin steigt bei PaaS-Angeboten, im Vergleich mit IaaS-Angeboten, die Koppelung der eigenen Entwicklungsergebnisse an den gewählten Anbieter. Entsprechend größer sind die Vendor Lock-In-Effekte.

Software as a Service (SaaS)

Bei SaaS-Angeboten handelt es sich um Software für Endanwender die vom Cloud-Anbieter bereitgestellt wird. Insofern unterscheidet sich die Zielgruppe deutlich von IaaS- und PaaS-Angeboten. Bei SaaS-Angeboten gibt es heutzutage häufig nicht einmal die Wahl zwischen Bezug als Cloud-Lösung oder selbstverwaltet (on premise). Die Auswahl eines SaaS-Angebotes unterscheidet sich damit nicht groß von anderen Softwareentscheidungen in Unternehmen. Entsprechend schwierig bis nutzlos ist es hier allgemeingültige Vor- und Nachteile aufzuzeigen.

Wer “Wir müssen in die Cloud” in diesem Zusammenhang als Entscheidungskriterium sieht, hat das Thema verfehlt. Welche Entscheidungskriterien wichtig sind, hängt unter anderem davon ab, in welchem Unternehmensbereich die Software eingesetzt werden soll und welche Anforderungen an die Software gestellt werden. Zunehmend muss aber auch die Frage gestellt werden, ob die Software zur Unternehmenskultur passt.

Gerade Sicherheits- und Souveränitätsanforderungen können dabei ein Ausschlusskriterium für SaaS-Angebote darstellen. Auch Anforderungen an die verfügbare Bandbreite und Latenz müssen immer häufiger beachtet werden. Gerade in Deutschland ist der DSL-Anschluss gerne das entscheidende Nadelöhr. Auf der anderen Seite wird es möglich Software und die benötigte Rechenleistungen entsprechend der tatsächlichen Nutzung abzurechnen. Dadurch lassen sich Kosten sparen. Gerade wenn die Wartung der eigenen Software schon vorher ausgelagert war, geht durch die Nutzung eines SaaS-Angebotes kaum Erfahrung verloren. Letztendlich bleiben damit in der Regel mehr Ressourcen, um sich auf das Kerngeschäft zu fokussieren.

Häufig wird es als Vorteil von SaaS-Angeboten verkauft, dass man von kontinuierlichen und zeitnahen Updates profitiert. Mitunter führt dies aber auch dazu, dass Anbieter ihre Software vor der Auslieferung weniger ausführlich testen und stattdessen auf Feldtests setzen. Sollte ein Fehler auftreten, kann man diesen ja schnell mit einem weiteren Update beheben. Auch Lock-In-Effekte müssen unbedingt beachtet werden. Kann man seine Daten nur manuell zu einem anderen Anbieter übertragen, oder lediglich in abstrusen Formaten exportieren, ist es mit der oft beschworenen Flexibilität schnell vorbei.

Fazit

Cloud Computing ist vor allem eine Abstraktionsebene. Dadurch wird die IT nicht weniger kompliziert. Vielmehr wurden neue Konzepte geschaffen, welche die Kompliziertheit ihrer Implementation vor dem Nutzer verstecken. Werden diese Konzepte richtig verstanden, ermöglicht dies eine stärkere Spezialisierung der einzelnen Akteure und schafft dadurch Mehrwerte.

Auf der anderen Seite können diese Konzepte aber auch missverstanden werden. Dadurch kann Komplexität unterschätzt und die eigene Kompetenz überschätzt werden. Je länger diese Missverständnisse mitgeschleppt werden, desto teurer ist häufig der Schaden.