Vendor Lock-in bei Cloud-Diensten – wie vermeide ich die Abhängigkeit?

Moin Anna, zu deiner Frage: Ja, proprietäre Datenbank- oder Storage-Dienste alleine reichen schon aus, um von Lock-in zu sprechen. Du musst nicht warten, bis zusätzlich noch APIs oder Automatisierung dazukommen - das verstärkt es nur.

Für deine Fallstudie würde ich folgende Kategorien durchgehen, das ist in der Praxis auch der übliche Blick:

• Proprietäre APIs: Wenn die Anwendung direkt gegen anbieterspezifische Schnittstellen programmiert ist (nicht gegen offene Standards), ist ein Wechsel teuer, weil du Code umschreiben musst.
• Datenformate: Manche Managed-Services speichern Daten in proprietären Formaten oder mit anbieterspezifischen Metadaten. Export ist dann oft möglich, aber mit Aufwand und Qualitätsverlust verbunden.
• Automatisierung/Infrastructure-as-Code: Wenn Deployment-Skripte auf anbieterspezifischen Tools basieren, musst du die auch neu bauen.
• Vertragliche Bindung: Laufzeiten, Ausstiegsklauseln, Kosten für Datenausgang (Egress-Fees) - das wird gern unterschätzt.
• Know-how der Mitarbeiter: Oft ignoriert, aber wenn dein Team nur mit einem Anbieter-Ökosystem vertraut ist, ist das auch eine Form von Lock-in.

Mein Tipp: Geh den Text durch und markiere, wo explizit Dienste mit Eigennamen genannt werden (nicht nur "Datenbank", sondern "verwalteter Datenbankdienst XY"). Das ist meist der Fingerzeig, dass proprietär gearbeitet wurde. Viel Erfolg!

Hallo Anna, Tobi hat die Kategorien schon sehr gut aufgezählt. Ich würde deiner Fallstudie noch einen zweiten Teil spendieren: nicht nur bewerten, wie stark der Lock-in ist, sondern auch, welche Gegenmaßnahmen das Unternehmen hätte ergreifen können. Das macht sich in einer Projektarbeit meistens gut, weil es zeigt, dass du über die reine Analyse hinausdenkst.

Typische Gegenmaßnahmen, die in der Literatur und auch bei uns im Studium immer wieder genannt werden:

• Multi-Cloud-Strategie: Anwendungen bewusst so bauen, dass sie auf mehreren Anbietern lauffähig sind, z. B. über Containerisierung. Das reduziert zwar nicht automatisch alle Abhängigkeiten, verteilt aber das Risiko.
• Offene Standards und Abstraktionsschichten: Statt direkt gegen die proprietäre API zu programmieren, eine eigene Schnittstellenschicht einziehen, die die Anwendung vom konkreten Dienst entkoppelt. Kostet am Anfang Mehraufwand, zahlt sich aber beim Wechsel aus.
• Standardisierte Datenformate: Wo möglich offene Formate nutzen statt anbieterspezifischer Exporte, damit eine Migration ohne großen Qualitätsverlust läuft.
• Infrastructure-as-Code mit neutralen Tools: Es gibt Automatisierungswerkzeuge, die mehrere Cloud-Anbieter ansprechen können, statt sich auf die anbieterspezifische Lösung festzulegen.

Wichtig für deine Bewertung: Diese Maßnahmen schließen sich meist nicht gegenseitig aus, sondern wirken nur, wenn man mehrere kombiniert. Und man sollte in der Fallstudie auch ehrlich abwägen, dass komplette Anbieterunabhängigkeit oft teurer in der Entwicklung ist – das ist ja gerade der Trade-off, den Unternehmen eingehen.