Replatform to STACKIT: Überblick zu Spring Boot und PostgreSQL

PLAN

Spring-Boot-Replatform-Pfad

Ordnen Sie den Plattformwechsel in das vollständige Migration Framework ein: Workload bewerten, SKE und PostgreSQL Flex entwerfen, Landing Zone vorbereiten, mit expliziten Datenfreigaben migrieren und vor der Optimierung stabilisieren. Das Anwendungs-JAR bleibt gleich; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

STACKIT Migration Framework von Assess über Design and Mobilize und Migrate bis Run

PLAN

Rapid Discovery

Erstellen Sie eine erste Workload-Baseline für Spring-Boot-VM, PostgreSQL-Daten, Abhängigkeiten und Kapazität. Qualifizieren Sie die Migrationsabsicht und identifizieren Sie die Unbekannten, die eine detaillierte Discovery vor der Plattformentscheidung klären muss.

In 4 Trails

Rapid-Discovery-Prozess von der Quellerfassung bis zur ersten Migrations-Baseline

Überblick

Rapid Discovery liefert in kurzer Zeit eine schnelle, automatisierte Ausgangsbasis über bestehende Umgebungen in On-Premises- und Cloud-Landschaften. Der Fokus liegt auf der quantitativen Erfassung des IT-Portfolios, damit frühe Migrations- und kommerzielle Entscheidungen fundiert getroffen werden können.

In dieser Phase sind Mengen und Verteilung wichtiger als die detaillierten Abhängigkeiten einzelner Anwendungen.

Welche Informationen Rapid Discovery erfasst

Rapid Discovery erstellt ein initiales Inventar von Infrastruktur- und Plattform-Assets, unter anderem:

Compute-Basis

Anzahl virtueller Maschinen und Hosts.

Storage-Basis

Speicherkapazitäten und Storage-Klassen.

Betriebssystem-Landschaft

Betriebssystemfamilien und Versionen.

Kubernetes-Basis

Anzahl und Basiseigenschaften von Kubernetes-Clustern.

Datenbank-Inventar

Datenbank-Engines, Größen und Instanzanzahlen.

Diese Kennzahlen bilden die erste belastbare Sicht auf den Umfang der Migration.

Warum es in der Assess-Phase wichtig ist

Die Ergebnisse aus Rapid Discovery sind eine zentrale Grundlage für:

Frühe Preisindikation: Eine erste STACKIT-nahe Kostenindikation erzeugen.
Erste TCO-Sicht: Einen initialen TCO-Korridor ableiten.
Kapazitätsannahmen: Erste Annahmen zur Zielkapazität und Landing Zone definieren.

Dadurch können sich Programm-Stakeholder frühzeitig auf eine finanzielle Richtung und eine technische Ausgangsbasis einigen.

Abgrenzung zur Discovery-Phase

Rapid Discovery ist bewusst keine vollständige Analyse auf Applikationsebene. Es umfasst weder tiefgehende Interviews mit allen Application Ownern noch eine vollständige Abbildung aller Laufzeitabhängigkeiten.

Diese Tiefe wird in der anschließenden Discovery-Phase erreicht: Dort werden Infrastruktur-Exporte durch gezielte Assessments und Informationen der Application Owner ergänzt, um ein vollständiges Applikationsbild zu erstellen.

Typische Eingaben und zukünftige Assets

Typische Eingabequellen sind Exporte wie Tabellen oder ähnliche Inventardateien aus bestehenden Umgebungen. Die Phase kann durch KI-gestützte Tools beschleunigt werden, die aus hochgeladenen Datensätzen die benötigten Baseline-Kennzahlen extrahieren.

Rapid Discovery ist damit eine wichtige Voraussetzung für eine strukturierte Kostenindikation sowie für die Entwicklung einer realistischen Strategie für die Cloud-Zielumgebung.

KI-gestützte Discovery-Assets

KI-gestützte Discovery-Assets können helfen, Workload-Beschreibungen und Daten aus Inventaren in erste Assessment- und Design-Artefakte für die fachliche Prüfung zu überführen.

Asset-Titel

Framework

Asset-Typ

Software

CloudMent AI-Powered Cloud Advisor

CloudMent

Migration assess discovery design-and-mobilize design +5

Open Source In 1 Trail

Partner-Software-Asset für KI-gestützte STACKIT-Migrationsbewertung, R-Strategie-Auswahl, Zielarchitektur, Business Case und evidenzbasierte Migrationsplanung.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Rapid-Discovery-Prozess auf einen Blick

Das folgende Diagramm zeigt den Kern von Rapid Discovery: Rohdaten aus Quellsystemen werden durch Tooling in eine entscheidungsreife Baseline überführt, die frühe Preisindikationen und erste Sizing-Annahmen ermöglicht.

Seitlich wischen, um das ganze Diagramm zu sehen

Methodik in der Praxis

Eine belastbare Rapid Discovery folgt typischerweise einem klaren Ablauf:

Datensammlung aus vorhandenen Quellen (CMDB, Hypervisor-Exporte, Cloud-Inventare, Monitoring, Storage-Reports, Datenbanklisten).
Standardisierung und Konsolidierung der Daten in ein einheitliches Schema.
Kategorisierung nach Workload-Typen und technischen Merkmalen.
Aggregation auf Management-Ebene für schnelle Entscheidungsfindung.
Erste Plausibilisierung mit Fachverantwortlichen.

Ziel ist kein perfektes Zielbild, sondern ein verlässlicher Startpunkt mit ausreichender Genauigkeit für frühe Entscheidungen.

Datenqualität und Annahmen

Die Aussagekraft der Ergebnisse hängt stark von der Datenqualität ab. Typische Herausforderungen sind Dubletten, veraltete Einträge, inkonsistente Benennungen und fehlende Leistungsdaten.

Empfehlung für diese Phase:

Annahmen dokumentieren: Wachstumsraten, Konsolidierungsfaktoren und Reserven transparent halten.
Unklare Datensätze markieren: Unsichere Datensätze kennzeichnen statt früh zu verwerfen.
Konfidenzniveau vergeben: Ergebnisse als hoch, mittel oder niedrig einstufen.

So bleibt die Kostenindikation nachvollziehbar und später in der Discovery-Phase gezielt verfeinerbar.

Verbindung zu Preisindikation und TCO

Rapid Discovery liefert die Mengengerüste für erste Kostenmodelle. Dafür werden die erfassten Bestände in STACKIT-nahe Verbrauchseinheiten überführt, zum Beispiel:

Compute-Sizing: vCPU und RAM als Grundlage nutzen.
Storage-Klassen: Storage-Kapazität und I/O-Profile verwenden.
Managed Services: Datenbanktyp und Größenklassen zuordnen.
Plattformkosten: Cluster- und Node-Anzahlen einbeziehen.

In Kombination mit Betriebsannahmen (Betriebszeiten, Verfügbarkeit, Wachstumspfad) entsteht daraus eine belastbare Preisindikation und ein erster TCO-Korridor.

