Im Oktober 2010 startete der Bilderdienst Instagram. Zwei Monate später hatten mehr als eine Million Nutzer die Foto-App installiert, im Juli 2011 überstieg die Zahl der hochgeladenen Fotos bereits die 100-Millionen-Marke. Ein derartig rasantes Wachstum war für Instagram nur deshalb möglich, weil das Unternehmen von Anfang an auf Cloud-Ressourcen setzte. Die Vorteile der Cloud – Flexibilität, effizienter Ressourceneinsatz, schnelle Entwicklungszyklen und eine praktisch unbegrenzte Skalierbarkeit – waren essenziell für den Erfolg des Unternehmens.

Die Schattenseite des Cloud-Computings zeigte sich jedoch, als Instagram 2012 von Facebook übernommen wurde. Im Zuge der Integration sollte das Backend von den EC2-Instanzen bei Amazon Web Services (AWS) in die Rechenzentren des Social-Media-Anbieters umziehen. Ein schwieriges Unterfangen, das gut ein Jahr dauerte – viel Zeit, wenn man bedenkt, dass der Aufbau der Plattform nur zwei Jahre gebraucht hatte.

Das Beispiel Instagram zeigt deutlich: Wer seine Workloads in die Cloud migriert, gewinnt zwar viele Freiheiten, begibt sich aber auch in eine Abhängigkeit. «Oft entstehen neue Lock-ins durch Serviceangebote oder Schnittstellen, ebenso verliert der Kunde die Wahlmöglichkeit, was den Hypervisor betrifft», sagt Markus Pleier, CTO und SE Director Central Europe bei Nutanix, einem Anbieter von Hyperconverged-Infrastructure-Lösungen. Die European Network and Information Security Agency (ENISA) stuft das Risiko einer Provider-Abhängigkeit in der Cloud als hoch ein.

«Cloud-Services basieren häufig auf proprietären, nicht standardisierten Datenformaten und Applikationslogiken. Das kann die Migration von Daten und Services zu einem anderen Cloud-Provider erschweren oder sogar unmöglich machen», heisst es in der ENISA-Studie «Cloud Computing – Benefits, Risks and Recommendations for Informa­tion Security».

Laut einer Umfrage des European Telecommunications Standards Institute (ETSI) unter mehr als 350 kleinen und mittelständischen Unternehmen in Europa stufen denn auch 63 Prozent der Teilnehmer einen Vendor- oder Daten-Lock-in als kritisch oder sehr kritisch ein. Zu ähnlichen Ergebnissen kommt eine Befragung von 114 Unternehmen durch Justice Opara-Martins und Kollegen von der Bournemouth University in Grossbritannien. Nach Sicherheitsbedenken war die Angst vor Abhängigkeit der am zweithäufigsten genannte Grund, warum Unternehmen nicht in die Cloud migrieren.

Rund 40 Prozent der Befragten schätzten das Risiko eines Daten-Lock-ins als kritisch ein, 80 Prozent bezeichneten einen Vendor-Lock-in als sicher oder potenziell abschreckend für eine Cloud-Migration. «Das Thema Vendor-Lock-in hat in der letzten Zeit wieder an Bedeutung gewonnen», bestätigt Alexander Sommer, Director, Practice Leader Private Cloud beim Cloud-Spezialisten Rackspace diesen Trend.

Manche Cloud-Anbieter sehen das ganz anders. «Vendor-Lock-in ist in unseren Kundengesprächen ganz selten ein Thema», sagt Constantin Gonzalez, Principal Solutions Architect bei der Amazon Web Services GmbH (AWS), «ab und zu kommt einmal eine Diskussion darüber auf, wenn es um einen sehr speziellen Service geht.

Für Manfred Kessler, CEO des Cloud-Providers Global Access Internet Services, hängt es stark von Branche und Wettbewerbssituation ab, ob die Gefahr einer Abhängigkeit überhaupt thematisiert wird: «Es gibt eine Kundengruppe, die von einem Vendor-Lock-in nichts hören will, sondern einfach nur so schnell wie möglich ihren Dienst zum Laufen bringen möchte», sagt Kessler, «viele Unternehmen stehen unter einem so hohen Konkurrenzdruck, dass sie dafür vieles in Kauf nehmen.» Anwender aus regulierten Bereichen wie der Finanzbranche, der Pharmaindustrie oder auch dem öffentlichen Sektor seien wesentlich zurückhaltender. «Dieser Kundentyp zögert selbst dann noch, in die Cloud zu gehen, wenn er dadurch 20 bis 30 Prozent an Kosten sparen könnte.»

