Standard-Cloud-Dienste: Kategorie unbedenklich

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.

Kategorien weicher und harter Vendor Lock-in

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.

Harter Vendor Lock-in: Strategien 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.