Wie Banken die fünf größten Fallen in der Cloud-Transformation umgehen

Die Cloud verändert, wie Software entwickelt und betrieben wird. Applikationen stecken dabei in virtuellen Containern, die ihre Software und Daten gegenüber anderen abgrenzen. Betriebsumgebungen, wie Kubernetes, steuern diese Container und organisieren sie so, dass die Applikationen automatisch bereitgestellt, verwaltet und skaliert werden. Diese Philosophie ist die konsequente Weiterentwicklung des in den 2000er-Jahren beliebt gewordenen Einsatzes virtueller Maschinen. Um die Vorteile der Cloud nutzen zu können, müssen Banken ihre Software zunächst „cloud-ready“ machen und dafür sorgen, dass künftige Entwicklungen „cloud-native“ passieren.

1.) „Cloud-ready“ bedeutet nicht einfach „in die Cloud“

Sieben Anforderungen müssen erfüllt sein, damit eine für die Cloud angepasste Software als „cloud-ready“ gilt:

1. Viele monolithische Applikationen steuern ihre Teilsysteme selbst, um etwa auf Laständerungen zu reagieren. Diese Steuerung wird innerhalb der Cloud durch einen Orchestrator wie Kubernetes (siehe weiter oben) vorgenommen, nicht mehr durch die Applikation selbst. Daher sollte diese Steuerung aus den Applikationen entfernt oder zumindest konfigurativ ausgeschaltet werden.
2. Konfigurationen dürfen nicht mehr in den Applikationen codiert sein, sondern müssen sich von außen verändern lassen. Dies gilt insbesondere für Credentials, wie Passwörter oder Tokens, die über ein Vault oder einen Hilfscontainer („Sidecar“) bereitgestellt werden. Technische Konfigurationen sollten grundsätzlich nicht in einer Datenbank abgelegt sein.
3. Falls technische Zustände einer Applikation gespeichert werden sollen, ist ein globales Volume zu verwenden und kein lokales Volume innerhalb der Applikation. Weil NFS in der Cloud nur bedingt skaliert, sollte diese Speichertechnologie möglichst wenig verwendet werden.
4. Technische und fachliche Logs sollten separat voneinander geschrieben werden. Dies vereinfacht, das technische und fachliche Monitoring zielgruppengerecht einzurichten und das darauf aufsetzende Alerting besser zu steuern. Darüber hinaus sollte jeder Applikationsteil, der in einem Container steckt, mindestens zwei „Monitoring Probes“ per Pull-Verfahren bereitstellen, die für den Orchestrator notwendig sind: Liveness (Container „lebt“) und Readiness (Container ist bereit, Anfragen entgegenzunehmen).
5. Jede Applikation soll zudem über mindestens zwei „Operatoren“ verfügen. Operatoren sind administrative Dienste spezifisch für jede Applikation, die während des Deployments einmalig aktiviert werden. Einer steuert, wie die Software innerhalb der Cloud-Umgebung deployt wird. Der andere, wie Migrationen, etwa bei einem Update, zu laufen haben.
6. Verbindungen von und zu den Applikationen und den anzuschließenden Middleware-Ressourcen werden über Netzwerkregeln gesteuert. Sie geben beispielsweise vor, über welchen Port eine Anwendung mit Daten versorgt wird (Ingress) und welche Datenbankverbindung die von ihr erzeugten Daten speichert (Egress). Die entsprechenden Regeln sollten Teil des Deployments sein und nicht separat erfolgen.
7. Rollen und Rechte bestimmen darüber hinaus, welche Personen und Applikationen auf welche Applikationen wie zugreifen dürfen. Bei dieser Zuweisung soll stets das Need-to-know-Prinzip gelten und die Definition sollte analog zur Anforderung davor als Teil des Deployments ausgebracht werden.

2.) Nicht-fachliche Anforderungen sind nicht zu unterschätzen

Was ein Cloud-Transformationsprojekt kompliziert macht, sind nicht zuerst die fachlichen Anforderungen, die die Applikationen zu erfüllen haben. Zwar entsteht dadurch ein umfassender Katalog an Kriterien. Der Anteil am Gesamtaufwand, um diese umzusetzen, liegt in den Projekten erfahrungsgemäß jedoch bei lediglich 30%. Alles andere ergibt sich durch nicht-fachliche Anforderungen, wie Regulatorik, Cyber-Sicherheit oder Service Level Agreements (SLA). Von der Verschlüsselung über ein IT-System für Rollen und Rechte bis hin zur „Disaster Recovery“ gibt es zahlreiche Vorgaben, die mitunter mit jeweils eigener Software umgesetzt werden. Diese muss folglich den gleichen Regeln genügen wie die fachlichen Applikationen.

