Build vs. Buy
Die strategische Entscheidung, ob Software oder KI-Lösungen selbst entwickelt oder als fertige Produkte eingekauft werden – mit Vor- und Nachteilen beider Ansätze.
Die Abhängigkeit von einem Anbieter, die einen Wechsel schwierig oder teuer macht – ein Risiko bei Cloud, SaaS und proprietären Technologien.
Vendor Lock-in bedeutet: Du bist so abhängig von einem Anbieter, dass ein Wechsel schwierig oder teuer wird. Je länger du bleibst, desto stärker die Bindung.
Arten von Lock-in:
Technisches Lock-in:
├── Proprietäre Datenformate
├── Anbieter-spezifische APIs
├── Nicht-portable Integrationen
└── Spezielle Features ohne Standard
Vertragliches Lock-in:
├── Lange Mindestlaufzeiten
├── Hohe Exit-Gebühren
├── Volumenrabatte mit Commitment
└── Automatische Verlängerung
Praktisches Lock-in:
├── Mitarbeiter kennen nur dieses Tool
├── Prozesse sind darauf ausgerichtet
├── Dokumentation im System
└── Gewohnheit und Komfort
| AWS-spezifisch | Portabel |
|---|---|
| Lambda | Kubernetes + Knative |
| DynamoDB | MongoDB, PostgreSQL |
| SQS | RabbitMQ, Kafka |
| S3 (API) | MinIO (S3-kompatibel) |
| Bedrock | OpenAI API, Ollama |
# ❌ Direkte AWS-Abhängigkeit
import boto3
def upload_file(file, bucket):
s3 = boto3.client('s3')
s3.upload_file(file, bucket, file)
# ✅ Abstraktion für Portabilität
from abc import ABC, abstractmethod
class StorageProvider(ABC):
@abstractmethod
def upload(self, file, path): pass
class S3Storage(StorageProvider):
def upload(self, file, path):
boto3.client('s3').upload_file(file, self.bucket, path)
class GCSStorage(StorageProvider):
def upload(self, file, path):
storage.Client().bucket(self.bucket).blob(path).upload_from_filename(file)
# Wechsel = nur Provider-Klasse ändern
storage = S3Storage() # oder GCSStorage()
storage.upload("data.csv", "uploads/data.csv")
# ❌ Lock-in: Anbieter-spezifisches Format
model = sagemaker.Model(model_data="s3://bucket/model.tar.gz")
# ✅ Portabel: Standard-Formate
# ONNX - läuft überall
torch.onnx.export(model, dummy_input, "model.onnx")
# MLflow - anbieterunabhängig
mlflow.pytorch.log_model(model, "model")
## Lock-in Assessment
Für jeden Anbieter/Service bewerten (1-5):
| Kriterium | Score |
|-----------|-------|
| Proprietäre Datenformate | ___ |
| Anbieter-spezifische APIs | ___ |
| Integrationen nur mit Anbieter | ___ |
| Vertragliche Bindung | ___ |
| Migrationskomplexität | ___ |
| Team-Abhängigkeit (Know-how) | ___ |
Summe: ___/30
Interpretation:
- 6-12: Niedriges Lock-in
- 13-20: Mittleres Lock-in
- 21-30: Hohes Lock-in → Exit-Strategie planen!
1. Daten-Export
- Regelmäßige Backups in portablen Formaten
- API für Datenexport testen
2. Dokumentation
- Alle Integrationen dokumentieren
- Abhängigkeiten kartieren
3. Alternativen evaluieren
- Jährlich Markt prüfen
- PoC mit Alternative
4. Vertragsklauseln
- Exit-Unterstützung verhandeln
- Datenherausgabe garantieren Vendor Lock-in ist wie ein Handyvertrag mit Gerät: Am Anfang günstig, aber nach 2 Jahren merkst du, dass ein Wechsel teuer ist – deine Daten, Apps und Gewohnheiten sind an den Anbieter gebunden.
Technisch: Proprietäre Formate, APIs, Integrationen
Vertraglich: Lange Laufzeiten, Exit-Gebühren
Praktisch: Migrationaufwand, Schulung, Prozessänderungen
Cloud-Anbieter
AWS-spezifische Services vs. portable Lösungen
SaaS-Tools
Daten und Workflows in proprietären Systemen
ML-Plattformen
Modelle in anbieter-spezifischen Formaten
Architektur
Proprietäre Features vs. Standard-SQL
Nicht unbedingt. Proprietäre Features können Vorteile bieten. Lock-in ist ein Trade-off: Mehr Features vs. weniger Flexibilität. Bewusst entscheiden!
Open Standards nutzen, Abstraktionsschichten, Multi-Cloud-Strategie, Exit-Klauseln verhandeln, regelmäßig Alternativen evaluieren.
Oft 50-200% der Jahreskosten. Datenmigration, neue Integrationen, Schulung, Produktivitätsverlust. Je länger beim Anbieter, desto teurer der Wechsel.