Skip to content

필사 모드: IDP 2026 Deep Dive: Backstage, Port, Cortex, OpsLevel, Humanitec — The Present and Future of Platform Engineering

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction: Why IDPs Became Mandatory in 2026

In 2024, Gartner predicted that "by 2026, 80% of large software organizations will operate a platform team." In 2026, that prediction has effectively been realized. The CNCF 2025 Annual Survey shows that Backstage has become the fastest-adopted CNCF Incubating project after GitOps tooling, and SaaS IDPs like Port and Cortex have closed Series C and D rounds, entering their full-scale expansion phase.

But in late 2025, one event shook the IDP community: Spotify split key features from its internal "Portal" out of Backstage open source and released them as a separate commercial package. The move ignited fierce debate about Backstage governance and licensing, and forced organizations to re-evaluate the trade-off between "managed Backstage" (Roadie) and self-hosting.

This article takes a deep look at 11 major players in the 2026 IDP market — Backstage, Port, Cortex, OpsLevel, Humanitec, Mia-Platform, Compass (Atlassian), Roadie, Configure8, Mercari ATLAS, and Naver SCM Portal.

Platform Engineering vs DevOps: What Is Different

The 2010s DevOps movement tore down the wall between development and operations with the philosophy of "You build it, you run it." But by the mid-2020s, with microservices exploding, the model showed its limits. Demanding that the average full-stack developer deeply understand Kubernetes manifests, Terraform, Helm charts, ArgoCD, Prometheus, Grafana, Datadog, Snyk, and SonarQube — all of it — was unrealistic.

*Team Topologies*, published in 2019 by Manuel Pais and Matthew Skelton, offered an answer: a **Platform team** must provide self-service infrastructure so that **Stream-aligned teams** (value delivery teams) can move quickly.

Platform Engineering is not a rejection of DevOps but its evolution. The cultural values of DevOps (collaboration, automation, measurement, sharing) are preserved, while a well-designed abstraction layer is added to reduce cognitive load.

Team Topologies and the Four Team Types

Team Topologies defines four fundamental team types:

1. **Stream-aligned team** — aligned with a value stream (e.g. payments, search, recommendations)

2. **Platform team** — provides a self-service platform for stream-aligned teams

3. **Enabling team** — supports and coaches other teams in a specific technical domain (security, SRE, data)

4. **Complicated-subsystem team** — owns areas requiring deep specialist expertise (e.g. ML inference engines, trading engines)

The golden rule for platform teams is **"treat the platform as a product."** The users are the stream-aligned developers, and their satisfaction (NPS) and adoption rate become the success metrics for the platform team.

Backstage 1.30: What Changed at the Core

As of May 2026, Backstage is on the 1.30.x line. Major changes in the 1.30 series include:

- **New Frontend System (NFS)** GA: the new extension model replacing the legacy createPlugin API is now stable.

- **Catalog database backend** performance improvements: SQLite in production (beyond PostgreSQL) is officially in the deprecation phase.

- **Permission Framework** integration: per-catalog-entity RBAC policies can now be expressed in OPA (Open Policy Agent) or Casbin.

- **Software Templates** schema migration from v1beta3 to v1.

The biggest operational shift is the **NFS (New Frontend System)**. If you don't migrate existing plugins, support will end after 1.32. For organizations with 50+ in-house plugins (Netflix, Spotify, Rakuten), this is a 6–9 month migration project.

Backstage Core Concepts: Software Catalog

The Software Catalog is the heart of Backstage. Every component (service, library, website), API, resource (database, S3 bucket), system, and domain is expressed as a `catalog-info.yaml` file.

apiVersion: backstage.io/v1alpha1

kind: Component

metadata:

name: payment-service

description: Core payment processing service

annotations:

github.com/project-slug: acme-corp/payment-service

backstage.io/techdocs-ref: dir:.

pagerduty.com/integration-key: PAGERDUTY_KEY_REF

sonarqube.org/project-key: payment-service

grafana/dashboard-selector: "tag = 'payment'"

tags:

- java

- spring-boot

- tier-1

spec:

type: service

lifecycle: production

owner: team-payments

system: checkout

providesApis:

- payment-api-v2

consumesApis:

- fraud-detection-api

- notification-api-v1

dependsOn:

- resource:postgres-payments

- resource:redis-payment-cache

