Platform Engineering means designing, building and maintaining an internal platform (Internal Developer Platform or IDP) that gives development teams environments, tools and workflows in self-service. This lesson is for teams whose DevSecOps organisation slows down under the weight of its tools, and who are looking for a method to build a useful platform rather than yet another infrastructure project.
Picture a developer who needs a test environment. Without a platform, they open a ticket, wait for the infrastructure team to handle it, answer clarification questions, then wait again. With a well-designed IDP, they pick a template in a portal and get an environment in minutes, with the right security settings applied automatically.
This discipline aims to reduce developers' cognitive load (they do not have to master Kubernetes, Terraform and the whole infrastructure stack), to speed up deployments and to guarantee compliance (security, costs, standards). It treats the platform as an internal product whose customers are the development teams, an idea popularised notably by the Team Topologies model.
What you will learn
- Distinguish Platform Engineering from a simple renaming of DevSecOps
- Identify the symptoms showing that an organisation needs a platform
- Build an IDP gradually, starting from the most valuable Golden Paths
- Choose the technical components suited to your context (portal, provisioning, observability)
- Tell the paved road, which makes the safe way simpler, from the guardrail, which refuses the dangerous way
- Measure adoption and the value perceived by product teams
This lesson builds on DevOps culture, the feedback loop and a first practice of Infrastructure as Code (in French): the platform industrialises these three foundations rather than replacing them.
Which problem does Platform Engineering solve?
Many organisations adopted DevSecOps tools (Kubernetes, Terraform, CI/CD) without asking who would use them and how. The result: developers overwhelmed by complexity, operations teams worn out by requests, and processes that slow down instead of speeding up.
Teams without a structured platform show recurring symptoms. They signal a hidden cost, invisible in classic dashboards but very real in the teams' daily work:
- Provisioning delays: days or even weeks to get a test environment
- High cognitive load: developers must master Kubernetes, Terraform, CI/CD and security
- Constant reinvention: each team creates its own scripts, pipelines and configurations
- Inconsistencies: different versions, diverging configurations, standards not followed
- Bottleneck: an infrastructure team flooded with tickets
- Shadow IT: teams work around processes deemed too slow
Does Platform Engineering replace DevSecOps?
No. Platform Engineering is a way to implement DevSecOps in a more structured manner. In particular, it fixes the anti-pattern where "DevSecOps" becomes the name of a team stuck between Dev and Ops instead of a shared culture. The table sums up the differences in approach.
| Aspect | DevSecOps without a platform | Platform Engineering |
|---|---|---|
| Focus | Dev/Ops collaboration | Platform treated as a product |
| Model | Each team tools itself | Self-service provided by a platform team |
| Users | Mixed teams | Developers, seen as customers |
| Deliverable | Processes, culture | Platform (IDP) |
| Measurement | DORA indicators | Developer satisfaction and DORA indicators |
Where does Platform Engineering stand in 2026?
Platform Engineering is no longer an emerging trend: it has become the norm in organisations that deliver at scale. Gartner predicted that 80 % of large software engineering organisations would have a platform team by 2026, up from 45 % in 2022. The DORA 2025 report confirms the shift: 90 % of the organisations surveyed already use an internal platform, and 76 % have set up a dedicated platform team.
The same report qualifies the contribution of artificial intelligence: code assistants increase individual output, but this raw productivity does not automatically translate into organisational performance. The deciding factor is platform quality: with a low-quality platform, AI's effect on performance is negligible; with a quality platform, it becomes clearly positive. AI does not replace the groundwork of Platform Engineering, it makes it more urgent.
On the tooling side, Backstage, born at Spotify, is a CNCF project (Cloud Native Computing Foundation, the foundation that hosts Kubernetes) at the Incubating maturity level since March 2022. It remains the open source reference for the developer portal. That is no reason to adopt it blindly: it is a sign that the market has settled around a few proven building blocks.
How do you build an internal platform?
The classic mistake is to start with tools ("let's install Backstage!") instead of the teams' real problems. The approach below has five steps, from listening to the teams to measurement, and the diagram sums it up.
Step 1: identify pain points
A pain point is a recurring obstacle that slows a team down without the team having the power to remove it. Before choosing any tool, interview the development teams about their daily work and list what makes them lose time:
- How do you get an environment close to production?
- How do you quickly rebuild a corrupted environment?
- How do you access simulations (mocks) of external services for tests?
- How long does it take to deploy a first version?
Step 2: prioritise by value
Rank pain points by productivity impact. Start with those that affect the most teams, generate the most tickets or interruptions, and directly block deployments. A platform that solves a marginal but visible problem loses its credibility at launch.
Step 3: build Golden Paths
Turn each pain point into a Golden Path: a documented, secure-by-default route that the product team follows without a ticket. Three ingredients make it effective: self-service (the user acts alone), guardrails (standards and security built in by default) and illustrated documentation of each path.
A Golden Path is offered, not imposed: if it is simpler than the alternative, teams adopt it on their own. The GitOps lesson shows an example of a marked path for deployment.
Step 4: treat the platform as a product
A platform without a clear owner drifts with each emergency. Appoint a Product Owner who prioritises the backlog according to real needs, set up a feedback loop (surveys, usage metrics, regular interviews), publish a visible roadmap and formalise internal commitments on availability and response time.
Step 5: measure and iterate
Track three families of indicators: developer experience (DevEx: satisfaction, time for a newcomer to become productive), adoption (share of teams using the Golden Paths) and the DORA metrics (deployment frequency, lead time, failure rate, restore time). The results feed back into step 1: the platform evolves with the pain points.
Which components make up an IDP?
An IDP is not a product you install, but a set of interconnected services. You do not need every component at first: start with those that address your priority pain points, then extend. The developer portal is often the most visible; Backstage dominates open source, while Port or Cortex target those who prefer a managed product.
| Component | Function | Example tools |
|---|---|---|
| Developer portal | Unified entry point | Backstage, Port, Cortex |
| Provisioning | On-demand environments | Terraform, Crossplane, Pulumi |
| Orchestration | Container management | Kubernetes, Nomad |
| CI/CD | Standardised pipelines | GitLab CI, GitHub Actions, Tekton |
| Observability | Metrics, logs, traces | Prometheus, Grafana, OpenTelemetry |
| Security | Scanning, secrets, policies | Vault, Trivy, OPA |
| Service catalogue | APIs, reusable components | Backstage, ServiceNow |
Observability deserves special attention: without it, you cannot prove that the platform brings value or spot Golden Paths that silently drift. The observability guide details this building block.
Which security guardrails should the platform carry?
A platform carries security in two ways, which must be told apart. The paved road makes the safe way simpler than the others: a project template comes with its pipeline already hardened, and the team adopts it because it saves time. The guardrail refuses the dangerous way, whatever path is taken: an unsigned image is rejected at deployment, whether the project came from the portal or from a repository created by hand.
The difference matters, because a Golden Path is offered, not imposed. A team that bypasses it also bypasses the security it carries, unless the critical controls live outside the path, at the level of the organisation, of admission or of provisioning. The table sorts the guardrails this course teaches by the layer where they apply.
| Layer | Guardrail | What it prevents | Lesson |
|---|---|---|---|
| Project template | pipeline shipped with scanners and minimal permissions | starting from an empty pipeline | Secure pipeline |
| Repository organisation | rulesets, mandatory review, allowlist of actions | merging without review, running an unapproved action | Source code governance, Allowed actions |
| Provisioning | workload identities and short-lived tokens injected | handing out a static key | Workload identity |
| Infrastructure as code | policy as code on the Terraform plan | creating an out-of-policy resource | Terraform policy as code |
| Admission | Kyverno policy on images and registries | deploying an unverified artifact | Kyverno |
Two principles make these guardrails sustainable. First, each one says why it refuses: an error message that names the rule and how to comply costs a few minutes, a silent refusal costs a ticket and frustration. Second, each one is measured: the share of deployments that pass without an exception is a platform indicator in the same way as adoption, and a granted exception is dated and assigned, like a vulnerability exception.
How do you know the platform succeeds?
These criteria help assess progress objectively. The point is not to reach everything at once, but to have clear goals; the numeric thresholds are internal benchmarks to adapt to your context.
- A developer gets an environment in under 30 minutes, without a ticket
- Security standards are applied automatically by guardrails
- A new developer is productive in less than a day
- A large majority of teams, around 80 %, use the Golden Paths
- DevEx indicators are collected and tracked every quarter
- The platform has a Product Owner and a public roadmap
- Product teams no longer reinvent their own basic tools
- Environment request tickets have dropped significantly
Two concrete scenarios
These two composite scenarios reflect frequent situations in organisations that adopt Platform Engineering. Durations are illustrative: they show the order of magnitude of the gap, not a published measurement.
Scenario 1: onboarding a new team
A new team joins the organisation and must ship its first feature in three weeks. Without a platform, it takes two weeks to get access, configure pipelines and understand the standards: delivery is late. With an IDP, the team creates its project from a portal template (repository, CI/CD pipeline, development environment) and has an environment compliant with the standards within a few hours.
Scenario 2: a critical CVE in a shared dependency
A critical CVE hits a dependency used by 40 services. Without a platform, each team updates by hand; some forget, others do not know how, and the fix drags on for weeks. With an IDP, the platform team updates the catalogue's base image, pipelines identify the affected services and automatic merge requests open on each repository: the fix takes days.
Which traps should you avoid?
Building an internal platform is hard, and many teams make the same mistakes out of enthusiasm or a wish to go too fast. Knowing them in advance saves months of wasted work; the table pairs each trap with its fix.
| Trap | Why it is a problem | Fix |
|---|---|---|
| Building without consulting | Unused platform, disconnected from needs | User interviews before each feature |
| Imposing everything | Rejection, shadow IT, workarounds | Attractive Golden Paths, not mandatory ones |
| Underestimating support | Frustration, platform abandoned | Dedicated support, complete documentation |
| Copying the neighbour's platform | Does not fit your context | Start from your pain points, not a generic blueprint |
| Ignoring the existing estate | A large share cannot migrate right away | Gradual migration paths |
| Neglecting observability | Impossible to prove value | Metrics from day one |
| Isolated platform team | Disconnected from the field | Rotations, embedded engineers, office hours |
| Aiming for perfection | Late delivery, scope creep | Minimum version, short iterations |
Key points
- Platform Engineering treats the platform as an internal product whose customers are developers.
- The goal is to create Golden Paths: marked, self-service, secure-by-default routes.
- It does not replace DevSecOps, it fixes its anti-patterns by structuring the approach.
- According to DORA 2025, 90 % of organisations already use an internal platform and 76 % have a dedicated team.
- A quality platform determines whether AI pays off; on a weak platform, its effect is negligible.
- A successful IDP is measured by developer satisfaction and Golden Path adoption.
- Critical guardrails live outside the Golden Path, at the organisation, provisioning and admission levels: a team that bypasses the path does not bypass security.
- Start with high-value pain points, not with fashionable tools.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: DevSecOps best practices: the 4 pillars to master
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most frequent doubts about Platform Engineering: its relationship to DevSecOps, Golden Paths and the choice of a developer portal.