Viele Unternehmen starten in der Public Cloud, weil alles schnell und bequem wirkt. Nach einigen Quartalen zeigt sich oft eine andere Realität: schwer durchschaubare Preislogik, steigende Komplexität im Betrieb und spürbar höhere Gesamtkosten. Wer stattdessen auf deutsche Hoster wie 1&1 IONOS oder Hetzner setzt und einen konsequent offenen Stack betreibt, behält die Wahlfreiheit – und damit die Kontrolle über Budget, Datenschutz und Roadmap.
Kosten: schwer planbar – und häufig höher als gedacht
Hyperscaler-Preise bestehen aus vielen Bausteinen: Instanztypen, Storage-Klassen, API-Aufrufe, Egress, regionenabhängige Zuschläge, Support-Pläne. Sobald Traffic, Datenvolumen und Services wachsen, wird die Rechnung unübersichtlich. Typische Kostentreiber sind Ausgeh-Traffic und Managed-Services mit Komfortaufschlag; dazu kommen interne Abhängigkeiten, die Overprovisioning begünstigen. Ergebnis: Budgets, die sich nur mit erheblichem Analyseaufwand stabilisieren lassen – und sich vor allem kaum zuverlässig im Voraus prognostizieren lassen.
Bei deutschen Hostern sind Compute und Storage in der Regel einfacher kalkulierbar. Rechenleistung, Bandbreite und Speicher folgen klaren Tarifen; teure Überraschungen durch Datenverkehr über „Premium-Kanten“ lassen sich architektonisch vermeiden.
Komplexität: steile Lernkurven, hoher Betriebsaufwand
Die Feature-Dichte großer Clouds erzeugt eine Architektur, die permanent Aufmerksamkeit verlangt: Identitäts- und Netzwerkmodelle, regionale Limits, Dutzende Spezialdienste mit eigenen Betriebsregeln. Teams investieren viel Zeit, um die Plattform zu verstehen – Zeit, die anderswo Produktwert schaffen könnte. Wer stattdessen einen schlanken, offenen Stack betreibt, reduziert kognitive Last: weniger proprietäre Sonderfälle, klarere Zuständigkeiten, bessere Vorhersagbarkeit.
Lock-in: kleine Abkürzungen, große Ketten
Lock-in entsteht nicht über Nacht. Er wächst durch viele bequeme Entscheidungen: eine proprietäre Datenbank-Variante hier, ein serverloser Dienst mit anbieterspezifischen Triggern dort, ein Observability-Stack mit Formaten, die anderswo nicht funktionieren. Solange alles im selben Ökosystem bleibt, fällt das kaum auf. Spätestens bei Preissteigerungen, neuen Datenschutzanforderungen oder höheren Verfügbarkeitszielen zeigt sich, wie fest die Kopplung ist – Migration wird teuer, langsam und riskant.
Die Alternative: deutscher Hoster plus offener Stack
Ein tragfähiges Setup basiert auf offenen Bausteinen, die es bei vielen Anbietern gibt: Linux/Debian für Stabilität, Nginx oder HAProxy am Rand, PostgreSQL als relationale Datenbank, Redis für Caching, S3-kompatibler Objektspeicher für Binärdaten, Prometheus und OpenTelemetry für Metriken, Logs und Traces. Container folgen dem OCI-Standard, Identitäten laufen über OIDC. So bleibt die Anwendung portierbar: Beim Anbieterwechsel muss der Code nicht neu gedacht werden, weil Schnittstellen stabil sind.
Im Alltag heißt das: VMs oder Bare-Metal bei 1&1 IONOS oder Hetzner, Container-Orchestrierung nach Bedarf, Datenbanken mit Standard-SQL, Observability mit offenen Protokollen, Objektdaten in S3-kompatiblen Buckets. Die Plattform bleibt austauschbar, das Produkt bleibt beweglich.
Kostenhebel im lock-in-freien Betrieb
Wer die Plattform frei wählen kann, optimiert Kosten dort, wo es zählt. Compute läuft dort, wo Preis und Leistung passen, Speicher dort, wo Kapazität günstig ist. Komfortaufschläge verschwinden, weil nicht jeder Baustein als proprietärer Managed Service eingekauft wird. Egress-Kosten lassen sich durch Caching, lokale Replikation und S3-kompatible Speicher außerhalb der Hyperscaler entschärfen. Observability auf offenen Standards zeigt reale Auslastung – das verhindert Overprovisioning und rechtfertigt Downsizing mit Zahlen statt Bauchgefühl.
Falls das Team beim Aufräumen Starthilfe braucht – Architekturcheck, IaC-Module, praxistaugliche Runbooks und ein sauberer Exit-Plan aus proprietären Diensten – sind die Linux Consulting und Support Dienstleistungen der Blunix GmbH aus Berlin ein unkomplizierter Einstieg: Senior-Engineers, die Standards setzen, damit der Betrieb anschließend in der eigenen Hand bleibt.
Datenschutz und Souveränität
Standorte in der EU vereinfachen Governance und reduzieren geopolitische Risiken. Verträge, Support und Dokumentation auf Deutsch beschleunigen im Ernstfall die Lösung. Vor allem aber bleibt die Architektur frei: Compute bei Anbieter A, Objektspeicher bei B, DNS/CDN bei C – ohne Architekturbruch. Das ist praktische digitale Souveränität, nicht nur Papier-Compliance.
Architektur-Checkliste für den Umstieg
Erstens den Ist-Zustand erkennen: Welche Komponenten sind heute anbieterspezifisch, welche bereits offen? Zweitens Exit-Pfade definieren: Für jede Datenhaltung braucht es einen dokumentierten Export; Konfigurationen müssen portierbar sein; Identität und Netzwerk dürfen nicht an proprietäre Annahmen gekettet werden. Drittens Standards festschreiben: Infrastruktur als Code mit Terraform, Systemzustände mit Ansible; anbieterspezifische Details nach innen kapseln, nach außen nur Standard-Schnittstellen exponieren (HTTP, SQL, S3, OIDC, OTLP). Viertens Portabilität üben: Einmal pro Quartal den Stack in einer Staging-Umgebung bei einem zweiten Anbieter hochfahren, Daten importieren, DNS-Umschaltung simulieren – Dauer und Stolpersteine protokollieren.
Mini-Fallbeispiel: Shop-Stack ohne Zementschuhe
Frontend und API laufen auf Debian-VMs, Nginx übernimmt Edge und Caching, PostgreSQL speichert Transaktionen, Redis beschleunigt Sessions und Produktlisten, Assets liegen in einem S3-kompatiblen Bucket. Observability erfasst Metriken und Traces über offene Protokolle. Das Ganze läuft bei einem deutschen Hoster, ist aber identisch bei einem zweiten Anbieter reproduzierbar. Wenn Preise steigen oder Anforderungen sich ändern, zieht der Stack kontrolliert um – ohne Rewrites.
Nächste Schritte
Sinnvoll ist ein schrittweiser Umstieg entlang der natürlichen Erneuerungszyklen. Neue Services werden sofort vendor-neutral entworfen, bestehende werden bei Gelegenheit auf offene Bausteine umgestellt. Messen Sie den Fortschritt nicht in „Prozent migriert“, sondern in gewonnener Handlungsfreiheit: Wie viele kritische Pfade sind heute standardisiert? Wie viele Daten lassen sich ohne Spezialwerkzeug exportieren? Wie schnell könnten Sie Anbieter wechseln?
So entsteht ein Setup, das mit dem Geschäft wächst – kostentransparent, portabel und souverän.