Once this file is pushed to GitHub, the Backstage Catalog Processor discovers it and automatically indexes all metadata, owners, and dependency graphs. When a new engineer on another team asks "who owns the payment system? what DB does it use?", the answer lives in a YAML file next to the code.

Software Templates and the Scaffolder

Software Templates deliver on the IDP's most powerful promise — **"a new service in production in five minutes."**

apiVersion: scaffolder.backstage.io/v1beta3

kind: Template

metadata:

name: java-spring-microservice

title: Java Spring Boot Microservice (Golden Path)

description: Java 21 + Spring Boot 3.3 + JPA + OpenTelemetry

spec:

owner: team-platform

type: service

parameters:

- title: Service Identity

required: [name, owner, tier]

properties:

name:

type: string

pattern: '^[a-z][a-z0-9-]{2,30}$'

owner:

type: string

ui:field: OwnerPicker

tier:

type: string

enum: [tier-1, tier-2, tier-3]

steps:

- id: fetch-template

name: Fetch Skeleton

action: fetch:template

input:

url: ./skeleton

values:

name: ${{ parameters.name }}

owner: ${{ parameters.owner }}

- id: publish

name: Publish to GitHub

action: publish:github

input:

repoUrl: github.com?repo=${{ parameters.name }}&owner=acme-corp

defaultBranch: main

protectDefaultBranch: true

requireCodeOwnerReviews: true

- id: register

name: Register in Catalog

action: catalog:register

input:

repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

catalogInfoPath: /catalog-info.yaml

Running this template once automatically triggers: GitHub repo creation, branch protection, CODEOWNERS setup, ArgoCD ApplicationSet registration, Datadog monitor provisioning, OpsGenie on-call schedule linking, and a SonarCloud project. A developer can go from first commit to production deploy in 30 minutes.

TechDocs: Documentation Next to the Code

TechDocs is Backstage's implementation of "docs as code." Built on MkDocs, it renders markdown files placed in each component's `docs/` directory into a searchable site inside Backstage.

The key operational pattern is the split between **TechDocs Out-of-the-box (OOTB) vs Recommended**. OOTB mode builds docs on demand when a user enters the catalog, which creates severe latency at 200+ component scale. The Recommended mode builds MkDocs in CI, pushes to S3/GCS, and Backstage merely serves static files. In production environments, Recommended mode is effectively the standard.

Backstage Plugin Ecosystem: Five Core Plugins

Backstage's true value comes from its plugin ecosystem. As of May 2026 there are 350+ official and community plugins. Here are the five most widely adopted:

1. **@backstage/plugin-kubernetes** — surfaces K8s deployment, pod, service, and HPA state per component. Multi-cluster support is solid; EKS/GKE/AKS auth is all standard.

2. **@backstage-community/plugin-github-actions** — embeds recent GHA workflow runs into each component's catalog page.

3. **@backstage-community/plugin-sonarqube** — exposes code quality metrics (coverage, smells, vulnerabilities) in the catalog.

4. **@backstage/plugin-techdocs** — the docs-as-code engine described above.

5. **@backstage-community/plugin-cost-insights** — displays per-component cloud cost over time. The favorite plugin of FinOps teams.

Port: Model-Driven Low-Code IDP

Port (getport.io) was the fastest-growing SaaS IDP in 2024–2025. Where Backstage takes a "code-first" approach (catalogs defined in YAML), Port is "model-first": you first define what entity types (Blueprints) exist and what properties and relations they have, via UI or JSON.

{

"identifier": "service",

"title": "Service",

"schema": {

"properties": {

"language": { "type": "string", "enum": ["go", "java", "python", "node"] },

"tier": { "type": "string", "enum": ["1", "2", "3"] },

"on_call_rotation": { "type": "string", "format": "url" },

"slo_availability": { "type": "number", "minimum": 0, "maximum": 100 }

},

"required": ["language", "tier"]

},

"relations": {

"owning_team": { "target": "team", "required": true, "many": false },

"deployments": { "target": "deployment", "required": false, "many": true }

},

"calculationProperties": {

"is_production_ready": {

"calculation": ".properties.tier == \"1\" and .properties.slo_availability >= 99.9",

"type": "boolean"

}

}

}

Port's strengths:

- **Exporters**: AWS, GCP, K8s, GitHub, Snyk, Datadog, and 30+ integrations configurable without code.

- **Scorecards**: quantitative service maturity.

- **Self-Service Actions**: trigger actions like `/port deploy` from Slack.