Typische Ergebnisse

Am Ende der Rapid-Discovery-Phase sollten mindestens folgende Ergebnisse vorliegen:

Konsolidierte Asset-Baseline

Mengen je Technologiebereich liegen konsolidiert vor.

Sinnvolle Segmentierung

Assets sind nach Kritikalität, Umgebung und Modernisierungsbedarf segmentiert.

Nachvollziehbare Annahmen

Annahmen und erkannte Datenlücken sind transparent dokumentiert.

Erste Kostenindikation

Eine erste Kostenbandbreite mit den wichtigsten Treibern liegt vor.

Priorisierte Kandidaten

Eine priorisierte Liste für die vertiefende Discovery-Phase ist verfügbar.

Diese Ergebnisse bilden die Arbeitsgrundlage für Architektur, Planung und Governance der nächsten Assess-Schritte.

Risiken und Gegenmaßnahmen

Häufige Risiken in Rapid Discovery sind zu grobe Kategorisierung, unvollständige Quellsysteme oder eine Überschätzung der Datenreife.

Bewährte Gegenmaßnahmen:

Datenquellen kombinieren: Mehrere Quellen nutzen statt nur einer Quelle.
Ausreißer prüfen: Sehr große oder sehr alte Systeme systematisch bewerten.
Perspektiven abstimmen: Finanz- und Technikblick gemeinsam ausrichten, um Fehlinterpretationen zu vermeiden.

Damit bleibt die Phase schnell, ohne an Entscheidungsqualität zu verlieren.

Übergang in die Discovery-Phase

Der Übergang ist erreicht, wenn ein belastbarer Überblick über Mengen, Technologietypen und Kostenhebel vorliegt und die offenen Punkte klar benannt sind.

In der Discovery-Phase werden diese offenen Punkte gezielt geschlossen, unter anderem durch Interviews mit Application Ownern, vertiefende Assessments und die Analyse von Abhängigkeiten, Compliance- und Betriebsanforderungen.

STEP

Discovery

Bestätigen Sie Java- und PostgreSQL-Kompatibilität, Zustandshaltung, geplante Schreibzugriffe, Schemaabhängigkeiten, Datenmenge und Änderungsrate, Ausfallzeittoleranz, Recovery-Ziele und repräsentativen Bedarf. Validieren Sie diese Eingaben mit den Anwendungs- und Datenbankverantwortlichen vor der Zielauswahl.

In 4 Trails

Discovery-Analyse aus technischen Messungen und Nachweisen der Anwendungsverantwortlichen

Überblick: Discovery

Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.

Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.

Zentrale Ziele

Vollständige Basis

Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.

Transparente Abhängigkeiten

Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.

Business-Abgleich

Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.

Planungsreife

Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.

Was Discovery typischerweise erfasst

Inventarisierung

Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.

Abhängigkeitsanalyse

Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.

Ressourcennutzung

Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.

Betriebskontext

Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.

Input der Application Owner

Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.

Typisches Vorgehen

In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.

Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.

Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.

Zwei Evidence-Streams: technisch vs. human-driven

Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:

Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.

Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.

Discovery-Prozess auf einen Blick

Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.

Seitlich wischen, um das ganze Diagramm zu sehen

Typische Analyse-Muster im Discovery-Tooling

Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:

Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.

Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.

KI-gestützte Discovery-Assets

KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.

Asset-Titel

Framework

Asset-Typ

Software

CloudMent AI-Powered Cloud Advisor

CloudMent

Migration assess discovery design-and-mobilize design +5

Open Source In 1 Trail

Partner-Software-Asset für KI-gestützte STACKIT-Migrationsbewertung, R-Strategie-Auswahl, Zielarchitektur, Business Case und evidenzbasierte Migrationsplanung.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Methodik in der Praxis

Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.

Warum Discovery kritisch ist

Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.

Relevanz für nachgelagerte Module

Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:

Design

Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.

Security und Compliance

Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.

Landing Zone

Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.

Migrationsplan

Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.

Operating Model und Business Case

Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.

Ergebnisse aus Discovery

Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:

Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.

Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.

LIFT

Replatform-Strategie und Werkzeuge

Bestätigen Sie die zwei bewussten Ersetzungen: Aus einem VM-Service wird ein Kubernetes-Deployment, aus VM-lokalem PostgreSQL wird PostgreSQL Flex. Behalten Sie Spring-Music-JAR und fachliches Verhalten bei; dies ist Replatform, kein VM-Rehost oder Anwendungs-Refactor.

In 2 Trails

R-Strategie-Methode mit Replatform zwischen Rehost und Refactor

Überblick: Replatform

Replatform behält das Kernverhalten der Anwendung bei, ändert aber ausgewählte Plattform-Komponenten, um betriebliche oder wirtschaftliche Vorteile zu erreichen. Der Ansatz liegt zwischen Rehost und Refactor.

Wann Replatform sinnvoll ist

Betriebliche Engpässe lassen sich durch Plattform-Fähigkeiten reduzieren.
Moderate Veränderungen sind möglich, ein vollständliches Redesign aber nicht.
Skalierungs- und Verfügbarkeitsziele erfordern Infrastruktur-Verbesserungen.
Kostenziele sind mit selektivem Plattformwechsel erreichbar.

Design-Aspekte im STACKIT-Kontext

Auswahl der Plattform-Komponenten

Festlegen, welche Schichten angepasst werden sollen (zum Beispiel Runtime, Datenbetrieb, Integrationskontrollen).

Kompatibilitätsgrenzen

Technische Randbedingungen und Fallback-Optionen vorab prüfen.

Risikogesteuerte Sequenzierung

Änderungen so staffeln, dass in einem Cutover-Fenster nicht zu viele Unbekannte zusammenkommen.

Nachweise und Abnahme

Messbare Verbesserungen für Performance, Stabilität und Betriebsaufwand definieren.

Empfohlener Design-Ablauf

Define Landing Zone für den Workload und seine Kontrollgrenzen.
Map Target Platform für Runtime-, Daten- und Integrationskomponenten.
Adapt Platform Stack mit Voraussetzungen, Sequenzierung und Rollback-Checkpoints.
Use migration tools für die Umsetzung über den gemeinsamen Migrationspfad.
Nicht-funktionale Anforderungen validieren und Übergabe freigeben.

Datenplattform bei Replatform

Für zustandsbehaftete Workloads müssen Verantwortlichkeiten in Quelle und Ziel der Datenplattform vor dem Runtime-Cutover eindeutig festgelegt werden.

Verantwortung in der Quelle: Zuständigkeit für Export/Dump und Konsistenzprüfungen festlegen.
Verantwortung im Ziel: Zuständigkeit für Managed-DB-Bereitstellung, Zugriffskontrollen und Backup-Baseline festlegen.
Ablauf der Migration: Schema-/Datenübernahme vom Runtime-Wechsel trennen und je Gate separat validieren.
Temporäre Zugriffskontrollen: Temporäre Zugriffe für die Migration plus Rücknahme-Checkpoints explizit planen.

