The application and platform split — who owns what

The application/platform split is the first operating-model decision a delivery system must make explicit. The split is a named ownership line: the application team owns the application code, the platform team owns the shared delivery capability, and the boundary between them is a file the audit chain can read. Without an explicit split, the delivery system drifts toward “whoever has cluster access”, and the audit chain breaks at the first link.

What the split is

The split is not a tooling decision. It is not “we use GitHub Actions” versus “we use Jenkins”. It is not “we have a Kubernetes cluster” versus “we use VMs”. The split is the answer to a single question: who owns the path from a commit to a running service, and on whose shoulders does the rollback sit when the path fails?

flowchart LR
    subgraph APP["Application team"]
        AC["Application code\nbusiness logic"]
        AM["Application manifest\nimage, env, replicas"]
    end
    subgraph PLAT["Platform team"]
        CP["CI/CD pipelines"]
        REG["Registry"]
        GO["GitOps controller"]
        POL["Policies and guardrails"]
    end
    APP -->|"opens PR against"| PLAT
    PLAT -->|"runs CI, signs, deploys"| APP
    AC --- AM

The application team owns the application code, the application manifest, and the change rationale. The platform team owns the CI/CD pipelines, the artifact registry, the GitOps controller, and the policies that every application change must satisfy. The boundary is the pull request: the application team opens a PR; the platform team’s automation (not a person) builds, signs, and deploys it.

What each side owns

The application team’s ownership is the what. They own:

• The application source code and its tests.
• The container image build (the Dockerfile and the build arguments it depends on).
• The application manifest, expressed as a Kubernetes workload, a Helm values file, or a Kustomize overlay.
• The change rationale, captured in the commit message and the pull request description.

The platform team’s ownership is the how. They own:

• The CI/CD pipeline that builds, scans, signs, and publishes the artifact.
• The OCI registry that stores the artifact by digest.
• The GitOps controller that reconciles the cluster to the declared state.
• The policies and guardrails that the application team’s change must satisfy - signed commits, required reviewers, vulnerability gates, drift detection, image-digest pinning.

The boundary is the CODEOWNERS file. The platform team owns the directories /.github/workflows/, /clusters/, /platform/, and the application team owns the directories /services/<app-name>/. A change to a platform-owned directory requires a platform-team reviewer; a change to an application-owned directory requires an application-team reviewer.

The three anti-patterns when the split is implicit

A team that has not made the split explicit produces one of three failure modes:

1. The platform team owns everything. The application team opens a ticket and the platform team writes the manifest. The platform team becomes a bottleneck; the application team loses the ability to ship; the audit chain blurs because the change author and the change implementer are different people.
2. The application team owns everything. The application team has cluster-admin and writes its own pipelines. The platform team does not exist as a coherent entity; the policies are inconsistent across teams; the audit chain is broken because every team invents its own signing and review rules.
3. Ownership is by seniority, not by directory. The most senior engineer on the team approves every change, regardless of which directory it touches. The CODEOWNERS file does not exist; the audit chain depends on who happens to be online.

The fix is always the same: write the CODEOWNERS file, publish the ownership line in the team README, and treat every pull request as a test of whether the line is honoured.

Production discipline

1. Publish the ownership line. The CODEOWNERS file in the default branch is the canonical statement.
2. Require the matching reviewer. A pull request that touches /platform/ requires a platform-team reviewer; the branch protection rule enforces it.
3. Audit the ownership line quarterly. A repository whose CODEOWNERS no longer matches the team roster is a repository whose audit chain is about to break.
4. Treat ownership as a directory, not a person. People leave; directories stay.

Cross-course references

• This course, Part CVII (ProductionArch) covers the reference architecture whose seven components are owned across the split.
• This course, Part CVI (ChangeMgmt) covers the change record that the ownership line makes auditable.
• Linux for Production Sysadmins - Part XXXIV (ConfigMgmt) covers the same split at the configuration-management level.

Quiz