Ihr Unternehmen will sich technisch neu ausrichten und möchte voll auf die IT-Services eines großen Cloudanbieters wie Amazon, Microsoft oder Google setzen? Welche Strategien und Überlegungen bei solch einer weitreichenden Entscheidung eine Rolle spielen, habe ich bereits in diesen beiden Beiträgen skizziert:

• Mit der Cloud ist alles einfacher – ist es aber auch besser?
• Multi Cloud – die Unabhängigkeitserklärung der IT

Im Kern ging es dabei um die Aspekte zur Erarbeitung einer Unternehmens-Cloudstrategie und das waren im Wesentlichen die folgenden:

• Warum will ich einen Cloudservice nutzen (Kosten, Qualität und Flexibilisierung)?
• Was will ich in der Cloud betreiben?
• Wie will ich es in der Cloud betreiben?
• Welche kurzfristigen und langfristigen Konsequenzen hat das für meine IT, insbesondere im Bereich der Flexibilisierung?

Man könnte diesen Beitrag nun als die logische Fortsetzung der ersten beiden betrachten, den ich eigentlich nie schreiben wollte. Einige Projekte in den vergangenen zwei Jahren haben mich jedoch dazu veranlasst, doch noch einmal die Feder für dieses Thema zu spitzen. Dabei geht es heute darum, Optionen des eigentlichen Übergangs in die Cloud zu diskutieren. Also genau das, was nach der strategischen Entscheidung kommt. Dieser Teil des Weges wird in der realen Welt nach meiner Erfahrung stark vernachlässigt, sodass man bei manchen Projekten etwas überspitzt von einer Mischung aus Naivität und technischer Überforderung sprechen könnte.

In der realen Welt hat man zuweilen den Eindruck, dass IT-Verantwortliche glauben, mit der generellen Entscheidung für (oder gegen) eine Cloud sei die Arbeit erledig. Einfach den Schalter umlegen und fertig ist die neue IT. So funktioniert das nicht. Denn wurde die hoffentlich gut durchdachte Entscheidung für ein Cloudmodell einmal getroffen, fängt die eigentliche Arbeit erst so richtig an. Bei Verlagerungen von IT-Infrastruktur oder Teilen der IT in eine virtuelle Cloudumgebung gibt es neben den rechtlichen Facetten – wie die Einhaltung von regulatorischen Maßgaben beispielsweise der GoBD oder die Bewertung des U.S. Cloud Acts in Bezug auf die DSGVO – auch eine Reihe technischer Aspekte, die zu planen und zu berücksichtigen sind.

Wie der Weg in die Cloud beschritten werden kann, differenziert sich dabei in zwei extreme Ansätze, die ich hier als Lift and Shift und Micro-Service-Architektur bezeichne. Deren reale Ausgestaltung mündet in der Regel jedoch in einen sinnvollen Mittelweg, da Extreme meist keine gute Lösung sind. So wie immer kann sich die Konkretisierung dieses Weges aufgrund unternehmensspezifischer Gegebenheiten differenzieren. Generell empfehle ich Kunden dringend, die Flexibilität der IT als eine der zentralen Anforderungen zu betrachten. Und nein, mit der Cloud wird eben nicht alles besser, billiger, einfacher und flexibler – das ist ein verbreiteter Trugschluss. Entsprechend darf der Weg einer IT in die Cloud niemals als Einbahnstraße betrachtet werden. Eine vollständige Strategie sollte berücksichtigen, dass ein mittelfristiger oder gegebenenfalls sogar kurzfristiger Wechsel des Cloudproviders möglich sein muss (siehe: Beiträge oben). Grade deshalb und bei hybriden Lösungsmodellen, also einer Mischung aus On-Premises- und Cloud IT, sollten beispielsweise auch die Herausforderungen von Latenzen und Durchsatz berücksichtig werden (Details dazu siehe auch: Wenn Daten träge werden – Data Gravity). Ist doch logisch, meinen Sie? Ja, das sollte man glauben. Aber man kann sich nicht vorstellen, wie häufig dieser wichtige Punkt vor allem bei großen Infrastrukturen vernachlässigt oder gänzlich falsch eingeschätzt wird und folgerichtig später zu Problemen führt.

Lift and Shift – schnell, aber häufig nicht gut

Als erstes Szenario könnte in Betracht gezogen werden, einfach das, was vorhanden ist, zu nehmen und so wie es ist in die Cloud „zu tragen". Dieser Ansatz ist auch als Lift and Shift bekannt. Bei dem Verfahren werden bestehende Systeme einfach auf z. B. VM-Cloudinstanzen installiert und dabei nach Möglichkeit keine Softwareanpassungen vorgenommen. Im Extremfall werden ganze Systeme, so wie sie sind, in die Cloud „transferiert", also eine Lift-and-Shift-Umstellung. Hier unterstützen die großen Cloudanbieter häufig mit Tools und Verfahren, um Kundensysteme möglichst einfach in eine Cloudinfrastruktur zu überführen. Vorteil dieses Ansatzes ist, dass maßgebliche Redesigns oder Softwareanpassungen wegfallen, die ein Transformationsprojekt hin zur Cloudumgebung verzögern könnten. Nachteil dieses Ansatzes ist, dass genau die Vorzüge von echter Cloudtechnologie bestenfalls nur teilweise oder auch gar nicht genutzt werden können. Konzepte, die eine Cloudnutzung attraktiv machen (z. B. Zero Downtime, Auto Scaling oder eine kontinuierliche Deployment Pipeline), bleiben ungenutzt, weil die Software sie einfach nicht unterstützen kann. Eine moderne Cloudinfrastruktur ist mit veralteter Software leider auch nicht viel wert. Im ungünstigsten Fall endet ein Lift-and-Shift-Projekt mit dem schlechtesten aus zwei Welten, nämlich der Abhängigkeit von einem Cloudprovider aufgrund einiger proprietärer Services und den immer noch vorhandenen Nachteilen einer On-Premises-Architektur – nur jetzt in einer virtuellen Cloudumgebung. Von daher halte ich auch nicht viel von diesem Ansatz. Ein CIO kann so zwar relativ schnell den Haken bei der „Cloudumstellung" machen und sein variables Gehalt einfordern, aber mit einer echten Modernisierung der IT hat das nichts zu tun. Es hat in der Realität noch nie gut funktioniert, erst einmal mit Krücken Fakten zu schaffen, um es anschließend richtig machen zu wollen. Ein gutes Provisorium hält eben auch in der Cloud fünf Jahre. Das kann man sich auch sparen.

