---
title: Cloud-Design-Patterns
description: Anwendungsorientierte STACKIT-Designleitlinie mit Entscheidungskriterien für IaaS, PaaS und SaaS, Runtime-Auswahl, Guardrails und Design-Assets für Teams.
sidebar:
  label: Cloud Design
  order: 1
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/design/cloud-design-patterns/"
source_file: "docs/de/migration/design-and-mobilize/design/cloud-design-patterns.mdx"
---

## Warum diese Seite existiert

Das Design-Modul entscheidet vor der Ausführung der Migration, wie eine Anwendung auf STACKIT betrieben werden soll.
Diese Seite fokussiert auf Zielarchitektur-Entscheidungen für Anwendungen, nicht auf Landing-Zone-Basisthemen.

## Welche Fragen ein gutes Design der Anwendung beantworten muss

Für jede Anwendung sollte das Zielbild diese zentralen Fragen beantworten:

- **Workload-Modell**: Soll die Anwendung auf VM, Kubernetes, Cloud Foundry, als statische Auslieferung oder auf einem SaaS-Ziel laufen?
- **Service-Modell-Fit**: Welches Service-Modell (IaaS, PaaS, SaaS) balanciert Kontrolle, Geschwindigkeit und Betriebsaufwand am besten?
- **State- und Weg der Daten**: Wie werden Datenkonsistenz, Cutover-Sequenz und Rollback umgesetzt?
- **Betriebsmodell**: Welches Team verantwortet Day-1/Day-2-Betrieb, Alerting, Backup und Incident Response?
- **Regeln für Risiken**: Welche Architekturentscheidungen sind verpflichtend, nur als Ausnahme zulässig oder ausdrücklich ausgeschlossen?

## Orientierung zum Service-Modell (IaaS, PaaS, SaaS)

Diese Orientierung hilft bei der praktischen Auswahl für Designs von Anwendungen:

- **IaaS wählen, wenn**: Tiefe OS-/Runtime-Kontrolle, Legacy-Abhängigkeiten oder spezielle Anforderungen ans Netzwerk erforderlich sind.
- **PaaS wählen, wenn**: Schnellere Lieferung und weniger Betriebsaufwand gewünscht sind, bei weiterhin eigener Verantwortung für die Anwendung.
- **SaaS wählen, wenn**: Der Geschäftsprozess ein standardisiertes Produkt akzeptiert und Differenzierung keinen eigenen Plattformbetrieb erfordert.

Nicht nach Gewohnheit entscheiden. Auf Basis messbarer Anforderungen, verfügbarer Betriebskapazität und Zielen über den Lebenszyklus entscheiden.

## Runtime-Auswahl für typische STACKIT-Zielbilder

<CardGrid>
  <Card title="VM-Runtime (IaaS)">
    Geeignet für Low-Change-Migrationen und Komponenten mit OS-naher Kontrolle, Spezialagenten oder
    ausgeprägten Legacy-Abhängigkeiten.
  </Card>
  <Card title="Kubernetes-Runtime (PaaS-nahes Betriebsmodell)">
    Geeignet für containerisierte Workloads mit Bedarf an skalierbarer Ausführung, standardisierten
    Releases und Plattformbetrieb.
  </Card>
  <Card title="Cloud-Foundry-Runtime (PaaS)">
    Geeignet, wenn Teams hohe Entwicklerproduktivität und schnelle Bereitstellung über tiefe
    Plattformkontrolle priorisieren.
  </Card>
  <Card title="Statische Auslieferung mit Object Storage/CDN">
    Geeignet für Frontend-/Static-Workloads mit hohem Verteilungsbedarf und geringer
    Runtime-Komplexität.
  </Card>
  <Card title="SaaS-Ersatzpfad">
    Geeignet, wenn Prozessfit und Standardfähigkeiten mehr Mehrwert liefern als Migration und
    Betrieb des bisherigen Stacks.
  </Card>
</CardGrid>

## Architektur-Guardrails für Designs von Anwendungen