Erforderliche Ergebnisse

Gemeinsame Ergebnisse für alle Migrationspfade

Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
Übergabepaket für Migration Factory Setup und Wellenplanung.

Replatform-spezifische Ergebnisse

Replatform-Entscheidungsmatrix mit ausgewählten Anpassungen.
Kompatibilitäts- und Randbedingungsanalyse.
Sequenziertes Migrations- und Rollback-Design.
Zielbild für den Betrieb.
Nutzenmetriken und Abnahmekriterien.

Diagramm-Schrittreferenz

Define Landing Zone

Landing-Zone-Controls und Guardrails als Ausgangspunkt für den Replatform-Pfad festlegen. Plattformvoraussetzungen für Runtime-, Daten- und Integrations-Schichten früh absichern, damit Substitutionen ohne Bruch in Governance und Betrieb eingeführt werden können.

Map Target Platform

Zielplattform-Mapping für den Replatform-Pfad über Runtime, Daten und Schnittstellen festlegen. Abhängigkeiten inklusive Identität, Netzwerk und Daten-Verantwortung explizit dokumentieren, damit jeder Wechsel vor Cutover einzeln validiert werden kann.

Adapt Platform Stack

Erforderliche Plattform-Voraussetzungen und Sequenz für den kontrollierten Wechsel definieren. Rollback-Leitplanken, Readiness-Gates und Run-Ownership festlegen, damit Wellen auch bei mehreren gleichzeitigen Plattformänderungen planbar bleiben.

STEP

Plattform und Workload automatisieren

Nutzen Sie versioniertes Terraform für Infrastruktur und Kubernetes-Ressourcen, Helm für Envoy Gateway und Routen sowie ein separates freigegebenes Skript für die Datenmigration. Halten Sie Bereitstellung und Datenaustausch unabhängig prüfbar; dieses Ziel benötigt keine Ansible-Hostkonfiguration.

In 3 Trails

Zielbild

Automatisierung stellt sicher, dass Landing-Zone-Funktionen reproduzierbar, versioniert und testbar bereitgestellt werden.

Für Migrations-Landing-Zones ist Automatisierung das Delivery-Rückgrat, das Plattform-APIs, IaC-Werkzeuge, Entwickler-Workflows und Release-Kontrollen in ein verlässliches Betriebsmodell überführt.

Kernbausteine der Automatisierung

STACKIT API: Nutzen Sie die API als grundlegende Steuerungsschnittstelle für Plattformautomatisierung und Integrationsmuster. Dokumentation
Terraform Provider: Nutzen Sie den offiziellen Provider für deklarative Infrastruktur-Bereitstellung und Lifecycle-Steuerung. Dokumentation
OpenTofu Provider: Nutzen Sie OpenTofu mit dem STACKIT Provider als offene IaC-Option mit vergleichbaren deklarativen Workflows. Dokumentation
Pulumi: Nutzen Sie Pulumi, wenn Teams für Infrastruktur-Automatisierung allgemeine Programmiersprachen bevorzugen. Dokumentation
Ansible: Nutzen Sie Ansible primär für Post-Provisioning-Konfiguration und Betriebsaufgaben. In einem kombinierten Modell stellen Terraform/OpenTofu die Infrastruktur bereit, während Ansible OS- und Middleware-Konfiguration übernimmt.
STACKIT CLI: Standardisieren Sie CLI-basierte Operationen für Skripting, Fehleranalyse und wiederholbare Betriebsaufgaben. Dokumentation
SDKs (Go, Python, Java): Nutzen Sie SDKs für kundenspezifische Automatisierung und Service-Integrationen, wenn IaC-Abstraktionen nicht ausreichen. Go SDK , Python SDK , Java SDK .
STACKIT Git: Nutzen Sie Git als Source of Truth für IaC-Module, Policies und Delivery-Workflows. Dokumentation
CI/CD Pipeline: Nutzen Sie Pipelines für Validierung, Policy-Prüfungen, kontrollierte Promotion und auditierbare Releases. Dokumentation
Container Registry: Nutzen Sie eine zentrale Registry für versionierte Build-Artefakte und konsistente Deployments über Umgebungen hinweg. Dokumentation

Wie die Bausteine zusammenspielen

Steuerungsschicht: STACKIT API, CLI und SDKs liefern direkte und programmierbare Steuerungsschnittstellen.
Provisioning-Schicht: Terraform/OpenTofu und Pulumi definieren und synchronisieren den gewünschten Infrastrukturzustand.
Konfigurationsschicht: Ansible setzt Host- und Middleware-Konfiguration nach dem Infrastruktur-Provisioning um.
Delivery-Schicht: Git und CI/CD Pipelines erzwingen Qualitäts-Gates, Policy-Prüfungen und kontrollierten Rollout über Umgebungen.
Artefakt-Schicht: Die Container Registry liefert unveränderliche und versionierte Artefakte für vorhersehbare Deployments.

Delivery-Flow mit Terraform/OpenTofu und Ansible

Terraform oder OpenTofu und Ansible lösen unterschiedliche Aufgaben innerhalb eines Delivery-Flows. Halten Sie die Grenze explizit, damit Infrastrukturänderungen prüfbar und Host-Konfigurationen wiederholbar bleiben.

Terraform / OpenTofu

Verantwortet den Infrastruktur-Lifecycle: Projekte, Netzwerke, Sicherheitskontrollen, Compute, Storage, Managed Services und die für das Konfigurationsmanagement benötigten Outputs.

Ansible

Verantwortet die Konfiguration im erreichbaren Ziel: Betriebssystempakete, Middleware, Applikationsartefakte, Service Units und die Validierung auf Workload-Ebene.

Versionieren Sie Infrastruktur-Inputs, Konfiguration und Referenzen auf Applikationsartefakte in Git.
Validieren und prüfen Sie den Terraform/OpenTofu-Plan einschließlich Ersetzungen und Security-Auswirkungen.
Wenden Sie den freigegebenen Plan an und übergeben Sie nur das von Ansible benötigte Zielinventar und die erforderlichen Outputs.
Führen Sie Ansible idempotent aus, um Betriebssystem, Middleware, Workload und Telemetrie zu konfigurieren.
Validieren Sie Infrastrukturzustand, Service Health und betriebliche Kontrollen und bewahren Sie die Nachweise auf.
Promoten Sie denselben versionierten Workflow durch die Umgebungen, statt manuelle Einrichtungsschritte zu wiederholen.

Verwischen Sie die Zuständigkeit beider Ebenen nicht durch Provisioner oder Ad-hoc-Skripte. Ansible aus Terraform anzustoßen kann eine praktische Brücke sein, aber jedes Werkzeug muss eigenständig verständlich, testbar und wiederholbar bleiben.

Empfohlenes Betriebsmodell

