Cloud-Strategie 2.0

Warum Cloud-Strategie 2.0?

Die Cloud ist 2023 keine neue Technologie mehr. Aber der lange Lebenszyklus von Anwendungen, der mehr als 20 Jahre betragen kann, erfordert immer noch eine Cloud-Strategie.

Vor 20 Jahren gab es noch keine Cloud-Architekturen. Alte Anwendungen wurden vielleicht vor einigen Jahren im Rahmen einer Cloud-Strategie 1.0 virtualisiert und per REHOST auf eine Cloud-Infrastruktur gehoben. Die Anwendungsarchitektur hat sich dadurch aber nicht oder nur marginal verändert. Das Rad der Zeit dreht sich trotzdem weiter, Anwendungen altern und Technologien erreichen das Ende ihres Wartungszyklus. Ich sehe daher die Notwendigkeit einer Cloud-Strategie 2.0. Diese dreht sich in erster Linie um Anwendungen und Geschäftsprozesse. Nicht mehr um die Infrastruktur.

Analyse

Als Cloud-Strategie 2.0 bezeichne ich die Transformationsmodelle REFACTOR, REBUILD und REPLACE, die sich vor allem auf den Lebenszyklus von Anwendungen und Geschäftsprozessen beziehen. In diesem Sinne ist die Cloud-Strategie 2.0 gleichzeitig eine Strategie für den Lebenszyklus einer Anwendung und fällt auch in die Zuständigkeit des Application Life-Cycle Managements.

Im folgenden gehe ich auf die Unterschiede der Transformationsmodelle für eine Cloud Migration ein:

REHOST

REHOST, auch Lift & Shift genannt: Verlagert eine Anwendung auf möglichst einfache Weise in eine Cloud, indem die Anwendung statt auf lokalen (virtuellen) Maschinen auf kompatiblen Maschinen in der Cloud ausgeführt wird. Wurde früher bevorzugt als Strategie zur Bereitstellung auf virtuellen Maschinen (Infrastructure as a Service: IaaS) verwendet. Wird heute aber auch verwendet, um Container-Plattformen zu nutzen (Container as a Service: CaaS).

• Überträgt eine Anwendung möglichst ohne Änderungen auf eine Cloud-Infrastruktur.
• Ist eine einfache und schnelle Strategie
• Ist sinnvoll, wenn Wartungskosten für lokale Hardware in die Cloud verlagert werden sollen
• Ist nur für bestehende Anwendungen möglich
• Die Anwendung wird auf der Ebene der Virtualisierung (IaaS) oder auf der Ebene des Containermanagements (CaaS) in die Cloud verlagert.

REPLATFORM

REPLATFORM, auch Lift, Tinker & Shift genannt: Verlagert die Anwendungen wie REHOST in eine Cloud. Wo möglich, werden zusätzlich einfache Cloud-Dienste wie eine Persistenzschicht mit Datenbanken oder Dateiablagen genutzt. Dadurch kann die Anwendung in einem engen Rahmen skaliert werden, ohne dass die grundlegende Architektur angetastet werden muss.

• Ist nützlich, um eine Anwendung - soweit möglich - ohne große Änderungen zu skalieren.
• Kann von Cloud-Diensten wie Database as a Service profitieren
• Die Anwendungsarchitektur in Form der Anwendungslogik und der Geschäftsprozesse bleibt unangetastet.

REFACTOR

Unter REFACTOR versteht man die Überarbeitung einer bestehenden Anwendung. Dabei kann auch die Softwarearchitektur einer Anwendung verändert werden. Im Gegensatz zur nachfolgenden Strategie (REBUILD) wird bei REFACTOR ein Großteil der Anwendungslogik noch als Eigenleistung im Unternehmen erbracht (neu entwickelt oder gewartet). Wo es der Aufwand rechtfertigt, wird auf eine dünne Schicht von Plattformdiensten aus der Cloud aufgesetzt. Da diese Plattformservices das Alleinstellungsmerkmal der großen Cloud-Anbieter sind, muss auf gewollte oder ungewollte Vendor Lock-Ins geachtet werden. Wer hier nicht aufpasst, kann schnell in eine ungewollte Abhängigkeit von einem Cloud-Anbieter rutschen.