The downsides are SaaS dependency and enterprise-tier pricing (starting around `$25K`/year), with on-prem options arriving late, which remains a barrier for Korean financial sector adoption.

Cortex: Service Maturity at the Center

Cortex (cortex.io) is an IDP centered on "Service Maturity." Where Port and Backstage balance catalog and actions, Cortex makes **Scorecards** the first-class citizen.

Cortex Scorecards support rule-based evaluations like:

- Every service must have an owner team.

- Tier-1 services must have a PagerDuty integration.

- SLO definitions must be refreshed within 90 days.

- Every production service must have an SBOM registered.

- Code coverage above 70%.

Each rule has a weight, and every service is auto-classified as "Bronze / Silver / Gold." Platform teams can tune weights quarterly to reflect company priorities (e.g. a security-hardening quarter, a reliability quarter).

OpsLevel: Rubrics and Campaigns

OpsLevel (opslevel.com) is the most direct competitor to Cortex. Its core concepts are **Rubrics** and **Campaigns**.

- **Rubrics**: checklists each service must satisfy (similar to Cortex Scorecards).

- **Campaigns**: time-bounded improvement initiatives like "remove Log4j 1.x across the entire company within 30 days." Each team's progress is tracked in real time.

OpsLevel's differentiator is **AI Engineer** (launched in 2025) — you can query the catalog in natural language ("which tier-1 services have no PagerDuty integration?"). Compare this with Backstage's RAG-based catalog search, which is still experimental.

Humanitec and Score: Standardizing Workload Specs

Humanitec (humanitec.com) sits at a different layer from the other IDPs. If Backstage, Port, and Cortex are the "portal" layer, Humanitec is the "Internal Developer Platform Orchestrator" — the engine that actually abstracts environment provisioning and deployment.

The open spec Humanitec drives is **Score** (score.dev). Score joined CNCF Sandbox in 2025 and aims to be the environment-agnostic standard for workload specifications.

apiVersion: score.dev/v1b1

metadata:

name: orders-api

containers:

main:

image: ghcr.io/acme/orders-api:v3.4.2

variables:

DATABASE_URL: ${resources.orders-db.connection}

REDIS_URL: ${resources.cache.url}

LOG_LEVEL: info

resources:

requests:

cpu: "200m"

memory: "256Mi"

limits:

cpu: "1000m"

memory: "512Mi"

service:

ports:

http:

port: 8080

targetPort: 8080

resources:

orders-db:

type: postgres

params:

version: "16"

cache:

type: redis

dns:

type: dns

A single file transparently translates to docker-compose in dev, Kubernetes + RDS in staging, and EKS + Aurora in production. If Backstage answers "what exists?", Score answers "how is it run?"

Mia-Platform: Europe's IDP Heavyweight

Mia-Platform (mia-platform.eu) is a Milan-based IDP that has strong adoption across European financial services. It packages a Backstage UI on top of Mia's own fast-data engine, microservice templates, and multi-cluster deployment tooling. Its SaaS+self-hosted hybrid model and built-in PSD2/GDPR compliance are its main strengths in the EU.

Compass (Atlassian): Integration with Jira and Confluence

Atlassian Compass targets organizations already running Jira, Confluence, and Bitbucket. Its standout strength is **workflow integration**. From a service in the Compass catalog, you can create Jira tickets directly, and change history publishes automatically to Confluence pages.

The catch: Compass is currently Atlassian Cloud-only, and many large Korean and Japanese organizations still on Data Center are hesitant to adopt. Whether Atlassian ships a Data Center version of Compass in 2026 is a key thing to watch.

Roadie: Managed Backstage

Roadie (roadie.io) is the SaaS for organizations that "don't want to run Backstage themselves but still want Backstage's flexibility." Roadie packages Backstage core as plugins-as-a-service without forking, maintaining upstream compatibility.

Decision criteria for choosing Roadie:

- Platform team of 5 or fewer → Roadie recommended (self-hosting Backstage needs 2–3 full-time engineers).

- Low need for custom plugin development → Roadie recommended.

- Data sovereignty (especially EU/Korea financial) → self-hosted Backstage.

- 200+ services → factor in Roadie's multi-tenancy limits.

Configure8: IDP Focused on Visualization

Configure8 is a newer IDP with a strong emphasis on service topology visualization. Its differentiators are dependency graphs, real-time traffic flow, and blast-radius visualization during incidents. Catalog consistency and self-service automation are still less mature than Port or Backstage.