Empfehlung 1: Nutzen Sie Git plus CI/CD als Standard-Steuerungspfad und vermeiden Sie direkte manuelle Änderungen in produktiven Scopes.
Empfehlung 2: Wählen Sie je Plattformdomäne ein primäres IaC-Tool (Terraform oder OpenTofu), um Fragmentierung zu reduzieren.
Empfehlung 3: Nutzen Sie Ansible für Konfigurationsmanagement, nicht als Ersatz für deklaratives Infrastruktur-Provisioning.
Empfehlung 4: Nutzen Sie SDKs für domänenspezifische Automatisierung, wenn Provider-Ressourcen das gewünschte Verhalten nicht abdecken.
Empfehlung 5: Versionieren und promoten Sie Container-Artefakte über klare Umgebungsstufen mit rollbackfähigen Tags.

Wichtige Entscheidungen

Automatisierungs-Schnittstellenstrategie: Definieren Sie, wo API, CLI, SDK und IaC-Werkzeuge als Primärschnittstellen eingesetzt werden.
IaC-Tool-Strategie: Entscheiden Sie Terraform versus OpenTofu versus Pulumi anhand von Skills, Governance und Ecosystem-Fit.
Modul- und Repository-Strategie: Definieren Sie wiederverwendbare Modulgrenzen, Versionierung und Ownership.
Pipeline-Control-Modell: Implementieren Sie Validierung, Policy-Prüfungen, Freigaben und Promotion-Gates.
Artefakt- und Release-Strategie: Definieren Sie Registry-Nutzung, Image-Versionierung und Rollback-Standards.

Typische Ergebnisse

Wiederverwendbare Automatisierungs-Baseline: IaC-Module, Templates und Konfigurations-Playbooks mit Ownership-Modell.
Delivery-Blueprint: CI/CD-Flow mit Qualitäts-Gates, Policy-Prüfungen und gestufter Promotion.
Integrations-Toolkit: Standardisierte Nutzung von CLI- und SDK-Automatisierung für Betrieb und produktspezifische Workflows.
Release-Baseline: Versionierter Artefakt-Lifecycle in der Container Registry mit rollbackfähigen Praktiken.

Typische Anti-Patterns

Zu viele Automatisierungs-Paradigmen: Parallele Tool-Stacks ohne klare Ownership oder Governance-Modell.
Provisioning und Konfiguration ad hoc vermischt: Keine klare Trennung zwischen IaC-Provisioning und Ansible-Konfiguration.
Keine Artefakt-Disziplin: Veränderliche Container-Tags und unklare Release-Nachverfolgbarkeit.
CLI-Skripte ohne Git- und Pipeline-Kontrollen: Betriebsautomatisierung ist nicht verlässlich auditierbar oder reproduzierbar.

OPS

Zielarchitektur der Laufzeit

Blueprint

Spring Boot auf SKE mit PostgreSQL Flex und Gateway API

STACKIT

Migration design-and-mobilize design target-architecture replatform kubernetes postgresql object-storage spring-boot

Open Source In 2 Trails

Spring-Boot-Replatform mit SKE, PostgreSQL Flex, Gateway API, DNS und Observability entwerfen und die getestete Basis von künftigen Erweiterungen klar trennen.

Owner

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Diese Architektur überführt die VM-basierte Spring-Boot- und PostgreSQL-Quelle in eine Kubernetes-Laufzeit mit Managed-Datenbank auf STACKIT. Dasselbe Anwendungs-JAR bleibt erhalten, während sich Bereitstellung, Deployment, Traffic-Steuerung, Daten-Recovery und Betriebsverantwortung ändern.

Die Referenzbasis verwendet einen SKE-Worker und PostgreSQL Flex mit Envoy Gateway, STACKIT DNS und Observability. Die zusätzlichen Dienste und die Multi-Zonen-Topologie des nachfolgenden optionalen Erweiterungsmusters werden nicht bereitgestellt.

Einsatz

Laufzeit standardisieren: Einen systemd-verwalteten Java-Prozess durch ein reproduzierbares Deployment mit Zustandsprüfungen ersetzen.
Datenbankbetrieb verlagern: PostgreSQL in einen Managed Service überführen, ohne das Anwendungsschema neu zu entwerfen.
Plattformwechsel kontrollieren: Rollout, Skalierung, Netzwerkzugriff und Recovery vor der Produktionsabnahme unabhängig qualifizieren.

Architekturdiagramm

Laufzeit- und Datengrenzen

Ein Init-Container prüft die Prüfsumme des auf einen Commit fixierten JARs, bevor Java startet. Anwendungscontainer sind austauschbar: Die maßgeblichen Albumdaten liegen in PostgreSQL Flex, nicht im Pod-Dateisystem oder auf einem Kubernetes PersistentVolume. Kubernetes Secrets liefern Datenbankzugangsdaten; eine externe Secret-Manager-Integration ist in dieser Basis nicht implementiert.

Die Flex-ACL verwendet standardmäßig die tatsächlichen SKE-Egress-CIDRs. Anwendung und Migrationsclient benötigen verschlüsselte Datenbankverbindungen. Der Migrationsclient verwendet eine isolierte Probedatenbank und ersetzt Anwendungsdaten erst nach expliziter Freigabe und verifiziertem Backup vor dem Cutover. Für den dumpbasierten Pfad sind weder eine Verbindung zur Datenbank der Quell-VM noch eine temporäre öffentliche Flex-ACL nötig.

Netzwerkverkehr und Observability

Terraform installiert Envoy Gateway und anschließend ein lokales Routing-Chart. Der Anwendungs-Service ist vom Typ ClusterIP; Envoy stellt den öffentlichen LoadBalancer bereit. SKE-verwaltetes ExternalDNS veröffentlicht den HTTPRoute-Hostnamen anhand der Gateway-Adresse. Dies ist Gateway API, kein älterer Ingress-Controller und kein separat bereitgestellter STACKIT Application Load Balancer Service.

HTTP ist der getestete Standard. Stellen Sie für HTTPS ein vertrauenswürdiges TLS-Secret bereit und konfigurieren Sie gateway_tls_secret_name nach dem Repository-Verfahren. Ausstellung und Erneuerung von Zertifikaten bleiben externe Aufgaben. Die separaten Metrik-Listener sind in der Referenz öffentlich und ohne Authentifizierung erreichbar; schützen Sie sie vor sensibler Nutzung.

Boot 2 Actuator bindet an das pod-lokale Loopback; der Metrikadapter veröffentlicht ausgewählte Messwerte. PostgreSQL-Exporter und SKE-Monitoring-Integration beliefern Observability. Terraform erstellt Grafana-Ordner und Dashboard. Dessen Verfügbarkeit allein weist jedoch weder Anwendungszustand noch durchgängiges Scraping oder funktionierende Alarmzustellung nach.

Entscheidungen zu Verfügbarkeit und Recovery

