Vendor Lock-in? So stellen sich FSI mit einem Cloud-provider-agnostic-Ansatz unabhängig und flexibel auf

Die Cloud heute als die technologische Grundlage der digitalen Zukunft der Finanzbranche zu bezeichnen, ist längst keine gewagte These mehr. Im September 2021 sprach sich der Bundesverband deutscher Banken e.V. für eine „verantwortungsbewusste und technologieneutrale“ Verwendung von Cloud-Lösungen aus. Doch die Branche ist mehr denn je gefangen zwischen einem Sicherheit- und Wachstumsbedürfnis. Während bereits 70 Prozent der Finanzdienstleister Cloud Services einsetzen, lässt sich dennoch beobachten, wie zögerlich die Institute bei ihrer cloud-native Transformation sind. Wenn es um die Evolution von Anwendungen hin zu cloud-native Prinzipien geht, bleibt hier bislang viel Potenzial ungenutzt.

von Christian Hüning, Director of Technology Cloud & Uwe Sandner, CTO finleap connect

Benötigt werden Cloud-Umgebungen, die eine schnelle und flexible Bereitstellung neuer Services erlauben, gleichzeitig müssen die hochsensiblen Daten selbstverständlich sicher, dynamisch und rechtskonform verarbeitet werden. Die richtige Cloud-Strategie in Zeiten von Open Banking, verstärkter Internationalisierung und gleichzeitig wachsenden Cyberrisiken zu finden, stellt IT-Entscheider zahlreicher Finanzinstitute vor eine Herausforderung. Ob „all in Cloud-Provider integration“ oder Cloud-provider-agnostic Ansatz, gesucht werden geeignete Wege, ihre Workloads sicher und skalierbar in Cloud-Umgebungen zu betreiben. Doch welcher ist der richtige Weg und viel wichtiger: wie gelingt die Umsetzung?

Cloud-native: skalierbare Anwendungen in modernen Cloud-Umgebungen

Beim cloud-native Ansatz werden die Applikationen bereits von Anfang an für den Einsatz in der Cloud konzipiert. Eine Anwendung wird als „nativ“ bezeichnet, wenn sie modernen Designprinzipien wie 12-Factor und Beyond 12 Factor folgt. Das Ergebnis sind dann Native-Cloud-Applikationen, die die Stärken der Cloud-Computing-Architektur vollständig nutzen und auf einer kombinierten Nutzung dreier grundlegender Technologien basieren:

Computational Grids, Data grids und der automatischen Skalierung innerhalb einer verwalteten Infrastruktur.”

Dadurch ermöglicht es dieser Ansatz, skalierbare Anwendungen in modernen Cloud-Umgebungen zu realisieren. Seine wesentlichen Komponenten sind Microservices und Container-Technologien. Microservices ermöglichen durch ihre unabhängige Entwicklung, die sich auf Schnittstellen stützt, über cloud-native Prinzipien enorme Skalierbarkeit und Agilität.

Die Container bieten eine höhere Effizienz und vereinfachen das Deployment vieler verschiedener Microservices, dank der Vereinheitlichung von Applikationen/Services auf diversen Plattformen bzw. Umgebungen.”

Googles Container-Orchestrations-System Kubernetes hat sich zum Standard in der Branche entwickelt. Es demonstrierte, wie man Applikationen, Services und Produkte in einem Cloud-Umfeld betreiben, verwalten und warten kann. Die lose gekoppelten Systeme sorgen für erhöhte Flexibilität, Resilienz gegenüber Fehlern, Zuverlässigkeit, Ausfallsicherheit, Observability, ein passendes Preis-Leistungs-Verhältnis und Sicherheit. Die Vorteile des Gesamtsystems sind die hohe Verfügbarkeit, die optimale Nutzung vorhandener Computing- und Speicherressourcen und die flexible Skalierbarkeit.

Abhängigkeit statt Flexibilität? Der Vendor Lock-in