• Die zukünftige Skalierung der Anwendung kann an neue Anforderungen angepasst werden.
• Neue Geschäftsfähigkeiten können implementiert werden
• Der Architekturstil der Anwendung kann komplett geändert werden (z.B.: Monolith zu Microservices).

REBUILD

REBUILD ist der große Bruder von REFACTOR. Er beschreibt die komplette Neuentwicklung einer Anwendung auf Basis von Cloud-Technologien. Dabei werden Plattformdienste intensiv genutzt, was eine intensive Auseinandersetzung mit den Aspekten des Vendor Lock-Ins erfordert. Die Schicht der selbst entwickelten Anwendungslogik wird auf ein Minimum reduziert. Lediglich die Geschäftsprozesse verbleiben vollständig in der Verantwortung der Eigenentwicklung im Unternehmen.

• baut eine komplett neue Anwendung
• behält die Geschäftsprozesse bei oder ändert sie selbst
• Verwendet von Anfang an eine Cloud-native Architektur

REPLACE

REFACTOR und REBUILD verursachen bei komplexen Anwendungen einen hohen Projekt- und Entwicklungsaufwand. Dieser Aufwand ist nicht immer gerechtfertigt. Als Alternative kann daher das Transformationsmodell REPLACE eingesetzt werden. Dabei wird eine bestehende Anwendung durch eine SaaS-Anwendung (SaaS = Software as a Service) ersetzt. Dies ist vor allem bei Anwendungen sinnvoll, die standardisierte Prozesse abwickeln. Für hochindividuelle Geschäftsprozesse ist diese Strategie nicht geeignet. Ein REPLACE ist nicht automatisch schnell und einfach. Eine Migration von einem lokalen SAP R3 System zu einem System auf Basis von SAP HANA Cloud ist beispielsweise auch ein REPLACE. Dabei handelt es sich oft um Projekte mit erheblichem Aufwand, auch wenn der Aufwand nicht mit dem einer kompletten Neuentwicklung eines ERP-Systems vergleichbar ist.

• Schneller und einfacher als die anderen Transformationsmodelle
• Gegebenenfalls sind Änderungen in den Geschäftsprozessen erforderlich (das Unternehmen muss sich an die Software anpassen!).
• Herausforderungen liegen in der Migration der benötigten Daten von der alten in die neue Anwendung.

Leitlinien

Für die Cloud-Strategie 2.0 schlage ich folgende Leitlinien, basierend auf der  Pace Layered Architecture vor:

• Systems of Record sind stark standardisiert, so dass es sich kaum lohnt, sie selbst zu entwickeln. Sie sind gute Kandidaten für ein REPLACE.

• Systems of Differentiation sind teilweise standardisierbar. Für Anwendungen, die relativ neu sind, kann sich der Aufwand für einen REFACTOR durchaus lohnen. Ist die Technologie jedoch schon zu alt, kommt nur noch ein REBUILD in Frage. Bevor dieser Aufwand betrieben wird, sollte geprüft werden, ob die alte Anwendung in Teilanwendungen zerlegt werden kann. Eventuell gibt es für diese Teilanwendungen SaaS-Software, die per REPLACE eingesetzt werden kann. In diesem Fall spart man sich den Aufwand für ein REBUILD.

• Systems of Innovation evolvieren per Definition so schnell, dass sich eine Erhaltungsstrategie nicht lohnt. Es gibt auch keine Standardsoftware, die diese Prozesse unterstützen könnte. Es bleibt nur das Transformationsmodell REBUILD für diese Kategorie von Anwendungen.

Maßnahmen

Neben der naheliegenden Maßnahme, Anwendungen zu klassifizieren und entsprechende Migrationsprojekte zu starten, sind die beiden großen Themen der Cloud-Strategie 1.0 auch in der Cloud-Strategie 2.0 aktuell: Datensicherheit und Vendor Lock-in. Datensicherheit kann separat betrachtet werden, Vendor Lock-in ist wie Hybrid Cloud und Multi Cloud eine Frage der Architektur.

Datensicherheit

