Standardizing Infrastructure with Crossplane v2: The SIPOC Assembly Line Model

Any Customer Can Have Any Cloud Resource, Provided It Comes Off the Assembly Line: Crossplane v2 and the SIPOC Factory Floor

Crossplane v2 introduces a standardized assembly line for cloud infrastructure through its new Pipeline mode and refined API schemas. By treating cloud resources like a 1913 Ford Model T, engineers can replace bespoke ticketing with automated, self-service GitOps workflows.

Why This Matters

Modern platform engineering teams often struggle with artisanal, ticket-driven infrastructure provisioning that lacks predictability and speed. The transition to Crossplane v2 addresses this by enforcing strict standardization through Composition Functions and Composite Resource Definitions (XRDs). This shift from manual cloud portal clicks to an automated pipeline reduces technical debt by ensuring every resource matches a pre-approved blueprint. Continuous reconciliation beats traditional manufacturing by monitoring every ‘car’ ever built and automatically fixing deviations from the original spec.

Key Insights

• Crossplane v2 XRDs now use apiVersion: apiextensions.crossplane.io/v2 and default to Namespaced scope, removing the need for Claims.
• The SIPOC mental model (Supplier, Input, Process, Output, Consumer) maps directly to Providers, XRDs, Pipeline Compositions, Managed Resources, and App Teams.
• Composition Functions act as specialized tools, such as function-patch-and-transform for mapping XR fields to managed resources.
• Crossplane v2 consolidates internal machinery under the spec.crossplane field to keep consumer-facing spec.parameters clean.
• The crossplane render tool allows engineers to prototype and test assembly line configurations locally without making calls to cloud APIs.

Working Examples

XRD (The Blueprint) defining the contract between the platform team and consumers.

apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
  name: xazureresourcegroups.platform.example.com
spec:
  scope: Namespaced
  group: platform.example.com
  names:
    kind: XAzureResourceGroup
    plural: xazureresourcegroups
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              parameters:
                type: object
                required: [resourceGroupName, location]
                properties:
                  resourceGroupName: {type: string}
                  location: {type: string}

Composition in Pipeline mode acting as the moving assembly line.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: xazureresourcegroup-azure-v1alpha1
spec:
  compositeTypeRef:
    apiVersion: platform.example.com/v1alpha1
    kind: XAzureResourceGroup
  mode: Pipeline
  pipeline:
  - step: patch-and-transform
    functionRef:
      name: function-patch-and-transform
  - step: auto-ready
    functionRef:
      name: function-auto-ready

Practical Applications

• Use Case: Azure Resource Group self-service where teams request resources via namespaced XRs. Pitfall: Using the old inline ‘resources’ mode instead of ‘Pipeline’ mode, which lacks modular function support.
• Use Case: Multi-step subscription provisioning where Station 2 waits for a Subscription ID generated by Station 1. Pitfall: Failing to set policy.fromFieldPath: Required, causing downstream failures before IDs exist.
• Use Case: Enforcing organizational standards for tagging and cost centers at the ‘factory’ level. Pitfall: Allowing manual edits in the cloud portal, which Crossplane will continuously overwrite to maintain the desired state.

References:

• https://dev.to/the-software-s-journey/any-customer-can-have-any-cloud-resource-provided-it-comes-off-the-assembly-line-crossplane-v2-230i