Der Vendor-Lock-in hat tech­nische und organisatorische Gründe: Es mangelt an Standardschnittstellen und offenen APIs. Zudem erschweren unterschiedliche Formate für Daten, Container und virtuelle Maschinen eine Migration, Einrichtung und Verwaltung der Cloud-Ressourcen erfolgen über proprietäre Systeme und Bedienoberflächen und die eigenwillige Architektur der unterschiedlichen Clouds erfordert Expertenwissen. «Je mehr Produkte eines Providers ein Unternehmen nutzt und je stärker die Verschränkung der Dienste ist, desto komplexer wird ein Umzug», sagt Global-Access-CEO Kessler.

Die Situation sei heute allerdings deutlich besser als noch vor wenigen Jahren, beobachtet Patrick Schidler, Business Manager Cloud & Enterprise Group bei der Microsoft Deutschland GmbH: «Mittlerweile haben offene Standards und im Web geschaffene Quasi-Standards viele alte Protokolle abgelöst. Früher war beispielsweise allein die Authentifizierung von Benutzern über System- und Anwendungsgrenzen hinweg noch ein schwieriges Problem. Heute bietet der Hybrid-Cloud-Ansatz fertige Lösungen dafür.»

Ein weiterer Faktor, den Kunden berücksichtigen müssen, ist die «Data Gravity». «Terabyte oder Petabyte an Daten wieder, aus welchen Gründen auch immer, wegzubewegen oder gar der vollständige Rückzug aus der Public Cloud kann extrem teuer, langwierig und schwierig sein», warnt Nutanix-CTO Pleier. Das Problem wird sicher noch zunehmen, denn das Datenwachstum ist nicht zu stoppen. «Die Menge der bei uns gespeicherten Daten verdoppelt sich alle 1,5 Jahre», sagt Manfred Kessler vom Cloud-Provider Global Access.

AWS Architect Gonzalez erklärt, dass Kunden sowohl beim Import als auch beim Export von Daten unterstützt werden, gibt allerdings zu, dass der Transfer in die Cloud preisgünstiger ist als umgekehrt. «Es ist etwas teurer, die Daten aus der Cloud herauszubekommen, das ist aber nicht nur bei uns so.» Wer zum Beispiel 30 TByte in die Cloud transferieren möchte, kann sich für eine einmalige Gebühr von 250 Dollar die AWS-Speicherlösung Snowball schicken lassen. Beim Weg aus der Cloud über das öffentliche Netz werden pro GByte 3 bis 4 US-Cent fällig, was sich bei 30 TByte auf 900 bis 1200 Dollar summiert. Das sei aber keine Strafgebühr, betont Gonzalez: «Wir berechnen nur die Kosten, die wir selber aufbringen müssen, um den Dienst zu erbringen.»

Die Abhängigkeit von einem Provider kann nicht nur beim Export von Daten teuer werden. Auch Preiserhöhungen oder Tarifänderungen können das Budget erheblich und unerwartet belasten. «Es ist nicht zwangsläufig so, dass ein Vendor-Lock-in zu massiven Kostensteigerungen führt, aber es kann durchaus passieren», sagt Global-Access-CEO Kessler.

Neben den Kosten ist es aber auch die Produktpolitik eines Providers, die Kunden Sorgen machen kann. «Für Anwender ist es natürlich ungünstig, wenn nicht abzusehen ist, wie die Servicequalität von Plattformen sich in einigen Jahren entwickelt oder falls die Strategie eines Anbieters von der eines Anwenders abweicht», sagt Frank Strecker, Senior Vice President Cloud Partner Products & Ecosystems bei T-Systems, der das Cloud-Geschäft der Telekom verantwortet. Veränderungen im Serviceangebot oder eine Erhöhung der Preise müssen womöglich akzeptiert werden, weil die Kosten und die Risiken einer Migration weit höher liegen. «Wie teuer ist der Kompromiss zwischen Lock-in und Nutzen wirklich?», sei immer die Kernfrage, erklärt Rackspace-Director Sommer.

