Vendor Lock-In ist ein Spektrum, kein Binärzustand: Ein pragmatisches Bewertungsframework
Ein pragmatisches Framework zur Bewertung von Vendor Lock-In über fünf Dimensionen — das Architekten hilft, fundierte Abwägungen zwischen Cloud-nativer Effizienz und Portabilitätskosten zu treffen.
"Wir können Azure Cosmos DB nicht verwenden, weil das Vendor Lock-In erzeugt."
Diese Aussage behandelt Lock-In als binär — entweder Sie sind locked-in oder nicht. In der Realität ist Lock-In ein Spektrum. Jede Technologieentscheidung beinhaltet einen gewissen Grad an Kopplung, und das Ziel ist nicht null Lock-In (was unerreichbar ist), sondern informiertes Lock-In, bei dem die Vorteile die Wechselkosten rechtfertigen.
Dieses Framework hilft Architekten, Lock-In über fünf Dimensionen zu bewerten und pragmatische statt ideologische Entscheidungen zu treffen.
Die fünf Dimensionen von Lock-In
Dimension 1: Daten-Lock-In
Wie schwierig ist es, Ihre Daten aus dem Dienst zu extrahieren?
| Bewertung | Beschreibung | Beispiel |
|---|---|---|
| 1 | Standardformate, einfacher Export | Azure Blob Storage (Standard-APIs, einfache Migration zu S3) |
| 2 | Standardformate, großes Volumen | Azure SQL Database (Standard-SQL, aber Terabytes an Daten brauchen Zeit) |
| 3 | Proprietäres Format, Export verfügbar | Cosmos DB (proprietäres Wire-Protokoll, aber JSON-Export funktioniert) |
| 4 | Proprietäres Format, komplexer Export | Dynamics 365 (strukturierte Daten, komplexe Beziehungen) |
| 5 | Daten sind mit Service-Logik verwoben | Power Platform (Daten + Geschäftslogik + UI sind miteinander verflochten) |
Schlüsselfrage: Können Sie alle Ihre Daten in einem Format exportieren, das ein anderer Dienst ohne Datenverlust importieren kann?
Dimension 2: API- und Schnittstellen-Lock-In
Wie eng ist Ihr Anwendungscode an die APIs des Anbieters gekoppelt?
| Bewertung | Beschreibung | Beispiel |
|---|---|---|
| 1 | Industriestandard-APIs | S3-kompatibler Speicher (viele Anbieter unterstützen die S3-API) |
| 2 | Standardprotokoll, anbieterspezifische Erweiterungen | Azure Service Bus (AMQP-Standard, aber proprietäre Management-API) |
| 3 | Anbieterspezifisches SDK, Abstraktion möglich | Azure Functions (Anbieter-SDK, aber Geschäftslogik ist portabel) |
| 4 | Tiefe API-Integration | Azure AD/Entra ID (Identitätsmodell tief in der Anwendung eingebettet) |
| 5 | Kein Äquivalent existiert anderswo | Azure Arc (kein direktes Äquivalent auf anderen Plattformen) |
Schlüsselfrage: Wie viele Codezeilen müssten geändert werden, um den Anbieter zu wechseln?
Dimension 3: Identitäts- und Zugriffs-Lock-In
Wie abhängig sind Sie von der Identitätsplattform des Anbieters?
| Bewertung | Beschreibung | Beispiel |
|---|---|---|
| 1 | Standardprotokolle (OIDC/SAML) | Jeder OIDC-konforme IdP (einfach austauschbar) |
| 2 | Standardprotokolle mit Erweiterungen | Entra ID mit Conditional Access (OIDC + proprietäre Richtlinien) |
| 3 | Tiefe Identitätsintegration | Microsoft 365 + Entra ID + Intune (Identität = Plattform) |
| 4 | Identität ist die Plattform | Entra ID mit PIM, Access Reviews, Identity Governance |
| 5 | Plattformübergreifende Identitätsabhängigkeit | Entra ID föderiert mit 50 SaaS-Anwendungen |
Schlüsselfrage: Wenn Sie den Identitätsanbieter wechseln würden, wie viele Systeme würden nicht mehr funktionieren?
Dimension 4: Netzwerk-Lock-In
Wie eng ist Ihre Netzwerkarchitektur an den Anbieter gekoppelt?
| Bewertung | Beschreibung | Beispiel |
|---|---|---|
| 1 | Standard-Netzwerk | VNet Peering (Konzept existiert auf allen Clouds) |
| 2 | Anbieterspezifische Funktionen | Azure Private Link (proprietär, aber Konzept ist portabel) |
| 3 | Tiefe Netzwerkintegration | ExpressRoute mit spezifischen Peering-Standorten |
| 4 | Anbieterspezifische Architektur | Azure Front Door + WAF + Private Endpoints-Kette |
| 5 | Netzwerk ist das Produkt | Azure Virtual WAN über mehrere Regionen |
Dimension 5: Operatives Wissens-Lock-In
Die am meisten unterschätzte Dimension. Wie viel der Expertise Ihres Teams ist anbieterspezifisch?
| Bewertung | Beschreibung | Beispiel |
|---|---|---|
| 1 | Übertragbare Fähigkeiten | Kubernetes (funktioniert auf jeder Cloud) |
| 2 | Größtenteils übertragbar | Terraform (anbieterspezifische Module, aber gleiche Sprache) |
| 3 | Teilweise übertragbar | Azure DevOps (CI/CD-Konzepte übertragbar, spezifische Funktionen nicht) |
| 4 | Größtenteils anbieterspezifisch | Azure Monitor + Log Analytics (Abfragesprache und Dashboards) |
| 5 | Vollständig anbieterspezifisch | Power Platform / Power Automate |
Schlüsselfrage: Wenn Ihr Team morgen auf AWS arbeiten müsste, wie lange würde es dauern, bis es produktiv ist?
Bewertung und Interpretation
Für jede Service- oder Plattformentscheidung bewerten Sie alle fünf Dimensionen (1-5). Die Gesamtpunktzahl zeigt das Lock-In-Niveau:
| Gesamtpunktzahl | Lock-In-Niveau | Interpretation |
|---|---|---|
| 5-10 | Niedrig | Migration ist unkompliziert. Nutzen Sie native Dienste frei. |
| 11-15 | Moderat | Migration ist machbar, erfordert aber Planung und Investition. |
| 16-20 | Hoch | Migration ist teuer. Stellen Sie sicher, dass die geschäftliche Rechtfertigung überzeugend ist. |
| 21-25 | Sehr hoch | Migration ist ein Großprojekt. Nur akzeptieren, wenn die Vorteile die Wechselkosten klar überwiegen. |
Die Kosten der Lock-In-Vermeidung
Lock-In-Vermeidung hat ihre eigenen Kosten:
Abstraktionsschicht-Steuer
Der Aufbau von Abstraktionsschichten (z. B. Azure Blob Storage und S3 hinter einer gemeinsamen Schnittstelle kapseln) kostet vorab Engineering-Zeit und danach dauerhafte Wartungszeit. Wenn Sie nie migrieren, hat diese Investition null Rendite.
Architektur auf dem kleinsten gemeinsamen Nenner
Nur Funktionen zu nutzen, die auf allen Clouds verfügbar sind, bedeutet, die Funktionen zu verpassen, die jede Cloud wertvoll machen. Die Multi-Modell-Fähigkeit von Azure Cosmos DB, das Lambda-Ökosystem von AWS und die Analytics-Leistung von GCP BigQuery sind Wettbewerbsvorteile, die Sie für Portabilität aufgeben.
Multi-Cloud-Betriebsoverhead
Workloads auf mehreren Clouds gleichzeitig zu betreiben bedeutet:
- Mehrere IAM-Systeme verwalten
- Mehrere Abrechnungssysteme überwachen
- Mehrere Monitoring- und Alerting-Plattformen
- Mehrere Netzwerkmodelle verstehen
- Teamschulung und Zertifizierung über mehrere Plattformen
Ehrliche Einschätzung: Für die meisten Unternehmen mit weniger als 10.000 Mitarbeitern übersteigen die Betriebskosten von Multi-Cloud das Lock-In-Risiko, das es mindert.
Wann Lock-In akzeptabel ist
- Der Dienst liefert erheblichen Wettbewerbsvorteil — Die globale Verteilung von Cosmos DB ist das Lock-In wert, wenn Ihre Anwendung einstellige Millisekunden-Latenz über Kontinente benötigt
- Die Wechselwahrscheinlichkeit ist sehr gering — Wenn Sie ein 5-Jahres-Azure-EA haben und keinen realistischen Migrationsgrund, optimieren Sie für Azure-native Effizienz
- Die Wechselkosten sind beherrschbar — Lock-In bei Bewertung 10-15 bedeutet, Migration ist ein Projekt, keine Krise
- Die Alternative kostet mehr — Eine "portable" Architektur, die 40 % mehr im Aufbau und Betrieb kostet, ist kein guter Tausch
Wann Lock-In gefährlich ist
- Die Anbieterbeziehung verschlechtert sich — Preisstreitigkeiten, sinkende Supportqualität, divergierende strategische Ausrichtung
- Regulatorisches Risiko — Eine neue Verordnung könnte Datensouveränität erfordern, die Ihr aktueller Anbieter nicht bieten kann
- Akquisitionsrisiko — Der Anbieter könnte übernommen und das Produkt eingestellt werden
- Konzentration auf einen Anbieter — Wenn 100 % Ihrer Infrastruktur bei einem Anbieter liegt, hat eine Preiserhöhung existenzielle Hebelwirkung
Praktische Empfehlungen
- Bewerten Sie jede bedeutende Architekturentscheidung anhand der fünf Dimensionen
- Akzeptieren Sie Lock-In bewusst — Dokumentieren Sie die Entscheidung und die Begründung
- Investieren Sie in Portabilität nur dort, wo ein Wechsel innerhalb von 3-5 Jahren plausibel ist
- Nutzen Sie Standardschnittstellen, wo die Kosten gering sind — Kubernetes statt proprietärer Container-Orchestrierung, PostgreSQL statt proprietärer Datenbanken
- Überprüfen Sie Lock-In-Bewertungen jährlich — Der geschäftliche Kontext ändert sich, und damit sollte sich auch Ihre Toleranz ändern
Benötigen Sie Unterstützung bei der Bewertung von Vendor Lock-In für Ihre Cloud-Architektur? Kontaktieren Sie uns — wir helfen Architekten, pragmatische Entscheidungen über Portabilität und native Service-Adoption zu treffen.
Themen