Beim Betrieb einer Anwendung in der Cloud gibt es eine Reihe von Maßnahmen zur Wahrung der Datensicherheit, die beachtet werden sollten. In diesem Artikel konzentriere ich mich jedoch auf die Gesamtstrategie und erwähne hier nur kurz die wichtigsten Maßnahmen:

• Zugriffskontrolle: Sicherstellen, dass nur autorisierte Personen auf die Daten zugreifen können.
• Verschlüsselung: Sensible Daten sowohl bei der Übertragung als auch bei der Speicherung in der Cloud verschlüsseln.
• Auditing: Regelmäßige Prüfung der Cloud-Umgebung, um mögliche Sicherheitslücken zu erkennen und zu schließen.
• Compliance: Sicherstellen, dass die Cloud-Umgebung den geltenden Datenschutz- und Sicherheitsvorschriften entspricht.
• Risikobewertung: Bewertung der Risiken für Daten und Anwendungen und Ergreifen von Maßnahmen, um diese Risiken zu minimieren.

Architektur

Um die Architektur einer Cloud-Anwendung hybrid und multi-cloud-fähig zu machen und den gefürchteten Vendor Lock-in (strategische Abhängigkeit von einem Anbieter) zu vermeiden, kann man nachfolgend beschriebene strategische Maßnahmen einleiten. Diese Maßnahmen müssen Bestandteil jeder Anwendungsarchitektur sein. Es kann dennoch Situationen geben, in denen man sich bewusst in die Abhängigkeit eines einzelnen Anbieters begeben möchte. Die strategischen und wirtschaftlichen Konsequenzen sollten dabei jedoch bedacht werden.

Insbesondere bei hochverfügbaren Systemen kann ein hybrider Cloud-Ansatz notwendig sein. Denn Ausfälle können auch die größten Anbieter treffen, wie z.B. Amazon AWS im Dezember 2022. Das ist selten, kann aber eine Rolle spielen, wenn Anwendungen wirklich hochverfügbar sein müssen.

Maßnahmen für die Anwendungsarchitektur

• Standardisierte Container sollten für alle Komponenten verwendet werden, für die dies möglich ist. Dies betrifft vor allem die Komponenten der Anwendung, die der Logikschicht zugeordnet sind. Bei Web-GUIs auch die Komponenten der Präsentationsschicht. Standardisierte Container (z.B.: Docker) haben den Vorteil, dass sie in beliebigen Umgebungen eingesetzt werden können. Dadurch können Anwendungen zwischen verschiedenen Cloud-Anbietern, aber auch On-Premise-Umgebungen verschoben werden.

• Standardisierte Persistenz: Die Persistenzschicht speichert die Daten einer Anwendung dauerhaft. Dazu werden typischerweise Datenbanken (relational oder NOSQL) und Dateiablagen verwendet. Für eine portable Cloud-Anwendung sollten übertragbare Persistenzen verwendet werden. Das bedeutet, dass die Anwendung beispielsweise eine  PostgreSQL-Datenbank verwendet und nicht eine Cloud-Provider-spezifische Datenbank. Es ist in Ordnung, einen Datenbankservice eines Cloud-Providers zu verwenden, der mit PostgreSQL kompatibel ist. Gleiches gilt für die Dateiablage. Im Cloud-Umfeld bietet sich hierfür ein S3-Service an. Das S3-Protokoll wurde zwar von  Amazon erfunden, ist aber mittlerweile weit verbreitet und kann auch mit Open-Source-Produkten wie  MinIO oder  Ceph verwendet werden. Damit ist eine Persistenzschicht auf Basis von S3 nicht mehr anbieterspezifisch.

• Fassaden vor Cloud-Diensten: Für bestimmte Use Cases kann es vorkommen, dass man provider-spezifische Cloud-Dienste nicht vermeiden kann. Möchte man beispielsweise eine Anwendung schreiben, die per gesprochener Sprache mit einem Nutzer kommuniziert, dann sind  Amazon Lex und  Polly äußerst nützlich. In diesem Rahmen wird dann auch  Amazon Lambda benötigt. Durch dieses Vorhaben begibt man sich zwangsläufig in eine Abhängigkeit zu den Amazon Webservices. Würde man diese AWS-Dienste direkt in die Anwendung integrieren, wäre eine Migration zu einem anderen Cloud-Provider sehr aufwändig. Daher sollte vor den Cloud-Diensten eine dünne Fassade stehen, die diese von der eigentlichen Anwendung entkoppelt. Möchte man zu einem späteren Zeitpunkt den Cloud-Anbieter wechseln, kann die Fassade mit vergleichsweise geringem Aufwand angepasst werden.
  
  Sollte ein fließender Wechsel der Cloud Provider notwendig sein, könnte die Fassade flexibler gestaltet werden. Die Fassade könnte dann beispielsweise eine text-to-speech-API anbieten, die im Hintergrund entweder  Amazon Lex oder  Azure Text-to-Speech verwendet.

