Platform Engineering, DevOps and SRE: Define the Responsibilities First

Separate platform, DevOps and SRE responsibilities, identify repeated delivery constraints, and fund a supported capability with measurable value and reliability.

A platform is an operating commitment, not a DevOps replacement

Platform engineering is useful when several teams repeatedly need a capability that one accountable group can provide better as a supported product. That capability might be a deployment path, an environment, an identity integration or a reliable way to find service ownership. It need not begin with Kubernetes or a developer portal.

DevOps, platform engineering and site reliability engineering (SRE) are complementary. They are not stages in a sequence where each new label replaces the previous one. Renaming an operations team does not change how work flows, who owns production or whether developers can complete their tasks.

This article is for engineering leaders deciding what to fund and where responsibility belongs. The companion article on running an internal developer platform pilot covers testing one self-service capability with users.

Compare the jobs, not the job titles

Google's explanation of SRE and DevOps treats them as closely related approaches rather than competing departments. A company can use SRE practices without creating a team bearing that name. A platform team can also apply SRE practices to the platform it operates.

Consider a failed release. The application owner is responsible for the application's behavior. The platform owner investigates a defect in a shared deployment capability. Reliability specialists may help evaluate the service objective and failure mode. The incident lead coordinates the response. None of those responsibilities follows automatically from who maintains the portal.

A useful handoff says which component failed, who can act and what evidence is required. “Send it to DevOps” is not a sufficient operating model.

Find repeated friction before building shared infrastructure

The engineering leader should inspect real tasks across candidate users. Follow a deployment, an environment request, a credential rotation and a recovery exercise. Record active work, waiting, repeated manual steps and failed attempts.

Different causes need different interventions:

The CNCF Platforms White Paper frames platforms as user-oriented capabilities and allows them to compose managed or internally provided services. That supports a thin shared layer where it is sufficient, not a mandate to build every underlying system.

A historical adoption forecast does not establish the return on your investment. The case should come from the tasks, risk and economics in your organization. Record the cost of maintaining the shared capability as well as the effort it may remove.

Keep the portal separate from the platform

Backstage describes itself as a framework for developer portals, including a catalog, templates and documentation. Those features can expose a platform. They do not, by themselves, provide an authorized provisioning API, restore a database or support a failed deployment.

A capability can start through a command-line interface, an API, a reviewed workflow or clear documentation. Add a portal when discovery and interaction are the bottlenecks. Otherwise, a portal risks presenting a polished front end to the same manual queue.

The interface should reveal status and ownership, not just offer a “create” button. A user needs to know whether a request was accepted, is waiting, failed, partially succeeded or needs operator attention. Retrying an ambiguous request must not create duplicate infrastructure.

Runtime selection is a separate decision. Managed application services, function platforms, containers and Kubernetes have different controls and operating burdens. Select against workload, security, recovery and team capability. A platform does not become more mature merely because it supports more runtimes.

Write the service boundary before promising self-service

For every capability, record what the platform owns and what remains with its users.

Platform capability contract
  User task and eligible workloads:
  Supported interface and version:
  Platform-owned components and operating responsibilities:
  Application-owned configuration, data and behavior:
  Security/data policy owner:
  Success, failure and partial-completion states:
  Service objectives and support coverage:
  Upgrade, deprecation and recovery policy:
  Exceptions and accountable off-path owner:

For a managed database workflow, the platform might own provisioning automation, policy enforcement and integration with a database provider. The application team may own schema design, query behavior and data correctness. Backup configuration, restore execution and verification must be explicitly assigned. They should not fall into the gap between those two groups.

Some controls are mandatory because of risk or applicable obligations. Other choices can be supported defaults. An exception process should identify who accepts the additional operating work and how the exception is reviewed. “Off path” cannot mean bypassing authorization or losing an owner.

Reliability and developer value need to be measured together

A platform that is pleasant to use but frequently blocks releases is not successful. Neither is a highly available portal whose users cannot complete their tasks.

Google's SLO guidance explains how reliability objectives inform engineering decisions. Apply that to meaningful platform journeys. For example, measure whether an authorized deployment reaches its intended state within the promised window, not only whether an API returned a success code.

Choose staffing from the supported capability scope, maintenance queue, support coverage and reliability obligations. A universal platform-to-engineering ratio cannot tell you whether the team can operate its commitments.

Fund a capability through evidence gates

Begin with one capability whose users and failure states are understood. Budget discovery, delivery, documentation, migration and operation. A fixed six-month roadmap or a universal adoption target can conceal the fact that the chosen task was never validated.

Version templates and APIs. A template creates resources at a point in time; it does not automatically keep them patched forever. Decide how existing users receive upgrades, how incompatibilities are detected and who owns drift.

Roll out changes to a bounded set of eligible users. Retain a known-compatible capability version where safe, and test partial provisioning recovery. Reverting the portal or template does not necessarily revert resources already created or data already changed. Reconciliation and operator visibility matter as much as release automation.

Questions to settle before approving the investment

• The proposed capability addresses repeated, observed work
• DevOps, application, platform and reliability responsibilities are explicit
• A portal is being considered separately from the underlying service
• Runtime and managed-service choices follow workload requirements
• Success measures include task value, reliability and support burden
• Security controls and exceptions have accountable owners
• Existing users have an upgrade and deprecation path
• Partial failure and recovery were tested before expanding adoption

These distinctions do not prescribe an organization chart or guarantee faster delivery. They help expose the commitments hidden inside “build a platform.” Start by writing one capability contract and checking whether a real user can complete its task. Cloud platform engineering concerns that shared capability; DevOps and SRE concerns the delivery and reliability practices around it.