Die Cloud — Skalierende Infrastrukturen als unser digitales Rückgrat

Die Art der Lieferung erklärt den Dienst. Erhalte ich einen virtualisierten Server mit einem Betriebssystem meiner Wahl (IaaS) oder eine voll funktionsfähige Anwendung (SaaS), in die ich mich nur noch einloggen muss. Andere Liefermodelle können auch gesamte Infrastrukturen inklusive eines zu konfigurierenden Netzwerks bedeuten oder eine Kombination aus den genannten Diensten sein. Das Service Modell beantwortet die Frage nachdem „wo“ und hilft, die Verantwortung für den reibungslosen Betrieb des Dienstes zu definieren. Muss sich der Konsument des Dienstes im Problemfall selbst helfen oder übernimmt das Troubleshooting der Cloud Provider?

Allein diese beiden Aspekte führen zu einer Vielzahl von Möglichkeiten, helfen aber aus meiner Sicht nur bedingt, sich dem Begriff Cloud auf eine verständliche & nachhaltige Art und Weise zu nähern. Die Nutzung von Cloud hat Konsequenzen, die auf den ersten Blick nicht immer zu sehen sind. Denn auch wenn Cloud vor allem technischer Natur ist, treibt auch der un-technische Nutzer mit seinem Verhalten die Cloud Adaption voran.

Allein aus der Beobachtung wie Dateien auf moderne Art und Weise — über alle Geräte in den Geschmacksrichtungen Dropbox, iCloud, Box.com und Co. synchronisiert — gespeichert werden, ergibt sich eine einfache Konsequenz: Irgendwo müssen die Bytes (zwischen-)gelagert werden. Laut Ciscos Global Cloud Index¹ werden zu diesem Zweck in Zukunft immer häufiger Hyperscale Data Centers zum Einsatz kommen und ironischerweise wieder zu einer Konsolidierung der Daten an einem physischen Ort führen. Aber nicht nur die Speicherung der Dateien nimmt eine schwindelerregende Größenordnung an. Alles, was in einem entfernten Rechenzentrum gespeichert wird, muss rein und wieder raus transportiert werden. Der damit verbundene Traffic sorgt für weitere Herausforderungen in unseren globalen Netzwerken.

Aber nicht nur der private IT-Konsument steigert den Ressourcenbedarf in der Cloud, sondern auch der IT-Verantwortliche, der beschließt, seine Entwicklungsumgebungen in From von virtuellen Maschinen und Containern bei Digital Ocean oder Amazon Web Services (AWS) hosten zu lassen. Hier kommt neben dem benötigten Festplattenspeicher noch der Bedarf nach Rechenleistung in Form von virtualisierten CPUs und Arbeitsspeicher hinzu. Am liebsten im gleichen Modus: Klein beginnend, skalierbar ins quasi Endlose. Cloud scheint vielmehr ein Potential als ein Ort zu sein, welches realen Einfluss auf unser IT-Verhalten hat.

Und obwohl der Begriff Cloud mindestens 10 Jahren stark strapaziert Verwendung findet, kämpfen technische Anbieter und Service Provider um die Deutungshoheit. Jeder hat seine eigene Cloud: der Bund, die Hochschule, die Firmen, die Telkos und natürlich die Riesen von [F]AMAG. Allerdings hat keiner der zuvor genannten den Begriff Cloud erfunden; einige sagen und schreiben² die Wortfindung dem inzwischen verschwundenen (mit HP verschmolzenen) Compaq zu. Dieser hatte als erster die Vision von Diensten³ „oben in den Wolken“.

Jeder, der nur ein wenig IT-Infrastruktur verwalten muss, kann von den Herausforderungen und Schmerzen berichten, die allgemein mit dem Betrieb von Systemen verbunden sind, wenn es darum geht, diese ohne Unterbrechung, immer aktuell gepatcht sowie nie am Leistungslimit „am Leben zu erhalten“. Nicht umsonst hat Werner Vogels als einer der visionären Architekten des Distributed Computing und Erfinder von Amazon Web Services sowie inzwischen Technischer Leiter/CTO von Amazon, gesagt, er sehe seine Rolle exakt in diesem Pain Management und hat entsprechend das Angebot von AWS aufgestellt. So falsch kann er damit nicht liegen: Die Cloud Infrastruktur Angebote von Microsoft, Google, Amazon, IBM und Alibaba sind sich verdammt ähnlich, wenn man auf die Vergleichstabellen der CMPs schaut.