Viele Gremien, Standardisierungsorganisationen und Verbände sind angetreten, Standards und Spezifikationen zu entwickeln, die eine Migration zwischen Providern sowie den parallelen Betrieb mehrerer Cloud-Plattformen erleichtern sollen. «Offene Standards haben die Integration von Multi-Vendor-Cloud-Lösungen deutlich vereinfacht», sagt Patrick Schidler von Microsoft.

Nicht alle Spezifikationen werden allerdings auch erfolgreich eingesetzt. So führen etwa die von der Organization for the Advancement of Structured Information Standards (OASIS) entwickelten Standards TOSCA und CAMP laut den Experten noch ein Schattendasein.

«In der Theorie können solche Standards helfen, jedoch sehen wir es in der Praxis nicht», beobachtet Alexander Sommer von Rackspace. Das grösste Problem an Standards sei ihre lange Entwicklungsphase, meint AWS-Architect Gonzalez: «Nach meiner Erfahrung dauert es immer sehr lange, bis sich die Gremien auf eine gemeinsame Basis einigen können.» Standards würden zudem immer nur den kleinsten gemeinsamen Nenner beschreiben. «Je mehr Cloud-Provider sie einbinden wollen, desto kleiner wird die Schnittmenge der Funktionen, die standardisiert werden kann.»

Ein probates Mittel gegen Vendor-Lock-in ist der Einsatz quelloffener, plattformunabhängiger Dienste und Applikationen. «Es gibt keine erfolgreiche Cloud-Plattform, die nicht zu einem grossen Teil Open-Source-Lösungen integriert hat», erklärt Global-Access-Chef Kessler. Einige der Initiativen haben es sich zum Ziel gesetzt, komplette Cloud-Bereitstellungsmodelle auf Open-Source-Basis zu definieren, so etwa die Cloud Foundry Foundation für Platform as a Service (PaaS) oder das OpenStack-Projekt für Infrastructure as a Service (IaaS). «OpenStack hilft dem Kunden, eine gewisse Plattformunabhängigkeit zu gewinnen, was viele Unternehmen schätzen und was oft die Entscheidung für eine Cloud-Plattform erleichtert», erklärt Rackspace-Director Sommer.

Im Public-Cloud-Umfeld gibt es allerdings nur noch wenige Anbieter, die auf OpenStack setzen. «Die meisten Public-Cloud-Angebote auf OpenStack-Basis wurden wieder eingestellt», sagt Crisp-Analyst Carlo Velten im Interview mit com! professional (siehe Seite 42). Prominenteste Ausnahme ist die Deutsche Telekom, die in Zusammenarbeit mit Huawei die Open Telekom Cloud (OTC), eine Public-Cloud-Plattform auf OpenStack-Basis anbietet. «Das in der Open Telekom Cloud eingesetzte OpenStack wird praktisch von allen Hardware-Lieferanten unterstützt. Insofern glauben wir, dass Kunden hier keine technologische Sackgasse droht», meint T-Systems-Vice-President Strecker.

Ein sehr erfolgreiches Open-Source-Projekt ist das Container-Management-System Kubernetes. «Das Produkt ist für ein Open-Source-Projekt sehr schnell sehr reif geworden», sagt Rackspace-Director Sommer. AWS hat auf seiner Konferenz re:invent Ende 2017 einen EC2-Container-Service für Kubernetes (EKS) angekündigt. «Viele unserer Kunden verwenden bereits Kubernetes», sagt Constantin Gonzalez.

Auch Microsoft baut die Kubernetes-Unterstützung auf seiner Cloud-Plattform Azure stetig aus. Im Oktober 2017 hat es den Azure Container Services (AKS) angekündigt, der aktuell in einer Public Preview verfügbar ist. Der Dienst erlaubt den Aufbau voll gemanagter Kubernetes-Cluster und soll Orchestrierung und Monitoring erheblich vereinfachen.

