Multi-Cloud-Abstraktionfeedback

Vorgeschlagen

Dieser Funktionsbaustein wurde als strategisch notwendig identifiziert und befindet sich in der Konzeptionsphase.

Status: Vorgeschlagen | Erstellt am: 13. März 2026 | Autor: BMDS-Architekturteam

lightbulb Motivationfeedback

Der D-Stack soll auf verschiedenen SCS-konformen Cloud-Anbietern betreibbar sein. Ohne eine Abstraktionsschicht entstehen Provider-Lock-in, inkonsistente Provisionierung und manuelle Infrastrukturanpassungen beim Wechsel zwischen Cloud-Umgebungen.

• Provider-Unabhängigkeit: Einheitliche API für Infrastruktur-Provisionierung.
• Hybrid-Cloud: Nahtlose Nutzung von On-Premise- und Cloud-Ressourcen.
• Compliance: Flexible Platzierung von Workloads nach Datenschutzanforderungen.
• Kostenoptimierung: Workloads auf dem jeweils günstigsten Provider betreiben.

settings Kernfunktionalitätenfeedback

• Deklarative Infrastruktur: Kubernetes-native Provisionierung von Cloud-Ressourcen.
• Provider-Plugins: Unterstützung für OpenStack (SCS), AWS, Azure und weitere Provider.
• Composition: Wiederverwendbare Infrastruktur-Templates für D-Stack-Bausteine.
• Drift-Detection: Automatische Erkennung und Korrektur von Konfigurationsabweichungen.
• Cost-Management: Transparente Kostenübersicht über alle Provider.

engineering Technische Einordnungfeedback

Eigenschaft	Wert
Kategorie	Betrieb & Plattform
GovStack-Mapping	○ -
Referenzstandards	SCS-Standards, Kubernetes Resource Model
Open-Source-Referenz	Crossplane, Terraform (OpenTofu), Pulumi

share Abhängigkeitenfeedback

• Container-Orchestrierung (Kubernetes als Control Plane)
• DevSecOps / GitOps (IaC-Manifeste in Git)

arrow_forward Nächste Schrittefeedback

• Evaluierung Crossplane vs. OpenTofu für SCS-Infrastruktur
• PoC: Crossplane-Provider für OpenStack/SCS
• Definition von Composition-Templates für D-Stack-Standard-Workloads
• Integration in den D-Stack