Kunden, die in die Cloud wechseln möchten, äußern immer noch Bedenken bezüglich der “Anbieterbindung”. Diese reichen von allgemeinen “Eier in einem Korb”-Bedenken bis hin zu spezifischen Bedenken hinsichtlich der Ausfallsicherheit von Diensten und der DR-Sicherheit des Unternehmens. Unternehmen äußern die Befürchtung, dass es schwierig und kostspielig sein würde, wieder auszusteigen, wenn sie einmal “drin” sind.
Gilt dies speziell für die Cloud?
Die Abhängigkeit von einem einzigen Service-Provider ist nicht neu. Unternehmen, die in die Cloud migrieren wollen, ziehen (im Allgemeinen) von einem verwalteten Rechenzentrum um. Normalerweise wird die Hardware (und ein Großteil der Software) vom Rechenzentrumsanbieter geleast. Die Ausfallsicherheit wird durch eine zusätzliche Rechenzentrumspräsenz des gleichen Dienstleisters realisiert. Die Verträge haben in der Regel eine feste Laufzeit von drei, fünf oder zehn Jahren. Capacity Right-Sizing ist möglich, aber oft gibt es Überkapazitäten in der Plattform. In der Regel wird es als betrieblich unkomplizierter und kostengünstiger angesehen, einen Rechenzentrumsanbieter für alles zu nutzen. Die Migration von einem Rechenzentrumsanbieter zu einem anderen wäre ein großes Projekt, das alle Risiken und Kosten einer groß angelegten Infrastruktur-Änderung mit sich bringt. Die Bindung an einen Anbieter ist ein Dauerbrenner und nicht nur bei Cloud-Implementierungen ein Thema. Für Unternehmen bleibt das Problem bestehen, unabhängig vom Service-Provider – wohin mit einer groß angelegten Infrastrukturplattform?
Cloud-Plattformen bieten mehr Flexibilität als traditionelle Rechenzentrumsdienste.
- Die Möglichkeit, zusätzliche Kapazität nach Bedarf bereitzustellen.
- Keine langfristigen Vertragsanforderungen (reservierte Kapazität ist eine gute Kostenmanagement-Praxis, keine vertragliche Anforderung).
- Es gibt keine vertragliche Bindung.
Die technische Bindung ist jedoch eine berechtigte Sorge. Plattformen, die meist auf IaaS-Ressourcen aufgebaut sind, können als “tragbarer” angesehen werden. Bereitstellungs- und Konfigurationsmanagement-Tools wie Terraform und Ansible bieten eine Abstraktionsebene zwischen der zugrunde liegenden Infrastruktur und den Anwendungen. Die umfassenderen Vorteile von Cloud-Diensten – reduzierter betrieblicher Aufwand, die Möglichkeit, neue Dienste zu entwickeln und die Nutzung am effektivsten an die Kapazität anzupassen – werden jedoch realisiert, wenn man sich von “traditionellen” serverbasierten Architekturen wegbewegt und PaaS-, SaaS- und FaaS-Dienste nutzt. Je Cloud-nativer die Dienste sind, die in einer Plattform verwendet werden (d. h. weg von IaaS und hin zu mehr verwalteten Diensten), desto mehr kann sie als technisch, in einen bestimmten Anbieter eingebettet, angesehen werden.
Lock-in-Abschwächungen
(z. B. Konfigurationsmanagement-Tools, Containerisierung, lose Kopplung zwischen Diensten)
Welche Ansätze können verwendet werden, um gegen ein wahrgenommenes Lock-in vorzugehen?
Multi-Cloud-Strategien bieten die Möglichkeit, Dienste entsprechend der besten Eignung zu platzieren und/oder Resilienz über CSPs hinweg zu implementieren. Dies bringt jedoch einen eigenen Verwaltungsaufwand mit sich, einschließlich einer zusätzlichen Schicht von Multi-Cloud-Verwaltungstools von Drittanbietern, um eine einheitliche Sicht auf die Dienste zu ermöglichen. Eine Multi-Cloud-Implementierung erfordert Multi-Cloud-Kenntnisse und Multi-Cloud-Tooling-Konfigurationen, was für kleinere Unternehmen möglicherweise nicht praktikabel ist. Die Reduzierung des betrieblichen Aufwands, die durch verwaltete Ressourcen geboten wird, kann durch den zusätzlichen Aufwand für die Verwaltung von Konfigurationen über mehrere Anbieter hinweg zunichte gemacht werden. Die Implementierung von Service-Resilience über mehrere CSPs hinweg wird wahrscheinlich auch zusätzliche Kosten in Form von doppelten Ressourcen verursachen.
Für Unternehmen, für die eine Multi-Cloud-Präsenz nicht praktikabel ist, welche Ansätze können da eine gewisse Sicherheit gegen Vendor Lock-in bieten?
Die Abstrahierung der Schichten einer Plattform mit Tools wie Terraform und Ansible ermöglicht eine einfachere Modellierung zwischen CSPs. Obwohl sich die Details einer spezifischen Terraform-Konfiguration beispielsweise zwischen AWS und Azure unterscheiden, bleibt die Abstraktionsebene dieselbe. Eine architektonische Sicht auf Anwendungsdienste und Interaktionen, die von einer spezifischen CSP-Implementierung abstrahiert ist, verhindert, dass eine Plattform nur im Hinblick auf CSP-Technologien gesehen wird. Durch die Implementierung von Komponenten, die über Standard-APIs interagieren, kann eine Plattform auf einem anderen CSP modelliert werden. Die Containerisierung bietet ein gewisses Maß an Portabilität, da Docker-Images selbst unabhängig von bestimmten CSP-Diensten sind. Allerdings benötigen containerisierte Anwendungen eine Orchestrierungsschicht; diese kann providerspezifisch (ECS) oder providerunabhängig (Kubernetes) sein. Beide Ansätze fügen eine zusätzliche Schicht für Design und Betrieb hinzu, und eine dekomponierte, containerisierte Architektur ist nicht für alle Anwendungen geeignet.
Eine strategische Analyse der aktuellen und mittelfristigen technischen Anforderungen kann die Ausrichtung auf einen bestimmten CSP vor der Migration klären.
Unternehmen A mag PaaS-Angebote für seine Unternehmensanwendungen bevorzugen; Unternehmen B kann sich auf der Grundlage von verwalteten Container-Plattformen für den Aufbau von mandantenfähigen Diensten entscheiden. Die Anbieter fügen ständig neue Servicefunktionen hinzu, sowohl als Reaktion auf den Wettbewerb als auch auf das Feedback der Kunden. Die realen Preise sind aufgrund von Innovationen und Skaleneffekten gefallen. Es ist sehr unwahrscheinlich, dass ein Unternehmen bei einem bestimmten Cloud-Anbieter in eine “technische Sackgasse” gerät. Für viele Unternehmen ist es sinnvoller, einen Anbieter auszuwählen und die Zeit und den Aufwand auf die Maximierung der Nutzung von Services zu konzentrieren, als Ressourcen für die Entwicklung und den Betrieb von Prozessen zur Vermeidung von Lock-Ins aufzuwenden.