Dabei wird häufig übersehen, dass sich diese zusätzlichen Anforderungen auf die gesamte Service-Architektur auswirken. Beispiel: „Disaster Recovery“. Regulatorisch vorgegeben ist, dass Bank-Systeme ausfallsicher in verschiedenen Zonen und Regionen betrieben werden müssen. Fällt eine Region aus, etwa wegen eines Hochwassers, muss die Plattform in einer anderen Region den Betrieb möglichst nahtlos fortführen (Geo-Redundanz). Die maßgeblichen Kennzahlen dafür lauten RPO (Recovery Point Objective) und RTO (Recovery Time Objective). Sie geben vor, in welcher Zeit und mit welchem Datenbestand im Katastrophenfall auf eine andere Region geschwenkt wird. RPO und RTO fließen deshalb mit in den Kriterienkatalog ein, dem alle Komponenten – insbesondere die Persistenz-Middleware – der gewählten Service-Architektur genügen müssen.

3.) Wie sich technische und fachliche Betriebsumgebungen schaffen lassen

Im Betrieb hat sich bewährt, eine technische und eine fachliche Cloud-Umgebung vorzusehen, um betriebliche Vorgänge einheitlich zu normieren und gleichzeitig die bestehenden Möglichkeiten der Cloud-Provider nutzen zu können.

Die technische Umgebung umfasst dabei alles, was die Applikationen benötigen, um in der Cloud betrieben und administriert werden zu können. Dazu gehören Datenbanken, Netzwerkprotokolle, Schnittstellen wie REST-APIs – kurz: alles, was die Applikationen an Middleware voraussetzen. Je übersichtlicher diese Anforderungsliste ausfällt und je mehr davon durch den Cloud-Provider bereitgestellt wird, desto besser.

Die fachliche Umgebung wird substanziell durch die Möglichkeiten der Cloud, wie „Big Data“ (Reporting und Archivierung), begünstigt und umfasst vor allem das fachliche Betriebs-Monitoring und -Alerting, welches den Betrieb durch Real-Time-Recherchen unterstützt und dadurch erheblich erleichtert. Für Langzeitarchive gilt, dass die Recherchen über die gesamte Aufbewahrungsdauer mit gleicher Qualität und Suchzeit erfolgen können.

4.) Wiederholbarkeit mit „Infrastructure as Code“ herstellen

Ein Aspekt der technischen Betriebsumgebungen betrifft die Art, wie Infrastruktur – etwa die von den Applikationen benötigte Middleware – bereitgestellt wird. Mit „Infrastructure as Code“ (IaC) lässt sich die Zuordnung solcher Ressourcen wie Code behandeln. Damit ist gemeint, dass deklarativ über eine Software wie Terraform beschrieben wird, welche Applikationen in einem Container auf welche Middleware zugreifen sollen. Da die Anzahl dieser Definitionen in der Cloud üblicherweise groß ist, sollte das IaC-Prinzip angewendet werden. Damit wird der regulatorische Prozess des Go-Live über mehrere Umgebungen automatisch wiederholbar und damit weniger anfällig für Fehler. Darüber hinaus lässt sich dieser technische Unterbau, auch wenn er einmal entwickelt werden muss, wiederverwenden.

5.) Warum das Staging automatisiert werden sollte

Diese Wiederverwendbarkeit zahlt sich spätestens beim Staging aus. Darunter wird der Übergang der Applikation von der Entwicklungs- über die Test- und Abnahmeumgebung bis zur Produktion verstanden. Regulatorisch darf zwischen Abnahmeumgebung und Produktion kein Unterschied in der Applikationsversion und der fachlichen Konfiguration bestehen. Lediglich die technischen Konfigurationen unterscheiden sich. Daraus ergibt sich jedoch enormer Aufwand und ein beträchtliches Fehlerrisiko, wenn das Staging nicht automatisiert wurde. „Infrastructure as Code“ beschleunigt diese Vorgänge spürbar. Darüber hinaus lassen sich die Vorteile eines automatisierten Stagings auch im Testmanagement nutzen.

––––––––––––––––––––

*Jens Dittmer ist Entwicklungsleiter und Lead Architect bei dem Beratungs- und Softwarehaus PPI AG. Die PPI AG gehört zu den Premium-Partnern von Finanz-Szene.de. Mehr zu unserem Partner-Modell erfahren Sie hier.

Wie die Hamburg Commercial Bank (HCOB) die Cloud-Transformation ihrer ausgelagerten Zahlungsverkehrsplattform nach der oben beschriebenen Blaupause bewerkstelligt hat, beschreibt ein Kapitel des voraussichtlich am 30. September 2025 im FCH-Verlag erscheinenden Buches „DORA & Cloud-Sicherheit: Praxisleitfaden für Banken & IT-Dienstleister“. Am 30. Oktober 2025 findet zudem ein Webinar statt, zu dem sich Interessierte hier anmelden können