The infrastructure team role — the boundaries

The infrastructure team is the layer beneath the platform team. The infrastructure team owns the substrate - cloud accounts, network topology, storage backends, base images, IAM identity primitives - and produces a named contract that the platform team consumes. The platform team consumes that contract and exposes a delivery capability to the application team. The three layers stack: the infrastructure team at the bottom, the platform team in the middle, the application team on top.

The layer the infrastructure team owns

The infrastructure team’s ownership is the substrate. The substrate is the set of resources that exist whether or not any application is running: the cloud account, the VPC and subnets, the IAM roles and policies, the Kubernetes control plane, the object storage buckets, the container registries, the base operating system images.

flowchart TB
    subgraph INFRA["Infrastructure team (substrate)"]
        CA["Cloud accounts + IAM"]
        NET["Network: VPC, subnets, peering"]
        STO["Storage: buckets, volumes"]
        IMG["Base images + AMIs"]
        ID["Identity: OIDC providers"]
    end
    subgraph PLAT["Platform team (capability)"]
        CP["CI/CD pipelines"]
        REG["Registry mirror"]
        GO["GitOps controller"]
    end
    subgraph APP["Application team (workload)"]
        WK["Service manifests"]
    end
    INFRA -->|"named contract: IAM role, subnet, image"| PLAT
    PLAT -->|"delivery capability"| APP

The infrastructure team does not write application manifests. The infrastructure team does not write CI pipelines. The infrastructure team does not own the GitOps controller. The infrastructure team’s output is the contract that the platform team consumes: a named IAM role, a named subnet, a named base image, a named OIDC provider, a named container registry.

The named contract

The contract between the infrastructure team and the platform team is the artefact the two teams agree on and review. The contract is a module, a document, or a set of Terraform outputs that the platform team reads. The contract names four things:

1. The account and the region. The cloud account ID and the AWS region, Azure subscription, or GCP project that the platform team deploys into.
2. The IAM role and the trust policy. The role the CI workflow assumes, the trust policy that limits the assumption, and the OIDC provider that the GitHub Actions or GitLab CI workflow authenticates against.
3. The network boundaries. The VPC, the subnets, the security groups, and the peering or transit gateway topology that the platform team’s workloads run inside.
4. The base image and the registry. The container base image the platform team extends, the registry the platform team pushes to, and the image-pull policy the workloads use.

The contract is versioned. A change to the IAM role is a new contract version; the platform team consumes the new version after a migration window. The contract is auditable. A pull request against the contract is a change to the substrate, and the change record is the pull request.

The boundary failure mode

A team that has not separated the infrastructure and platform roles produces a single boundary failure mode: the infrastructure team absorbs the platform work. The infrastructure team, which already owns the substrate, is the team the platform team calls when the pipeline breaks. The infrastructure team fixes the pipeline. The infrastructure team now owns both layers.

The signal is the on-call rotation. A team that pages the same rotation for VPC problems and for CI pipeline problems has merged the two layers. A team that pages the infrastructure rotation for VPC problems and the platform rotation for pipeline problems has not.

The fix is to write the contract, name the infrastructure rotation and the platform rotation separately, and route the on-call escalation through the correct rotation. The infrastructure team owns the substrate; the platform team owns the capability; the on-call rotation reflects the boundary.

Production discipline

1. Write the contract. A versioned module or document that names the four pieces of substrate the platform team consumes.
2. Separate the on-call rotations. The infrastructure rotation owns the substrate; the platform rotation owns the capability.
3. Audit the contract quarterly. A contract that has drifted from the actual substrate is a contract that has become misleading.
4. Treat the contract as code. A change to the contract is a pull request with the same review properties as a change to any other production artefact.

Cross-course references

• This course, Part CXV-03 (PlatformRole) covers the consumer side of the contract.
• This course, Part CVII (ProductionArch) covers the identity flow that the contract’s IAM role implements.
• Terraform for Production Sysadmins - Parts IX-XII (State) cover the state file that records the contract’s application.

Quiz