Wenn sich Unternehmen einmal für den Betrieb geschäftskritischer Anwendungen in der Cloud entschieden haben, wechseln sie in der Regel nur noch ungern den Provider. Sie haben sich auf dessen Ökosystem festgelegt und sind daran gebunden. Die Kosten für einen Wechsel wären einfach zu hoch, sagt Sid Nag, Vice President of Cloud Services and Technology bei Gartner. "Wer gut plant, sollte auch gar nicht in die Verlegenheit kommen, seine Anwendungen verschieben zu müssen", so der Analyst.

Pablo Del Giudice, Partner im Studio für Cloudops und Cybersicherheit beim Dienstleistungsunternehmen Globant, sieht das ähnlich: "Der Schlüssel liegt darin, auf offene Plattformen und Frameworks zu setzen, so dass der Cloud-Anbieter letztendlich nur den Infrastruktur-Layer bereitstellt." Wer diesen Ansatz verfolge, sei zwar mit einer steileren Lernkurve konfrontiert, werde aber langfristig die besseren Ergebnisse bekommen. Der Berater wirbt dafür, einen plattformneutralen Softwarearchitekten um Rat zu fragen, der in der Lage sei, die Grenzen optimal abzustecken und Lösungen zu finden, die möglichst wenig mit den proprietären Diensten bestimmter Anbieter verflochten sind.

Cloud-Dienste zu nutzen heißt, Kompromisse einzugehen

Etwas weniger strikt geht Jamie Holcombe vor, CIO des US Patent and Trademark Office (USPTO): "Bei der Nutzung von Cloud-nativen Diensten einzelner Anbieter sollten Sie sorgfältig abwägen, welche Kompromisse Sie eingehen wollen", rät er. Wer sich konsequent gegen die nativen Services seines Anbieters entscheide, um "agnostisch" zu bleiben, werde am Ende viele der "Besser-Billiger-Schneller-Metriken" verlieren, die für einen Business Case wichtig werden könnten, so Holcombe. Nicht nur die Bindung an einen Provider habe ihren Preis, das gelte für Agnostik genauso.

Globant-Berater Del Giudice sieht drei Varianten der Bindung an einen Cloud-Anbieter.

• Ein Plattform-Lock-in liegt demnach vor, wenn eine vollständige Cloud-Grundkonfiguration (Ressourcengruppierung, Richtlinien, RBAC, hybride Konnektivität, Überwachung, Compliance etc.) vorhanden ist, so dass eine Migration zu einer anderen Plattform schwierig wird. All diese Elemente müssten dort neu erstellt werden, was viel Aufwand und eine hohe Komplexität bedeute.

• Ein architektonisches Lock-in liegt vor, wenn die Anwendung auf mehrere verwaltete Dienste des Cloud-Anbieters angewiesen ist. In diesem Fall müssen Unternehmen ihre Anwendung neu gestalten, bevor sie diese migrieren können.

• Und dann gibt es noch den rechtlichen Lock-in, wenn sich Firmen für einen bestimmten Zeitraum an einen Dienstleistungsvertrag gebunden haben. "Diese Verpflichtungen sind schwer zu kündigen und erschweren eine Migration", sagt Del Giudice.

Auch der Finanzdienstleistungs- und Versicherungskonzern USAA hat sich lange überlegt, welchem der vier Cloud-Anbieter seiner Wahl er jeweils welche Workloads und Geschäftsanwendungen anvertrauen soll. "Wir haben die Provider dann auf diejenigen geschäftlichen und technischen Services festgelegt, die sie aus unserer Sicht am ehesten beherrschen", sagt CTO Jeff Calusinski. Die Multi-Cloud-Strategie basiere auf dem Prinzip "Open by Design". Man verwende wo immer möglich offene Standards und reduziere so ungewollte Abhängigkeiten. Calusinski räumt aber ein, einige nativen Services böten ein solch überzeugendes Wertversprechen, dass dieses gegen die Nachteile eines Lock-in abgewogen werden müsse.