Die meisten Finanzinstitutionen setzen auf große Provider wie AWS, Google oder Microsoft, wenn es um ihre Cloud-Transformation geht. Dadurch hat sich ein irreführendes Verständnis entwickelt, das den cloud-native Ansatz gleichsetzt mit der möglichst umfangreichen Nutzung zahlreicher Dienste eines Public Cloud Providers (all in Cloud-Provider Integration) und der Auslagerung von Services wie Datenbanken an den Provider.

Besinnt man sich allerdings auf die ursprüngliche Definition der Cloud Native Computing Foundation (CNCF), meint cloud-native originär lediglich den Einsatz von Technologien und Techniken, um die entsprechenden Fähigkeiten für die eigenen Produkte zu erlangen:

Cloud-native Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und hybriden Clouds zu erstellen und auszuführen. Container, Service-Meshes, Microservices, unveränderliche Infrastruktur und deklarative APIs sind Beispiele für diesen Ansatz.“^[1]

Auch in der Private Cloud, in Hybrid-Cloud Modellen oder bei regionalen Hostern lassen sich cloud-native Infrastrukturen umsetzen und nach denselben Prinzipien nutzen.

Das stark eingeschränkte Verständnis von cloud-native Ansätzen gilt es zu hinterfragen. Denn der strenge Fokus auf die genannten Cloudprovider führt vor allem zu einem wesentlichen Kritikpunkt in Hinblick auf die Nutzung proprietärer Dienste für z.B. Datenbanken, Queuing Systeme: die starke Bindung an einen einzigen Cloudprovider.

Sobald eine Anwendung nativ an die Services eines Providers angebunden ist, entsteht eine Abhängigkeit zu eben diesem Provider und damit der viel zitierte „Vendor Lock-in“. Als Gegenargument wird häufig angebracht, dass man eine SQL Datenbank oder ein Queuing System bei jedem Cloudprovider bekommt und ein Wechsel durchaus möglich sei und daher kein Lock-in entstünde.”

Doch in jeder Umgebung, die sich hinreichend in Produktion befindet und entsprechend historisch gewachsen ist, stimmt diese Annahme nicht mehr. Implizite Integrationen und Annahmen über Subsysteme des jeweiligen Anbieters lassen sich selten vermeiden und sind noch seltener hinreichend bekannt oder dokumentiert.

Diese Schwierigkeit ist in der Finanzbranche relevant. Vor dem Hintergrund des Open Banking Trends, den zunehmenden Kooperation von Finanzinstituten, Non Financials und FinTechs und der Internationalisierung von Produkten ist diese starke Abhängigkeit zunehmend problematisch. Auch vor dem Hintergrund aktueller Ereignisse und zunehmender Cyberattacken und bekanntgewordener Datenlecks ist die Frage nach Standort und Sicherheit der Daten entscheidender denn je. Drängende Fragen wie: „Akzeptieren meine Kunden meinen Cloud-Provider als Sub-Vendor? Und wie leicht ist eine Migration zu einem anderen Provider, wenn in bestimmten Regionen Einschränkungen vorliegen?“ könnten dank des Cloud-provider-agnostic-Ansatzes hingegen der Vergangenheit angehören.

Der Cloud-provider-agnostic-Ansatz: einheitliche Cloudservices über Ländergrenzen unabhängig vom Provider

Eine Cloud-Provider-agnostische Strategie kann einen flexiblen und unabhängigen Lösungsansatz bieten. Sie folgt dem Gedanken, die eingesetzten Technologien so auszuwählen, dass sie auf einem gemeinsamen Fundament lauffähig sind, welches sich bei einer Vielzahl von Cloud-Providern abbilden lässt.

Kombiniert man cloud-native mit Cloud-provider-agnostic Ansätzen, kann Kubernetes das gemeinsame Fundament darstellen.”

Im ersten Schritt muss geklärt werden, wie Kubernetes und dafür notwendige Basisdienste wie Compute & Storage auf verschiedenen Providern umgesetzt werden können. Public Cloud Provider bieten dafür zwar „managed Kubernetes Lösung” an, doch ihnen mangelt es eindeutig an Uniformität und Standardisierung. Derzeit unterscheiden sich alle leicht in ihrer Funktionsweise, was die praktische Implementierung erschwert.