- **Immer umsetzen**: Ziel-Runtime, Verantwortung für Daten, Rollback-Trigger und Day-1-Betrieb vor Freigabe der Migration festlegen.
- **Nur als Ausnahme**: Temporärer Dual-Run, manuelle Handover oder teilweise Automatisierung nur mit explizitem Risiko und Enddatum.
- **Vermeiden**: Runtime-Wechsel, Datenmigration und große Integrationsänderungen in einem unkontrollierten Cutover bündeln.
- **Nie umsetzen**: Kein Zielbild ohne Observability-Baseline, Backup-/Recovery-Modell und klar benannte Betriebsverantwortung freigeben.

## Praktischer Design-Ablauf pro Anwendung

<Steps>

1. Anwendungsscope, Abhängigkeiten und nicht-funktionale Anforderungen bestätigen.
2. Service-Modell-Fit (IaaS, PaaS, SaaS) bewerten und zulässige Runtime-Ziele eingrenzen.
3. Ein Zielmuster auswählen und dokumentieren, warum Alternativen verworfen wurden.
4. Datenpfad, Cutover-Sequenz, Validierungsgates und Rollback-Logik festlegen.
5. Betriebsverantwortung, Monitoring-Baseline und Handover-Kriterien definieren.
6. Architekturentscheidungen in das Migrations-Runbook überführen.

</Steps>

## Typische STACKIT-Designoptionen

<CardGrid>
  <Card title="VM-Muster mit Betriebsbaseline">
    Spring Boot auf VM mit Application Load Balancer, Observability-Integration und
    Backup-Strategie.
  </Card>
  <Card title="Kubernetes-Plattformmuster">
    Spring Boot auf SKE mit gemanagten Datendiensten, Object Storage, Secret Handling und Messaging.
  </Card>
  <Card title="Statische Auslieferung mit CDN-Option">
    Statische Auslieferung aus Object Storage mit optionaler CDN-Beschleunigung für internetseitige
    Nutzung.
  </Card>
  <Card title="Hybrides Connectivity-Muster">
    Zugriff auf den Workload über VPN und zentrale Firewall-Controls für Enterprise-Netze.
  </Card>
  <Card title="Cloud-Foundry-Muster">
    Spring Boot auf Cloud Foundry mit angebundenen Backing Services wie Redis und RabbitMQ.
  </Card>
</CardGrid>

Die Pattern-Karten dienen als mögliche Zielbilder. Pro Anwendung sollte ein explizites Zielbild gewählt werden.
Mehrere Muster nur kombinieren, wenn Koexistenz bewusst als Übergangszustand geplant ist.

## Best practices für Zielbilder auf STACKIT

- **Architektur und Runbook trennen**: zuerst das Zielbild definieren, danach Sequenz und Rollback für die Migration ableiten.
- **Betrieb von Anfang an einplanen**: Observability-Signale, Alarm-Grenzen und Backup- oder Recovery-Erwartungen im Zielzustand festlegen.
- **Managed Services bewusst nutzen**: gemanagte Plattform-Services bevorzugen, wenn sie Betriebsaufwand senken und keine unnötige Codeänderung erzwingen.
- **Vertrauensgrenzen im Netzwerk explizit definieren**: Ingress, Egress, Ost-West-Controls und Hybrid-Bedarf vor der Umsetzung dokumentieren.
- **Secrets und Zugriffe als Design-Input behandeln**: IAM-Rollen, Service Accounts und Secret-Manager-Nutzung früh im Architektur-Paket aufnehmen.
- **Datenmigration vom Runtime-Wechsel entkoppeln**: bei stateful Workloads Daten-Gates getrennt von Runtime-Cutover validieren.
- **Messbare Abnahmekriterien festlegen**: Verfügbarkeit, Latenz, Skalierung und Recovery müssen vor Handover prüfbar sein.

## Verwandte Design-Seiten

- <LinkChip href="/de/migration/design-and-mobilize/design/runbook/">Runbook Blueprint</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/replatform/">Replatform</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/rehost/">Rehost</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/relocate/">Relocate</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/repurchase/">Repurchase</LinkChip>

## Architektur-Assets

Diese Architektur-Assets dienen als konkrete Design-Referenzen.

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag={["design", "target-architecture"]}
/>

## Ausführbare Beispiele für Migrationen (bestehend)

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag="runnable-example"
/>

Die Architektur-Assets helfen bei Auswahl und Begründung der Zielarchitektur, die Runbook-Assets bei der konkreten Umsetzung des Migrationspfad.