Um das Risiko eines Vendor-Lock-ins zu minimieren, sollten Unternehmen schon bei der Wahl eines Providers, einer Cloud-Applikation oder beim Design einer eigenen Cloud-Anwendung auf Portabilität achten. «Bei Applikationen, die klar die Kernstrategie des Unternehmens betreffen, sollten die Unternehmen versuchen, einen Microservices-Ansatz zu wählen und nur wenig native Funktionen einer Plattform nutzen – damit ist die grösstmögliche Flexibilität gewährleistet», rät Rackspace-Director Alexander Sommer. «Unternehmen sollten im besten Fall mit einem technologieunabhängigen Provider zusammenarbeiten», ergänzt Frank Strecker von der Telekom.

Standardisierte Schnittstellen und Datenformate erleichtern eine Migration erheblich. Auch eigene Applikationen sollten möglichst auf Standard-APIs basieren. «Ich würde alle infrage kommenden Workloads auf mehreren Public-Cloud-Plattformen testen, um den Aufwand für Betrieb, Migration oder Bewegung von Daten und Workloads besser einschätzen zu können», rät Nutanix-CTO Pleier.

Microsoft-Manager Schidler plädiert für eine ganzheitliche Betrachtung des Cloud-Computings über die technische Sicht hinaus. Auch Prozesskomponenten seien zu berücksichtigen: «Wie soll etwa das Kostenmanagement verschiedener Cloud-Anbieter erfolgen? Wie kann ich Sicherheits- und Managementvorgaben über die Grenzen eines einzelnen Cloud-Anbieters hinweg umsetzen?»

«Einen gewissen Grad an Vendor-Lock-in wird es immer geben», erklärt Rackspace-Director Sommer. Kunden, die das volle Potenzial einer Cloud ausschöpfen wollen, bleibt nichts anderes übrig, als sich darauf einzulassen. Das Innovations­tempo bei AWS, Azure, Google & Co. ist extrem hoch, ständig kommen neue Services und Funktionen hinzu, die zwangsläufig zunächst einmal proprietär sind. «Es liegt in der Natur der Unternehmen, Produkte zu gestalten, die sich nirgendwo sonst finden», weiss auch Manfred Kessler von Global Access Internet Services, «und immer wenn ich solche Produkte nutze, habe ich auch einen Vendor-Lock-in.»

Clouds sind zudem so unterschiedlich, vielfältig und komplex, dass sich nur mit vertieftem Wissen über ihre Architektur das Maximum herausholen lässt. Unternehmen müssen deshalb Experten ausbilden oder einstellen – eine Investi­tion, die durch einen Provider-Wechsel verloren wäre.

Bei aller Skepsis sollte man ausserdem nicht vergessen, dass der Vendor-Lock-in auch im eigenen Rechenzentrum seit vielen Jahren Realität ist. Trotz aller Standardisierungsbemühungen haben es Hard- und Software-Hersteller immer verstanden, ihre Produkte einzigartig zu gestalten und so den Wechsel zu erschweren. Hinzu kommen langjährige Lizenz- und Wartungsverträge, gegenüber denen der Vendor-Lock-in in der Cloud geradezu harmlos erscheint. Dennoch sollten Unternehmen das Thema Vendor-Lock-in bei jeder strategischen Entscheidung für eine oder mehrere Clouds im Auge behalten, das Risiko realistisch abschätzen und minimieren, indem sie auf Standards und Open Source setzen, Software in Containern betreiben oder Applikationen als Microservices entwickeln.

Carlo Velten, CEO bei der Crisp Research AG, erklärt im Interview mit com! professional, welche Abhängigkeiten beim Gang in die Cloud drohen – und warum man sich davon nicht abschrecken lassen sollte.

Carlo Velten: Es spielt bei fast allen Ausschreibungen eine grosse und strategische Rolle. Ein möglichst geringer Vendor-Lock-in ist ein wesentlicher Bestandteil der sogenannten nicht-funktionalen Anforderungen.

Velten: Man muss das vor dem Hintergrund der letzten Jahrzehnte sehen, in denen es vor allem Software-Unternehmen wie Oracle oder SAP verstanden haben, Kunden sehr stark an sich zu binden. Das hat bei den IT-Verantwortlichen zu einer gewissen Vorsicht geführt. Sie wollen sich nicht in neue Abhängigkeiten begeben.

Velten: Absolut. Es ist klug, einen möglichen Vendor-Lock-in im Auge zu behalten. Man darf das unternehmerische Risiko aber auch nicht überbewerten. Die Unternehmen müssen aufpassen, dass sie vor lauter Furcht vor einem Vendor-Lock-in nicht die Chancen verpassen, welche die Cloud bietet. Die Vorteile lassen sich ja nur dann realisieren, wenn ich die Cloud tatsächlich nutze.