Dem entgegen wirkt als Open Source Projekt die SAP Gardener-Lösung. Mit dem Ziel, weltweit auf einheitliche Art und Weise uniforme Kubernetes Cluster zu provisionieren und zu managen, abstrahiert sie die Unterschiede und löst das Problem der variierenden Anforderungen verschiedener Provider. Neben der Unterstützung, die diese Lösung für die großen Anbieter (GCP, AWS, Azure, Alibaba) bietet, existieren für SAP Gardener bereits Integrationen für regionale Anbieter wie Hetzner oder Lösungen wie Openstack und VMWare zur Verfügung. Mit Kubernetes als einheitlichem Fundament ist es möglich, aus den mittlerweile vielfältigen Angeboten für – auf Kubernetes lauffähigen – Diensten zu wählen. Eine Übersicht bietet die Cloud Native Landscape der CNCF.

Neben den reinen Betriebsfähigkeiten für Container und Datenbanken stellen sich häufig viele Metafragen nach Authentifizierung, Autorisierung, Secrets Management und Verschlüsselung.

Ebenfalls nicht vendor-spezifische Produkte und Projekte wie Hashicorp Vault (Secrets Management), Service Meshes wie Linkerd (mTLS Encryption in Transit) oder multi-cloud/multi-cluster fähige Permission Management Lösungen wie Monoskope oder loft.sh leisten hier in Kombination mit zentralen IAMs (z.B. OneLogin) die notwendigen Dienste, um in diesen Bereichen beweglich und unabhängig von den großen Cloud Providern zu bleiben.

Mit dem Cloud-provider-agnostic Ansatz ist es möglich, eine Vielzahl an Providern zu nutzen (Google, AWS, Azure, Alibaba, Private Clouds via VMWare, Openstack und viele mehr).

Diese Möglichkeit wird für Finanzinstitute vor allem dann relevant, wenn sie ihre Lösungen und Produkte in einer Region auf den Markt bringen möchten, wo es nur einen Provider gibt.”

Hier kommt der weiter oben besprochene Vorteil der weltweiten Vereinheitlichung zum Tragen: SAP Gardener abstrahiert die Spezialitäten der jeweiligen Zielplattformen, mit dem Ergebnis einer einheitlichen Kubernetes Cluster-Lösung, die für die Anwender gleich aussieht. Egal welches Land und welcher Provider, Nutzer haben dieselbe Netzwerklösung und Storage-Abstraktion und können sich darauf verlassen, dass ihre Workloads darauf funktionieren.

Darin zeigt sich der tiefere Sinn und Vorteil der Cloud-Agnostizität: Alle Workflows bzw. der gesamte Tech-Stack kann in Kubernetes mit Containern umgesetzt werden. Wird dies konsequent verfolgt, wird eine komplette Flexibilität geschaffen. Ein Provider-Wechsel ist einfach umzusetzen, denn im Grunde müssen nur die Daten umgezogen werden.

Fazit: Die Umsetzung einer Cloud-provider-agnostic-Lösung ist aufwändig aber lohnenswert

Sieht sich ein FinTech-Unternehmen mit der Aufgabe konfrontiert, eine Anwendung gemäß Cloud-provider-agnostic zu implementieren, sind Uniformität und Standardisierung unerlässlich. Dafür ist eine IT-Strategie nötig, die darauf abzielt, dass Entwickler ausschließlich ausgesuchte Werkzeuge und nur bestimmte Programmiersprachen nutzen. Das alles bindet Zeit und vor allem erfordert es Personal, das gewillt ist, tief einzusteigen. Ist die Umstellung aber erst geschafft, ist dieses Vorgehen nachhaltiger. Unternehmen, die diese Transformation anschieben wollen, stehen nicht allein da: In diesem Umfeld tummeln sich bereits viele kleine Player und im Open-Source-Feld lockt eine aktive Community, die sich ein beachtliches Schwarmwissen aufgebaut hat.Christian Hüning, Director of Technology Cloud & Uwe Sandner, CTO finleap connect

 ^[1] „Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.“