Microsoft Azure Einsatz im Bankenumfeld

Die erste Ankündigung der Azure IT Plattform ist fast 15 Jahre her und noch immer wird leidenschaftlich darüber diskutiert, ob oder wie Azure im Bankenumfeld zum Einsatz kommen sollte oder darf – strategisch wie juristisch und technisch.

Argumente für und gegen eine Cloud-Migration im Banking

Was spricht für und was spricht gegen eine Migration in die Cloud?

Generell kann man sagen: Cloud-Projekte scheitern nicht an fehlenden Compliance-Möglichkeiten, sondern an Nicht-Nutzung vorhandener Ressourcen (z.B. SOC 2 Zertifikate bei Azure) und internen Anforderungen, die umfangreicher sind, als aufsichtsrechtlich notwendig.

Argumente gegen eine Cloud-Migration

Einige der am häufigsten in Diskussionen genannten Argumente gegen eine Cloud-Migration einzelner Services oder der Orientierung des gesamten Unternehmens an einer (Public) Cloud-First Strategie sind:

Datenhoheit,
Zu feste Bindung an einen Provider,
Skepsis bei Performance und Latenz,
Höhere Kosten bei Public Cloud-Nutzung.

Datenhoheit

Die Bank möchte Daten im eigenen Rechenzentrum oder zumindest im eigenen Heimatland halten.

Public Cloud Provider wie Microsoft Azure erlauben die feingranulare Steuerung, in welchen Rechenzentren IT-Workloads und auch Backups gehostet werden. Eine Eingrenzung auf die Europäische Union oder nur Deutschland ist ohne (wesentliche) Einschränkungen möglich.

Das eigene Rechenzentrum bietet heute keine wirklichen Sicherheitsvorteile gegenüber den auf höchster Stufe abgesicherten Public Cloud Rechenzentren. Hier kommen Skaleneffekte voll zum Tragen, da die Sicherheitsfunktionen sehr homogen für eine Vielzahl gleichartiger Rechenzentren erbracht werden können.

Entscheidend für die Datenhoheit sowohl im eigenen Rechenzentrum wie in der Public Cloud ist nicht die physische Kontrolle, sondern die korrekte Anwendung der Konfiguration der vorhandenen virtuellen Sicherheitsinstrumente – und hier sind die Angebote in der Azure Cloud umfangreicher als alle eigenen Werkzeuge.

Die Steuerung der Zugriffsmöglichkeiten und Verschlüsselungsmechanismen aller Daten, sowohl in Ruhe wie in Transit und Betrieb, sind vollumfänglich gegeben und müssen nur konsequent genutzt werden.

Zu feste Bindung an einen Provider

Oft wird mit einem „Vendor lock-in“ argumentiert. Hierbei sollten zwei wesentliche Cloud-Bereiche unterschieden werden:

Die Bereitstellung von Rechen- und Speicherleistung als Infrastructure-as-a-Service,
Die Verwendung fortgeschrittener Werkzeuge.

1. Die Bereitstellung von Rechen- und Speicherleistung als Infrastructure-as-a-Service

Virtuelle Maschinen und noch mehr Container u.ä. sind hochgradig standardisiert und können mit professionellen Tools relativ leicht zwischen On-Premise- und mehreren Cloud-Installationen verschoben werden. Der wesentliche „Lock-in“ ergibt sich hierbei zumeist durch die Kosten (und ggf. Dauer) der notwendigen Datentransfers. Hierbei werden oftmals Datentransfers in eine Public Cloud günstig oder kostenlos angeboten, während die Übermittlungen aus der jeweiligen Cloud heraus (oft prohibitiv) teuer sind. Dies sollten Banken vor der jeweiligen Cloud-Entscheidung eruieren und ggf. auch vertraglich absichern.

