Publiziert:

Vendor Lock-in

Abhängigkeit bewusst eingehen, den Ausstieg von Anfang an mitdenken

Vendor Lock-in entsteht, wenn die Kosten für den Wechsel von einem Technologieanbieter zu einem anderen so hoch sind, dass ein Wechsel wirtschaftlich unmöglich wird. In der Cloud-Welt geschieht dies oft schleichend durch die Nutzung herstellerspezifischer Dienste (proprietäre APIs).

Ein gewisser Grad an Abhängigkeit ist unvermeidlich, um die Vorteile von Cloud-Plattformen zu nutzen. Die Strategie muss jedoch sein, diese Abhängigkeit bewusst einzugehen und Exit-Szenarien für kritische Komponenten zu haben.

Anti-Patterns: Die Lock-in Fallen

  • Proprietäre Datenbank-Funktionen: Nutzung von Logik (Stored Procedures), die nur in einer spezifischen Cloud-Datenbank (zum Beispiel DynamoDB, CosmosDB) läuft.
  • Serverless-Integrationen: Starkes Verweben der Anwendungslogik mit anbieterspezifischen Event-Triggern.
  • Spezial-Hardware: Bindung an Infrastruktur, die nur bei einem Anbieter verfügbar ist.
  • Daten-Transit-Kosten (Egress): Hohe Gebühren für den Export grosser Datenmengen, was den Umzug zu einem anderen Anbieter bestraft.

Strategien zur Risikominimierung

  1. Containerisierung (Docker/Kubernetes): Anwendungen werden in standardisierte Container verpackt, die auf vielen standardisierten Container- und Kubernetes-Umgebungen portierbar sind, sofern Abhängigkeiten bewusst gekapselt werden.
  2. Infrastruktur als Code (Terraform): Definition der Umgebung in neutralen Skripten, was den Wiederaufbau bei einem anderen Anbieter beschleunigt.
  3. Abstraktionsschichten: Nutzung von Standard-APIs und Bibliotheken, die verschiedene Backends unterstützen (zum Beispiel S3-kompatibler Speicher statt herstellerspezifischer Blobs).
  4. Exit-Strategie: Jährliche Bewertung: "Was würde ein Umzug zu Anbieter X kosten?". Wenn diese Kosten den Unternehmenswert übersteigen, muss gegengesteuert werden.
  5. Multi-Cloud-Ready: Architektur-Design, das theoretisch den Parallelbetrieb auf zwei Clouds erlaubt, auch wenn man aktuell nur eine nutzt.

Der Fokus: Verhandlungsposition erhalten

Wer jederzeit gehen könnte, verhandelt bessere Konditionen und wird vom Anbieter als strategischer Partner statt als gefangener Kunde wahrgenommen.

FAQ

Ist es nicht viel teurer, alles herstellerneutral zu bauen?

Herstellerneutrales Bauen verursacht in der Regel einen initialen Mehraufwand bei der Entwicklung. Wie hoch er ausfällt, hängt von Workload, Team, Anbieter und Ausstiegsdesign ab. Dem stehen reduzierte Anbieterrisiken und eine bessere Verhandlungsposition gegenüber; ob die Betriebskosten langfristig sinken, ist szenarienabhängig und sollte fallweise gerechnet werden.

Warum dürfen wir die neuen Features von Cloud X nicht direkt nutzen?

Diese Features dürfen genutzt werden, wenn der Nutzen den Lock-in rechtfertigt. Ihre Nutzung wird hinter einer internen API gekapselt, damit der Rest der Anwendung nicht umgebaut werden muss, wenn der Cloud-Anbieter wechselt.

Referenzen