Die getestete Worker-Anzahl, der HTTP-Endpunkt und die Beispielanwendung bilden eine funktionale Basis, keine hochverfügbare Produktionsarchitektur. Wählen Sie eine unterstützte SKE-Version und passende Zonenkapazität. Bewerten Sie mehrere Worker, Zonenverteilung, Disruption Budgets, Replikasicherheit, Datenbankverfügbarkeit und das Traffic-Routing als separate Designentscheidungen mit Ausfalltests.

Der Datenbank-Rollback stellt das Ziel vor dem Cutover wieder her; Managed-Flex-Backups dienen der Service-Recovery. Keiner der beiden Wege leitet Benutzer automatisch zur Quell-VM zurück. Definieren Sie Schreibverantwortung, Befugnis zur Traffic-Umschaltung, Rollback-Deadline, Aufbewahrung und Recovery-Ziele vor der Migration.

Optionales Erweiterungsmuster

Das folgende umfassendere Design zeigt mögliche Ergänzungen, keine vom Referenz-Terraform erstellten Ressourcen. Weitere Node Pools, Topologieregeln, persistente Volumes, RabbitMQ, Object Storage und Secret Manager benötigen eigene Implementierung, Verantwortlichkeiten und Validierung. Nutzen Sie sie nur bei nachgewiesener Workload-Anforderung; leiten Sie aus dem Diagramm keine Hochverfügbarkeit ab.

Designprinzipien

Freigaben für Laufzeit und Datenmigration entkoppeln: Datenbankmigration und Laufzeit-Rollout unabhängig validieren.
Secret-Bereitstellung explizit entwerfen: Die Referenz nutzt Kubernetes Secrets und geschützten Terraform-State; bei Bedarf eine geprüfte externe Secret-Integration ergänzen.
Observability-Labels und Dashboards standardisieren: Betrieb und Incident-Behandlung über Anwendungen hinweg vereinheitlichen.
RabbitMQ bewusst optional halten: Nur bei Bedarf an asynchroner Integration oder Pufferung ergänzen.
Verfügbarkeit separat qualifizieren: Ein Multi-Zonen-Design benötigt geeignete Worker-Kapazität, Platzierungsregeln, Disruption Budgets und Ausfalltests für Anwendung und Datenbank; die Basis aktiviert dies nicht.

Weiterführendes

Cloud Framework Spring Boot mit Terraform auf eine neue Plattform umstellen Den ausführbaren Workflow für Bereitstellung, Quellnachweise, Probe, Cutover und Rollback dieser Architektur nutzen. Seite öffnen

Repository

Code & Registry github.com STACKIT CMF Replatform Spring Boot Kubernetes Repository Repository öffnen

Datei aus dem Beispiel kopieren: cp env.tfvars.example env.tfvars
Erforderliche Werte für Identität und Projekt setzen:

service_account_key_path    = "/path/to/stackit-sa-key.json"
create_project              = true
target_project_owner_email  = "owner@sa.stackit.cloud"
parent_container_id         = "cmf-parent-container-id"
ske_cluster_name            = "rpltfk8s01"
observability_instance_name = "cmf-rpltf-observability"
dns_zone_name               = "cmf-example.runs.onstackit.cloud"
dns_zone_display_name       = "cmf-example"

Zielarchitektur-Flags setzen:

observability_enabled         = true
create_observability_instance = true
dns_enabled                   = true
create_dns_zone               = true
deploy_workload               = true
enable_postgres_flex          = true
enable_springboot_hpa         = false
enable_load_generator         = false
springboot_replicas           = 1
deploy_postgres_migration_job = false
create_grafana_dashboard     = true

Optionaler CMF-Flag-Wrapper (flags.env):

setup_project=true
setup_observability=true
setup_database=true
setup_workload=true
setup_loadgen=false
setup_dns=true

Ausführen:

terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan

Erwartetes Ergebnis: springboot_url erreicht die Anwendung über das Gateway, die Anwendung nutzt PostgreSQL Flex und grafana_dashboard_url öffnet das verwaltete Dashboard. Die Bereitstellung importiert keine Quelldaten. Führen Sie nach der Zielvalidierung den separaten Probe- und Cutover-Workflow aus; lassen Sie HPA während der gesamten Migration deaktiviert.

Code & Registry github.com Implementierte Topologie und Voraussetzungen Genaue Ressourcendefinitionen und betriebliche Grenzen im Spring-Boot-Replatform-Repository prüfen. Repository öffnen

AUTO

Datenbankmigration

Entwerfen Sie den Datenbankumzug unabhängig von der Laufzeitbereitstellung. Definieren Sie Quellschreibstopp, konsistenten Dump mit Manifest, isolierte Probe, nachgewiesenes Zielbackup, transaktionalen Restore und Rollback-Deadline. Traffic-Umschaltung und Quell-Failback bleiben explizite Betreiberentscheidungen.

In 2 Trails

Kontrollpunkte der Migrationswelle von Bereitschaft über Cutover und Validierung bis zur Übergabe

Überblick: Replatform

Replatform behält das Kernverhalten der Anwendung bei, ändert aber ausgewählte Plattform-Komponenten, um betriebliche oder wirtschaftliche Vorteile zu erreichen. Der Ansatz liegt zwischen Rehost und Refactor.

Wann Replatform sinnvoll ist

Betriebliche Engpässe lassen sich durch Plattform-Fähigkeiten reduzieren.
Moderate Veränderungen sind möglich, ein vollständliches Redesign aber nicht.
Skalierungs- und Verfügbarkeitsziele erfordern Infrastruktur-Verbesserungen.
Kostenziele sind mit selektivem Plattformwechsel erreichbar.

Design-Aspekte im STACKIT-Kontext

Auswahl der Plattform-Komponenten

Festlegen, welche Schichten angepasst werden sollen (zum Beispiel Runtime, Datenbetrieb, Integrationskontrollen).

Kompatibilitätsgrenzen

Technische Randbedingungen und Fallback-Optionen vorab prüfen.

Risikogesteuerte Sequenzierung

Änderungen so staffeln, dass in einem Cutover-Fenster nicht zu viele Unbekannte zusammenkommen.

Nachweise und Abnahme

Messbare Verbesserungen für Performance, Stabilität und Betriebsaufwand definieren.

Empfohlener Design-Ablauf

Define Landing Zone für den Workload und seine Kontrollgrenzen.
Map Target Platform für Runtime-, Daten- und Integrationskomponenten.
Adapt Platform Stack mit Voraussetzungen, Sequenzierung und Rollback-Checkpoints.
Use migration tools für die Umsetzung über den gemeinsamen Migrationspfad.
Nicht-funktionale Anforderungen validieren und Übergabe freigeben.

Datenplattform bei Replatform

Für zustandsbehaftete Workloads müssen Verantwortlichkeiten in Quelle und Ziel der Datenplattform vor dem Runtime-Cutover eindeutig festgelegt werden.