Micro Service Architektur (Container) – gut, aber häufig nicht schnell

Der andere Ansatz wäre ein Redesign bzw. eine Überführung aller Anwendungen in eine echte Service-Architektur. Dabei empfiehlt sich die Nutzung von Container-Technologie bzw. eines Orchestrierungsservices wie Kubernetes oder OpenShift. Vorteil dieses Konzeptes sind die bereits oben benannten Vorzüge von echter Cloudtechnologie, wie z. B. Möglichkeiten zu Zero Downtime Deployments, Auto Provisioning, eine kontinuierliche Deployment Pipeline oder Rolling Updates/Roll Backs. Hauptnachteil dieses Ansatzes sind sicherlich die in der Regel entstehenden Projektaufwände zur Neugestaltung der Anwendungslandschaft. Darüber hinaus sind viele Softwareprodukte der On-Premises-Welt heute gar nicht als echte containerisierte Lösung verfügbar. Und unter dem, was verfügbar ist, gibt es leider jede Menge Altbestände der On-Premises-Welt, die man bei genauerer Betrachtung nicht wirklich als „Cloudtechnologie" bezeichnet sollte. Schon bei trivialen Security-Scans z. B. mit „trivy" füllen die kritischen Findings nicht selten ganze DIN-A4-Seiten. Das hindert jedoch viele Kunden nicht daran, solche Software einfach einzusetzen. Grund dafür ist zum einen die technische Unerfahrenheit und Überforderung des Personals mit den neueren Technologien, zum anderen aber auch die Kombination mit dem vom Management formulierten und zum Teil vollkommen unrealistischen Zeit- und Budgetvorgaben. Da muss man sich nicht wundern, wenn Scheunentor-große Sicherheitslücken in der IT klaffen und sich russische Hackerbanden mit der Installation von Verschlüsselungssoftware bedanken.

Oder vielleicht doch SaaS?

Im Zuge einer Transformation hin zum echten Cloudservice könnten theoretisch auch On-Premises-Softwarelösungen gegen SaaS-Angebote eines Cloudanbieters ausgetauscht werden. Für kleine und mittelständische Unternehmen ist das sicherlich auch eine echte Alternative. Ab dem gehobenen Mittelstand sollte jedoch die potenzielle Abhängigkeit zum Lösungsanbieter berücksichtig werden und mehr Gewicht erhalten. Solche SaaS-Ansätze sind aus meiner Sicht nur dann sinnvoll, wenn es sich um einfache und standardisierte Software handelt. Komplizierte Prozesse in proprietäre SaaS-Angebote zu integrieren, ist definitiv eine technische Einbahnstraße im Sinne der IT-Flexibilität und sollte vermieden werden. In diesen Fällen ist die Abhängigkeit vom Cloudanbieter noch höher, als sie es im eigenen Rechenzentrum jemals war. Machen Sie sich nichts vor: Kunden haben bei SaaS-Lösungen weder Software, Netzwerk noch Hardware unter Kontrolle. Was für kleine und mittelständische Unternehmen vielleicht von Vorteil sein kann, sollten sich Unternehmen im Enterprise-Segment besser zweimal überlegen. Fallen sie nicht auf die Vertriebsfloskeln der Cloudanbieter herein und glauben Sie nicht, dass alles flexibel und einfach wird. Grade bei SaaS-Angeboten kann genau das Gegenteil der Fall sein.

In der Mitte liegt die Wahrheit

Da es in der realen Welt bestehende IT-Lösungen gibt, die aus dem Stand nicht 100 Prozent Cloud-native sind und eine Überführung in die Cloud auf der anderen Seite kein Endlosprojekt werden soll, bietet sich am Ende doch eine Mischform der beiden Extremansätze an. Somit sollte für jedes System bzw. für jeden Anwendungsfall einzeln bewertet werden, welche Optionen auf dem Tisch liegen und in welchem sinnvollen Verhältnis die Möglichkeiten im Bezug von Aufwand und Nutzen stehen. Gegebenenfalls garniert mit einfachen SaaS-Angeboten, kann die Reise in die Cloud oder in die hybride IT-Welt auch ein Erfolg werden. Die Herausforderung besteht vor allem darin, diese Optionen überhaupt zu kennen bzw. sichtbar zu machen und dann auch bewerten zu können.