Vendor Lock-In in der Cloud richtig erkennen

Besitzen Sie mehrere Apple-Produkte? Dann können Sie nicht einfach auf ein Samsung Smartphone umsteigen, da Ihnen so die Kompatibilität zu Ihrer Apple Watch verloren ginge. Sie müssten sich zusätzlich noch eine andere Smartwatch zulegen, die mit Ihrem neuen Smartphone kompatibel ist. Selbst wenn Sie gerne also ein Samsung Smartphone hätten, der komplette Umstieg auf eine andere Marke wäre teuer. Hindern Sie die abzusehenden Kosten an einem solchen Umstieg und Sie bleiben deshalb bei Ihrem iPhone, hat Apple Sie „eingelockt“ – man spricht hier auch von „Vendor Lock-In“. Wir zeigen Ihnen was Vendor Lock-In ist und wie Sie es richtig erkennen.

Vendor Lock-In ist die Abhängigkeit eines Anwenders/ Kunden/ Nutzers bezüglich eines oder mehrerer Produkte oder Services von einem bestimmten Hersteller. Diese Abhängigkeit entsteht dadurch, dass ein Wechsel zu einem alternativen Anbieter

• aufgrund mangelnder Alternativen (z.B. fehlender Funktionen) nicht möglich oder
• aufgrund zu hoher Transaktionskosten unwirtschaftlich ist.

Das klingt zunächst nach etwas, womit wir uns nur selten befassen müssen. Aber weit gefehlt – Vendor Lock-In kann nicht nur in unserem Alltag auftreten, sondern auch in der Cloud. Wie entsteht ein solcher Vendor Lock-In und wie können Sie ihn erkennen?

Vendor Lock-In der Cloud – was ist das?

Ein Vendor Lock-In in der Cloud entsteht dann, wenn die Kosten für eine Migration höher sind als ihr Nutzen.¹ Haben Sie sich für einen bestimmten Cloud-Anbieter entschieden, kann es verschiedene Gründe geben, dass ein Umstieg zu einem anderen Cloud-Anbieter – sollte dieser gewünscht oder notwendig sein – so teuer ist, dass diese Kosten die Vorteile der Migration überwiegen. Im Rahmen meiner Thesis habe ich ein Vorgehen entwickelt, um einen möglichen Vendor Lock-In in der Cloud frühzeitig erkennen und ihm vorbeugen zu können.

Vendor Lock-In am Beispiel von Serverless-Plattformen

Wie ein Vendor Lock-In in der Cloud entstehen kann, lässt sich sehr gut anhand verschiedener Serverless Plattformen zeigen. AWS Lambda und Google Cloud Functions ermöglichen beispielsweise beide das Erstellen von Functions. Functions sind in ihrer Funktion abgeschlossene Code-Einheiten, die bei Bedarf automatisiert ausgeführt werden. Vergleicht man AWS Lambda² mit Google Cloud Functions³, so fällt zunächst auf, dass nicht unbedingt die gleichen Programmiersprachen und Laufzeitumgebungen verwendet werden können. Von beiden Umgebungen werden Node.js, Python und Go unterstützt, seitens AWS Lambda zudem noch Java, C# und Ruby. Wurden nun Functions für AWS Lambda in Java erstellt, können diese nicht für die Google Cloud übernommen werden, da hier keine Java Functions unterstützt werden.

Weiterhin werden in den verschiedenen Cloud-Plattformen verschiedene proprietäre Bibliotheken verwendet. Eine Bibliothek ist eine vorgefertigte Sammlung von Programmcode, der für bestimmte Aufgaben eingesetzt werden kann. Für die betrachteten Plattformen gibt es zum Beispiel die folgenden Bibliotheken:

• AWS – aws-lambda-java-core: Diese Bibliothek enthält unter anderem das Lambda-Context-Objekt, über das mit der AWS Lambda-Ausführungsumgebung interagiert wird.⁴
• Azure – com.microsoft.azure.functions: Diese Bibliothek enthält unter anderem den ExecutionContext, durch den mit der Azure Functions-Ausführungsumgebung interagiert wird.⁵

Functions können also nicht immer einfach von einer Cloud in die andere übernommen werden, sondern müssen vorher möglicherweise angepasst oder komplett neu geschrieben werden.

