Layer stack · 05 of 10 · Multi-cloud platform

One platform surface across every cloud

Teams ask for a capability once. Only the compositions layer knows whether that is AWS, Azure or Google Cloud, so product teams converge on one surface and differ only where regulation or workload genuinely requires it.

One platform surface across every cloud Layer stack from foundations at the bottom through GitOps delivery, cloud-specific Crossplane compositions, the golden-path API and product teams at the top, marking Terraform below and Crossplane plus ArgoCD above, with cloud differences confined to the compositions layer. L5Product teamsevery team uses the same APIsTeam CTeam BTeam AL4Golden-path APIone typed abstraction per capabilitySecretsQueuePostgreSQLApplicationL3Compositionscloud specifics live here and nowhere elseGoogle CloudAzureAWSL2GitOps deliveryper-cluster repos · lower/upper AppProject boundaryper-cluster repoKyvernoArgoCDL1Foundationsaccounts · networks · clusters · IAM rootsGKEAKSEKSTerraformTERRAFORM BELOW · CROSSPLANE + ARGOCD ABOVEABSTRACTCONCRETELEGENDWhere clouds differShared across cloudsProvisioned onceTooling boundary

Problem

Multi-cloud Kubernetes, IaC, GitOps. Serve every product team without a separate platform for each one; converge where they drifted for no reason.

Design choices

  • Terraform for foundations; Crossplane and Argo for everything above the cluster. State the boundary out loud.
  • PostgreSQL becomes RDS, Azure Database or Cloud SQL from the same XR.
  • Convergence is a queue: inventory drift, score justified vs accidental, converge the accidental.

Evidence and gap

Built in Hangar: the per-cluster repo decision, two ArgoCD instances per cluster, lower/upper AppProject boundary, generator-driven cluster bootstrap, a PostgreSQL component on CNPG. Gap: Hangar runs on kind and Apple container, not on a public cloud.

Hangar · reference architecture