Provider families & multi-cloud

One platform API, many backends.

Advanced12 min · lesson 10 of 12

Because a claim is just an API you defined, the backend that fulfills it can change without the developer noticing. That is the multi-cloud angle: the same XPostgresInstance XRD can have an AWS composition and a GCP composition, and a selector decides which one fulfills a given claim — so a developer asks for “a Postgres instance” and gets one on whichever cloud your policy chooses. The platform API is stable; the implementation is swappable.

claim.yaml

apiVersion: acme.io/v1alpha1
kind: PostgresInstance
metadata: { name: orders-db, namespace: team-orders }
spec:
  size: small
  compositionSelector:
    matchLabels: { provider: aws }   # or gcp — same claim, different backend
  writeConnectionSecretToRef: { name: orders-db-conn }

Provider families

Modern cloud providers are split into families — provider-aws-rds, provider-aws-ec2, provider-aws-s3 — each a smaller package, all sharing one ProviderConfig for the family. You install only the services you use, which keeps the control plane lean and the CRD count manageable. A composition can mix resources across families (RDS + EC2 + IAM) freely, since they all reconcile through the same AWS credentials.

One API, many backends

stable contract

XRD: PostgresInstance

what developers claim

swappable implementations

Composition (AWS)

RDS + subnet + SG

Composition (GCP)

Cloud SQL + network

Developers depend on the XRD, not the cloud. The platform team changes backends without breaking claims.

Abstraction hides real differences

A single “Postgres” API over multiple clouds is powerful but leaky — clouds differ in features, limits, and failure modes, and pretending they are identical can bite you (a size that exists on AWS but not GCP, different backup semantics). Keep the abstraction honest: expose only what all backends can truly deliver, and be explicit where a claim is cloud-specific rather than portable.

Composition functionsRBAC, policy & guardrails