Korean and Japanese Cases: Kakao, Mercari ATLAS, Rakuten

In Korea, **Kakao's Cognity** platform team — in collaboration with Kakao Enterprise — operates a Backstage-based internal IDP. It integrates SLO, cost, and security compliance management across 200+ microservices. **Naver runs SCM Portal**, an in-house IDP, which couples GitHub Enterprise + Jenkins + Argo + their own K8s control plane. **LINE (LY Corporation)** maintains an internal fork of Backstage as its dev portal.

In Japan, the best-known case is **Mercari's ATLAS**. First disclosed in 2022 on the Mercari Engineering blog, ATLAS is a Backstage-based internal portal that integrates ML Platform, SRE, and Security tools. As of 2026, it manages 800+ components across the Mercari group. **CyberAgent's AKE** (AbemaTV Kubernetes Engine) and **Rakuten's One Platform** also operate their own IDPs. **Sansan** is known as an early Japanese adopter of Compass.

Golden Paths and Paved Roads

"Golden Path" is a term Spotify introduced in 2020 — one recommended, well-paved route where infrastructure, security, and observability come automatically. Netflix calls the same idea the "Paved Road" — on the road you are safe and fast, but off-roading is your own responsibility.

Golden Paths are not mandatory. Teams with special requirements can deviate, but they shoulder the responsibility (security audits, cost optimization, incident response) themselves. When this trade-off is clearly communicated, developer autonomy and organizational standards can coexist.

Measuring DX: DORA + SPACE

How should a platform team define "success"? The four DORA (DevOps Research and Assessment) metrics are the starting point.

1. **Deployment Frequency** — how often you deploy

2. **Lead Time for Changes** — time from commit to production

3. **Change Failure Rate** — share of deployments causing incidents/rollbacks

4. **Mean Time to Recovery** — time to restore service after an incident

But DORA alone is not enough. The **SPACE framework** published by Microsoft Research in 2021 adds five dimensions: Satisfaction, Performance, Activity, Communication/collaboration, and Efficiency. Developer satisfaction in particular must be tracked via a quarterly NPS — if the IDP's real users don't enjoy it, the quantitative metrics are likely lying.

Self-Service Infrastructure Templates: Terraform Modules + Crossplane

Day 0 of Software Templates is easy; Day 2 (lifecycle management) is hard. The 2026 standard pattern:

- **Terraform Modules** (or Pulumi/CDK) — opinionated units of cloud resources.

- **Crossplane Compositions** — managing cloud resources Kubernetes-natively.

- **Backstage Scaffolder** triggers both and registers the resulting resources in the catalog.

What happens when a developer requests "New Postgres DB" in the Backstage UI

backstage scaffolder run \

--template postgres-database \

--name orders-db \

--tier production \

--size medium

Under the hood

git push -> renovate-style PR -> ArgoCD sync ->

Crossplane Composition -> AWS RDS Aurora cluster ->

catalog entity registration -> Datadog monitor created ->

PagerDuty service linked -> Slack notification

Multi-Cluster App Management

In 2026, the standard for large organizations is a fleet of clusters — separated by region, environment, and team. The Backstage Kubernetes plugin handles 30+ clusters well, but beyond that you need the following patterns:

- **Modularize cluster locators**: model cluster metadata as catalog entities.

- **ArgoCD ApplicationSet + Backstage**: visualize a single component deployed across 5 regions simultaneously.

- Integrate multi-cluster control planes like **KubeFleet / Karmada / Liqo**.

Open Source IDP vs SaaS: Decision Matrix

| Item | Backstage (self-hosted) | Roadie (managed BS) | Port | Cortex | OpsLevel |

| --- | --- | --- | --- | --- | --- |

| Initial learning curve | High | Medium | Low | Low | Low |

| Customization freedom | Very high | High | Medium | Medium | Medium |

| Operational FTEs | 2~3+ | 0.5~1 | 0.5~1 | 0.5~1 | 0.5~1 |

| Starting price (annual) | Infra only | about `$15K` | about `$25K` | about `$30K` | about `$30K` |

| Data sovereignty | Full control | Limited | SaaS-dependent | SaaS-dependent | SaaS-dependent |

| Plugins | 350+ | 100+ (curated) | 30+ integrations | 20+ integrations | 25+ integrations |

