Platform engineering
Platform engineering is a discipline that focuses on building and maintaining the underlying infrastructure and tools that enable software development teams to deliver applications and services more efficiently. It emerged from the DevOps movement as a response to the cognitive load placed on product teams expected to own the full delivery and operations toolchain. A platform engineering team builds a software delivery platform that abstracts away the complexities of the underlying infrastructure, so developers can focus on writing code and delivering value to customers.
Where DevOps asks each product team to take ownership of build, deploy, and runtime concerns, platform engineering concentrates that ownership in a dedicated team that offers the rest of the organization a shared platform as a product. Product teams then consume the platform rather than each assembling their own toolchain. The platform is built on the same DevOps practices – infrastructure as code, CI/CD, container orchestration, and observability – but exposes them through opinionated, higher-level interfaces that hide the moving parts. The discipline pays off most in larger organizations, where many product teams would otherwise re-derive the same pipelines, the same alerting, and the same security baseline.
Self-service and golden paths
The defining property of an internal platform is self-service. A developer should be able to provision an environment, deploy a service, wire up a database, and attach monitoring without filing a ticket, waiting on an operations team, or learning the underlying tools in depth. Self-service is what distinguishes a platform from infrastructure that is merely shared. Without it, the platform becomes another silo and the handover problems DevOps set out to dissolve reappear.
Self-service is delivered through golden paths (sometimes called paved roads): a small set of supported, opinionated routes through the platform that cover the common cases. A golden path bundles the approved compute model, runtime, deployment pipeline, secret management, and observability into a single, supported combination, so a team that follows it gets sensible defaults for free. Teams can step off the path when they need something the platform does not provide, but they then own the extra complexity they take on.
The aim is to reduce cognitive load on product teams and to improve developer experience at scale. The platform team is also the natural home for shift-left concerns – security scanning, policy enforcement, and compliance controls – which can be baked into the golden path once rather than re-implemented by each team.
Relationship to PaaS and SRE
An internal platform is, in effect, a private platform as a service. The difference is ownership and audience. A public PaaS serves many tenants on shared infrastructure; an internal platform serves one organization, is shaped by that organization’s standards, and can be changed to meet its needs. Many platform teams build on top of a public PaaS or a cloud service provider rather than raw infrastructure, treating the cloud as the substrate and the internal platform as the product their colleagues consume.
Platform engineering also overlaps with site reliability engineering. SRE treats reliability as a software problem and governs it through error budgets; platform engineering treats the delivery toolchain itself as a software product. The two are complementary and often coexist in the same organization, with the platform team owning the paved road and the SRE team owning the reliability of the services that travel along it.
Important
A common failure mode is to build the platform and declare it mandatory without treating it as a product. A platform that product teams are forced to use but have no say in becomes a constraint rather than a service, and they will route around it. Successful platform teams treat their internal developers as customers, gather feedback, measure adoption, and keep the alternative of teams building their own tooling honestly in view.