Langweilig ist schön: Warum souveräne Clouds das Hyperscaler-Buffet nicht brauchen

Vor ein paar Wochen sagte jemand bei einem Konferenzdinner zu mir, fast entschuldigend: „Wir würden ja gerne weg von AWS, aber es ist einfach unmöglich.“

Diesen Satz habe ich in der einen oder anderen Form oft genug gehört, um zu erkennen, was dahintersteckt. Frust. Unsicherheit. Das leise Gefühl, dass die großen Cloud-Anbieter inzwischen so tief in allem verwoben sind, dass man ihnen nicht mehr entkommt. Und jedes Mal erkenne ich dieses Gefühl wieder: diese Mischung aus Unausweichlichkeit, leichtem schlechten Gewissen und dem Verdacht, dass man gerade über den Tisch gezogen wird.

Manchmal ist dieses Gefühl berechtigt. Oft genug wurde es aber auch sorgfältig gezüchtet.

Nach über dreißig Jahren in dieser Branche – erst als Sysadmin, dann als Entwickler, heute als Geschäftsführer – bin ich ziemlich überzeugt: Die gefühlte Unmöglichkeit, die Hyperscaler zu verlassen, ist zumindest teilweise eine Geschichte, die sie sehr gut zu erzählen gelernt haben. Die technische Realität ist meistens deutlich langweiliger.

Und langweilig ist genau das, was du willst.

Mein Argument ist also schlicht: Eine souveräne Cloud muss nicht 200 Hyperscaler-Services klonen, um eine echte Alternative zu sein. Und wenn du glaubst, du könntest die Public Cloud niemals verlassen, liegst du wahrscheinlich falsch

Die Abhängigkeit, die wir gerne wegreden

Die meisten europäischen Unternehmen sagen, sie wollten weniger Abhängigkeit von US-Anbietern. Und trotzdem wird die Abhängigkeit immer größer – der europäische Marktanteil im Cloud-Geschäft schrumpft seit Jahren, statt zu wachsen. Wir landen in dieser seltsamen Situation, in der fast alle sagen, sie wollten Veränderung, während sie genau das Gegenteil tun.

Ein Teil davon ist ehrlich. Hyperscaler sind gut in dem, was sie tun, und eine Migration ist echte Arbeit. Aber ein anderer Teil ist unangenehmer: Die Hyperscaler haben fünfzehn Jahre damit verbracht, ein Ökosystem aufzubauen, in dem ein Ausstieg sich nicht nur teuer, sondern irgendwie auch unverantwortlich anfühlt. Als könnte kein ernstzunehmendes Unternehmen ohne den kompletten Katalog überleben.

Die aktuelle Welle an „Sovereign Cloud“-Ankündigungen von AWS, Microsoft und Google baut genau auf diesem Gefühl auf. Lokalisierte Rechenzentren. In der EU ansässiges Personal. Von Partnern betriebene Regionen. Manchmal nützlich. Aber die Muttergesellschaft unterliegt weiterhin dem US-amerikanischen CLOUD Act, der es US-Behörden erlaubt, den Zugriff auf Daten zu erzwingen, die bei US-Unternehmen liegen – egal, wo die Server physisch stehen.

Wenn du einen Moment willst, der das auf den Punkt bringt: Im Juni 2025 wurde der Director of Public and Legal Affairs von Microsoft Frankreich vor dem französischen Senat gefragt, ob er garantieren könne, dass die Daten französischer Bürger niemals an US-Behörden weitergegeben würden. Er konnte es nicht. Er sagte, bisher sei es nicht passiert.

Das ist keine Souveränität. Das ist Hoffnung mit angehängtem SLA.

Es gibt inzwischen einen Begriff dafür: Sovereignty Washing. Und ja, das ärgert mich. Etwas „souverän“ zu nennen, während die Muttergesellschaft nur einen Gerichtsbeschluss von einer anderen Antwort entfernt ist, reicht nicht. Im besten Fall ist es eine teilweise Risikominderung. Im schlimmsten Fall macht das Marketing die Arbeit, die eigentlich die Architektur machen sollte.