An den Besonderheiten der Cloud-Provider kommt niemand vorbei

Gartner-Mann Nag glaubt ohnehin nicht daran, dass Unternehmen mit offenen Designprinzipien einem Lock-in entgehen könnten. "Selbst wenn man moderne Dienste verwendet, fällt die Implementierung auf jeder Plattform unterschiedlich aus. Amazons EC2-Substrat leistet beispielsweise dasselbe wie Googles GCP, aber eine Anwendung, die auf EC2 läuft, lässt sich nicht ohne teure Nacharbeiten auf GCP ausführen". Und obwohl Kubernetes ein Industriestandard sei, funktionierten Implementierungen wie Azure Communication Services und Google Kubernetes Engine keineswegs identisch.

Del Giudice hält dagegen, dass sich sehr wohl "einige Abstraktions-Layer" herausgebildet hätten, die Migrationen zwischen Cloud-Providern vereinfachen könnten - sogar wenn Anwender native Cloud-Dienste verwenden wollten. "Dienste wie Pub/Sub, Service Invocation, Secrets Management oder State Management abstrahieren die Komponenten der Anwendung unabhängig vom Cloud-Anbieter." Anwender könnten sich mit offenen Standards mehr Optionen offenhalten, auch wenn sie natürlich einige Arbeiten vornehmen müssen, um den Cloud-Anbieter zu wechseln.

Auch bei den Datenanforderungen geht es nicht ohne sorgfältige Planung. Gartner-Analyst Nag beobachtet: "Das Verschieben einer Anwendung in eine andere Cloud ist kostspielig, da auch die zugehörigen Daten verschoben werden müssen. Und das ist eine kostspielige Angelegenheit."

Denken Sie bei der Migration vor allem an Ihre Daten!

Holcombe empfiehlt in diesem Zusammenhang: "Schließen Sie keinen Vertrag mit einem Anbieter ab, wenn Sie nicht wissen, wie Sie Ihre Daten herausbekommen und die jeweiligen Software-Services anderswo replizieren können." Das dürfte allerdings nicht ganz einfach werden, warnt Del Giudice: Obwohl die Anbieter von Cloud-Diensten für sich in Anspruch nähmen, offene Plattformen zu verwenden und auf entsprechende Protokolle für den Datenzugriff wertzulegen, behinderten oft Netzwerkbeschränkungen und Sicherheitslösungen die Migration, beobachtet er.

Gerade hohe Sicherheitsanforderungen verstärkten oft den Lock-in-Effekt, stellt auch Holcombe fest. "Wenn Ihre diesbezüglichen Standards hoch sind, wird eine durchschnittliche Vorgehensweise möglicherweise nicht ausreichen", warnt er. Je spezifischer aber die individuellen Security-Anforderungen ausfielen, desto starrer verhalte sich der jeweilige Service und desto tiefer werde die Anbieterbindung. Zudem sähen sich Unternehmen mit datenintensiven Workloads oft mit Speicher- und Bandbreitenproblemen konfrontiert. Laut Holcombe nutzen PaaS- und IaaS-Anbieter beides als Differenzierungsmerkmale im Wettbewerb. Es sei schwierig, eine gute Performance für beides zu erzielen.

Der CIO des US-Patent- und Markenamts verfolgt beim Nutzen nativer Services einen Ansatz, den er für sich als "schwarze Fichte" bezeichnet. So wie der Baum seine Äste dicht am Stamm halte, bleibe auch die Behörde dicht an den Standards und halte ihre Anpassungen so "dünn" wie möglich. So ließen sich Abhängigkeiten reduzieren und es könne sichergestellt werden, dass die Organisation nicht mit einem überladenen und teuren Versionspfad belastet werde.

An Standards orientiert sich auch Calusinski: "Die meisten PaaS-Optionen haben eine Kernfunktion und eine Reihe von zusätzlichen Features. Wir begrenzen die Anzahl dieser Zusatzfunktionen und konzentrieren uns weitestgehend auf den Kern."