Warum Europa keine Hyperscaler braucht

Sondern bessere Cloud-Architekturen

Die europäische Cloud-Debatte wird seit Jahren von einer scheinbar einfachen Frage dominiert: Braucht Europa eigene Hyperscaler?

Politik, Wirtschaft und Medien diskutieren regelmäßig darüber, ob Europa einen technologischen Gegenspieler zu den großen Plattformanbietern aus den USA aufbauen sollte. Milliardenprogramme, Förderprojekte und Initiativen versuchen, eine „europäische Cloud" zu schaffen, die mit den großen globalen Plattformökosystemen konkurrieren kann.

Doch vielleicht ist diese Fragestellung von Anfang an falsch gewesen.

Europa muss keine neuen Hyperscaler bauen. Europa braucht vor allem bessere Cloud-Architekturen.

Denn die eigentliche Abhängigkeit entsteht nicht durch Infrastruktur allein – sondern durch die Art, wie moderne Plattformen aufgebaut sind.

---

Das Missverständnis der Hyperscaler-Logik

Hyperscaler sind in erster Linie Plattformökosysteme.

Sie kombinieren Infrastruktur, Plattformservices, Entwicklungswerkzeuge und Betriebsumgebungen zu einem integrierten System. Datenbanken, Messaging-Systeme, KI-Dienste, Observability, Identity-Management, CI/CD und Monitoring sind tief miteinander verzahnt.

Für Entwicklerteams ist das äußerst attraktiv. Neue Services lassen sich schnell integrieren, Plattformfunktionen sind sofort verfügbar, und viele komplexe Infrastrukturprobleme werden von der Plattform selbst gelöst.

Doch diese Integration hat einen strukturellen Effekt:

Sie verschiebt Kontrolle von der Architektur des Systems zur Plattform des Anbieters.

Je stärker Anwendungen auf plattformspezifischen Diensten aufbauen, desto schwieriger wird es, diese Plattform später zu verlassen. Datenstrukturen, APIs und Betriebsmodelle sind eng miteinander verwoben.

Das Ergebnis ist kein technischer Lock-in im klassischen Sinne – sondern ein ökosystemischer Lock-in.

Und genau hier liegt das eigentliche Problem.

---

Infrastruktur ist nicht das Problem

Europa verfügt bereits über eine enorme Menge an digitaler Infrastruktur.

Rechenzentren, Netzwerke, Infrastrukturprovider und Hosting-Unternehmen existieren in großer Zahl. Technologisch sind viele dieser Anbieter absolut konkurrenzfähig. Moderne Hardware, globale Netzanbindung und automatisierte Plattformen sind längst Standard.

Die eigentliche Herausforderung liegt daher nicht in fehlender Infrastruktur.

Sie liegt in der Architektur moderner Plattformen.

Hyperscaler haben es geschafft, Infrastruktur zu einem integrierten Softwareprodukt zu machen. Anwendungen laufen nicht mehr nur auf Servern – sie laufen innerhalb eines kompletten Plattformökosystems.

Wenn Europa versucht, dieses Modell einfach zu kopieren, wird es immer hinterherlaufen.

Der entscheidende Schritt ist ein anderer:

Europa muss die Architektur der Cloud neu denken.

---

Die Chance der Cloud-Native-Architektur

Interessanterweise entstehen genau dafür gerade die richtigen Technologien.

Containerisierung, Kubernetes, Infrastructure as Code und GitOps haben in den letzten Jahren eine neue Plattformebene geschaffen. Anwendungen können heute auf standardisierten Plattformschichten betrieben werden, die unabhängig von der darunterliegenden Infrastruktur funktionieren.

Diese Entwicklung verändert die Machtbalance der Cloud.

Wenn Anwendungen konsequent auf offenen Standards basieren, wird Infrastruktur wieder austauschbar. Workloads können zwischen verschiedenen Umgebungen verschoben werden – von Public Cloud zu Private Cloud, von On-Premise zu Colocation oder zwischen verschiedenen Providern.

Die Plattform gehört dann nicht mehr dem Infrastrukturbetreiber.

Sie gehört dem Betreiber der Architektur.

---

Cloud-Souveränität ist ein Architekturproblem

In vielen politischen Diskussionen wird digitale Souveränität häufig mit geografischen Fragen verbunden: Wo steht das Rechenzentrum? Welcher Anbieter betreibt die Infrastruktur? In welchem Land werden Daten gespeichert?

Diese Fragen sind wichtig – aber sie greifen zu kurz.

Digitale Souveränität entsteht nicht allein durch den Standort eines Servers. Sie entsteht durch technische Kontrolle über:

• Infrastruktur
• Daten
• Plattformarchitektur
• Automatisierung
• Software Supply Chain

Wer diese Ebenen kontrolliert, kann Infrastruktur austauschen, Plattformen wechseln und Technologien anpassen.

Wer sie nicht kontrolliert, bleibt abhängig – unabhängig davon, wo die Server physisch stehen.

---

Ein anderes Modell für Cloud-Plattformen

Genau hier setzt ein alternativer Ansatz an.

Statt ein weiteres geschlossenes Plattformökosystem zu bauen, können Cloud-Architekturen bewusst auf offenen Technologien und modularen Plattformen aufbauen.

In diesem Modell wird die Plattform selbst zur zentralen Instanz – nicht der Infrastrukturprovider.

Die Architektur folgt dabei einigen zentralen Prinzipien:

