Cloud Vendor Lock-in vermeiden: Was echte Souveränität technisch bedeutet

Vendor Lock-in ist das unausgesprochene Geschäftsmodell vieler Cloud-Plattformen. Wer einmal tief genug integriert ist, wechselt nicht mehr. Nicht weil das Tool besonders gut ist, sondern weil der Wechsel zu teuer, zu aufwändig und zu riskant wird. Dieser Artikel zeigt, warum das kein Naturgesetz ist, wie Cloud Vendor Lock-in vermeiden konkret aussieht und wie lowcloud dieses Muster architektonisch bricht.

Was Vendor Lock-in wirklich bedeutet

Die meisten Entwickler denken bei Vendor Lock-in zuerst an Preiserhöhungen. Der Anbieter verdoppelt seine Tarife, und man sitzt fest, weil die Migration zu aufwändig wäre. Das ist real, aber es ist nur die Oberfläche.

Mehr als Preiserhöhungen: die strukturelle Abhängigkeit

Echter Lock-in entsteht tiefer. Er entsteht, wenn die Infrastruktur, auf der deine Dienste laufen, nicht dir gehört. Wenn deine Daten auf Servern liegen, auf die du keinen direkten Zugriff hast. Wenn deine Deployments über proprietäre APIs gesteuert werden, die kein anderer Anbieter kennt.

In diesem Zustand bist du nicht Kunde. Du bist Geisel.

Warum Migration bei klassischen PaaS so teuer ist

Bei Plattformen wie Heroku, Render oder Railway läuft deine Infrastruktur auf den Server-Accounts des Anbieters. Du siehst eine saubere Abstraktionsschicht: Git pushen, App läuft. Das ist bequem. Aber wenn du wechseln willst wegen Preisen, wegen Features, wegen einem Unternehmensende, dann fängst du von vorne an.

Neu provisionieren. Daten migrieren. DNS umstellen. Alle abhängigen Dienste neu konfigurieren. Das dauert Tage bis Wochen und kostet im laufenden Betrieb erheblich – Kosten, die in einem vollständigen Cloud-TCO-Modell erfasst werden müssen. Das wissen die Anbieter. Und genau deshalb ist das Modell so verbreitet.

Wie klassische PaaS-Plattformen strukturell sperren

Das Grundproblem ist architektonischer Natur: Der Anbieter hält die Infrastruktur. Du zahlst für die Nutzung, aber du besitzt nichts.

Bei Heroku zum Beispiel laufen deine Dynos auf Salesforce-Servern. Du kannst konfigurieren, was auf diesen Dynos läuft, aber du kannst nicht auf den zugrunde liegenden Server zugreifen, ihn direkt ansprechen oder ihn in eine andere Umgebung überführen. Deine Datenbanken? Ebenfalls beim Anbieter. Deine Add-ons, Umgebungsvariablen, Build-Pipelines? Alle proprietär.

Dieselbe Struktur findet sich bei den meisten modernen PaaS-Angeboten. Das Deployment-Erlebnis ist hervorragend. Der Ausstieg ist es nicht.

Das ist kein Versehen. Es ist das Modell.

Cloud Souveränität: Was das konkret technisch bedeutet

Cloud Souveränität ist ein Begriff, der in der Branche viel verwendet und selten genau definiert wird. Meistens bedeutet er: Datenspeicherung in einem bestimmten Land oder bei einem bestimmten Anbieter. Das ist relevant, aber nicht ausreichend.

Echte Souveränität bedeutet: Du kannst deinen Anbieter wechseln, ohne deinen Betrieb zu gefährden. Du kannst deinen Anbieter abschalten, ohne deine Applikationen zu verlieren. Du hast zu jedem Zeitpunkt direkten Zugriff auf die Infrastruktur, auf der deine Dienste laufen.

Deine Infrastruktur, dein Account. Der BYOC-Ansatz

BYOC steht für Bring Your Own Cloud oder konkreter: Bring Your Own Account. Das Prinzip ist einfach: Statt dass ein PaaS-Anbieter Infrastruktur für dich mietet und dir Zugang dazu verkauft, verbindest du deinen eigenen Cloud-Account (etwa bei Hetzner, Kyberio, Plusserver oder einem anderen Anbieter) mit dem Tool. Das Tool orchestriert deine Infrastruktur auf deinem Account. Es besitzt sie nicht.

Der Unterschied ist fundamental. Du bist nicht Mieter. Du bist Eigentümer.

Der „Was-passiert-wenn"-Test als Architekturkriterium

Ein einfacher Test für jede Cloud-Plattform: Was passiert, wenn der Anbieter morgen aufhört zu existieren?

Bei klassischen PaaS-Modellen ist die Antwort unangenehm: Deine Dienste fallen aus. Du musst sofort migrieren. Unter Zeitdruck, ohne Vorbereitung.

Bei einem BYOC-Modell ist die Antwort eine andere: Die Infrastruktur läuft weiter, weil sie dir gehört. Du verlierst das Orchestrierungs-Tool, aber du verlierst nicht deinen Betrieb.

Dieser Test ist kein akademisches Gedankenspiel. Startups sterben. Anbieter pivoten. Preise steigen. Wer seine Architektur nach diesem Test ausrichtet, schläft besser.

