SCS & Verwaltungscloud

Früher Entwurf

Dieses Dokument ist ein früher Entwurf (Early Draft) und befindet sich noch in der aktiven Bearbeitung und Abstimmung bezüglich des D-Stacks.

Im Rahmen der Architekturkonzeption für den D-Stack und die Deutsche Verwaltungscloud (DVC) spielt der Hosting- und Infrastruktur-Layer eine tragende Rolle. Der Sovereign Cloud Stack (SCS) ist hierbei von zentraler Bedeutung.

info 1. Einordnung von SCS im D-Stackfeedback

SCS ist als verbindlicher Standard für den Cloud-Layer des D-Stacks verankert. Die folgende Kette zeigt die strategische Einbettung, von der europäischen GovStack-Spezifikation bis hin zum Betrieb der Deutschen Verwaltungscloud:

SCS hat aktiv am "GovStack Cloud Infrastructure Building Block" mitgewirkt und erfüllt nahezu alle Anforderungen dieser Spezifikation (nur zwei als reines "Recommendation" markierte Requirements werden derzeit ausgelassen). SCS agiert somit marktseitig als De-facto-Referenzimplementierung. Im Deutschland-Stack ist SCS als verbindlicher Standard für den Bereich "Managed Services und Cloud" verankert.

flag 2. Sovereign Cloud Stack (SCS): Stärken & Kritikfeedback

SCS bietet eine wichtige Grundlage für souveräne Verwaltungsinfrastruktur, doch die Praxis zeigt strukturelle Grenzen. Die folgende Darstellung gibt einen ausgewogenen Überblick über Stärken, Risiken und Reifegrad.

Stärkenfeedback

• Offene Standards (SCS-compatible) mit Zertifizierungsprogramm
• OSBA-Community-getragen, herstellerunabhängig
• OpenStack + K8s als bewährte Basis mit breitem Ökosystem
• BSI-C5-Compliance-fähig, dt. Rechenzentren
• Referenzimplementierung für Verwaltungscloud-Infrastruktur
• Multi-Cloud-Fähigkeit durch standardisierte APIs

Kritik & Risikenfeedback

• OpenStack-Komplexität: Hunderte Microservices, hoher Betriebsaufwand
• Fachkräftemangel: Wenige OpenStack-Experten am Markt verfügbar
• CloudStack als IaaS-Alternative zunehmend als Sackgasse gesehen
• Förderungsabhängigkeit: BMWK-Mittel laufen 2024 aus, Nachhaltigkeit?
• Adoption: Nur wenige CSPs nutzen den vollen SCS-Stack produktiv
• Fehlende PaaS/SaaS-Schicht über der Infrastruktur-Ebene

Einschlägige Marktanalysen zeigen strukturelle und konzeptionelle Herausforderungen bei der Umsetzung:

1. Begrenzung auf IaaS/CaaS: SCS deckt technisch primär die Infrastruktur-Schicht (OpenStack) und die Container-Orchestrierung (Kubernetes) ab. Es mangelt am integrierten Angebot von Plattform-Diensten (PaaS/SaaS wie Managed Databases, Message Queues, Serverless Functions, AI/ML-Services). Gerade diese Plattformdienste sind es jedoch, die die Attraktivität der Hyperscaler für Entwicklerteams ausmachen.

2. Betriebskomplexität („OpenStack-Dilemma“): Die Basis OpenStack ist hochkomplex. Wie Marktexperten betonen (vgl. "Honest Review"-Vortrag der SCS-Gründer; Zitate bei CloudAhead), gibt es akute Probleme beim Betrieb. Laut Analysen (z.B. Storware) klagen 86 % der Unternehmen über einen Mangel an Fachexpertise, was dazu führt, dass rund die Hälfte aller OpenStack-Installationen operativ scheitert.

3. Leistungsfähigkeit vs. Souveränität: Nach Kritik von Branchenanalysten (u.a. CloudAhead) definiert SCS Souveränitätsstufen, für die jedoch keine Skalierungs- oder Leistungsanforderungen greifen. Technologisch ließen sich höchste Souveränitätsstufen mit Kleinst-Installationen (z.B. auf einem Laptop) erreichen; dies entspricht jedoch nicht den Anforderungen an hochverfügbare E-Government-Services der DVC. Föderierte Kleinst-Clouds können die massiven ökonomischen und technologischen Skaleneffekte der globalen Hyperscaler (Economies of Scale) schwer replizieren. Das Fördervolumen durch das BMWK ist Ende 2024 ausgelaufen, die Dauerfinanzierung des Projekts ist eine offene Herausforderung.

swap_horiz 3. Alternative und Ergänzende Cloud-Technologienfeedback

SCS deckt den IaaS/CaaS-Bereich solide ab, stößt aber bei Betriebskomplexität, PaaS-Angeboten und Fachkräfteverfügbarkeit an Grenzen. Behördenauswertungen und Analysen des europäischen IaaS/KaaS-Marktes zeigen folgende marktfähige Alternativen:

IaaS-Vergleichsmatrixfeedback

Die Matrix gibt eine schnelle Einordnung der IaaS-Optionen entlang zentraler Kriterien. Sie ersetzt keine Detailanalyse, erleichtert aber die Vorauswahl.

Basierend auf der Sopra Steria Analyse:

Kriterium	OpenStack (SCS)	CloudStack	Proxmox VE	VMware (Broadcom)	K8s-native Stack
Lizenz	Apache 2.0	Apache 2.0	AGPL v3	Proprietär (Subscription)	Apache 2.0
Reifegrad	Hoch (15+ Jahre)	Hoch	Mittel (wachsend)	Sehr hoch	Niedrig (emerging)
Komplexität	Sehr hoch	Mittel	Gering	Hoch	Hoch (noch fragmentiert)
PaaS-Angebot	Nein (nur IaaS)	Nein	Nein	Ja (Tanzu)	Nativ (Helm, Operators)
BSI C5	Machbar	Machbar	Begrenzt	Zertifiziert	In Entwicklung
Fachkräfte DE	Gering	Sehr gering	Wachsend	Rückläufig	Wachsend
Sovereign-ready	SCS-Standard	Nein	Teilweise	Nein	Design-Ziel

IaaS-Implementierungsoptionen im Vergleichfeedback

Die folgenden Karten ergänzen die Matrix mit einer visuellen Einordnung typischer Stärken und Schwächen. Sie zeigen Reifegrad, Betriebsaufwand und strategische Eignung im Verwaltungsumfeld, ohne Produktempfehlung, aber mit klarem Entscheidungsfokus.

OpenStack (SCS-Basis)

• Ausgereift, riesiges Ökosystem
• Hohe Betriebskomplexität
• Referenz: plusserver, Wavecon
• Zukunft: stabil, aber schwerfällig

Apache CloudStack

• Einfachere Administration
• Schrumpfende Community
• Wenig Innovation seit 2020
• Risiko: technologische Sackgasse

Proxmox VE

• KVM/LXC, einfache Web-UI
• Beliebt bei KMU & Homelabs
• Keine Enterprise-Governance
• Kein natives Multi-Tenancy

VMware (Broadcom)

• Marktführer bei Virtualisierung
• Broadcom-Übernahme: massive Preiserhöhungen, Lizenzänderungen
• Kunden suchen Exit-Strategien

Source: SCS, Oxide, CNCF Survey 2025

Oxide Computer

• Integrierte HW + Open-Source-SW
• Cloud-in-a-Rack-Ansatz
• Zielgruppe: On-Premises-Cloud
• Noch frühes Stadium, US-Fokus

K8s-native Stack (neu)

• KubeVirt + Metal³ + Cluster API
• Kubernetes als IaaS-Kontroll-Ebene
• Stark wachsendes CNCF-Ökosystem
• Details auf den folgenden Folien

K8s-native IaaS: Kernkomponentenfeedback

Die nachstehenden Bausteine bilden zusammen einen Kubernetes-nativen Infrastruktur-Stack. Sie ermöglichen es, klassische IaaS-Funktionen wie VMs, Bare-Metal-Provisioning, Netzwerk und Multi-Tenancy direkt über Kubernetes-Ressourcen zu steuern, ohne eine zusätzliche OpenStack-Schicht.

KubeVirt (VMs auf K8s)

• VMs als K8s-Pods, KVM-basiert
• CNCF Incubating Project
• Cross-Cluster Live Migration
• Nutzer: Red Hat, SUSE, IBM

Metal³ (Bare Metal)

• Bare-Metal-Provisioning via K8s
• CNCF Incubating (seit 08/2025)
• Ironic-basiert, deklaratives API
• Basis für souveräne HW-Kontrolle

Cluster API (Lifecycle)

• Deklaratives Cluster-Management
• Multi-Provider (AWS, vSphere, Bare Metal, OpenStack)
• GitOps-Integration möglich
• Automatisiertes Day-2-Ops

Cilium eBPF-Networking

• eBPF-basiertes CNI-Plugin
• CNCF Graduated Project
• L3/L4/L7-Policies, Encryption
• 500+ Enterprise-Adopter (2025)

Source: Metal³ CNCF, KubeVirt, Cilium Adopters

Kube-OVN (SDN)

• OVN/OVS-basiertes Netzwerk
• VPC, Subnet, QoS auf K8s
• Klassisches SDN-Modell
• Alternative zu Cilium für Telco/Enterprise-Szenarien

Kamaji (Control Planes)

• Hosted K8s Control Planes
• 1000+ Cluster auf einem Host
• Multi-Tenancy für Managed K8s
• Von Clastix, CNCF Sandbox

Migrationslogik: Vom aktuellen Stack zum Zielbildfeedback

Die Analyse zeigt: Ein Weiterbetrieb des bestehenden SCS/OpenStack-Stacks ist langfristig durch Betriebskomplexität und Fachkräftemangel belastet. Der strategische Zielpfad führt zu einem Kubernetes-nativen Stack, über eine hybride Migrationsphase, in der beide Welten parallel betrieben werden können.

Der Übergang wird auf 2026–2028 terminiert. In dieser Phase können Behörden bestehende OpenStack-Workloads schrittweise auf KubeVirt und Metal³ migrieren, während neue Dienste direkt K8s-nativ entwickelt und betrieben werden.

Kommerzielle Referenzenfeedback

Mehrere Anbieter setzen den K8s-nativen Stack bereits in Behördenprojekten produktiv ein:

Anbieter	Lösung	Behörden-Referenz
SUSE	Harvester + Rancher Prime + NeuVector	KRZN NRW
Red Hat	OpenShift Virtualization	Bundeswehr ITZBw
Spectro Cloud	Palette (Multi-Cluster)	US DoD (FedRAMP)
evroc/SUSE	EU Sovereign Cloud	Geplant (EU-finanziert)

summarize Fazit zur Cloud Governancefeedback

Behörden haben die Wahl zwischen dem eigenem, oft kostenintensiven, Aufbau von Plattform-Services auf einer SCS/IaaS-Schicht oder der Nutzung der Managed Services großer Cloud-Anbieter. Die DVC-Strategie muss Mechanismen etablieren, um den Mangel an PaaS-Angeboten auszugleichen und durch gezielte Automatisierung die Betriebskomplexität zu beherrschen.