• Infrastruktur bleibt austauschbar
• Plattformfunktionen basieren auf offenen Standards
• Deployments sind reproduzierbar
• Plattformen lassen sich automatisiert betreiben
• Anwendungen bleiben portabel

Diese Prinzipien sind nicht theoretisch. Sie lassen sich heute bereits technisch umsetzen.

---

Infrastruktur-Automatisierung als Schlüssel

Der entscheidende Faktor für diese neue Cloud-Architektur ist Automatisierung.

In modernen Plattformen wird Infrastruktur nicht mehr manuell betrieben. Sie wird vollständig über deklarative Konfigurationen beschrieben und automatisiert umgesetzt.

Infrastructure as Code, GitOps und automatisierte Deployments sorgen dafür, dass Plattformen reproduzierbar aufgebaut werden können.

Das bedeutet:

Eine komplette Plattform kann auf unterschiedlichen Infrastrukturen identisch aufgebaut werden.

Und genau hier liegt die eigentliche Grundlage für digitale Souveränität.

---

Wie diese Architektur praktisch funktioniert

Bei ayedo verfolgen wir genau diesen Ansatz.

Unsere Plattformarchitektur basiert auf offenen cloud-nativen Technologien wie Kubernetes, Containerisierung und Infrastructure-as-Code-Prinzipien. Anwendungen werden nicht an einzelne Infrastrukturprovider gebunden, sondern laufen auf standardisierten Plattformschichten.

Der entscheidende Baustein für diese Architektur ist Polycrate.

Polycrate ist ein Automatisierungs-Framework für Plattformteams und Systemadministratoren, das den gesamten Software Delivery Lifecycle automatisiert – von der Infrastruktur-Provisionierung über Deployment bis zum Betrieb.

Dabei verbindet Polycrate mehrere Ebenen moderner Plattformarchitektur:

• Configuration Management
• Container-Orchestrierung
• CI/CD
• Cloud-Provisioning
• Observability
• Infrastrukturautomatisierung

Alle diese Prozesse laufen über einen einheitlichen Workflow.

---

Deterministische Infrastruktur statt Plattformmagie

Ein zentrales Problem vieler Cloudplattformen ist Intransparenz.

Viele Plattformdienste funktionieren nach dem Prinzip „Platform Magic". Entwickler nutzen APIs oder Services, ohne genau zu wissen, welche Infrastruktur dahintersteht oder wie diese betrieben wird.

Das beschleunigt Entwicklung – reduziert aber gleichzeitig die Kontrolle.

Polycrate verfolgt einen anderen Ansatz: deterministische Infrastruktur.

Jede Infrastrukturänderung wird als deklarativer Code beschrieben. Deployments laufen reproduzierbar ab, unabhängig von der lokalen Entwicklerumgebung. Automatisierungsprozesse sind transparent, versioniert und auditierbar.

Das Ergebnis ist eine Plattform, die vollständig nachvollziehbar bleibt.

---

Infrastruktur wird wieder portabel

Ein entscheidender Vorteil dieses Ansatzes ist die Portabilität.

Da Plattformen nicht mehr an spezifische Infrastrukturservices gebunden sind, können Workloads zwischen verschiedenen Umgebungen verschoben werden.

Eine Plattform kann beispielsweise laufen auf:

• Public Cloud
• Private Cloud
• Bare-Metal-Infrastruktur
• Colocation-Rechenzentren
• hybriden Umgebungen

Polycrate orchestriert dabei die Infrastrukturautomatisierung über alle diese Umgebungen hinweg.

Für Unternehmen bedeutet das eine neue Form technologischer Beweglichkeit.

---

Compliance wird Teil der Architektur

Ein weiterer Vorteil dieser Architektur zeigt sich im Bereich Regulierung.

Neue europäische Regelwerke wie NIS-2, DORA, CRA oder der Data Act stellen hohe Anforderungen an Nachvollziehbarkeit, Sicherheit und Portabilität digitaler Systeme.

Viele Plattformökosysteme sind jedoch nicht für diese Anforderungen gebaut. Sie basieren auf proprietären Services und komplexen Plattformstrukturen.

In einer vollständig automatisierten Plattformarchitektur lassen sich diese Anforderungen dagegen direkt technisch abbilden:

• Audit-Logs für alle Infrastrukturänderungen
• automatisierte Compliance-Nachweise
• reproduzierbare Deployments
• transparente Software Supply Chains
• dokumentierte Exit-Strategien

Compliance wird damit Teil der Plattformarchitektur – nicht nachträgliche Dokumentation.

---

Europas eigentliche Chance

Europa wird wahrscheinlich keine neuen Hyperscaler hervorbringen, die die bestehenden Plattformgiganten direkt ersetzen.

Doch vielleicht ist genau das auch nicht notwendig.

Die Zukunft der Cloud könnte weniger von gigantischen Plattformökosystemen geprägt sein – und mehr von offenen, interoperablen Plattformarchitekturen.

Architekturen, die auf offenen Standards basieren, automatisiert betrieben werden und Infrastruktur bewusst austauschbar halten.

Europa verfügt bereits über die Technologien, die Infrastruktur und die Expertise, um genau solche Plattformen zu bauen.

Die entscheidende Frage lautet daher nicht:

Wie bauen wir den nächsten Hyperscaler?

Die entscheidende Frage lautet:

Wie bauen wir Cloud-Architekturen, die gar keinen Hyperscaler mehr brauchen?