Es lohnt sich, genau zu sein, was „souverän“ eigentlich heißen sollte, denn das Wort wurde so weit gedehnt, dass es fast alles abdeckt. Für mich ist es nicht eine Frage, sondern ein kleiner Stapel davon: Wem gehört das Unternehmen, das den Service anbietet? Unter wessen Rechtsordnung steht es? Wer betreibt die Control Plane? Wer hält die Verschlüsselungs-Keys? Und kannst du dich da auditierbar wieder herausarbeiten – und tatsächlich gehen, mit deinen Daten, in einem bekannten Zeitrahmen? Ein echtes souveränes Angebot sollte auf all das eine saubere Antwort haben. Die meisten Badges, die gerade auf dem Markt sind, beantworten ein oder zwei davon und schweigen zum Rest.

Ein nützliches Gegenbeispiel ist OpenStack. Verwaltet von der OpenInfra Foundation als herstellerneutrales Projekt, mit offenem Code und ohne ein einzelnes Unternehmen, das die Roadmap kontrolliert, beantwortet es die Fragen nach Eigentum, Rechtsordnung und Ausstieg strukturell statt vertraglich – du kannst es selbst betreiben, du kannst den Betreiber wechseln, und das Artefakt, von dem du abhängst, verschwindet nicht, wenn ein Hersteller es sich anders überlegt. Das ist die Messlatte, an der „souverän“ meiner Meinung nach gemessen werden sollte: nicht ein Label, das sich ein Anbieter selbst gibt, sondern eine Architektur und ein Governance-Modell, die auch dann noch tragen würden, wenn der Anbieter morgen verschwände.

Und genau deshalb ist Open Source in dieser Debatte keine ästhetische Entscheidung sondern eine Voraussetzung. Der Grund, warum OpenStack diese sauberen Antworten geben kann, ist, dass der Quellcode offen ist, die Lizenz permissiv genug, um ihn tatsächlich zu nutzen, und die Governance so aufgesetzt, dass keine einzelne Partei einem den Boden unter den Füßen wegziehen kann. Nimm auch nur eines davon weg, und „souverän“ fällt wieder in sich zusammen zu einer Marketing-Behauptung. Du kannst den Code lesen, ihn forken, ihn auf eigener Hardware betreiben und prüfen, was er tut – nichts davon ist verhandelbar, wenn die Alternative ist, der Aussage eines Anbieters darüber zu vertrauen, wohin deine Daten gehen. Closed-Source-Souveränität ist ein Widerspruch in sich: Du bist immer nur eine Übernahme, eine Lizenzänderung oder einen behördlichen Zugriff davon entfernt herauszufinden, dass die Antworten, die du bekommen hast, an Bedingungen geknüpft waren.

Der Mythos von den 200 Services

Hier bleibt das Gespräch meistens hängen. Die Leute sagen: „Schön und gut, aber die europäischen Anbieter haben die Services nicht, die wir brauchen.“

Und wenn man eine Cloud an der Größe ihres Katalogs misst, haben sie recht. Allein AWS hat weit über 200 Services. Aber hier ist die Frage, die ich meistens zurückstelle:

Wie viele dieser Services nutzt du tatsächlich?

In den meisten Setups, die ich sehe, lautet die ehrliche Antwort irgendwo zwischen fünf und fünfzehn. Compute. Object Storage. Eine Managed Database. Eine Container-Plattform. Ein bisschen IAM. Vielleicht eine Queue. Vielleicht ein CDN. Der Rest ist ein wunderbar vermarktetes Buffet, das niemand aufisst. für das aber alle zahlen: Mit kognitivem Overhead, mit Lock-in und mit den Betriebskosten, alles zusammenzustückeln.

Dan McKinley hat das vor Jahren in einem Essay auf den Punkt gebracht, den jeder Infrastrukturmensch einmal im Jahr lesen sollte: Choose Boring Technology. Seine Kernidee ist das Innovation Token. Jedes Team hat ein kleines Budget an Innovation, das es für seinen Stack ausgeben kann. Gib es dort aus, wo es dein Geschäft differenziert. Gib es nicht für einen sechsten Message Bus aus.

Souveräne Anbieter halten dich, teilweise notgedrungen, näher an den langweiligen Grundlagen. PostgreSQL. S3-kompatibler Object Storage. Kubernetes auf OpenStack. Ganz normales Cron. Nichts davon ist glamourös. Das meiste davon läuft in Produktion, seit es die Hälfte des AWS-Katalogs noch gar nicht gab. Die Fehlerbilder sind bekannt. Die Dokumentation ändert sich nicht alle fünf Minuten. Ein kompetenter SRE, der nächsten Monat anfängt, erkennt, was er da vor sich hat – ohne drei Runden Hersteller-Zertifizierung.

