Cloud-Architektur: Das 1x1 zum Umgang mit drohendem Vendor Lock-in

Wer sein Business in eine gut organisierte Cloud-Architektur einbindet, senkt nicht nur die Kosten, sondern steigert auch Effizienz, Flexibilität und Geschwindigkeit. Neueste Technologien und innovative Services sind über Cloud Service Provider (CSP) einfach zugänglich, Kapazitäten sind nach Bedarf skalierbar, eigene IT-Ressourcen bleiben überschaubar. Über zentrale Monitoring- und Management-Tools bieten große Public-Cloud-Anbieter ein hohes Maß an Transparenz und Compliance.

Auch Security-Vorgaben lassen sich oft leichter umsetzen als im eigenen Rechenzentrum. Finanzdienstleister können sich so stärker auf ihr Kerngeschäft konzentrieren, die Time-to-Market verkürzen und die Rentabilität verbessern. Damit wird die IT zum Wegbereiter für bisher nicht realisierbare Projekte.

Tatsächlich geht es bei der Nutzung eines CSP um ein ganzes Universum an Services und Schnittstellen, das rapide wächst und sich von Anbieter zu Anbieter erheblich unterscheidet. Das hat zwei Herausforderungen zur Folge: Zum einen ist die Portierung eines Service von einem Anbieter zu einem anderen nicht einfach – es sei denn, es handelt sich um De-facto-Standardservices aus dem Open-Source-Bereich. Zweitens entsteht als Folge davon schnell eine Abhängigkeit von einem einzigen Anbieter, da alternative Angebote fehlen oder sich nicht ohne erheblichen Aufwand umsetzen bzw. ersetzen lassen.

Ein solcher Vendor Lock-in ist kein wünschenswerter Zustand; unter anderem für Finanzdienstleister schreibt der Gesetzgeber sogar eine klare Exit-Strategie vor. Ihr Ziel ist der Anbieterwechsel auf Knopfdruck: Im Idealfall werden nur noch die Daten zum neuen Anbieter migriert.

Jedes Unternehmen will aus den Angeboten der Provider den größtmöglichen Nutzen herausholen – ohne sich zu sehr auf einen Anbieter zu fokussieren. Für regulierte Unternehmen wie Finanzdienstleister beginnt die Reise in die Cloud pflichtgemäß mit der Erarbeitung einer Exit-Strategie – also Überlegungen dazu, wie im Ernstfall eines CSP-Ausfalls gehandelt werden soll. Diese Anforderung ergibt sich aus der Regulatorik. Denn auch ein aktuell boomender CSP kann einmal vom Markt verschwinden oder Services kündigen. Nicht zuletzt können Risiken oder wirtschaftliche Gründe einen Ausstieg erforderlich machen, beispielsweise wenn der CSP eine Änderung am Preismodell vornimmt oder die Risiken nicht mehr akzeptabel sind.

Um im eigenen Unternehmen Transparenz zu schaffen, welche Cloud Services unbedenklich nutzbar sind, sollten diese unter Berücksichtigung des Risikos für einen Vendor Lock-in kategorisiert werden. Als Grundlage für die Bewertung von „unbedenklich“ über „weicher Vendor Lock-in“ bis „harter Vendor Lock-in“ eignen sich beispielsweise die Architekturprinzipien der Open Group. Dazu zählen unter anderem der unternehmerische Vorteil, der mit dem Service erzielbar ist, die Portabilität, die Kontrolle technologischer Diversität, Datensicherheit und -schutz, die Vereinbarkeit mit dem Gesetz und geltender Regulatorik sowie Security-Aspekte.

Insgesamt betrachtet rückt das Ziel der „Service-Portierung auf Knopfdruck“ immer näher und erfährt starke Unterstützung durch die wachsenden Angebote generischer Pipeline-Automatisierung (Continuous Integration, Continuous Delivery, Continuous Deployment – CI/CD). Durch Automatisierung können Abstraktionsebenen geschaffen werden, die einen Wechsel zwischen den Anbietern erleichtern und einen wichtigen Bestandteil einer umfassenden Cloud-Strategie darstellen. Unternehmen, die ihre Cloud-Adaption vorantreiben, sollten das Thema CI/CD unbedingt auf der Agenda haben.