Verantwortung in der Quelle: Zuständigkeit für Export/Dump und Konsistenzprüfungen festlegen.
Verantwortung im Ziel: Zuständigkeit für Managed-DB-Bereitstellung, Zugriffskontrollen und Backup-Baseline festlegen.
Ablauf der Migration: Schema-/Datenübernahme vom Runtime-Wechsel trennen und je Gate separat validieren.
Temporäre Zugriffskontrollen: Temporäre Zugriffe für die Migration plus Rücknahme-Checkpoints explizit planen.

Erforderliche Ergebnisse

Gemeinsame Ergebnisse für alle Migrationspfade

Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
Übergabepaket für Migration Factory Setup und Wellenplanung.

Replatform-spezifische Ergebnisse

Replatform-Entscheidungsmatrix mit ausgewählten Anpassungen.
Kompatibilitäts- und Randbedingungsanalyse.
Sequenziertes Migrations- und Rollback-Design.
Zielbild für den Betrieb.
Nutzenmetriken und Abnahmekriterien.

Diagramm-Schrittreferenz

Define Landing Zone

Landing-Zone-Controls und Guardrails als Ausgangspunkt für den Replatform-Pfad festlegen. Plattformvoraussetzungen für Runtime-, Daten- und Integrations-Schichten früh absichern, damit Substitutionen ohne Bruch in Governance und Betrieb eingeführt werden können.

Map Target Platform

Zielplattform-Mapping für den Replatform-Pfad über Runtime, Daten und Schnittstellen festlegen. Abhängigkeiten inklusive Identität, Netzwerk und Daten-Verantwortung explizit dokumentieren, damit jeder Wechsel vor Cutover einzeln validiert werden kann.

Adapt Platform Stack

Erforderliche Plattform-Voraussetzungen und Sequenz für den kontrollierten Wechsel definieren. Rollback-Leitplanken, Readiness-Gates und Run-Ownership festlegen, damit Wellen auch bei mehreren gleichzeitigen Plattformänderungen planbar bleiben.

BASE

Landing Zone

Etablieren Sie Governance, Identität, Sicherheit, Netzwerk, Kostenkontrollen und Automatisierung, bevor das Ziel davon abhängt. Bestätigen Sie Projektberechtigungen, Betreiberzugriff, DNS-Delegation, SKE-Kapazität, Datenbankzugriffsgrenzen und geschützten Terraform-State.

In 5 Trails

Sechs Kernkomponenten einer gesteuerten STACKIT Landing Zone

Überblick: Landing Zones

Eine Landing Zone ist die strukturierte Cloud-Grundlage, die festlegt, wie Ihre Organisation auf STACKIT von Anfang an betrieben wird. Sie verbindet Governance, Identität, Security, Netzwerkarchitektur, Kostensteuerung und Automatisierung zu einem belastbaren Rahmen.

Ohne diese Grundlage stocken Migrationswellen typischerweise durch fehlende Freigaben, inkonsistente Kontrollen und wiederkehrende Plattformentscheidungen.

Kernkomponenten

Die folgende Visualisierung zeigt die zentralen Komponenten für eine belastbare Plattform-Basis.

Warum Sie eine Landing Zone brauchen

Kontrolle und Risikoreduktion: Security- und Compliance-Kontrollen werden konsistent umgesetzt.
Skalierbare Delivery-Basis: Wiederverwendbare Muster beschleunigen mehrere Migrationswellen.
Klare Verantwortlichkeiten: Zuständigkeiten zwischen Plattform-, Security- und Applikationsteams sind klar.
Höhere Umsetzungsgeschwindigkeit: Grundlegende Kontrollen müssen nicht je Applikation neu entworfen werden.

Wann Sie starten sollten

Starten Sie den Landing-Zone-Stream so früh wie möglich parallel zum Discovery.

Zu spät: Produktive Migrationen werden blockiert, weil Pflichtkontrollen noch fehlen.
Zu früh ohne Discovery-Feedback: Relevante Applikationsrandbedingungen fehlen und führen zu Nacharbeit.

Bewährt hat sich ein zweigleisiges Vorgehen: Die Plattform-Basis früh etablieren und Application-Landing-Zone-Templates iterativ mit Discovery-Erkenntnissen verfeinern.

Zwei Ebenen: Platform und Application Landing Zone

Platform Landing Zone

Unternehmensweite Grundlage für Governance, Identität, Security, Netzwerk, Kostensteuerung und Automatisierung.

Zur Platform Landing Zone

Application Landing Zone

Workload-spezifische Umsetzungsprofile, abgeleitet aus Plattform-Basis und Discovery-Ergebnissen.

Zur Application Landing Zone

Typische Eingaben aus dem Unternehmen

Für ein belastbares Landing-Zone-Design werden typischerweise benötigt:

Organisations- und Ownership-Modell: Einheiten, Projektgrenzen und Verantwortungsmodell.
Compliance- und Policy-Anforderungen: Regulatorische Pflichten und interne Kontrollvorgaben.
Security-Anforderungen: IAM-Standards, Netzsegmentierung, Verschlüsselung und Logging.
Betriebs- und Supportvorgaben: Incident-Prozesse, Eskalationswege und Übergabemodell.
Erkenntnisse aus dem Applikationsportfolio: Discovery-Resultate zu Abhängigkeiten und Archetypen.

Vorgehensmodell

Unternehmensweite Leitplanken und Kontrollmodell definieren.
Platform Landing Zone als Code aufbauen und validieren.
Application-Landing-Zone-Templates aus Discovery und Migrationsdesign ableiten.
Mit Pilot-Workloads testen und über Migration-Factory-Runbooks skalieren.

STACKIT Beschleuniger und Assets

Um die Umsetzung zu beschleunigen, bietet STACKIT konkrete Best Practices und wiederverwendbare Vorlagen:

Asset-Titel

Framework

Asset-Typ

Blueprint

STACKIT Landing Zone Accelerator

STACKIT

Migration design-and-mobilize landing-zone opentofu terraform +1

Open Source In 2 Trails

STACKIT Basis-Asset zum Aufbau einer Platform Landing Zone mit wiederverwendbaren OpenTofu/Terraform-Modulen, Enterprise-Standards und zentralem Kubernetes.

STACKIT Landing Zone Accelerator

Migration

Blueprint

VM Application Landing Zone für Relocate

STACKIT

Migration design-and-mobilize landing-zone relocate vmware +4

Open Source In 1 Trail

Technisches Blueprint zum Aufbau einer VM Application Landing Zone mit STACKIT Accelerator, manuellen Security Groups und Coriolis- oder Acura-Übergabe.

VM Application Landing Zone für Relocate

Migration

Blueprint

Service

Managed Landing Zone Service

STACKIT

Migration design-and-mobilize landing-zone managed-service opentofu +1

Managed Asset Marketplace In 1 Trail

STACKIT Managed Service für Beratung, Einrichtung und Umsetzung von Landing Zones mit OpenTofu, Terragrunt und Boilerplate-Accelerators für Migration.

Managed Landing Zone Service

Migration

Service

Blueprint

meshStack Self-Service Landing Zone

meshcloud

Migration design-and-mobilize landing-zone dev-platform opentofu