Maßnahmen für die Infrastruktur-Architektur

• Infrastructure as Code: Damit die Cloud-Infrastruktur einer Anwendung bei Bedarf schnell aufgebaut werden kann, sollte sie komplett als Code vorliegen. Dazu eignen sich Werkzeuge wie  Terraform von Hashicorp oder  Ansible.

• Hot und Cold Standby: Als Hot Standby bezeichnet man eine Cloud-Umgebung, die jederzeit einsatzbereit läuft, im Regelfall aber nicht gebraucht wird. Im Ausnahmefall dagegen sorgt sie dafür, dass eine Anwendung weiterhin verfügbar ist, auch wenn die Primärumgebung ausgefallen ist. Um die Kosten für eine solche Umgebung im Rahmen zu halten, sollte sie so gebaut sein, dass sie bei Bedarf automatisch skaliert (“Auto-Scaling”). In der Regel beansprucht sie nur wenige Ressourcen und kann in Ausnahmefällen innerhalb von Sekunden auf höhere Lasten hochskaliert werden. Um die ständige Betriebsbereitschaft zu gewährleisten, sollten die Daten aus der Persistenzschicht der Primärumgebung in nahezu Echtzeit in die Hot-Standby-Umgebung gespiegelt werden.
  Ist ein Ausfall von wenigen Minuten für eine Anwendung tolerierbar, bietet sich ein Cold Standby an. Dieser besteht lediglich aus einem Spiegel der Persistenzschicht der Primärumgebung und Infrastructure as Code-Skripten, die jederzeit ausgeführt werden können. Da diese Umgebung in der Regel nicht existiert (abgesehen von der Datenbank und der Dateiablage), verursacht sie sehr geringe Kosten. Der Preis ist eine etwas längere Startzeit im Ausnahmefall im Vergleich zu Hot Standby.

• Backups: Dass man von all seinen Daten immer ein Backup haben sollte, muss man hoffentlich nicht mehr diskutieren. Im Falle einer unternehmenskritischen Cloud-Anwendung gilt das ganz besonders. Die Tatsache, dass man in jedem Fall ein Backup braucht, kann man sich in einer hybriden Cloud-Umgebung zunutze machen, indem man das Backup auf eine Hot-Standby- und/oder eine Cold-Standby-Umgebung spiegelt. Idealerweise befinden sich diese Umgebungen bei einem anderen Cloud-Anbieter oder sogar vor Ort in einem lokalen Rechenzentrum. So können zwei Fliegen mit einer Klappe geschlagen werden: jederzeit aktuelle Backups und Vermeidung von Vendor Lock-Ins.

Fazit

Mit der Cloud-Strategie 2.0 geht die Modernisierung der IT-Landschaft in die zweite Runde. Während bei den ersten Schritten in die Cloud die Modernisierung der Infrastruktur im Vordergrund stand, geht es nun um die Modernisierung der Anwendungsarchitektur und der Geschäftsprozesse. Tatsächlich sind die Projekte dadurch komplexer geworden, denn Anwendungs- und Geschäftsprozessarchitektur sind keine rein technischen Themen. Während die Modernisierung der Infrastruktur als IT-Problem angesehen werden konnte, betrifft die Cloud-Strategie 2.0 definitiv das gesamte Unternehmen. Dies sollte bei der Projektplanung berücksichtigt werden!

Beachtet man bei der Modernisierung die hier aufgezeigten strategischen Leitlinien und Maßnahmen, dann kann man zukunftsfähige, langlebige Anwendungen bauen, ohne in einen Vendor-Lock-in zu geraten.