--- title: Cloud Design Patterns description: Application-focused STACKIT design guidance with decision criteria for IaaS, PaaS, and SaaS, runtime selection, architecture guardrails, and practical design assets. sidebar: label: Cloud Design order: 1 source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/design/cloud-design-patterns/" source_file: "docs/migration/design-and-mobilize/design/cloud-design-patterns.mdx" --- ## Why this page exists The Design module decides how an application should run on STACKIT before migration runs start. This page focuses on application-level target architecture decisions, not on landing-zone foundation topics. ## What a good application design must answer For each application, the target design should answer these core questions: - **Workload model**: Should the application run on VM, Kubernetes, Cloud Foundry, static delivery, or a SaaS target? - **Service model fit**: Which service model (IaaS, PaaS, SaaS) best balances control, speed, and operational load? - **State and data path**: How are data consistency, cutover sequence, and rollback handled? - **Operations model**: Which team owns Day-1/Day-2 operations, alerting, backup, and incident response? - **Risk controls**: Which architecture decisions are mandatory, optional by exception, or explicitly out of scope? ## Service model decision guide (IaaS, PaaS, SaaS) Use this as a practical orientation for application design: - **Choose IaaS when**: You need deep OS/runtime control, legacy dependencies, or custom networking constraints that managed platforms cannot satisfy. - **Choose PaaS when**: You want faster delivery and lower operations burden while keeping application ownership and portability goals. - **Choose SaaS when**: The business process can adopt a standard product model and differentiation does not require custom platform operation. Do not choose based on team habit only. Choose based on measurable requirements, operating capacity, and life cycle goals. ## Runtime selection guide for typical STACKIT targets Best for low-change migrations and components needing OS-level control, custom agents, or strict legacy compatibility. Best for containerized workloads needing controlled scalability, release automation, and standardized platform operations. Best when teams prioritize developer productivity and fast app delivery over low-level platform control. Best for frontend/static workloads with high distribution needs and minimal backend runtime complexity. Best when process fit and standard capabilities provide higher value than migrating and operating the existing application stack. ## Design guardrails for application architecture - **Always do**: Define target runtime, data ownership, rollback triggers, and Day-1 operations before approving migration. - **Use by exception**: Temporary dual-run, manual handovers, or partial automation only with explicit risk and end-date. - **Avoid**: Mixing runtime switch, data migration, and major integration changes in one uncontrolled cutover step. - **Never do**: Approve a target design without observability baseline, backup/recovery model, and named operational ownership. ## Practical design workflow per application 1. Confirm application scope, dependencies, and non-functional requirements. 2. Decide service model fit (IaaS, PaaS, SaaS) and shortlist valid runtime targets. 3. Select one target pattern and document why alternatives were rejected. 4. Define data path, cutover sequence, validation checks, and rollback logic. 5. Capture operations ownership, monitoring baseline, and handover criteria. 6. Translate architecture decisions into the migration runbook blueprint. ## Typical STACKIT design options Spring Boot on VM with Application Load Balancer, observability integration, and backup strategy. Spring Boot on SKE with managed data services, object storage, secrets handling, and messaging. Static content delivery from Object Storage with optional CDN acceleration for internet-facing use cases. Workload access through VPN and central firewall controls for enterprise network integration. Spring Boot on Cloud Foundry with backing services such as Redis and RabbitMQ. Use the pattern cards as candidate architectures and select one explicit target per application. Do not combine multiple patterns unless coexistence is a deliberate transitional state. ## Best practices for target design on STACKIT - **Separate architecture and runbook concerns**: define the target architecture first, then derive migration sequencing and rollback steps. - **Design for operations from day one**: include observability signals, alerting boundaries, and backup or recovery expectations in the target state. - **Use managed platform capabilities intentionally**: prefer managed services where they reduce operational load without forcing unnecessary code change. - **Define network trust boundaries explicitly**: document ingress, egress, east-west controls, and hybrid connectivity needs before implementation. - **Treat secrets and access controls as design inputs**: include IAM roles, service accounts, and Secret Manager usage in the initial architecture package. - **Keep state migration independent from runtime switch**: for stateful workloads, validate data migration gates apart from runtime cutover gates. - **Add measurable acceptance criteria**: availability, latency, scaling behavior, and recovery objectives should be testable before handover. ## Related design pages - Runbook Blueprint - Replatform - Rehost - Relocate - Repurchase ## Architecture assets Use these architecture assets as concrete design references. ## Runnable migration examples (existing) Use the architecture assets to select and justify a target pattern, then use the runbook assets to run the migration path.