Während die Datentransfers für die Workloads selbst meist noch überschaubar groß sind, können die Volumina historisch aufzubewahrender Daten, beispielsweise von Dokumentenverwaltungen, tatsächlich zu einem faktischen Vendor-Lock-in führen. Dies gilt aber genauso bei (den oftmals beträchtlichen) Investitionen für eigene dedizierte Hardware und Software solcher Systeme.

2-Die Verwendung fortgeschrittener Werkzeuge

Verwendet man die oft extrem leistungsfähigen Werkezuge von Microsoft Azure wie proprietäre (ggf. Verteilte) Datenbanken, Funktionen für Serverless Computing oder künstliche Intelligenz, ergibt sich ein ähnlicher Lock-in, wie er seit Jahrzehnten bei der Bindung an z.B. Oracle oder DB2 Datenbanken in der klassischen IT auftritt. Andere Cloud Provider bieten zwar meist vergleichbare Funktionalitäten, aber eben nicht immer interoperabel.

Skepsis bei Performance und Latenz

Bedenken hinsichtlich der Leistung und Latenz von Cloud Infrastruktur haben sich in den vergangenen Jahren als nicht gerechtfertigt erwiesen. Einzig Latenzprobleme zwischen eigenen oder angemieteten Bankrechenzentren fernab der Cloud-Rechenzentren sind zu betrachten. Dies ist aber eine Problematik, die für jede Verteilung von Rechenleistung über mehrere weiter voneinander entfernte Standorte gilt – und diesunabhängig vom Public Cloud-Einsatz. Public Cloud ist an wichtige Internetknoten weltweit optimal angebunden.

Höhere Kosten bei Public Cloud-Nutzung

Hier wäre eine eindeutige Aussage vermessen. Für die Public Cloud Pricing-Modelle gilt: Höhere Flexibilität zieht höhere Kosten nach sich.Allerdings verfügen Banken – mit ihren in weiten Teilen anhand von Vergangenheitswerten gut vorhersagbaren Lastverteilungen und wenig saisonalem Geschäft – über gute Voraussetzungen, ihre Kosten für das Tagesgeschäft gut zu planen, was die ideale Voraussetzung für günstigere Preise auch in der Cloud darstellt.

Für Spitzen z.B. aus Kampagnen oder neuen Projekten überwiegen die Cloud-Vorteile in Sachen. Flexibilität eventuelle Kostenvorteile eigener Rechenzentren bei Standard-Lasten.

Außerdem sind die großen Cloud Provider mittlerweile die global größten Server-Hardware-Kunden und ihre Rechenzentren die am besten optimierte und automatisierte IT-Infrastruktur. Für die Zukunft ist also nicht zu erwarten, dass dedizierte Rechenzentren selbst großer Banken in der Lage sind, den Kostenvorsprung der Cloud Provider trotz deren zusätzlicher Margen zu kompensieren.

Daher sehe ich langfristig nur für einzelne Spezialfälle potenziell größere Kostennachteile von Public Cloud-Infrastruktur.

Argumente für eine Cloud-Migration

Das bekannteste Argument pro Public Cloud ist interessanterweise komplementär zum vorherigen Gegenargument:

Kostenvorteile bei Public Cloud-Nutzung,
Skalierbarkeit und Flexibilität,
Künstliche Intelligenz, Analytics und Migrationswerkzeuge,
Künstliche Intelligenz, Analytics und Migrationswerkzeuge.

Kostenvorteile bei Public Cloud-Nutzung

Verschiedene oftmals von Microsoft und anderen Public Cloud-Anbietern in Auftrag gegebene Studien führen Gesamtkostenvorteile (TCO – Total Cost of Ownership) von bis über 70 Prozent gegenüber traditioneller IT-Infrastruktur an. Dieses Argument allein bedang in der Vergangenheit zahlreiche strategische Überlegungen und Entscheidungen bezüglich Public Cloud – und auch Enttäuschungen !

Diese TCO-Vorteile sind in den beschriebenen Szenarien korrekt, aber beziehen sich eben nicht auf die reinen Rechenleistung-Kosten, sondern etwa auf Vorteile, die sich aus besonders hoher und effizienter Automation in bestimmten Cloud-Anwendungsszenarien ergeben. Daher sollte man solche extremen Kostenvorteile nicht als wesentliche Argumentationsgrundlage verwenden.

