Backstage, Port y Cortex: tres caminos al IDP
Actualizado: 2026-05-03
El término Internal Developer Platform (IDP) cobró tracción a lo largo de 2023. La idea es sólida: reducir la carga cognitiva de los 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[1] (Spotify, open source), Port[2] (comercial, low-code) y Cortex[3] (comercial, scorecards). Este artículo es una comparación honesta con criterios para elegir.
Qué problema resuelve un IDP
Los desarrolladores en organizaciones medianas y grandes pasan tiempo en tareas que no deberían consumirlo:
- 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 básica: “¿está mi servicio OK? ¿hay errores?”
Un IDP centraliza esto en un portal que es la puerta al ecosistema interno. La alternativa es fragmentación: wikis obsoletas, canales de Slack, conocimiento tribal. Ver el artículo sobre platform engineering e IDP para el contexto estratégico más amplio.
Backstage: el estándar open source
Backstage nació en Spotify y se liberó en 2020. Hoy es un proyecto de la CNCF con comunidad amplia.
Fortalezas:
- Open source puro (Apache 2.0). Sin vendor lock-in.
- Extensible vía plugins: catálogos, docs, costes, recursos cloud, Kubernetes — decenas disponibles.
- Catálogo basado en YAML en Git: los servicios se describen junto al código.
- TechDocs: documentación como código renderizada in-portal.
- Comunidad grande: meetups, conferencias, empresas contribuyendo activamente.
Debilidades:
- Curva de adopción alta: 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 pestaña 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 — mínimo tres personas — y compromiso multianual.
Port: low-code y más rápido
Port (israelí, fundada en 2022) toma un enfoque radicalmente diferente. SaaS comercial con configuración visual.
Fortalezas:
- Setup en horas, no meses: el modelo está prediseñado, solo lo adaptas.
- Catálogo dinámico: ingestión automática desde AWS, GitHub, Kubernetes, Terraform state, JIRA.
- Blueprints y acciones self-service visuales: developer self-service sin código.
- Scorecards integrados: “producción-ready”, “nivel de observabilidad”.
- 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 desarrollador.
- Menor extensibilidad: si necesitas algo muy custom, Port puede no llegar.
- Vendor lock-in: migrar a otro IDP sería reconstruir desde cero.
Port es para empresas que quieren IDP productivo rápido, sin invertir en equipo de plataforma propio.
Cortex: enfoque en scorecards
Cortex (fundada en 2019) 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 y otros.
- Reliability workflows: on-call, post-mortems, runbooks.
- Queries potentes: “muestra servicios sin owner con más de 100 errores/día”.
- Engineering excellence: foco en subir el nivel técnico de forma medible.
Debilidades:
- Precio alto: Cortex es de los más caros en esta categoría.
- Menos self-service que Port: foco en visibilidad y medición, no en aprovisionamiento.
- UI densa: curva para usuarios no técnicos.
Cortex es para empresas que quieren subir el nivel técnico medible, especialmente tras incidentes graves.
Tabla comparativa
| Aspecto | Backstage | Port | Cortex |
|---|---|---|---|
| Modelo | OSS | SaaS | SaaS |
| Time-to-value | 3-6 meses | semanas | 1-2 meses |
| Extensibilidad | Código React | Low-code | Configurable |
| Self-service | Con trabajo | Nativo | Menor |
| Scorecards | Plugin | Nativo | Núcleo |
| Coste | Infraestructura + equipo | Licencia SaaS | Licencia SaaS |
| Lock-in | Bajo | Alto | Alto |
Decisión según tamaño de equipo
Startup o equipo de menos de 30 ingenieros:
Un IDP sofisticado es overkill. Un README bien mantenido, un canal de Slack ordenado y dashboards de Kubernetes cubren el 80%. Si necesitas algo, empieza con Port en el tier gratuito o básico.
Mid-market (30-150 ingenieros):
Port es el sweet spot: productivo rápido, sin necesidad de equipo de plataforma dedicado. Cortex si el foco es elevar el nivel técnico medible — por ejemplo, tras un incidente grave que reveló falta de ownership y observabilidad.
Enterprise (150+ ingenieros):
Backstage empieza a justificarse por extensibilidad y personalización. Necesita equipo dedicado de tres a diez personas que lo opere y evolucione. Port o Cortex son alternativas si prefieres gestión comercial y menor carga operativa.
El error común: portal-fetish
Muchos equipos instalan Backstage y se sorprenden porque los desarrolladores no lo usan. La causa típica: el portal tiene solo catálogo estático — sin self-service real, sin workflows ejecutables, sin acciones.
Un IDP útil ofrece cuatro cosas:
- Catálogo con información rica: no solo nombre, sino dependencias, SLIs, on-call responsable.
- Acciones self-service ejecutables: crear repo, aprovisionar BD, hacer rollback.
- Automation integrada: no “haz clic aquí, luego copia-pega en otro sitio”.
- Observabilidad in-context: métricas del servicio visibles directamente en el portal.
Sin eso, es solo un wiki disfrazado de portal moderno.
Crawl, walk, run
Enfoque pragmático para construir un IDP de cero:
- Fase 1: catálogo de servicios — quién es owner de qué, links a repos y dashboards.
- Fase 2: docs as code (TechDocs en Backstage o equivalente).
- Fase 3: acciones self-service básicas (crear servicio, aprovisionar entorno).
- 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 a los tres meses. Para la capa de observabilidad subyacente que cualquier IDP consume, ver OpenTelemetry y unificación de observabilidad.
Alternativas más ligeras
Si la decisión es no montar IDP completo, hay puntos intermedios válidos:
- README + GitHub Topics: curar los repos como catálogo mínimo viable.
- OpsLevel: similar a Cortex, más enfocado en maturity scoring.
- Wiki estructurada en Notion o Confluence: low-tech pero funciona en equipos de menos de 50.
- Slack + bots para self-service: crear repo vía
/create-serviceen Slack.
No todo debe ser un portal React gigante con equipo dedicado.
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 total; Port para velocidad y pragmatismo; Cortex para disciplina técnica medible. El valor está en el contenido y los workflows ejecutables, no en la interfaz — instalar un portal bonito sin contenido real es el error más caro que puede cometer un equipo de plataforma.
