Ransomware
Cloud: Game Changer oder weitere Abstraktionsschicht
Die Cloud steht für mehr Agilität und Effizienz. Anhand der Entwicklung dahin mit immer weiteren Abstraktionsebenen und Automatisierungen zeigt der Autor deren Fluch und Segen für Unternehmen – aber auch was wichtig ist, um die Kontrolle zu behalten.
Ich habe bereits früher erklärt, dass die „Cloud“ mehr ist als nur eine neue Darreichungsform von Dienstleistung oder eine neue Technologie. Im Prinzip geht es darum, IT anders zu produzieren und deutlich agiler und effizienter zu konsumieren, ohne die tiefsten Kenntnisse über alle technischen Hintergründe selbst inhouse vorhalten zu müssen. Jedoch an eben dieser Stelle schleicht sich auch der kleine Schlendrian ein, geht es um die komplett selbst aufgebaute private Cloud, oder wenn das Unternehmen eben nicht im Rahmen von Shared-Responsibility-Modellen mit Cloud-Providern arbeitet.
Die technologische Entwicklung ins Cloud-Zeitalter
Im Laufe der Zeit habe ich die verschiedensten Technologie-Wellen kommen (und manche auch gehen) sehen, und habe sie immer wieder nur als weitere Abstraktionsebenen empfunden. Einzelne physische Server sind nicht optimal ausgelastet, also wird Virtualisierung eingeführt, damit man mehr Maschinen auf der jeweiligen Hardware betreiben kann. In einem nächsten Schritt kamen dann Virtualisierungs-Cluster mit zentralem Management. Auf diese Weise lassen sich mehr Server effizienter managen; aber der IT Betrieb trennt häufig nach wie vor die Silos Server, Netzwerk und Storage. Nun haben die Infrastrukturverantwortlichen aber die Fähigkeit „Hochverfügbarkeit“ für Applikationen auf VMs, deren Workloads diese Funktion per Design nicht haben, zur Hand (Achtung, trügerische Sicherheit!). Mit der Abstrahierung, also Einführung von virtuellen Netzwerken und virtuellen Speichersystemen lassen sich auch diese Hürden unterschiedlicher Zuständigkeiten im operativen Betrieb nach und nach weg abstrahieren und in Software gießen. Die darunter liegenden Technologien, zuvor noch Server, Netzwerk-Switch und SAN/NAS-System werden in Code konsolidiert auf (Hyper-) Converged Systeme. Auch so ist wieder alles unter einer weiteren Abstrahierungsschicht Software verborgen. Aber: Es ist noch da!
In weiteren Schritten bauten Unternehmen dann durch Software definierte Infrastrukturen also Software Defined Datacenter auf -- die Vorgänger oder Basisschicht einer Cloud, in denen mit viel Automatisierungs- und Orchestrierungsaufwand die eigentliche Bedienung von Software und Hardware auf das Ansteuern von APIs reduziert wird. Dieser Reifegrad der IT ist auch heute noch kein universeller Standard! Der große Vorteil dabei besteht darin, dass mehr Mitarbeiter das gleiche Ergebnis durch Ansteuern der Automation erzeugen können, zu dem früher Expertenwissen nötig war. Für die Erstellung eben jener Automatisierungen wurden externe Experten eingestellt oder eigene Mitarbeiter geschult – also böse gesagt, auch schnell mal wieder ein Bereichsfürstentum erschaffen, das essenziell ist für ihre IT-Wertschöpfungskette.
„Cloudifizierung“ und alles ist gut?
Mit zunehmender „Cloudifizierung“ werden nun die betriebenen Services weitestgehend automatisiert über CI/CD Pipelines provisioniert und den konsumierenden Benutzern und Operatorgruppen zur Verfügung gestellt. Diese Gruppen können ohne Fachkenntnisse zu zugrundeliegenden Technologien, Zusammenhängen der Systemarchitektur oder tiefergreifendem Verständnis der Mechanismen der Verfügbarkeitsmodelle diese Dienste konsumieren und sich auf die SLAs verlassen. Willkommen in der Cloud, möchte man sagen, wenn man sieht, dass nach der Virtualisierung, Containerisierung und Serverless Functions immer neue Abstraktionsmethoden gefunden und hinter Portalen oder besser (viel besser!) APIs versteckt werden.
Diese Entwicklung ist aus Sicht der auf Cloud setzenden Unternehmen Fluch und Segen zugleich, denn ohne die Kenntnisse in der Tiefe wird eine Migration aus einer Public Cloud zurück in eigene IT-Strukturen vermutlich langfristig keine Option sein. Ob eine Cloud-Exit-Diskussion langfristig von Belang ist, wird die Zeit zeigen. Es kommt am Ende wohl darauf an, wen man fragt.
Wer sein Datacenter mit Hardware und Software bestücken will, wird andere Beispiele haben als ein Hyperscaler, der die nächste SAP Landschaft aus dem Rechenzentrum in die Cloud hebt. Neben IT-Angriffen gibt es auch weitere Störfaktoren, die den IT Betrieb und damit den Geschäftsbetrieb tangieren können. Stromausfälle oder ein Ausfall der Klimaanlage sind noch harmlose Beispiele. Die Verlagerung in den Betrieb anderer Provider bedeutet eben nicht selbstredend „störungsfrei“, sondern einfach nur „fremdbetrieben“. Mit Hardware arbeiten die Dienstleister und ITs dieser Welt am Ende alle, und die braucht nun mal einige Rahmenparameter, damit sie läuft.
Warum so polemisch?
Der geringere Zeitaufwand, um sehr mächtige Technologien zu beschaffen, zu testen und ggfs. auch wieder abzugeben, ist bei der Nutzung von Cloud-Modellen ein absoluter Pluspunkt. Auf diese Weise herrscht eine technologische Chancengleichheit, die allein durch die Fähigkeit der Architekten und das verfügbare Personal limitiert wird. Das übergelagerte Ziel bleibt natürlich, die Technologien letztendlich für das Geschäft gewinnbringend einzusetzen. Die Überauswahl ist aber auch quasi der krasse Gegensatz zur „alten Welt“, in der es ewig lange Beschaffungsprozesse zu definieren gab und umständliche Technologieauswahlprozesse mit Proof-of-Concepts verwaltet werden mussten. Nach ausschweifenden Business Cases wurde dann ein Stück Software gekauft und implementiert, in der Hoffnung, dass der ursprüngliche Bedarf überhaupt noch so existiert.
Aus Beratersicht sollte man immer daran denken, sich nicht in der Begeisterung für eine Technologie zu verfangen! Es ist wichtig, die Augen offen zu halten und die Gesamtheit (also auch die Machbarkeit des Betriebs) der Lösung im Blick zu haben, damit sie am Ende einen Geschäftszweck unterstützt. Leider verbleiben wir am Ende dann doch gern in unserer Komfort-Zone-Technologie, die allzu häufig Symptome lindert. Aber jeder IT Betreiber muss seine Probleme nun wirklich noch in den Griff bekommen.
Ein tolles Beispiel von Technologien, die bis heute missverstanden werden, bieten die Fähigkeiten „Live-Migration“ und „Hochverfügbarkeit“ für virtuelle Maschinen. Beide liefern einen gewissen Beitrag zur Überbrückung von geplanten/ungeplanten Downtimes – aber in der Summe können sie keinen unterbrechungsfreien Betrieb gewährleisten. Fällt eine Hardware aus, gibt es keine Quelle für eine „Live Migration“. „Hochverfügbarkeit“ bedeutet, die virtuelle Maschine wird neu gestartet – der Dienst also unterbrochen. Dennoch haben sich Kunden zu Tausenden auf diese Funktion verlassen und als Hochverfügbarkeitsstrategie verwendet, ohne die Hersteller der Software auf den VMs dazu zu bringen, unterbrechungsfreie Resilienz zu schaffen. Ja – es gibt weitere Lösungen mit Zero und Fault Tolerance, aber auch diese versuchen nur die Unzulänglichkeiten in der Schicht darüber (der Applikation) auszugleichen.
Mit der zunehmenden Entwicklung von Cloud-nativen Applikationen, die Modelle wie dem der „12 Faktor App“ (https://12factor.net/de/) folgen, werden die Probleme am Schopf gepackt. Unterliegende Technologien können Unterbrechungen ggfs. überbrücken – aber die Intelligenz und Resilienz sollte doch bitte dort gelöst werden, wo sie benötigt wird: In der Applikation. Am Ende gilt wie immer: Verlasse dich nicht blind auf die Provider – in dem Fall die Plattform.
In der heutigen Applikationslandschaft sind die meisten noch nicht 100-prozentig dort angekommen, dass alle oder ein Großteil der heutigen Applikationswelt den Modellen von „12 Faktor App“ Anwendungen mit Microservices entsprechen. Die Applikationen sollten in Services und Prozesse aufgeteilt werden, die mit dem Prozessmodell skalieren und auf Einweggebrauch (Stateless) ausgerichtet sind. Das Auflösen einer Abhängigkeit einer Applikation von einer Hardware und die Schaffung der Portabilität, die beispielsweise durch Containerisierung erreicht werden kann, helfen zukünftig, auch Business Continuity- und Disaster Recovery-Prozesse neu zu überdenken.
Empfehlung
Die vorangegangenen Gedanken dienen eher als Impuls denn als konkreter Vorschlag, etwas zu verändern. Wichtig ist es, bewusste Entscheidungen unter Berücksichtigung der zur Verfügung stehenden Informationen zu treffen. Heute ist es sehr einfach, sich auf die höchste Abstraktionsschicht zu konzentrieren und die nicht mehr sichtbaren Anteile zu ignorieren. Das Bewusstsein für das Vorhandensein aller Komponenten hilft, Risiken sauber zu identifizieren und unser Risiko-Register zu befüllen mit mehr Gewissheit und weniger Annahmen.
Schließlich soll die Cloud ein Stück mehr Agilität und Effizienz bringen, das Geschäft unterstützen, und es hat sich selten ausgezahlt, „Blind Spots“ zu dulden und nicht zu beleuchten. Es gilt, das richtige Maß an Kontrolle zu finden und Hersteller wichtiger Software gezielt in die Verantwortung zu nehmen, die lückenlose Resilienz zu schaffen für kritische Geschäftsprozesse.