Unterschiedliche Cloud Provider bieten zwar ähnliche Dienste an, jedoch bekommt man selten das Beste (oder günstigste) Leistungsangebot bei nur einem Anbieter. Gleichzeitig will man nicht vollständig abhängig von nur einem Cloud Provider sein. Was passiert bei ungerechtfertigten Preissteigerungen oder Performance Engpässen. Mit Cloud Management Platforms (CMPs) unternehmen technische Anbieter genau diese Klimmzüge über unsere schöne Multi-Cloud Welt wieder ein einheitliches Interface zu bekommen und den Vendor Lock-in zu vermeiden.

Auf der anderen Seite führen diese Überlegungen, beispielsweise zwei statt nur einem Cloud Anbieter zu nutzen, zu noch mehr Komplexität und halten Amazon und Microsoft nicht davon ab weiterhin zweistellig zu wachsen. Beide verdanken große Teile ihres Erfolges im Cloudgeschäft Startups, die vom flexiblen Leistungs- und Bezahlansatz Pay-as-you-go/Pay-as-you-grow profitieren. Früher notwendige Investitionen in kostspielige Hardware sind für diese Unternehmen ein Kapitel aus einer fernen unterenehmerischen Vergangenheit.

Gleichzeitig profitieren moderne Entwicklungspradigmen wie DevOps oder Cloud-native von diesen Infrastrukturen, die nicht nur über ein Webinterface sondern auch über APIs gesteuert werden können.

Aber was passiert nach Cloud? On-Premise Verfechter sehen ein Comeback des eigenen Rechenzentrums, da in der Cloud vielleicht alles „einfacher“ aber mit Blick auf Total Cost of Ownership (TCO) - vor allem bei großen Infrastrukturen - nicht alles günstiger wird. Nicht jeder Workload benötigt komplexe HA/DR Konzepte, die mit Cloud Anbietern einfacher realisiert werden können (jedoch mit eingepreist sind). Andere sehen dezentrale und nicht nur distribuierte Systeme wie die Blockchain als Antwort auf die Frage. Auch hier sind die Argumente spannend: Wenn alles in den großen Rechenzentren liegt, wie bekommt man Daten und laufende Systeme wie virtuelle Maschinen im Zweifelsfall wieder heraus?

Don’t throw a Mattress into a Swimming Pool.

Nicht umsonst gibt es die Analogie zu folgendem Dorm Room Prank: Die Matratze eine Mitbewohners in den Pool des Wohnheims zu werfen. Solange sich die Matratze noch von innen trocken ist und oben schwimmt, bekommt man diese leicht wieder heraus. Sobald sie vollgesogen zu Boden sinkt, sind größere Anstrengungen wie etwa ein Kran oder das Ablassen des Wassers aus dem Pool von Nöten. Gleiches gilt für unsere Daten und Systeme, die wir bei Cloud Providern betreiben.

Ist die Antwort auf die offensichtliche Sitting Ducks Situation⁴ in den Rechenzentren von Google, Amazon, Microsoft und Alibaba die dezentrale Speicherung der Daten? In einer modernen Interpretation kommt einem die Blockchain-Technologie in den Sinn, ein wenig Oldschool könnte man auch über Peer-to-Peer Lösungen wie BitTorrent nachdenken. Kurzfristig bieten beide Ansätze keine befriedigende Lösung. Die Bereitstellung von einer flexibel skalierbaren, zuverlässigen (mindestens vier 9er) und performanten Infrastruktur auf eine dezentrale Art und Weise ist noch in weiter Ferne. Der Grund warum alles in die Cloud will, liegt auf der Hand: Der Betrieb von Infrastruktur & Diensten ist schwieriger ist als man denkt (wer hat gerade privat Backups für den Hardware Totalausfall?). Das Beste aus allen Welten bekommt man momentan nur bei den großen Cloud Providern oder unter massiven Einsatz von CapEx und OpEx für den Betrieb eines eigenen, Cloud-ähnlichen Rechenzentrums.

