Skip to content

Deployment

Target Architecture — Final-State Design

The topology below describes how generated SaaS runtimes are deployed and operated across Azure compute surfaces. All infrastructure is declared as Pulumi (.NET/C#) programs, planned and applied by RuntimeEnvironmentService and reconciled by the DriftDetectionWorker.

Runtime Topology

Each generated component is placed on the Azure compute surface that fits its workload shape:

Component Compute Surface Rationale
Generated API Gateway AKS (ingress) / Azure Container Apps Stable, scalable HTTP front door
Backend Microservices AKS node pools Long-running, high-throughput, mesh-integrated
Workers Azure Container Apps / Azure Functions Event-driven, scale-to-zero capable
Admin & Customer Portals Azure App Service Managed web hosting for Blazor/MFE front ends
Mobile App backends AKS / Container Apps Shared API surface for MAUI clients
Scheduled / bursty jobs Azure Functions Consumption-based, event/timer triggered

Topology Diagram

flowchart TB
    subgraph Region["Azure Region (per environment)"]
        subgraph AKS["AKS Cluster"]
            SysPool["System Node Pool"]
            AppPool["App Node Pool (microservices)"]
            GWPool["Gateway Node Pool (ingress)"]
        end
        subgraph ACA["Container Apps Environment"]
            WorkerApps["Worker Container Apps"]
        end
        subgraph Func["Azure Functions"]
            JobsFunc["Scheduled / Event Functions"]
        end
        subgraph AppSvc["Azure App Service Plan"]
            Portals["Admin & Customer Portals"]
        end
        subgraph Data["Data & Messaging"]
            SQL[("Azure SQL / PostgreSQL")]
            Cosmos[("Cosmos DB")]
            Bus[("Azure Service Bus")]
            Blob[("Azure Blob")]
        end
        KV[("Azure Key Vault")]
        AppI[("Application Insights")]
    end
    ACR[("Azure Container Registry")] --> AppPool
    ACR --> GWPool
    ACR --> WorkerApps
    GWPool --> AppPool
    AppPool --> Data
    WorkerApps --> Bus
    JobsFunc --> Bus
    Portals --> GWPool
    AppPool --> KV
    WorkerApps --> KV
    AKS --> AppI
    ACA --> AppI
    Func --> AppI
    AppSvc --> AppI
Hold "Alt" / "Option" to enable pan & zoom

Scaling

  • AKS — Horizontal Pod Autoscaler and KEDA scalers driven by ScalingPolicy; cluster autoscaler grows/shrinks node pools; gateway and app pools scale independently.
  • Container Apps — built-in HTTP/queue-based scaling rules, including scale-to-zero for idle workers.
  • Functions — consumption/elastic-premium scaling for event and timer triggers.
  • App Service — autoscale rules per plan for portal traffic.
  • All scaling is governed by ScalingPolicy aggregates and enforced by the ScalingPolicyWorker against live Application Insights metrics.

Configuration

  • Runtime configuration is delivered as versioned RuntimeConfiguration and synced by the ConfigurationSyncWorker (e.g. AKS ConfigMaps, Container Apps env vars, App Service settings).
  • Configuration is immutable per version and never contains secret values — only SecretBinding references.

Secrets

  • Secrets are resolved at runtime from Azure Key Vault via managed identity (AKS workload identity; system/user-assigned identities elsewhere).
  • The SecretRotationWorker rotates on schedule; bindings refresh without redeploy.

Health Checks

  • Every workload exposes liveness/readiness/dependency probes via ConnectSoft.Extensions.Diagnostics.HealthChecks.
  • AKS/Container Apps use these probes for traffic gating; RuntimeHealthService aggregates them into HealthCheckResults that gate deployment promotion.

Multi-Region

Target Architecture — Final-State Design

Multi-region is a first-class option of the environment model. A RuntimeEnvironment carries a region; production workloads can be provisioned across paired Azure regions for resilience.

  • Active-passive — primary region serves traffic; a paired region is provisioned and kept warm via the same Pulumi program, promoted on failover.
  • Active-active (selected workloads) — traffic distributed via Azure Front Door / Traffic Manager, with data replicated (Azure SQL geo-replication, Cosmos DB multi-region writes).
  • Drift detection runs per region; tenant data residency is honoured per RuntimeTenantBinding (a tenant's region constrains placement).

Self-Hosting Note

The platform's own 9 services are deployed the same way they deploy generated workloads — as containerized .NET 10 services on AKS/Container Apps, provisioned by Pulumi, observed via Application Insights — so the platform operates itself with the exact mechanisms it offers.