Backstage, Port y Cortex: tres caminos al IDP

El término Internal Developer Platform (IDP) cobró tracción durante 2023. La idea: reducir la carga cognitiva de desarrolladores dándoles un portal unificado donde descubrir servicios, aprovisionar entornos, ejecutar workflows comunes, y tener visibilidad del estado de sus sistemas. Tres opciones dominan la conversación: Backstage (Spotify, open source), Port (comercial, low-code) y Cortex (comercial, scorecards). Este artículo es una comparación honesta con criterios para elegir.

Qué problema resuelve un IDP

Los desarrolladores en organizaciones medianas-grandes pasan tiempo en:

• Descubrir: “¿qué servicio hace X? ¿dónde está el código? ¿quién lo mantiene?”
• Aprovisionar: “¿cómo pido una BD? ¿cómo levanto un entorno de staging?”
• Workflows repetitivos: “¿cómo hago rollback? ¿cómo escalo esto?”
• Observabilidad: “¿está mi servicio OK? ¿hay errores?”

Un IDP centraliza esto: un portal que es la puerta al ecosistema interno. La alternativa es fragmentación — wikis obsoletas, canales de Slack, conocimiento tribal.

Backstage: el estándar open source

Backstage nació en Spotify y se liberó en 2020. Hoy es un proyecto de la CNCF con comunidad grande.

Fortalezas:

• Open source puro (Apache 2.0). Sin vendor lock-in.
• Extensible vía plugins. Catálogos, docs, costs, cloud resources, kubernetes — decenas.
• Community grande. Meetups, conferencias, empresas contribuyendo.
• Catálogo basado en YAML en Git. Los servicios se describen junto al código.
• TechDocs: documentación como código renderizada in-portal.

Debilidades:

• Curva de adopción alta. Pasar de “npm create app” a producción toma meses.
• Mantenimiento continuo. Es una app React que tú operas. Updates de plugins rompen.
• Personalización requiere código. Añadir una tab nueva es un PR al código del portal.
• Discovery cuesta. Sin entity catalog bien nutrido, Backstage vacío es decepcionante.

Backstage es para: empresas con equipo de plataforma dedicado (3-10 personas mínimo) y compromiso multianual.

Port: low-code y más rápido

Port (israelí, fundada 2022) toma un enfoque diferente. SaaS comercial con configuración visual.

Fortalezas:

• Setup en horas, no meses. El modelo está prediseñado; lo adaptas.
• Catálogo dinámico. Ingestión desde AWS, GitHub, Kubernetes, Terraform state, JIRA — automática.
• Blueprints y self-service actions visuales. Developer self-service sin código.
• Scorecards integrados: “producción-ready”, “nivel de observabilidad”, etc.
• UI más pulida que Backstage de base.

Debilidades:

• SaaS. Datos fuera de tu red (aunque ofrecen private cloud).
• Comercial. Pricing por servicio o por developer.
• Menor extensibilidad. Si necesitas algo muy custom, Port puede no llegar.
• Vendor lock-in. Migrar a otro IDP sería reconstruir el portal.

Port es para: empresas que quieren IDP productivo rápido, sin invertir en plataforma propia.

Cortex: enfoque en scorecards

Cortex (fundada 2019, rebranded en 2020) se posiciona fuerte en service catalog + engineering standards.

Fortalezas:

• Scorecards sofisticados: define niveles (Bronze, Silver, Gold) y mide servicios contra ellos.
• Catalog automático desde GitHub, Jira, Datadog, etc.
• Reliability workflows: on-call, post-mortems, runbooks.
• Queries potentes: “muestra servicios sin owner que tengan >100 errors/día”.
• Engineering excellence: foco en subir el nivel técnico medible.

Debilidades:

• Precio alto. Cortex es de los más caros.
• Menos self-service que Port. Foco en visibilidad y medición, no en aprovisionamiento.
• UI dense. Curva para usuarios no técnicos.
• Ecosistema menos abierto que Backstage.

Cortex es para: empresas que quieren subir el nivel técnico medible, con énfasis en observación de madurez.

Tabla comparativa

Decisión según tamaño

Mi recomendación según contexto:

Startup / equipo <30 ingenieros:

• Un IDP sofisticado es overkill. Un README bien mantenido + un canal de Slack ordenado + Kubernetes dashboards cubren el 80%.
• Si necesitas algo: Port gratuito o básico.

Mid-market / 30-150 ingenieros:

• Port es sweet spot: productivo rápido, no necesitas equipo de plataforma dedicado.
• Cortex si el foco es elevar el nivel técnico (p.ej. tras incidente grave).

Enterprise / 150+ ingenieros:

• Backstage empieza a justificarse por extensibilidad y customización.
• Equipo dedicado (3-10 personas) lo operan y evolucionan.
• Alternativamente Port o Cortex si prefieres gestión comercial.

El error común: portal-fetish

Muchos equipos instalan Backstage y luego se sorprenden porque desarrolladores no lo usan. La causa típica: el portal tiene solo catálogo estático — no self-service real, no workflows ejecutables, no acciones.

Un IDP útil ofrece:

• Catálogo con information rica (no solo nombre, sino dependencias, SLIs, on-call).
• Acciones self-service (crear repo, aprovisionar BD, rollback).
• Automation integrada (no “click este link, luego copia-pega”).
• Observabilidad in-context (métricas del servicio directamente visibles).

Sin eso, es solo un wiki disfrazado.

Crawl, walk, run

Enfoque pragmático para construir un IDP:

• Fase 1: catálogo de servicios (quién owner qué, links a repos y dashboards).
• Fase 2: docs as code (TechDocs equivalente).
• Fase 3: self-service actions (crear servicio, aprovisionar).
• Fase 4: scorecards y engineering standards medibles.
• Fase 5: workflows complejos (blue-green, rollbacks orquestados).

Intentar todo a la vez es la receta para abandonar.

Alternativas más ligeras

Si la decisión es no montar IDP completo, hay puntos intermedios:

• README + GitHub Topics: curar los repos como catálogo mínimo.
• Service Catalog de OpsLevel: similar a Cortex, más enfocado en maturity.
• Wiki estructurada en Notion/Confluence: low-tech pero funciona en equipos <50.
• Slack + bots para self-service (crear repo via /create-service).

No todo debe ser un portal React gigante.

Conclusión

Los IDPs son útiles para equipos que han crecido más allá del punto donde “pregunta en Slack” funciona. La elección entre Backstage, Port y Cortex depende de recursos, cultura y ambición — Backstage para quien puede invertir en plataforma y quiere control, Port para velocidad y pragmatismo, Cortex para disciplina técnica medible. Evitar la trampa de montar un portal bonito sin contenido real es el consejo más importante. El valor está en el contenido y los workflows, no en la UI.

Síguenos en jacar.es para más sobre platform engineering, developer experience y IDPs.