Platform engineering: scaling DevOps across the hybrid cloud

SECTION 1

Why DevOps stalls at hybrid cloud scale

Infrastructure and operations teams struggle to scale their DevOps platforms in hybrid cloud environments, particularly when legacy systems run in isolated silos. The obstacles recur with regularity: siloed DevOps tools that prevent seamless communication, technical debt that accumulates as CI/CD pipeline complexity grows, resource bottlenecks that limit knowledge-sharing, and production failures when platforms and hybrid environments are misaligned.

What worked on a narrow scope no longer holds once you multiply environments and providers: every product team reinvents its pipelines, its conventions and its cloud access, and developers' cognitive load explodes. Platform engineering, which extends DevOps toolchains to manage requirements across varied environments, offers a viable answer to this problem, not yet another tool, but a coherent foundation on which teams ship without reinventing infrastructure every time.

Cognitive load is not an abstraction: when a developer has to master three cloud consoles, two CI tools, a catalogue of Terraform modules and the conventions of four teams to ship a feature, the time spent on infrastructure comes straight out of the product. Analysts converge on the same observation: traditional DevOps workflows fail to adapt to a rapidly evolving hybrid landscape, and the answer cannot be yet another tool added to the stack, the structure has to change, not the inventory.

SECTION 2

Platform engineering, the industrialised extension of DevOps

Platform engineering differs from traditional DevOps by emphasising tools and enabling infrastructure rather than cultural change alone. Its benefits lie in automation, unified toolchains and improved scalability: the internal platform becomes a product, with its users, the developers, its roadmap and its value indicators.

Its concrete deliverable is the internal developer platform (IDP): a coherent set of self-service tools, services and workflows covering the full lifecycle, provisioning an environment, creating a service, deploying it, observing it, decommissioning it. The developer consumes capabilities instead of opening tickets, and the platform team encodes security and compliance standards into those capabilities once and for all, rather than checking them after the fact at every delivery.

The Team Topologies framework provided the shared vocabulary: the platform is a product served by a dedicated team, consumed in self-service by stream-aligned teams, with the explicit goal of reducing extraneous cognitive load. This reading grid avoids the classic misunderstanding, renaming the old infrastructure team a platform without changing either the funding model or the relationship with product teams.

The discipline has moved past the trend stage to become an established practice in most large engineering organisations, to the point of forming a career path in its own right for DevOps profiles. Its value fully unfolds when the approach aligns with the principles of resilience engineering and IT service management (ITSM): the platform is then a coherent internal product, not a stack of juxtaposed tools.

@cite:l-evolution-de-l-ingenierie-de-plateforme

SECTION 3

Building a product-oriented platform team

Build a dedicated platform engineering team, accountable for increasing platform value and addressing scaling bottlenecks: data governance, compliance, knowledge-sharing. Success requires a fine understanding of product teams' pain points, gained through a collaborative discovery phase, interviews, observation of real workflows, measurement of friction, rather than tooling choices made behind closed doors.

### Composing a multi-disciplinary team

The team combines platform engineering profiles in the strict sense, Kubernetes, IaC, CI/CD, with product and design skills that are often neglected: documentation writing, internal interface design, animation of the user community. A technically flawless platform that is painful to use will not be adopted, and voluntary adoption is the only indicator that counts: imposing the platform by decree produces workarounds, not value.

### The key role of the platform product manager

Treating the platform as a product implies a platform product manager role: prioritising the backlog according to value for consuming teams, arbitrating between new capabilities and reliability work, and refusing the requests that would fragment the foundation. Without this role, the platform team reverts to a classic infrastructure team, driven by tickets rather than outcomes, and adoption erodes at the first friction point.

SECTION 4

Defining the hybrid cloud architecture: control plane, GitOps and IaC

Then define the hybrid cloud architecture of the DevOps platforms. Implementation requires platform owners and consumers to collaborate on architecture decisions, relying on a gap analysis to identify the tools needed for a cloud-native design that covers both public clouds and on-premise systems.

### Kubernetes as the universal control plane