Für ein paar Functions ist dies vielleicht kein großer Aufwand. Denken Sie jedoch daran, dass Ihre Anwendung vermutlich nicht ausschließlich aus Functions besteht. Sie müssen beispielsweise auch folgende Punkte genauer betrachten:

• Sind Ihre Daten kompatibel mit der Zieldatenbank in der neuen Cloud?
• Wie viel kostet der Export der Daten?
• Was muss in der Anwendung angepasst werden, um proprietäre Cloud-Schnittstellen unterstützen zu können?
• Und sind die benötigten Funktionalitäten überhaupt in der neuen Cloud verfügbar?

Vendor Lock-In richtig erkennen

Die Summe all dieser verschiedener Lock-In-Gefahren ist es, die am Ende einen Vendor Lock-In ausmachen können. Aus diesem Grund beschäftigte sich meine Thesis mit der Entwicklung einer Möglichkeit, einen Vendor Lock-In zu erkennen. Damit noch darauf reagiert werden kann, muss dies möglichst vor der Migration in eine Cloud oder vor der Neuentwicklung eines Cloud-Services geschehen.

Wie bereits erwähnt entsteht ein Vendor Lock-In dann, wenn die Kosten für eine Migration ihren Nutzen übersteigen. Es müssen also sowohl die Kosten einer Migration als auch ihr Nutzen identifiziert werden, um einen Vendor Lock-In erkennen zu können.

Da der tatsächliche Nutzen einer Migration erst in der Zukunft deutlich werden würde und somit nicht vorhersehbar ist, muss hierfür eine alternative Zahl herangezogen werden. Deshalb wird der Nutzen betrachtet, der bei der Wahl eines bestimmten (anstatt eines bestimmten anderen) Cloud-Anbieters entsteht. Beispielhaft ist dies hier mit fiktiven Zahlen zu sehen:

Abbildung: Beispiel für die Berechnung eines Vendor Lock-Ins (anhand fiktiver Zahlen)

Im Beispiel fällt die Entscheidung auf die Cloud A. Betrachtet werden die Erstellungskosten, bei denen zunächst gegenüber der Wahl von Cloud B ein Nutzen von 10.000€ entsteht. Durch die günstigeren Nutzungskosten in einem bestimmten Betrachtungszeitraum entsteht hier außerdem ein Nutzen von zusätzlich 5.000€. Der Nutzen im Betrachtungszeitraum insgesamt liegt also bei 15.000€. Diesem muss man jedoch die zu erwartenden Migrationskosten gegenüberstellen, im Beispiel 30.000€. Da der Nutzen dann negativ wird, entstünde hier ein Vendor Lock-In.

Fazit:

Letztendlich besteht jedoch auch hier das Problem, dass sich in der Zukunft die Nutzungskosten und die zu erwartenden Migrationskosten verändern können. Entweder wird so eventuell ein Vendor Lock-In vorausgesagt, der dann doch nicht entsteht, oder ein Vendor Lock-In tritt wider Erwarten doch auf. Es kann also keine genaue, durch Zahlen belegte Aussage getroffen werden, ob bei einem Cloud-Anbieter mit Sicherheit ein Vendor Lock-In auftreten wird.

Trotzdem können die identifizierten Migrationskosten zumindest als Einschätzung herangezogen werden, an welchen Stellen in einer Cloud-Anwendung ein Vendor Lock-In entstehen könnte. In Verbindung mit Expertenwissen kann so eingeschätzt werden, ob einem möglichen Lock-In entgegengewirkt werden sollte und welche Maßnahmen hierzu herangezogen werden können.

Quellen:

¹ angelehnt an: Justice Opara-Martins, Reza Sahandi und Feng Tian. „A Holistic Decision Framework to Avoid Vendor Lock-in for Cloud SaaS Migration. In: Computer and Information Science 10 (Juli 2017), S. 29. issn: 1913-8989. doi: 10.5539/cis.v10n3p29. (S.30)

² https://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html

³ https://cloud.google.com/functions/docs/writing

⁴ https://docs.aws.amazon.com/de_de/lambda/latest/dg/java-programming-model.html

⁵ https://docs.microsoft.com/en-us/java/api/com.microsoft.azure.functions.executioncontext?view=azure-java-stable