By 2025, DORA found that 90% of organisations reported using an internal developer platform, and 76% had dedicated platform teams. Platform engineering is no longer an emerging side topic inside DevOps; it is rapidly becoming the delivery model serious software organisations build around.
If your developers need to jump across CI dashboards, cloud consoles, ticket queues, secrets workflows, alerting systems, YAML files, and human approvals just to launch one service, you do not have engineering autonomy. You have accidental complexity. GitLab’s 2026 research found that 60% of DevSecOps teams use more than five software-development tools overall, 49% use more than five AI tools, and 94% experience factors that limit collaboration across the software delivery lifecycle. That is the real backdrop to DevOps 2026: toolchain sprawl, not tool scarcity.
Platform engineering matters because it changes the unit of optimisation. Instead of asking every product team to become part SRE, part cloud architect, part security engineer, and part release manager, it gives them a paved route to production: self-service environments, reusable templates, standard pipelines, secure-by-default deployment, and observability that is already wired in. That is why the internal developer platform, or IDP, is replacing DevOps chaos in enterprise software delivery.
Why DevOps became too fragmented
DevOps succeeded because it broke down the wall between development and operations, but cloud-native architecture kept raising the number of decisions individual teams had to make. As container platforms, CI/CD systems, policy controls, infrastructure-as-code, service meshes, secrets tooling, and observability stacks multiplied, “you build it, you run it” often became “you integrate everything yourself”. Google Cloud has described this drift as cognitive overload: developers drown in YAML, scattered tooling, and infrastructure detail that slows onboarding and delivery.
DORA’s research on flexible infrastructure explains why this happens. Teams only get the promised gains of cloud when environments are available on demand, scale elastically, and expose measurable usage. If developers still need to raise tickets or wait days for provisioning, they have not really gained cloud-native speed; they have simply moved slower processes onto newer infrastructure. DORA also found that elite performers were more than 23 times more likely than low performers to meet the essential characteristics of cloud computing.
This is why DevOps did not fail conceptually, but often failed operationally at scale. Platform engineering is the enterprise answer because it codifies DevOps practices into reusable, standardised workflows. It keeps the culture of DevOps, but reduces the burden of re-implementing that culture in every single team, repository, and workload.
What an Internal Developer Platform actually is
An internal developer platform is not one product, one vendor, or one portal. DORA defines platform engineering as a sociotechnical discipline focused on automation, self-service, and repeatability, typically delivered through an internal developer platform that offers shared tools, services, and golden paths. Google Cloud similarly defines an IDP as a set of tools and technologies that abstracts away technical complexity so developers can self-service and reduce cognitive load.
That distinction matters because many organisations confuse the portal with the platform. A developer portal is the front door: the interface where engineers discover services, launch templates, view ownership, and find documentation. The IDP is the full backend system beneath that door: orchestration, policy, templates, workflows, APIs, and automation. Google Cloud’s guidance is blunt on this point: a portal alone does not solve the problem.
The crucial mindset shift is to treat the platform as an internal product. DORA says the platform should not be seen as a pile of infrastructure tickets, but as a product designed for developers. The Cloud Native Computing Foundation platform white paper makes the same argument: a platform has to be designed around user requirements, self-service, documentation, and a consistent user experience. Backstage’s own adoption guidance says a central team should own the portal and treat it like a product, with adoption and developer experience as explicit goals.
In practical terms, a real IDP usually combines service templates, a software catalog, documentation, CI/CD automation, runtime provisioning, observability defaults, security controls, and cost visibility into one developer workflow. It should make the common path fast, safe, and boring. That is the real value proposition: not more tooling, but less decision fatigue.
The golden path model
The golden path is the core design pattern of platform engineering. Google Cloud describes golden paths as templates and automation for commonly performed tasks, while the CNCF white paper frames them as reusable, integrated workflows for building, scanning, testing, deploying, and observing applications. In plain English, a golden path is a pre-built route that lets developers ship common services without re-solving the same platform problems every week.
A good golden path is opinionated, but not authoritarian. The CNCF argues that platforms should be optional and composable, not a bottleneck. That means the safe path should be the easiest path, not the only path. Enterprises still need a controlled escape hatch for legitimate exceptions, but the default route should cover the majority of production work with stronger security, faster delivery, and lower cognitive load.
What belongs in that path? Google’s golden-path example is revealing: starter code, dependency management, a CI/CD template, infrastructure-as-code, Kubernetes manifests, policy guardrails, and built-in logging and monitoring. Backstage Software Templates supports exactly this model by letting teams load skeleton code, inject variables, and publish new projects directly into source-control systems such as GitHub or GitLab.
The best platform teams do not begin by building thirty golden paths. They begin with one or two high-friction journeys and deliver an MVP fast. The practical implementation guidance from PlatformEngineering.org argues for an MVP-first, eight-week approach because platforms fail more often from overreach, slow time-to-value, and poor adoption than from missing technical sophistication. In platform engineering, useful beats perfect every time.
Reference architecture for an enterprise IDP
A pragmatic 2026 reference architecture for an internal developer platform looks like this: source control and CI/CD on GitHub or GitLab; infrastructure provisioning via Terraform; runtime on Kubernetes; the portal and catalog layer in Backstage; observability built around OpenTelemetry, Prometheus, and Grafana; and secrets delivered through federated identity plus a dedicated secrets system such as Vault or a cloud-native equivalent. None of these components is the platform on its own. The platform is the way they are assembled into one self-service experience.
At the automation layer, GitHub Actions and GitLab CI/CD both provide event-driven pipelines defined in YAML and triggered by repository activity. Terraform from HashiCorp gives teams the write-plan-apply workflow that makes infrastructure reproducible and reviewable rather than ticket-driven and ad hoc. Kubernetes then provides the declarative runtime layer for containerised workloads and services, which is why it remains the default substrate for modern application platforms.
Secure-by-default deployment should sit across that whole stack, not bolt on afterwards. GitHub’s OIDC guidance explicitly recommends replacing long-lived cloud credentials with short-lived federated tokens, and Kubernetes documents RBAC and least-privilege handling for Secrets as core controls. Vault adds the ability to centralise secrets, rotate credentials, generate them on demand, and audit client interactions for compliance. In other words, the platform should make secure delivery the path of least resistance.
At the experience layer, Backstage brings the workflow together. Its Software Catalog centralises ownership and metadata, its templates scaffold new services, and TechDocs keeps documentation close to code. Backstage also reduces context switching by organising tooling around software entities rather than forcing engineers to hop across separate consoles all day. This is why Backstage became such a strong fit for platform teams: it gives the IDP a discoverable interface without pretending the UI is the whole system. The adoption practices documented there were refined inside Spotify, where the platform was explicitly treated as a product.
Observability has to be native to the platform, not left to every team to improvise. OpenTelemetry provides a vendor-neutral framework for generating and collecting traces, metrics, and logs; Prometheus stores time-series metrics; and Grafana visualises metrics, logs, and traces in one place. If your golden path ships code without telemetry, it is not production-ready. A platform worth adopting should provision the service, instrument it, and expose useful dashboards by default.
This reference stack also works well for hybrid and multi-cloud estates. CNCF’s late-2025 development data showed hybrid cloud use at 32% and multi-cloud at 26% among developers, while its 2026 annual survey said 82% of container users were running Kubernetes in production and described Kubernetes as the common operating layer for both cloud-native and AI workloads. That is why Terraform plus Kubernetes remains such a durable architecture choice for enterprise IDPs: it gives teams enough portability to live in real-world estates, not just single-cloud diagrams.
A concrete enterprise example helps. In 2025, John Lewis Partnership described how its digital platform evolved into a product used by roughly 25 teams in just over a year, with self-service resource provisioning on Google Cloud and a platform foundation on Kubernetes. The team later created a custom Kubernetes abstraction because only around 33% of the YAML their developers wrote was actually relevant to the application, which made simplification an obvious win. That is platform engineering at its best: shrinking the exposed surface area until product teams only see the pieces they truly need to control.
AI-assisted platform engineering
AI has made platform engineering more urgent, not less. DORA’s 2025 research found that 90% of technology professionals now use AI at work and more than 80% believe it has increased their productivity. But DORA’s core conclusion is even more important: AI is an amplifier. It strengthens good systems and accelerates bad ones. Strong teams with high-quality internal platforms turn AI into throughput; fragile teams mostly turn AI into faster-moving instability.
GitLab’s 2026 DevSecOps reporting makes the same pattern painfully concrete. AI-generated code now accounts for 34% of development work, yet 70% of practitioners say AI makes compliance harder and 76% say agentic AI creates unprecedented security challenges. Add that to toolchain sprawl and the outcome is obvious: if you speed up code creation without standardising testing, policy, release controls, and observability, you do not get faster delivery. You get a larger blast radius.
This is where platform engineering becomes the control plane for AI-assisted development. DORA explicitly states that a high-quality internal platform is the governance and distribution layer that turns AI’s speed into systemic organisational value. Its guidance on AI-accessible internal data goes a step further: the best results come when AI can securely access codebases, documentation, and operational metrics, because context-aware systems produce more useful and trustworthy outputs than generic prompts do. In 2026, the winning pattern is not “give every developer a chatbot”; it is “ground AI in platform standards, internal context, and production feedback loops”.
The practical use cases already show the shape of this future. DORA’s qualitative work found AI showing up most often in code generation, information seeking, code review, and testing, with growing use in debugging, refactoring, documentation, and learning. The smart move is to let AI accelerate those activities while forcing every generated change through the same golden paths, policy checks, test suites, deployment rules, and telemetry standards as human-written code. AI-assisted platform engineering is not about replacing governance. It is about embedding governance in the path AI uses.
The metrics that matter
Most platform dashboards fail because they measure platform activity instead of delivery outcomes. Start with four board-level numbers and two engineering guardrails. Lead time for changes tells you how long it takes to move from commit to production. Deployment frequency tells you how often value is actually shipped. Recovery time should stay on every executive dashboard, even though DORA’s current five-metric model now frames this more precisely as failed deployment recovery time. Cost per workload connects architecture decisions to economic reality by showing what it actually costs to run a service or application over time.
The reason cost per workload belongs beside delivery speed is simple: platform engineering is supposed to reduce both delivery friction and waste. The FinOps Foundation defines unit economics as the link between what an organisation spends on technology and the value that spending creates, and explicitly lists technical measures such as cost per service request and cost per workload as useful ways to drive design and operational trade-offs. DORA’s cloud research reinforces that point by tying true cloud flexibility to better cost visibility.
But do not optimise speed in isolation. DORA’s current model also tracks change fail rate and deployment rework rate because throughput without stability is just expensive thrash. If lead time falls while failures and rework climb, your platform is not improving delivery; it is hiding chaos behind more automation. The best platform teams treat speed, stability, and cost as one system, not three separate reporting streams.
Roadmap for small, mid-size, and enterprise teams
Small teams
If you are a small engineering organisation, resist the temptation to “build a platform” too early. Google Cloud notes that when applications are straightforward and teams can still manage their own infrastructure comfortably, simple CI/CD automation plus stronger DevOps habits may be enough. The right first move is usually one golden path for one frequent journey: create a new service, provision the standard infrastructure, deploy it, attach default telemetry, and handle secrets the same way every time. Start with the backend orchestration, not a portal.
Mid-size teams
Once your service count grows and discoverability becomes painful, move from automation to productised self-service. This is the point where Backstage starts to pay off: a software catalog, reusable templates, TechDocs, and integrated tooling reduce search time and context switching. Establish a central team that owns the experience, treats developers as customers, and encodes best practice into templates rather than tribal knowledge. By this stage, your IDP should already expose standard observability, security defaults, environment creation, and ownership metadata.
Enterprise teams
At enterprise scale, think in terms of platform product lines, not one giant monolith. Backstage’s own adoption model describes a “platform of platforms”, while the CNCF papers insist platforms should remain composable and optional. That means shared standards for identity, policy, telemetry, networking, and cost allocation, but room for separate application, data, and AI platform domains when needed. This is also where formal platform product management becomes critical: you need a roadmap, adoption metrics, exception handling, and clear workload-level economics, not just more engineering effort. The organisations that win here do not mandate adoption into existence; they make the golden path so useful that teams prefer it voluntarily.
Top comments (0)