Wie lowcloud Vendor Lock-in architektonisch ausschließt

lowcloud ist nach diesem Prinzip gebaut. Nicht als Marketingversprechen, sondern als technische Grundentscheidung, die das gesamte Produktdesign prägt.

Orchestrierung statt Hosting. Was der Unterschied ist

lowcloud mietet keine Infrastruktur für dich. lowcloud orchestriert Infrastruktur auf deinem Account.

Konkret: Du verbindest z.B. deinen Hetzner-Account mit lowcloud. lowcloud provisioniert dort Server, konfiguriert Docker-Container, richtet Netzwerke und Datenbanken ein. Alles auf deinem Account, mit deinen Zugangsdaten, in deiner Infrastruktur. lowcloud ist das Werkzeug, nicht der Eigentümer.

Das bedeutet:

• Die Server stehen in deinem Hetzner-Account. Du kannst sie jederzeit direkt ansprechen.
• Die Docker-Container und deren Konfiguration liegen bei dir.
• Deine Datenbanken laufen auf Servern in deinem Account.
• Du hast zu jeder Zeit vollständigen SSH-Zugriff und direkte Kontrolle.

Diese Architektur ist kein Feature. Sie ist eine Haltung: Wir wollen, dass du das Werkzeug nutzt, weil es deinen Alltag einfacher macht, nicht weil du ohne uns nicht weiterkommst.

Wenn du lowcloud abschaltest: was passiert und was nicht

Das ist der konkrete Test: Du kündigst deinen lowcloud-Account. Was passiert?

Deine Docker-Container laufen weiter. Deine Datenbanken sind erreichbar. Deine Server in deinem Hetzner-Account existieren weiter. Du verlierst das Dashboard, die automatisierten Deployments, die Überwachung und die einfache Verwaltungsoberfläche, aber du verlierst nicht deine Anwendungen.

Du kannst direkt mit SSH auf deine Server zugreifen und manuell weiterarbeiten. Du kannst ein anderes Tool anbinden. Du kannst die Infrastruktur in eine andere Verwaltungsschicht überführen.

Der Umstieg kostet Aufwand. Aber er ist möglich, kalkulierbar und kann unter normalen Bedingungen geplant werden, nicht als Notfallmaßnahme unter Druck.

Was das für DevOps-Teams in der Praxis bedeutet

Für Entwickler und DevOps-Teams ändert dieser Ansatz mehrere Dinge konkret:

Volle Transparenz über die Infrastruktur. Wer direkt auf den Hetzner-Account zugreifen kann, sieht genau, was läuft. Keine Blackbox, keine versteckten Netzwerkkonfigurationen, kein "das managed die Plattform für dich".

Notfallszenarien sind planbar. Ein Runbook für den Fall, dass lowcloud ausfällt oder nicht erreichbar ist, lässt sich schreiben. Die Infrastruktur ist bekannt. Die manuellen Schritte sind dokumentierbar. Das ist bei klassischen PaaS-Modellen oft schlicht nicht möglich.

Compliance wird einfacher. Viele Branchen stellen Anforderungen daran, wo Daten liegen und wer darauf Zugriff hat. Wenn die Infrastruktur auf dem eigenen Account läuft, sind diese Fragen einfacher zu beantworten. Du kannst nachweisen, dass nur du und niemand sonst Zugriff auf deine Produktionsdaten hat.

Kein Verhandlungsrisiko bei Preiserhöhungen. Wenn ein Anbieter die Preise verdoppelt, ist die Reaktion bei BYOC eine andere. Du kannst das Orchestrierungstool wechseln, ohne die Infrastruktur zu migrieren. Das verändert die Verhandlungsposition grundlegend.

Weniger Risiko bei Wachstum. Wer wächst, will nicht im falschen Moment feststellen, dass seine Infrastruktur an einen einzigen Anbieter gekettet ist. Früh die richtigen Architekturentscheidungen zu treffen, kostet wenig. Sie später zu korrigieren, kostet viel.

Fazit: Einfachheit und Unabhängigkeit schließen sich nicht aus

Der häufigste Einwand gegen BYOC-Ansätze ist: "Das ist komplizierter." Das stimmt für klassische Self-Hosting-Setups. Für lowcloud stimmt es nicht.

Das Ziel ist, dass du eine Plattform nutzt, die dir die Einfachheit eines modernen PaaS gibt. Deployments mit wenigen Klicks, automatische Skalierung, einfache Datenbankanbindung, ohne dass du dafür deine Unabhängigkeit aufgibst. Diese beiden Dinge sind kein Widerspruch, wenn das Produkt von Anfang an auf diesem Prinzip aufgebaut wird.

Cloud Vendor Lock-in vermeiden bedeutet nicht, auf Komfort zu verzichten. Es bedeutet, Komfort und Kontrolle zusammen zu bekommen. Eine durchdachte Cloud Exit Strategie stellt sicher, dass ein Wechsel jederzeit möglich bleibt.

lowcloud ist für Teams gebaut, die ihre Infrastruktur verstehen und kontrollieren wollen und trotzdem keine Zeit haben, alles manuell zu verwalten. Wenn du wissen willst, wie das konkret für dein Setup aussieht, kannst du lowcloud direkt ausprobieren und deinen eigenen Hetzner- oder Kyberio-Account anbinden.