RFC: IaC strategy — Pulumi integration vs first-party IaC primitive

[ChrisonSimtian]

Part of the Continuous Delivery Vision (#8). The strategic fork for the infrastructure-as-code pillar identified in the taxonomy RFC (#285).

The fork

For the IaC side of CD, two broad directions:

A) Pulumi integration

Lean on Pulumi (already C#-native, multi-cloud, mature provider ecosystem) and give Fallout a clean integration surface. Users who want IaC bring Pulumi; Fallout orchestrates it.

• ➕ Massive provider coverage for free; no reinventing cloud APIs.
• ➕ Lowest maintenance; users can already do this themselves today.
• ➖ External dependency + runtime; another tool/state backend in the chain.
• ➖ Less "code-first Fallout-native" feel.

B) First-party IaC primitive ("be cheeky and write our own")

A Fallout-native declare/plan/apply primitive (cf. #249 Fallout.Reconcile), with provider adapters tested against the emulators (Topaz/LocalStack/GCP emulators) and Proxmox.

• ➕ Fully code-first, single tool, consistent with Fallout's C#-native ethos.
• ➕ Tight fit with our plan/apply + CD primitives.
• ➖ Enormous surface to build and maintain (cloud APIs, drift, state).
• ➖ Competing with Pulumi/Terraform on their home turf.

Probably not binary

A middle path exists: ship the integration (A) as the pragmatic near-term answer and build a narrow first-party primitive (B) for the targets where we control the emulator cheaply (Proxmox/on-prem first?). This RFC is where we decide the sequencing.

Open questions

• Near-term: integration first, own-primitive later — or commit to one?
• If own: does it build on Fallout.Reconcile — generic plan/apply primitive for CD targets #249 Fallout.Reconcile as the plan/apply core?
• Scope of a v1 first-party primitive — which provider/targets, how narrow?

Design issue — no implementation commitment.