Die Wahrheit liegt wie so oft in der Mitte. Hybride Cloud Modelle bieten auf den ersten Blick viele Vorteile, bringen aber auch weitere Komplexität in den Betrieb der IT-Infrastruktur. Stichwort ist hier wieder die zentrale Managementplattform – nicht nur für die bessere Verwaltung sondern auch für den Kostenvergleich. Nur wenn die Kosten direkt auf den Betrieb eines Dienstes und/oder VM bzw. virtueller Server-Ebene berechnet werden können, kann wirklich entschieden werden, wo der Workload besser aufgehoben ist.

Auch Amazon sieht den Wunsch der Kunden nicht alles „oben“ in der Cloud laufen zu lassen und bietet die Möglichkeit seine virtuellen Maschinen (EC2 Instanzen) auf den hauseigenen SnowBall Edge Geräten zu betreiben. Microsoft bringt mit Azure Stack die gesamte Cloud Infrastruktur in das Rechenzentrum der Kunden. Die Argumente für diese technische Variante liegen auf der Hand: Die Berechnung der Daten erfolgt mit den bekannten Services von AWS oder Microsoft, bei gleichzeitiger Datenhoheit für den Kunden und ohne Notwendigkeit große Bandbreite für den Upload zur Verfügung zu stellen. Zusätzlich kann es Szenarien geben, in denen eine Verbindung zum Internet nicht möglich oder unerwünscht ist. Stichworte sind wohl Entwicklung von militärischem Gerät oder sehr, sehr teure Arbeit an Turbinen, Motoren und Co., die allesamt auf air-gapped Netzwerke setzen, allein um sich vor Spionage zu schützen. Aber auch hier möchte man auf die letzte Komponente von Cloud nicht verzichten: Alle Dienste sollen bequem über ein Self Service Catalog aufgerufen und über eine API angesprochen werden können.

Cloud ist Bequemlichkeit und bedeutet aus Anwendersicht vor allem eins: Die Verantwortung wo mehr Performance, mehr Speicherplatz, unendlich viele Accounts, unlimitierte Backups etc. herkommen, übernimmt ab sofort jemand anderes.

Genau jenem Anbieter obliegt es allerdings, sich den Kopf über den reibungslosen Betrieb zu zerbrechen. Immer wenn Verantwortung abgegeben wird, verschwinden zwar die Herausforderungen aus der unmittelbaren Wahrnehmung des Konsumenten/Nutzers, aber die Probleme bleiben genau genommen die gleichen. Zusätzlich konsolidieren sich in den Rechenzentren von Amazon, Microsoft, Google, Alibaba und Co. unsere Daten. Gleiches gilt für die geliebten Cloud Dienste zum Speichern unserer Daten und Fotos. Allerdings sind ohne diese Infrastrukturen viele moderne Dienste gar nicht mehr vorstellbar. Und nur so kann der Hunger nach mehr gestillt werden, ohne lästige Lade- und Wartezeiten.

Die Steuerung solcher Systeme ist komplex und eine Herausforderung in einer ganz eigenen Liga, in die sich nur die wenigsten und kapitalstarken Anbieter vorwagen können — und es dann noch schaffen, diese Infrastrukturen hoch profitabel zu betreiben. Gleichzeitig ist das Ease-of-Use dermaßen verlockend, dass niemand mehr zu einfachen virtuellen Servern ohne ausgeklügelte Redundanzmechanismen zurückkehren möchte. Verteiltes Computing – in welcher Form auch immer – ist der neue Standard. Wir wollen endlose Kapazitäten, funktionierende Backups, Plattformen mit Hyper Availability, schnelle Desaster Recovery Pläne, allerdings ohne die damit verbundene Arbeit. Das ist Cloud, egal ob Anwendung oder als vollständige Infrastruktur, und sie ist längst unser Underlying Grid, welches fast genauso wichtig ist, wie der Strom, der die Rechenzentren und unsere Endgeräte betreibt.

This content is only available in German

Die Cloud — Skalierende Infrastrukturen als unser digitales Rückgrat