Im Allgemeinen empfiehlt es sich, besonders für sehr große (und regelmäßige) Workloads die unterschiedlichen Pricing-Optionen der Public Cloud Provider besonders genau zu betrachten und auch längerfristige Bindung in Erwägung zu ziehen, um zum dedizierten Betrieb vergleichbare Kosten zu erreichen.

Skalierbarkeit und Flexibilität

Mit der regelmäßigen Virtualisierung der Workloads auch in den Bank-Rechenzentren hat sich der Cloud-Vorteil hier deutlich relativiert – vorausgesetzt, die Bank-IT hat hier wirklich alle möglichen Potenziale. Vorteile bezüglich möglicher verteilter Standorte innerhalb der EU und noch besserer Automatisierung in der Cloud bleiben jedoch sicher bestehen.

Die weitere Industrialisierung und Standardisierung der IT durch die steigende Verbreitung der Public Clouds lässt sich sehr gut mit der Automobilindustrie (Manufaktur vs. Fließband) vergleichen. Der Vorsprung der Public Clouds wird sich hier zukünftig sicher noch vegrößern.

Künstliche Intelligenz, Analytics und Migrationswerkzeuge

Zahlreiche in den großen Public Clouds verfügbare Werkzeuge und Anwendungsszenarien sind für den Einsatz im eigenen dedizierten Rechenzentrum nicht verfügbar oder nur mit unverhältnismäßigem Aufwand darstellbar. Langfristig wird sich auch die Verfügbarkeit von qualifiziertem Personal für hochgradig standardisierte Lösungen auf globalen Plattformen und gerade bei Hochschulabsolventen höher angesehenen Technologien im Cloud-Bereich besser entwickeln als für dedizierte Lösungen.

In der Wirtschaftsgeschichte seit der Industriellen Revolution haben sich langfristig immer die universelleren und besser skalierenden Lösungen durchgesetzt, selbst wenn Speziallösungen in ihren Nischen weiter existieren. Klar ist jedoch, dass Banken weniger technische Speziallösungen als fachliche Alleinstellungsmerkmale auf Basis flexibler Standard-Technologie für ihre weitere Entwicklung benötigen.

Letztendlich bedingt der schiere Erfolg der großen Public Cloud Provider weiteren Erfolg – eben, weil es immer mehr Cloud-Anwender gibt, werden immer mehr Werkzeuge für automatisierte Migration und Betrieb geschaffen sowie Kapazitäten für deren Nutzung bei den großen unabhängigen IT Service Providern und Beratungshäusern aufgebaut.

Es existieren erfahrene Teams für die strategische Planung sowie für die Fabrik-organisierte Migration selbst komplexer alter Mainframe-Umgebungen in die Cloud und den hoch-automatisierten sicheren Betrieb von Cloud-Umgebungen.

Die hauseigene Bank-IT kann sich wieder auf die wertschöpfende fachlich getriebene IT-Entwicklung fokussieren – die in den letzten Jahren zugunsten des Betriebs der immer komplexeren eigenen Rechenzentren oft vernachlässigt werden musste.

Da bei den meisten Banken in Deutschland ein umfangreiches Portfolio von Microsoft-Produkten im Einsatz ist, bietet die Azure Cloud oftmals besonders einfache Migrationspfade und Optimierungspotential etwa bei den Lizenzkosten.

Fazit: Spezialwissen für Poitentialausschöpfung

Für erfolgreiche Public Cloud-Planung und -Einsatz ist oftmals Spezialistenwissen erforderlich, aber auch verfügbar. Jeder Einzelfall sollte aber mit den richtigen Spezialisten zusammen betrachtet werden, um wirklich das wahre Potential auszuschöpfen und Kostenfallen oder technologische Einbahnstraßen zu vermeiden.