Eine Multi-Cloud-/Hybrid-Cloud-Strategie eignet sich also nur bedingt als Standardverfahren gegen einen Vendor Lock-in. Wirklich Sinn macht sie nur, wenn eine Anwendung gleichzeitig über mehrere Provider betrieben wird. Denn das zwingt dazu, in möglichst vielen Funktionsbereichen nach generischen und portablen Lösungen zu suchen, die bei allen gewählten Anbietern laufen. Der Aufwand ist groß – deshalb sollte dieses Modell nur sehr gezielt eingesetzt werden.

Der Weg zur passenden Cloud-Strategie und -Architektur erfordert unternehmerischen Weitblick, umfangreiche Kenntnis der Angebote am Markt, eine genaue Bewertung zahlreicher Technik- und Business-Faktoren und ein gut funktionierendes Risikomanagement. Wer ausschließlich auf Standarddienste setzt, verliert schnell den Anschluss an den Wettbewerb oder schließt sich selbst von Wettbewerbsvorteilen aus. Die Kunst ist ein passgenauer Mix aus Standard- und Exklusiv-Angeboten, ausgerollt in einer Single-, Multi- oder/und Hybrid-Cloud-Umgebung.

Recht einfach lassen sich die unbedenklichen Standard-Cloud-Dienste identifizieren, die meist aus dem großen Pool professioneller Open Source Services stammen. Dank des öffentlichen Zugangs zu diesen Technologien und ihres inzwischen fortgeschrittenen Reifegrads sind diese Services bei Cloud Providern weit verbreitet. Die Technologie ist bei vielen Anbietern als vollständig verwalteter Dienst (fully-managed) verfügbar und lässt sich sogar im eigenen Rechenzentrum nutzen. Durch die konsistente Schnittstelle der Technologie und ihrer Artgenossen wird eine architekturelle Portierbarkeit erreicht – und somit auch eine Unabhängigkeit vom Cloud-Anbieter. Weitere bekannte Beispiele sind PostgreSQL (relationale Datenbank) oder Kafka (Distributed Streaming Plattform). Bei der Wahl eines Cloud Providers zählen diese Services für viele Kunden inzwischen zum Pflichtrepertoire, da sie wichtige Basisfunktionalitäten bieten und den Kunden so Flexibilität in der Anbieterwahl ermöglichen.

Diese Open Source Services lassen sich auf mehrere Arten nutzen: direkt vom CSP oder von einem Sub-Provider auf der Infrastruktur des Zielproviders als vollständig verwalteter Service, in Eigenregie des Unternehmens beim CSP oder auf eigener Infrastruktur des Unternehmens. Um größere Vorteile aus der Cloud-Nutzung zu ziehen, ist es für Unternehmen ratsam, die Services vollständig verwaltet zu buchen. Das spart eigene Ressourcen für Betrieb und Verwaltung und neue Technologien lassen sich schneller adaptieren und für eigene Innovationen nutzen.

Zur Kategorie der unbedenklichen Dienste zählen auch solche, die bereits im eigenen virtualisierten Rechenzentrum containerisiert und getestet wurden. Auch sie sind ohne Probleme in Public Clouds auf eine passende Infrastruktur, wie zum Beispiel Kubernetes, verschiebbar. Der große Vorteil ist die dynamische Skalierbarkeit, wodurch sich Lastspitzen besser abdecken und Kosten optimieren lassen. Als Exit-Alternativen stehen beliebige andere CSPs zur Verfügung. Eine Abhängigkeit ergibt sich lediglich bei der Wahl der Infrastructure-as-a-Service-Lösung (IaaS). Doch auch hier stellen viele Anbieter inzwischen ähnliche Funktionalitäten zur Verfügung; zudem lässt das IaaS-Modell den Nutzern grundsätzlich große Freiheit.

Wenn der Exit so einfach umzusetzen ist, warum nicht gleich durchgängig auf Open Source und eigene Container setzen? Der Gedanke scheint verlockend und bietet Vorteile. Leider geht dieser Ansatz oft an der Realität vorbei. In vielen Fällen wäre es unklug, wertvolle Wettbewerbsvorteile liegen zu lassen, die nur Services bieten, die (noch) nicht zum Standard gehören und die Provider gerne als Sahnestückchen anbieten.