Velten: Abgesehen von den ganz grossen Konzernen können es sich die wenigsten Unternehmen leisten, zwei oder drei Expertenteams für die verschiedenen Cloud-Angebote zu etablieren. Gerade der Mittelstand sollte sich daher erst mal auf einen, maximal zwei Cloud-Provider beschränken und dafür Kompetenzen aufbauen. Nach erfolgreicher Migration der relevanten Workloads und ein, zwei Jahren Erfahrung kann man dann über eine Multi-Cloud-Strategie nachdenken.

Velten: Die Gefahr eines Vendor-Lock-ins lässt sich auch durch die kluge Wahl geeigneter Technologien reduzieren, die gegebenenfalls einen Umzug zu einem anderen Provider erheblich erleichtern.

Velten: Software lässt sich beispielsweise in Docker-Container packen und mit der Open-Source-Lösung Kubernetes verwalten. Damit ist eine Basis geschaffen, mit der sich der Vendor-Lock-in auf ein Minimum reduzieren lässt.

Velten: Nein, es muss sich um digitale Workloads handeln, die auf einer serviceorientierten Architektur basieren oder sogar schon in Microservices geschrieben sind. Es hat keinen Sinn,
Legacy-Applikationen in Container zu verpacken.

Velten: Aktuell sind die Serverless-Dienste der grossen Cloud-Provider noch sehr proprietär. Wenn man eine Applikation von einem Provider zu einem anderen umziehen möchte, ist die komplette Anwendung umzubauen. Was bei einem kleinen Modul noch machbar sein mag, kann in komplexen Umgebungen schnell sehr hohe Aufwände verursachen. Daher sollten sich Unternehmen vor der Entscheidung für Serverless Computing über Migrationsmöglichkeiten und den dann gegebenenfalls notwendigen Entwicklungsaufwand Gedanken machen. Oder sie setzen gleich auf Open Source und bauen ihre Serverless-Applikation mit quelloffenen Diensten auf.

Wir empfehlen gerade grossen Unternehmen mit den entsprechenden Personalressourcen, vermehrt auf Open Source zu setzen und zu evaluieren, inwieweit frei verfügbare Lösungen nicht nur den Vendor-Lock-in reduzieren können, sondern auch helfen, Kosten zu minimieren.

Velten: OpenStack ist sicher eine geeignete Lösung, um eine Pri­vate Cloud aufzubauen. Es ist aber auch sehr komplex und benötigt spezifisches Know-how. Die Hoffnung allerdings, dass sich Clouds jeder Ausprägung auf Basis von OpenStack nahtlos mitei­nander verbinden lassen, hat sich nicht erfüllt. Die meisten Public-Cloud-Angebote auf OpenStack-Basis wurden wieder eingestellt.

Velten: Die Menge der anfallenden Daten ist ein ganz entscheidender Faktor, nicht nur im Hinblick auf einen Vendor-Lock-in, sondern insgesamt bei der Entscheidung für eine bestimmte Cloud-Architektur. Datentransfer kostet Zeit und Geld, daher hat es zum Beispiel wenig Sinn, auf eine Multi-Cloud-Strategie zu setzen, wenn man ständig Terabyte an Daten zwischen den Clouds hin und her kopieren muss.

Velten: Bei der Migration in ihre Cloud unterstützen die Provider ihre Kunden sehr gut. Man kann Festplatten einsenden oder es kommt sogar ein Lkw, der die Daten per Kabel aus dem Rechenzentrum übernimmt. Die Daten wieder aus der Cloud herauszubekommen, kann dagegen sehr teuer werden. Deshalb ist die sogenannte Data Gravity ein wichtiger Punkt in der Cloud-Strategie eines Unternehmens.

Velten: Fähige Cloud-Strategen mit langjähriger Erfahrung sind in der Tat Mangelware. Mittelstandsunternehmen können sich aber nicht darauf zurückziehen, dass sie kein entsprechendes Personal finden. Jede Firma mit mehr als 1000 Mitarbeitern sollte spätestens bis 2020 mindestens einen, besser zwei Cloud-Spezialisten an Bord haben.