| Scorecard maturity | Medium (community) | Medium | High | Very high | Very high |

Prices are rough estimates based on publicly available information as of May 2026; actual enterprise contracts require separate negotiation.

Security and Governance: New Responsibilities the IDP Brings

As the privileges an IDP carries grow, so does its attack surface. PagerDuty keys, AWS account IDs, and GitHub PATs exposed in the Backstage catalog, combined with an SSRF vulnerability, can become a critical incident. The 2024–2025 Backstage security advisories (e.g. GHSA-9p4x-3v2h-9q4j) make it clear that the IDP is no longer just a catalog — it sits at the center of the supply chain.

Recommended controls:

- Enable the Permission Framework (default deny).

- OIDC SSO + step-up auth (sensitive actions require 2FA).

- Send every Scaffolder action's audit log to your SIEM.

- Express catalog secrets/keys only as references to an external vault.

Adoption Roadmap: 0 → 1 → N

The common pitfall when platform teams first adopt an IDP is "everything at once." A staged approach:

**Stage 0 (Months 1–2)**: 5–10 interviews with stream-aligned teams. Map cognitive load. Identify top 3 pain points.

**Stage 1 (Months 3–6)**: PoC one of Backstage or Port. Start with catalog only. Register 30–50 key services as catalog-info.yaml.

**Stage 2 (Months 6–9)**: Build exactly one Software Template. Example: "Java microservice golden path." Success means 5–10 new services are created from this template.

**Stage N (Year 2+)**: Add Scorecards. Integrate Cost Insights. Multi-cluster visualization. Adopt Score workload specs.

Seven Common Anti-Patterns

1. **Forcing the catalog before proving value** — top-down mandates don't drive adoption.

2. **Releasing too many templates at once** — one good template beats 30 mediocre ones.

3. **Platform team directly editing stream-aligned team code** — violates Topology principles.

4. **Using TechDocs OOTB in production** — collapses at 200+ services.

5. **Setting Scorecard weights once and never revisiting** — quarterly review is mandatory.

6. **Adopting SaaS IDPs without reviewing data residency** — fails audits in financial services.

7. **Reporting only quantitative metrics without measuring NPS** — DORA can be green while developers hate the platform.

Beyond 2026: The Future of IDPs

Three big currents will define the next five years of IDPs:

1. **AI-Native IDP**: triggering the Scaffolder via natural-language commands ("create a new service in staging"). OpsLevel AI Engineer and Port AI Agents are early examples.

2. **Broader adoption of the Score standard**: as the consensus solidifies that K8s manifests are too complex, workload abstraction layers will standardize.

3. **Evolution of Backstage governance**: the final lap toward CNCF Graduation. How the Spotify commercial fork issue is resolved is the central question.

Platform Engineering is no longer a trend — it is the standard operating model for late-2020s software organizations.

References

- [Backstage Official Documentation](https://backstage.io)

- [Backstage 1.30 Release Notes](https://backstage.io/docs/releases/v1.30.0/)

- [getport.io — Port IDP](https://www.getport.io/)

- [cortex.io — Service Maturity Platform](https://www.cortex.io/)

- [opslevel.com — Engineering Excellence](https://www.opslevel.com/)

- [humanitec.com — Internal Developer Platform Orchestrator](https://humanitec.com/)

- [score.dev — Workload Specification](https://score.dev/)

- [teamtopologies.com](https://teamtopologies.com/)

- [dora.dev — DORA Research](https://dora.dev/)

- [SPACE Framework Paper, Microsoft Research](https://queue.acm.org/detail.cfm?id=3454124)

- [Mia-Platform Documentation](https://mia-platform.eu/)

- [Atlassian Compass](https://www.atlassian.com/software/compass)

- [roadie.io — Managed Backstage](https://roadie.io/)

- [Configure8](https://www.configure8.io/)

- [Mercari Engineering — ATLAS Internal Platform](https://engineering.mercari.com/en/blog/)

- [CNCF Annual Survey 2025](https://www.cncf.io/reports/)

- [Spotify Engineering Blog — Golden Paths](https://engineering.atspotify.com/)

- [Netflix Tech Blog — Paved Road](https://netflixtechblog.com/)

현재 단락 (1/266)

In 2024, Gartner predicted that "by 2026, 80% of large software organizations will operate a platfor...

작성 글자: 0원문 글자: 19,021작성 단락: 0/266