Deswegen ist eine Cloud-Strategie, die ausschließlich auf Open Source Services basiert, nur in wenigen Ausnahmefällen sinnvoll. Ganz unbedenklich ist sie zudem nicht, denn es besteht die Gefahr, die Abhängigkeit von einem Anbieter durch die Abhängigkeit von einer bestimmten Open-Source-Technologie zu tauschen. Für das Fortbestehen von Open-Source-Projekten gibt es keine Garantie, da sie stark von der Aktivität der Community abhängen. Dieser Aspekt sollte nicht unterschätzt und im Rahmen des Architekturmanagements betrachtet werden.

Beim weichen Vendor Lock-in bieten andere CSPs die entsprechende Funktionalität ebenfalls an, allerdings mit anderen Schnittstellen. In der Applikation sind daher umfangreichere Anpassungen vorzunehmen. Ein Providerwechsel ist also möglich, erfordert jedoch einen gewissen Aufwand.

Die größte Herausforderung ist ein harter Vendor Lock-in. Für Services aus dieser Kategorie steht bei keinem anderen Anbieter adäquater Ersatz zur Verfügung. Doch gerade diese Services machen einen Anbieter oftmals besonders attraktiv, da kein anderer vergleichbares im Portfolio hat. Auch hier gibt es Wege aus der Abhängigkeit.

Eine Alternative zu einem harten Vendor Lock-in bietet die Eigenentwicklung. In der Regel ist sie jedoch mit hohem Aufwand verbunden, da die zu ersetzenden Services durch innovative Alleinstellungsmerkmale bestechen. Diese Innovationskraft selbst aufzubringen, erfordert exzellente Entwicklungsressourcen und eine geeignete Infrastruktur. Das würde jedoch zu hohen Kosten führen und wäre in der Praxis nur schwer umzusetzen. Auch wenn der Weg die größtmögliche Kontrolle verspricht, muss vorher eindeutig geklärt werden, ob er sich lohnt und welche Dienstleister hinzugezogen werden sollten.

Etwas komfortabler ist die zweite Variante: Ein anderer Anbieter hat einen funktional ähnlichen Service im Portfolio, aber mit anderen Schnittstellen. Gängig ist hier der Einsatz von Interfaces bzw. sogenannten Connector Services zur Abstraktion der Schnittstellen für die eigene Software. Durch die Abstraktion der Anbieterprogrammierschnittstelle (Application Programming Interface – API) erfolgt eine Entkopplung vom CSP, was die Anbindung eines neuen Anbieters an die eigene Software erleichtern kann. Bei korrekter Implementierung müssen Änderungen nur an einer Stelle ausgeführt werden. Was nach einem perfekten Exit klingt, ist mit Vorsicht zu genießen, da durch die Abstraktionsebene nicht selten die spezifischen Vorteile des ursprünglichen Service verloren gehen.

Eine dritte Möglichkeit, einem harten Vendor Lock-in entgegenzuwirken, ist der simultane Einsatz mehrerer CSPs – eventuell unter Einbindung des eigenen Rechenzentrums. Verfolgt ein Unternehmen von Anfang an konsequent das Ziel, Anwendungen unabhängig vom Anbieter bereitstellen zu können, kann der Lock-in abgemildert werden. Allerdings ist die Komplexität von Applikationen, die verteilt über mehrere CSPs ausgeführt werden, nicht zu unterschätzen. Dieses Modell eignet sich in der Regel nur für Anwendungen, die Anforderungen an regionale Verfügbarkeiten oder an anbieterübergreifende Redundanzen haben. Bei einer solchen Multi-Cloud-/Hybrid-Cloud-Strategie ist Vorsicht geboten: Sie fördert nicht zwingend die eigene Unabhängigkeit. Denn wer bei mehreren Providern einen Exklusiv-Service bucht, begibt sich im schlimmsten Fall gleich bei mehreren in einen harten Vendor Lock-in. Außerdem wird die eigene IT-Umgebung erheblich komplexer.

Es ist aktuell der Trend zu beobachten, dass einschlägige CSPs vermehrt mit eigenen Tools werben, die ein einheitliches Cloud-Management über alle Anbieter hinweg versprechen. Auch hierbei besteht das Risiko der Abhängigkeit: Kommt es zum Exit von einem Anbieter A, von dem aus ein Unternehmen Ressourcen bei einem Anbieter B und C verwaltet, betrifft der Exit von Anbieter A direkt die Ressourcen bei den anderen beiden. Es ist durchaus möglich, dass ein Exit dann eine Neuprovisionierung der gesamten Infrastruktur bei den anderen Anbietern zur Folge hat.