Open Source

Referenzarchitektur, die eine STACKIT Landing Zone um Self-Service mit Governance ergänzt: Applikationsteams bestellen Projekte und geroutete Netzwerke selbst.

meshStack Self-Service Landing Zone

Migration

Blueprint

Software

pfSense-Firewall-Connectivity-Pattern

STACKIT

Migration design-and-mobilize landing-zone network network-area +3

Open Source

Leitfaden für den Einsatz der STACKIT pfSense Firewall als zentraler Kontrollpunkt in Hub-and-Spoke-Network-Area-Architekturen für sichere STACKIT-Migrationen.

pfSense-Firewall-Connectivity-Pattern

Migration

Software

Service

CAF Landing Zones Implementation (PRODYNA)

PRODYNA

Migration design-and-mobilize landing-zone caf managed-service +1

Managed Asset Marketplace In 1 Trail

CAF Landing Zone Foundation Accelerator von PRODYNA: ein CAF-basierter Enterprise-IaC-Blueprint-Hackathon für sichere und skalierbare STACKIT Landing Zones.

CAF Landing Zones Implementation (PRODYNA)

Migration

Service

Basis als Code beschleunigen

Nutzen Sie bei Bedarf den Landing Zone Accelerator für die gesteuerte Projekt- und Plattformbasis. Halten Sie Verantwortlichkeiten getrennt: Das Anwendungsteam verantwortet SKE-Workload, Datenmigration, Gateway, Telemetrie und Workload-Recovery.

Landing Zone Accelerator mit getrennten Verantwortlichkeiten für Plattformbasis und Anwendungsworkload

LIVE

Migration Framework

Starten Sie die Migrationswelle mit freigegebenem Zieldesign, bereiter Application Landing Zone, getestetem Runbook und benannten Entscheidungsverantwortlichen. Führen Sie Bereitschaft, Migration, Cutover, Validierung, Stabilisierung und Übergabe als einen kontrollierten Ablauf aus.

In 4 Trails

Überblick: Migrate-Modul

Dieses Modul setzt die eigentliche technische Migration in der Migration Factory um. Zu diesem Zeitpunkt sind Entscheidungen aus Design getroffen, Landing Zones aufgebaut und Wellen geplant.

Der Fokus liegt auf reproduzierbarer Umsetzung für:

Relocate: Verlagerung von Workloads mit minimalen Änderungen an Annahmen zur Plattform.
Rehost: Lift-and-Shift auf STACKIT mit kontrolliertem Cutover und Rollback-Bereitschaft.
Replatform: Gezielte Anpassungen an der Plattform während der Migration ohne vollständiges Redesign.

Abhängigkeiten aus Design and Mobilize

Migrate startet erst, wenn aus der vorherigen Phase umsetzbare Ergebnisse vorliegen:

Design je Anwendung: Zielbild, Schnittstellen, Daten und nicht-funktionale Anforderungen sind festgelegt.
Zuordnung zur Wellenplanung: Jede Anwendung ist einer freigegebenen Welle mit Zeitfenster und Abhängigkeiten zugeordnet.
Runbook je Pfad der Migration: Für Pfad und Typ von Workload liegt ein validiertes Runbook vor, inklusive Go/No-Go-, Cutover- und Rollback-Kriterien.
Zuordnung zur Application Landing Zone: Anwendungen sind der passenden Ziel-Landing-Zone und Ownership zugeordnet.
Entscheidungswege und Kommunikation: Entscheidungswege, Eskalationsprozess und Kommunikation mit dem Application Owner sind festgelegt, inklusive der Frage, ob der Cutover gemeinsam durchgeführt werden muss.

Verweise auf Module:

End-to-End-Ablauf in der Factory

Wellenscope, Cutover-Fenster, Rollback-Kriterien und Runbook-Verantwortung final bestätigen.
Wellen-Baseline einfrieren (Versionen, Abhängigkeiten, Datenscope, Schnittstellenverträge).
Technische Readiness-Prüfungen in Quelle und Ziel durchführen.
Runbook-Schritte je Workload-Archetyp und R-Strategie-Pfad ausführen.
Cutover durchführen und Traffic gemäß Wellenplan auf STACKIT umschalten.
Technische, funktionale und operative Akzeptanzkriterien validieren.
Stabilisierungsmaßnahmen in kurzen Feedback-Schleifen umsetzen.
Stabilisierte Workloads an Optimize und Operate übergeben.

Ablauf je R-Pfad

Relocate-Ablauf

Platzierung im Ziel auf STACKIT mit äquivalenten Annahmen zur Topologie herstellen.
Daten und Zustände mit Konsistenzprüfungen migrieren.
Traffic mit Rollback-Leitplanken umschalten.
Geschäftskontinuität und operative Telemetrie verifizieren.

Rehost-Ablauf

Applikationen und Daten weitgehend unverändert übertragen.
Infrastruktur-Bindings und Konnektivität auf STACKIT neu zuordnen.
Kontrollierten Cutover mit Smoke-Tests durchführen.
Phase zur Stabilisierung und Performance-Baseline abschließen.

Replatform-Ablauf

Ausgewählte Managed Services und Plattformfunktionen in den Pfad der Migration integrieren.
Konfiguration, Deployment-Artefakte und Kontrollen im Betrieb anpassen.
Cutover mit Kompatibilitäts- und Datenintegritätsprüfungen durchführen.
SLO-Verhalten und Betriebsreife der Zielumgebung nachweisen.

Zentrale Artefakte pro Welle

Runbook-Nachweise

Vollständige Runbook-Protokolle, Entscheidungsnachweise und Rollback-Checkpoints pro Workload.

Cutover-Report

Zeitlich nachvollziehbares Ergebnis mit Abnahme, Defekten und eingeleiteten Maßnahmen.

Operative Baseline

Initiales Monitoring, Alerting, Ownership und Incident-Prozesse in der Zielumgebung.

Optimize-Backlog

Priorisierte Maßnahmen für Rightsizing, Performance-Tuning und Kostenoptimierung.

Abgrenzung zu Optimize, Repurchase und Refactor

Optimize startet direkt nach stabilem Cutover und nutzt Daten aus dem Betrieb für Tuning und Kostensteuerung: Optimize.
Repurchase folgt einer anderen SaaS-Logik und läuft bewusst außerhalb des klassischen Modells mit Wellen: Repurchase.
Refactor wird als eigener Pfad für Transformation geführt: Refactor.

Unterstützung direkt nach dem Cutover kann sich zeitlich mit Optimize überschneiden, wird aber inhaltlich in der Run-Phase behandelt.

SAFE

Entscheidungen und Migrationsfreigaben

Runbook

Spring Boot und PostgreSQL auf SKE und PostgreSQL Flex umstellen

STACKIT

Migration design-and-mobilize use-cases replatform spring-boot postgresql ske cutover migration

Open Source In 2 Trails