The dominant pattern makes Kubernetes the platform's control plane: Crossplane models the infrastructure of the various clouds as composite resources that developers consume in self-service, Argo CD continuously reconciles the state declared in Git with the reality of the clusters, and infrastructure as code, Terraform or its open source counterpart OpenTofu, provisions the foundations programmatically. This combination provides a single interface over heterogeneous environments, which is precisely what hybrid organisations lack.

Hybrid cloud adds constraints of its own: connectivity and latency between sites, sovereignty and data-residency requirements, an on-premise estate that will not disappear in the medium term. The architecture must therefore offer the same workflows, same pipelines, same templates, same portal, whatever the target environment, even if the underlying implementation differs. It is this uniformity of experience, more than technical uniformity, that actually removes the silos.

@cite:infrastructure-en-tant-que-code-ou-en-sommes-nous-aujourd

SECTION 5

Standardising: TVP, developer portal and golden paths

Simplicity is achieved through standardisation. The Thinnest Viable Platform (TVP) reduces costs by introducing only the strictly necessary abstraction: every added layer must be justified by a real need of the teams, otherwise the platform itself becomes a source of complexity. User-centred design offers intuitive interfaces aligned with developers' actual working journeys.

### The developer portal and golden paths

The developer portal, Backstage, adopted by the CNCF, has become its open source reference, alongside managed offerings, centralises the service catalogue, templates and documentation. Golden paths, those marked-out routes leading from code to deployment while enforcing security and compliance standards by default, turn good practice into the path of least effort: creating a compliant microservice takes a few minutes instead of a few weeks of tickets. A container-native platform finally standardises build processes through orchestration, across all environments.

Documentation and templates are part of the product just as much as the code: scaffolding that generates a pre-wired service, CI, observability, security, deployment, with its documentation up to date is worth more than an exhaustive wiki nobody reads. Every golden path must be tested end to end like a feature, because a broken template destroys teams' trust faster than any production incident.

SECTION 6

AI agents, the new building block of the internal platform

Since 2025, an additional building block has taken hold: AI agents embedded in the developer portal and pipelines. They suggest golden paths suited to the context, generate manifests and IaC modules compliant with the organisation's standards, and diagnose a failed deployment before the human on-call even steps in. The platform stops being a static catalogue and becomes a system that answers, suggests and fixes.

This evolution reinforces the demand for standardisation rather than replacing it: an AI agent is only reliable if it builds on clean templates, explicit conventions and quality telemetry. Organisations that invested in a well-governed foundation see their agents produce actionable results; the others automate their disorder.

The use cases are taking shape: a developer asks in natural language for an ephemeral test environment and the agent orchestrates the existing building blocks; a pull request review flags that a manifest deviates from the golden path; a failed pipeline is analysed, explained and, for known causes, fixed automatically. Each time, the agent builds on the platform's self-service capabilities, it does not replace them.

@cite:platform-engineering-idp-agents-ia

SECTION 7

Measuring platform value and scaling with Adservio

Together, a dedicated platform engineering team, a defined hybrid cloud architecture and simplified workflows make it possible to scale DevOps. It still has to be proven: the DORA metrics, deployment frequency, lead time for changes, change failure rate, time to restore, completed by the onboarding time of a new developer, the adoption rate of golden paths and the measured satisfaction of teams, objectify the value delivered and guide the next investments.

At Adservio, our consultants support this trajectory end to end: scoping the TVP, choosing proprietary or open source solutions aligned with your business needs, setting up the developer portal and golden paths, and progressively integrating AI agents, so that the platform becomes a lasting accelerator rather than one more programme.

### Where to start in practice

The safest starting point remains modest: pick one high-impact friction point, creating a new service, for instance, turn it into an end-to-end golden path with a few pilot teams, measure the gain, then extend. It is the demonstration of value, not the architecture diagram, that wins adoption. Platform failures almost always follow the opposite script: eighteen months of building behind closed doors, a launch with great fanfare, and product teams who cannot find their real use cases in it. Ship small, measure, iterate, the platform is built like the product it is.

FAQ

Frequently asked questions