Dieser letzte Punkt ist wichtiger, als wir zugeben. Wir reden viel über Kosten, Lock-in und Souveränität. Wir reden weniger über die Engineering-Zeit, die allein dafür verbrennt, mit Hyperscaler-spezifischem Tooling Schritt zu halten, das sich jedes Quartal ändert. Diese Zeit ist real. Sie taucht im Onboarding auf, in Incidents, in Architektur-Meetings und in der leisen Angst, dass niemand das Ding mehr ganz versteht.

Wo Hyperscaler ihren Platz haben

Bevor ich zu weit in die andere Richtung schieße: Für manche Workloads sind Hyperscaler die richtige Antwort, und das Gegenteil zu behaupten wäre nur eine andere Spielart von Marketing. Wenn du wirklich globale Edge-Präsenz in zwanzig Regionen brauchst, wenn dein Geschäft von den ausgereiftesten Managed-AI- oder Analytics-Services des Planeten abhängt, wenn du ein Plattform-Team hast, das groß genug ist, um die operative Komplexität aufzufangen, oder wenn Time-to-Market für die nächsten achtzehn Monate wichtiger ist als Portabilität – dann geh zu den Hyperscalern, und entschuldige dich nicht dafür.

Der Fehler ist nicht, AWS oder Azure zu nutzen, sondern sie standardmäßig für Workloads zu nutzen, die nichts davon brauchen. Ein Startup, das heute DynamoDB Global Tables und Bedrock braucht, sollte nicht seinen eigenen OpenStack-Cluster betreiben, um etwas zu beweisen. Ein mittelständisches Unternehmen, das ein paar Dutzend Services betreibt, die mit einer SQL-Datenbank und einem Object Store reden, sollte vermutlich nicht für eine Komplexität zahlen, die es gar nicht nutzt.

Die meisten Workloads, die ich sehe, fallen in den zweiten Topf, nicht in den ersten. Genau da lohnt sich das Gespräch.

„Aber wir stecken schon zu tief drin, um auszusteigen“

Drei Einwände kommen fast jedes Mal. Dieselben drei, meistens in derselben Reihenfolge.

„Wir haben so viel auf hyperscaler-spezifischen Services gebaut, dass eine Migration bedeuten würde, den halben Stack neu zu schreiben.“

Manchmal stimmt das. Die ehrliche Antwort lautet: Ja, das ist der Preis der Entscheidungen, die getroffen wurden. Aber in der Praxis ist der Rewrite meistens kleiner, als die Leute befürchten. Wenn dein Workload in Containern läuft, mit einer SQL-Datenbank redet und Blobs über eine S3-kompatible API speichert, bist du schon zum Großteil portabel. Der Schmerz ist da real, wo Teams stark auf proprietäres Serverless oder herstellerspezifischen Identity-Klebstoff gesetzt haben. Kein Zaubertrick lässt das verschwinden. Mein Rat ist langweilig: Hör auf, das Loch tiefer zu graben. Mach neue Systeme standardmäßig portabel und migriere den Rest zu natürlichen Zeitpunkten – ein Redesign, eine Vertragsverlängerung, ein Plattform-Refresh.

„Souveräne Anbieter können mit dem Service-Katalog der Hyperscaler nicht mithalten.“

Stimmt. Sie können auch nicht mit der Überraschungsrechnung am Ende des Quartals mithalten, mit den Egress-Gebühren, die niemand so richtig eingeplant hatte, oder mit der operativen Komplexität, die in dieser Rechnung versteckt ist. Manche Hyperscaler-Setups sind wirklich günstig, vor allem mit ernsthaften Commitments und reservierter Kapazität. Viele andere sind es nicht, und die Kosten werden erst sichtbar, wenn du versuchst zu gehen.

„Migration ist zu riskant und dauert zu lange.“

Bei diesem hier widerspreche ich am heftigsten. Ein Kunde kam zu uns, fest überzeugt, sein AWS-Ausstieg sei ein Achtzehn-Monats-Projekt mit drei Engineers. Wir haben uns mit dem tatsächlichen Deployment hingesetzt – nicht dem Architekturdiagramm, dem echten Ding. Rund vierzig containerisierte Services auf EKS, eine primäre PostgreSQL auf RDS, ein paar Terabyte in S3 und der übliche Wildwuchs aus CloudWatch-Dashboards und IAM-Policies, drumherum angeflanscht.