Spring-Boot-Replatform kontrolliert umsetzen: mit Quellnachweisen, isolierter PostgreSQL-Probe, freigegebenem Cutover, geprüftem Rollback und Betriebsübergabe.

Owner

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

BASE

Technische Umsetzung

STACKIT Neu

Replatform to STACKIT: Spring Boot auf SKE und PostgreSQL Flex

Migrieren Sie Spring Boot und PostgreSQL auf SKE und PostgreSQL Flex: Quelle und Ziel vorbereiten, Datenübernahme proben, Cutover prüfen und Betrieb übergeben.

Migration replatform spring-boot postgresql ske +4

Trail Steps

Replatform-Strategie und Werkzeuge
Zielarchitektur der Laufzeit
Referenzimplementierung
Labor und Repositorys vorbereiten

+ 19 more steps

GOAL

Abnehmen und an den Betrieb übergeben

Runbook

Spring Boot und PostgreSQL auf SKE und PostgreSQL Flex umstellen

STACKIT

Migration design-and-mobilize use-cases replatform spring-boot postgresql ske cutover migration

Open Source In 2 Trails

Spring-Boot-Replatform kontrolliert umsetzen: mit Quellnachweisen, isolierter PostgreSQL-Probe, freigegebenem Cutover, geprüftem Rollback und Betriebsübergabe.

Owner

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

GOAL

Stabilisieren und optimieren

Kehren Sie zum Optimize-Zyklus des Migration Framework zurück: repräsentative Betriebsnachweise sammeln, begrenzende Ebene identifizieren, eine kontrollierte Änderung umsetzen und Zuverlässigkeit, Performance sowie Kosten vor dem Beibehalten validieren.

In 7 Trails

Überblick: Optimize-Modul

Optimize startet, sobald Workloads auf STACKIT laufen und reale Daten aus dem Betrieb vorliegen. Das Modul überführt Beobachtungen aus dem Betrieb in messbare Verbesserungen für Performance, Stabilität und Wirtschaftlichkeit.

Optimize ist keine einmalige Aufgabe, sondern ein iterativer Zyklus, der sich mit früher Stabilisierung und Unterstützung direkt nach dem Cutover überschneiden kann.

Warum Optimize nach dem Cutover liegt

Viele Entscheidungen zu Rightsizing und Tuning sind erst unter echter Last belastbar. Nach dem Cutover lassen sich Annahmen mit Daten aus dem Betrieb validieren und präzisieren.

Optimize-Zyklus

Laufzeitdaten erfassen: Auslastung, Latenz, Fehlerquoten, Durchsatz und Kostentreiber.
Engpässe und Verschwendungsmuster auf Workload-, Plattform- und Datenebene identifizieren.
Maßnahmen nach Business-Effekt, Risikoreduktion und FinOps-Nutzen priorisieren.
Tuning-Änderungen in kontrollierten Inkrementen umsetzen.
Ergebnisse gegen SLO-, Stabilitäts- und Kostenziele validieren.
Erkenntnisse in Folgewellen und Betriebsstandards zurückführen.

Typische Bereiche

Rightsizing: Compute-, Storage- und Netzwerkressourcen an reale Last anpassen.
Performance-Tuning: Latenz und Durchsatz durch Konfiguration, Skalierung und Architekturmaßnahmen verbessern.
Reliability-Hardening: Incident-Häufigkeit durch Resilienz-, Monitoring- und Fehlerbehandlungsmaßnahmen reduzieren.
FinOps-Steuerung: Kostentransparenz verbessern, Verschwendung abbauen und Run-Rate optimieren.

Von der Theorie zur Umsetzung

Optimierungsentscheidungen sollten auf Laufzeitdaten basieren, nicht auf Annahmen. Für die praktische Umsetzung werden Workload-Telemetrie, Alerting und kontrollierte Infrastrukturänderungen kombiniert.

Managed-Observability-Basis: Mit STACKIT Observability Metriken, Logs und Traces mit Grafana, Prometheus, Thanos, Loki und Tempo erfassen.
Erkennungslogik: Klare Schwellwerte und Beobachtungsfenster für Unterauslastung und Überlast definieren.
Umsetzungspfad: Rightsizing über IaC-Änderungen (zum Beispiel VM-Flavors) mit Rollback-Checkpoints umsetzen.
Validierungsschleife: Nach jedem Tuning-Inkrement SLO, Fehlerquote und Laufkosten erneut messen.

Konkrete Beispiel-Assets

Asset-Titel

Framework

Asset-Typ

Runbook

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Migration migrate optimize rehost observability +2

Open Source In 2 Trails

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

Migration

Runbook

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Migration design-and-mobilize use-cases migrate optimize +6

Open Source In 2 Trails

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

Migration

Runbook

Replatform Spring Boot auf Cloud Foundry mit Autoscaling und Rightsizing optimieren

STACKIT

Migration migrate optimize replatform cloud-foundry +3

Open Source

Praktisches Optimize-Runbook für einen auf STACKIT Cloud Foundry migrierten Spring-Boot-Workload mit Observability-Signalen, Autoscaling und Validierung.

Replatform Spring Boot auf Cloud Foundry mit Autoscaling und Rightsizing optimieren

Migration

Runbook

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

STACKIT

Migration migrate optimize relocate vm +3

Open Source In 1 Trail

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

Migration

Runbook

Replatform-Optimierungsdimensionen

Für Replatform-Workloads auf Kubernetes umfasst Optimierung mehrere Ebenen und sollte als gemeinsamer Regelkreis gesteuert werden.

Pod-Skalierung: HPA nutzen, um die Replikazahl anhand von Last mit klaren Min-/Max-Grenzen anzupassen.
Node-Pool-Skalierung: Ausreichend Cluster-Headroom sicherstellen und den Maschinentyp (Flavor) für CPU-/Memory-Dichteanforderungen abstimmen.
Ingress-Skalierung: Den Serviceplan des Load Balancers neu bewerten, wenn Ingress-Durchsatz oder Verbindungsverhalten zum Engpass werden.
Storage-Rightsizing: Storage-Klassen nach Performance-Anforderungen persistenter Workloads auswählen.
Validierungsdisziplin: Nach jeder inkrementellen Tuning-Änderung Latenz, Fehlerquote und Kosten erneut prüfen.

Eingaben und Ergebnisse

Zentrale Eingaben

Cutover-Berichte, Incident-Trends, SLO-Messwerte, Telemetrie-Baselines und Kostenberichte.

Ergebnisse

Priorisiertes Verbesserungs-Backlog, validierte Tuning-Änderungen und aktualisierte Betriebsstandards.

Governance-Effekt

Nachvollziehbare Trade-off-Entscheidungen zwischen Performance, Stabilität und Kosten.

Abgrenzung zu anderen Modulen

Optimize folgt auf die technische Umsetzung in Migrate.
Aktivitäten direkt nach dem Cutover können parallel laufen, die fachliche Verankerung erfolgt jedoch in der Run-Phase.
Umfassende Umbauten bleiben im Modul Refactor.

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg