Zum Hauptinhalt springen

Cloud-Native Architektur

Erstellt am: 12. März 2026 | Zuletzt geändert: 12. März 2026 | Autor: Matthias, Enrico (GitLab)

Ziel des Dokuments: Dieses Dokument beschreibt die Referenzarchitektur für Cloud-Native Anwendungen im Kontext des D-Stacks und der Deutschen Verwaltungscloud (DVC). Es definiert die bevorzugten Technologien und Entwurfsmuster für den Neubau und die Modernisierung von Behördenanwendungen. Für die zugrundeliegende Infrastrukturschicht sei auf das Dokument SCS & DVC verwiesen.

lightbulb Leitgedanke und Motivationfeedback​

Cloud-Native beschreibt einen modernen Entwicklungsansatz, der Applikationen konsequent für den Betrieb in elastischen, automatisierbaren Cloud-Umgebungen entwirft. Im Vergleich zu klassischen, monolithischen Systemen ermöglicht dieser Ansatz deutlich kürzere Release-Zyklen, bessere Skalierbarkeit und eine resilientere Gesamtarchitektur. All das sind zentrale Anforderungen, die in den Kernprinzipien verankert sind.

Beschreibung: Das Diagramm zeigt den Zusammenhang von Anwendung, Betrieb, CI/CD und Infrastruktur im Cloud-Native-Zielbild der DVC.

gavel Regulatorische Bezügefeedback​

VorgabeRelevanzLink
DSGVO / DatenschutzVerarbeitung personenbezogener Daten, Privacy by Design../../rechtliches/data-protection.md
Sicherheit & ComplianceSBOM, gehartete Images, Auditierbarkeit../../vorgaben/security-compliance.md
BSI-C5-NachweiseAutomatisierbare Evidenzen aus CI/CD und Betrieb../d-stack-funktionsbausteine/bsi-c5-tooling.md

architecture Architekturdiagramm Schritt für Schritt erklärtfeedback​

  1. Frontend als Einstieg: Das Frontend (z. B. Webanwendung oder mobile Oberfläche) sendet alle Anfragen an das zentrale API Gateway.

  2. API Gateway als Kontrollpunkt: Das API Gateway übernimmt Authentifizierung, Autorisierung, Routing und Querschnittsfunktionen. Es ist damit der einheitliche Eintrittspunkt in die Fachlogik.

  3. Aufteilung in Microservices: Hinter dem Gateway ist die Anwendung in mehrere fachliche Services zerlegt:

    • Microservice A
    • Microservice B
    • Microservice C

    Jeder Service kapselt eine klar abgegrenzte Funktion und kann unabhängig entwickelt, deployed und skaliert werden.

  4. Asynchrone Kommunikation über den Message Bus: Microservice A veröffentlicht Ereignisse auf dem Message Bus. Andere Services konsumieren diese Nachrichten, ohne direkt gekoppelt zu sein. Das verbessert Skalierbarkeit und Fehlertoleranz.

  5. Eigene Datenhaltung pro Service: Die Datenbanken DB A und DB B zeigen das zentrale Cloud-Native-Prinzip "Database per Service". Fachdomänen behalten ihre Datenhoheit, statt eine gemeinsame monolithische Datenbank zu teilen.

  6. Plattformschicht für den Betrieb: Die Anwendung läuft nicht direkt auf Maschinen, sondern auf einer Betriebsplattform aus:

    • Kubernetes für Orchestrierung und Skalierung
    • Service Mesh für sichere Service-zu-Service-Kommunikation
    • Observability für Monitoring, Logging und Tracing

  7. CI/CD für kontinuierliche Auslieferung: Änderungen durchlaufen eine standardisierte Pipeline: Git → Build + Test → Security Scan → GitOps Deploy

    Dadurch wird sichergestellt, dass neue Versionen automatisiert geprüft und kontrolliert ausgerollt werden.

  8. Infrastruktur als Fundament: Unter der Plattform liegt die Infrastruktur der Deutschen Verwaltungscloud (DVC) bzw. des Sovereign Cloud Stack (SCS). Diese stellt Compute, Netzwerk und Security-Basisdienste bereit.

  9. Security als durchgehende Querschnittsfunktion: Die Security-Schicht (z. B. Cilium, Falco) ergänzt Netzwerksegmentierung, Laufzeitüberwachung und Workload-Schutz. Sicherheit ist hier kein Zusatz, sondern Teil der Zielarchitektur.

Kernaussagefeedback​

Die Architektur ist bewusst in vier kompakte Ebenen gegliedert:

  • Anwendung (Frontend, API, Microservices)
  • Betrieb (Kubernetes, Mesh, Observability)
  • Delivery (CI/CD und GitOps)
  • Infrastruktur (SCS / DVC + Security)

Damit wird sichtbar, wie fachliche Modularisierung, automatisierter Betrieb und souveräne Infrastruktur im D-Stack zusammenwirken.

memory Schlüsseltechnologienfeedback​

Containerisierung (Docker) bildet das Fundament aller Cloud-Native Deployments. Applikationen werden als unveränderliche, in sich geschlossene Container-Images paketiert, was eine reproduzierbare Ausführungsumgebung vom Entwickler-Laptop bis in die Produktion der DVC sicherstellt. Alle Container-Images müssen in einer internen Registry abgelegt und regelmäßig auf Schwachstellen gescannt werden (vgl. Sicherheitsvorgaben).

Kubernetes ist der De-facto-Standard für die Orchestrierung von Containern im Produktivbetrieb und wird als obligatorische Betriebsplattform im Sovereign Cloud Stack (SCS) eingesetzt. Kubernetes übernimmt die automatisierte Verteilung, Skalierung, Überwachung und den Selbstheilungsmechanismus (Self-Healing) von Applikationsinstanzen.

Serverless Computing ermöglicht die Entwicklung ereignisgesteuerter Microservices ohne permanente Infrastrukturverwaltung. Es eignet sich besonders für asynchrone Hintergrundprozesse und stark schwankende Lastprofile (z.B. Batch-Verarbeitung in Fachverfahren), birgt aber erhöhte Abhängigkeiten von Plattformdiensten (vgl. Microservices Muster).

CI/CD Pipelines automatisieren den gesamten Weg vom Quellcode bis zur produktiven Anwendung (Build, Test, Security-Scan, Deployment). Sie sind die technische Voraussetzung für das "Docs-as-Code"- und "Compliance-as-Code"-Prinzip, mit dem Architekturvorgaben automatisch bei jedem Commit überprüft werden.