VM-Runtime (IaaS)
Geeignet für Low-Change-Migrationen und Komponenten mit OS-naher Kontrolle, Spezialagenten oder ausgeprägten Legacy-Abhängigkeiten.
Spring Boot auf SKE mit PostgreSQL Flex und Gateway API
STACKIT
Cloud-Design-Patterns
Zuletzt aktualisiert am
Warum diese Seite existiert
Abschnitt betitelt „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
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „Runtime-Auswahl für typische STACKIT-Zielbilder“Kubernetes-Runtime (PaaS-nahes Betriebsmodell)
Geeignet für containerisierte Workloads mit Bedarf an skalierbarer Ausführung, standardisierten Releases und Plattformbetrieb.
Cloud-Foundry-Runtime (PaaS)
Geeignet, wenn Teams hohe Entwicklerproduktivität und schnelle Bereitstellung über tiefe Plattformkontrolle priorisieren.
Statische Auslieferung mit Object Storage/CDN
Geeignet für Frontend-/Static-Workloads mit hohem Verteilungsbedarf und geringer Runtime-Komplexität.
SaaS-Ersatzpfad
Geeignet, wenn Prozessfit und Standardfähigkeiten mehr Mehrwert liefern als Migration und Betrieb des bisherigen Stacks.
Architektur-Guardrails für Designs von Anwendungen
Abschnitt betitelt „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
Abschnitt betitelt „Praktischer Design-Ablauf pro Anwendung“- Anwendungsscope, Abhängigkeiten und nicht-funktionale Anforderungen bestätigen.
- Service-Modell-Fit (IaaS, PaaS, SaaS) bewerten und zulässige Runtime-Ziele eingrenzen.
- Ein Zielmuster auswählen und dokumentieren, warum Alternativen verworfen wurden.
- Datenpfad, Cutover-Sequenz, Validierungsgates und Rollback-Logik festlegen.
- Betriebsverantwortung, Monitoring-Baseline und Handover-Kriterien definieren.
- Architekturentscheidungen in das Migrations-Runbook überführen.
Typische STACKIT-Designoptionen
Abschnitt betitelt „Typische STACKIT-Designoptionen“VM-Muster mit Betriebsbaseline
Spring Boot auf VM mit Application Load Balancer, Observability-Integration und Backup-Strategie.
Kubernetes-Plattformmuster
Spring Boot auf SKE mit gemanagten Datendiensten, Object Storage, Secret Handling und Messaging.
Statische Auslieferung mit CDN-Option
Statische Auslieferung aus Object Storage mit optionaler CDN-Beschleunigung für internetseitige Nutzung.
Hybrides Connectivity-Muster
Zugriff auf den Workload über VPN und zentrale Firewall-Controls für Enterprise-Netze.
Cloud-Foundry-Muster
Spring Boot auf Cloud Foundry mit angebundenen Backing Services wie Redis und RabbitMQ.
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
Abschnitt betitelt „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
Abschnitt betitelt „Verwandte Design-Seiten“Architektur-Assets
Abschnitt betitelt „Architektur-Assets“Diese Architektur-Assets dienen als konkrete Design-Referenzen.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Ausführbare Beispiele für Migrationen (bestehend)
Abschnitt betitelt „Ausführbare Beispiele für Migrationen (bestehend)“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Die Architektur-Assets helfen bei Auswahl und Begründung der Zielarchitektur, die Runbook-Assets bei der konkreten Umsetzung des Migrationspfad.