Der Großteil davon – die Container, die Datenbank, der Object Storage – war in eher sechs Wochen umgezogen. Der PostgreSQL-Cutover brauchte ein geplantes Wartungsfenster von etwa vierzig Minuten; alles andere lief parallel, bis wir den Traffic umgeschaltet haben. Der lange Schwanz kam danach: eine Handvoll Lambda-Funktionen, die als geplante Jobs neu geschrieben werden mussten, etwas Identity-Klebstoff im Cognito-Stil, CloudWatch-Alarme, die in Prometheus und Alertmanager neu definiert werden mussten. Nervig, aber begrenzt – und nicht der Teil, der darüber entscheidet, ob die Migration machbar ist.

Die Schlagzeilen-Migration, der angeblich unmögliche Teil, war überhaupt nicht unmöglich.

Die interessante Frage ist nicht, ob ein Ausstieg möglich ist, sondern warum so viele Unternehmen gar nicht erst damit anfangen.

Wie das in der Praxis aussieht

Kurzer Einschub, weil ich es klar sagen sollte: NETWAYS – die Unternehmensgruppe, die ich führe – betreibt mit NETWAYS Web Services eine eigene OpenStack-basierte Cloud-Plattform, die Sebastian mit seinem Team zu einer mehr als konkurrenzfähigen Lösung ausgebaut hat. Ja, ich habe also etwas im Spiel. Du kannst das als kommerzielle Voreingenommenheit lesen. Fair. Du kannst es auch als die Sicht von jemandem lesen, der diese Migrationen in echten Kundenumgebungen erlebt hat, nicht nur auf Folien. Auch fair. Mir ist es lieber, die Voreingenommenheit zu benennen, als so zu tun, als hätte ich keine.

Wie migriert man also tatsächlich? Die langweilige Antwort ist die richtige.

Inventarisiere deine echten Abhängigkeiten, nicht deine eingebildeten. Die meisten Teams stellen fest, dass ein großer Teil ihres Workloads bereits portabel ist und dass sich der nicht-portable Teil auf ein paar herstellerspezifische Services konzentriert, die sie damals adoptiert haben, weil es gerade bequem war.

Wähle langweilige Abstraktionen. Container. Kubernetes. PostgreSQL. S3-kompatibler Storage. OpenStack darunter. Das sind die Primitive, auf denen alles läuft, von CERNs Forschungs-Workloads bis zu Telekommunikationsnetzen.

Beweg die einfachen Dinge zuerst. Stateless Services und Batch-Workloads sind meist günstig zu migrieren, sie reduzieren deinen Hyperscaler-Footprint sofort, und die Ersparnis hilft, die schwierigeren Teile zu finanzieren.

Und bitte, widersteh dem Drang, den Hyperscaler-Katalog auf deiner souveränen Cloud nachzubauen. Da liegt der Wahnsinn. Die meisten dieser Services existieren, um dich tiefer ins Ökosystem zu ziehen, nicht um dein Leben einfacher zu machen. Die meisten davon hast du wahrscheinlich von Anfang an nicht gebraucht.

Du sitzt nicht in der Falle

Das Gefühl, dass ein Ausstieg aus den Hyperscalern unmöglich ist, ist real. Ich will es nicht abtun. Aber es ist nicht hauptsächlich ein technisches Gefühl. Es wurde gezüchtet.

Hyperscaler sind nicht böse. Niemand muss morgen alles rausreißen. Aber die Unmöglichkeit, die du spürst, ist oft hergestellt. Die langweilige, souveräne Open-Source-Alternative ist näher, als du denkst.

Du schuldest AWS, Microsoft oder Google keine Loyalität. Du schuldest deinen Nutzern, deinem Team und deinem Geschäft einen Stack, den du durchdenken kannst, den du verlassen kannst, wenn du musst, und mit dem du nachts durchschläfst.

Das war’s eigentlich. Größtenteils unglamouröses Engineering und die Bereitschaft, dem Marketing nicht mehr zu glauben.

Nach gut dreißig Jahren in dieser Branche kann ich dir sagen: Das ist schwerer, als es klingt. Aber viel leichter, als die Verkäufer dich glauben machen wollen.