Cloud Vendor Lock-in vermeiden – ohne für zwei Clouds zu bauen
Alles doppelt auf zwei Clouds zu betreiben ist eine Fantasie, die die Kosten verdoppelt und das Tempo halbiert. Behandelt Lock-in stattdessen als Gradient: Docker + Postgres + S3-kompatibler Storage halten rund 90 % eines typischen Stacks portabel. Businesslogik raus aus proprietärem Glue-Code, alles als Code beschrieben — dann habt ihr, was in Preisverhandlungen wirklich zählt: einen glaubwürdigen Exit.
Wir betreiben Kundenprojekte auf AWS, Azure, GCP und Hetzner — und keines davon läuft auf zwei Clouds gleichzeitig. Das ist Absicht.
Warum „einfach auf zwei Clouds laufen" nicht funktioniert
Echtes Multi-Cloud heißt: Netzwerk, IAM, Pipelines und Monitoring doppelt bauen — und sich dabei auf den kleinsten gemeinsamen Nenner aller Services beschränken. Nach unserer Erfahrung verdoppelt das grob die Infrastrukturkosten und macht jedes Feature langsamer, das Infrastruktur berührt. Das Ziel ist nicht Symmetrie zwischen Anbietern. Das Ziel ist, gehen zu können.
Welche Cloud-Services binden euch am stärksten?
Lock-in ist nicht binär. Sortiert jeden Service danach, was der Ausstieg wirklich kosten würde:
| Service-Kategorie | Portabilität | Lock-in-Risiko |
|---|---|---|
| Compute & Container | Docker läuft überall | Niedrig |
| Managed Postgres | Dump, Restore, umziehen | Niedrig |
| S3-kompatibler Object Storage | Standard-API bei vielen Anbietern | Niedrig — Vorsicht Egress-Kosten |
| Queues & Messaging | Konzepte portabel, APIs nicht | Mittel |
| Serverless Functions | Code portabel, Trigger und Glue nicht | Hoch |
| Proprietäre AI- & Analytics-Suiten | Neu bauen statt migrieren | Sehr hoch |
Das Muster ist konsistent: Je näher ein Service an einem offenen Standard liegt, desto billiger der Exit.
Drei Regeln, die den Exit real halten
1. Auf einem langweiligen Kern bauen. Docker für Compute, Postgres für Daten, S3-kompatibler Storage für Dateien. Diese Kombination deckt etwa 90 % eines typischen Produkt-Stacks ab und zieht in Tagen zu jedem Anbieter um — nicht in Quartalen.
2. Businesslogik raus aus proprietärem Glue-Code. Cloud Functions und Workflow-Engines sind als dünne Trigger in Ordnung, die euren Code aufrufen. Sobald Preisregeln oder Domänenlogik in ihnen leben, habt ihr euren eigenen Migrationsblocker geschrieben.
3. Alles als Code beschreiben. Wenn eure Umgebung ein Haufen Konsolen-Klicks ist, bleibt der Exit Theorie. Sind es Terraform-artige Definitionen plus Container-Images, ist der Umzug zu einem anderen Anbieter ein Projekt — keine Odyssee.
Wann Lock-in ein guter Deal ist
Nicht jeder Lock-in ist ein Fehler. Eine Managed Database mit getestetem Failover, automatischem Patching und Point-in-Time-Recovery ersetzt real ein Stück einer Ops-Stelle — und bei Senior-Stundensätzen von 95–160 € gewinnt der Managed Service diese Rechnung oft. Geht solche Trades bewusst ein: an den Rändern eures Systems, nie im Kern.
Genau so arbeiten wir über Clouds hinweg: portabler Kern, bewusster Lock-in an den Rändern. Der Hebel ist nicht, dass wir ständig migrieren — das tun wir fast nie. Sondern dass wir es in Wochen könnten, und jeder Anbieter am Verhandlungstisch das weiß.
Ihr wollt eine ehrliche Einschätzung eurer Exit-Kosten? Das ist Standardteil unserer Cloud & DevOps Audits — oder startet mit unserem Blick auf den EU-souveränen Cloud-Stack.
Olio auf LinkedIn
