Platform engineering: plataformas internas para desarrolladores

Actualizado: 2026-05-03

Platform engineering ha emergido como disciplina distinta de DevOps y SRE. La idea central: en lugar de que cada equipo construya y operativice su propia infraestructura, un equipo dedicado ofrece una plataforma interna (IDP — Internal Developer Platform) como producto. El objetivo es que los equipos de producto entreguen valor rápido sin convertirse en expertos en Kubernetes, Terraform o el sistema de CI.

Puntos clave

• El problema que resuelven los IDPs es organizativo, no técnico: duplicación, fricción cognitiva e inconsistencia operativa entre equipos.
• Un IDP maduro combina portal de desarrollador, catálogo de servicios, golden paths, self-service y observabilidad por defecto.
• Backstage de Spotify es la referencia open-source, base de la mayoría de IDPs en empresas grandes, pero requiere inversión sustancial de adaptación.
• Los golden paths son el valor central: el “camino feliz” tan subvencionado que la mayoría lo sigue por defecto, sin que sea mandatorio.
• Antes de 30-50 desarrolladores, la inversión en IDP suele ser prematura.

El problema que resuelve

A partir de cierta escala (20+ servicios, 50+ desarrolladores), el patrón “cada equipo gestiona su stack” se vuelve caro por cuatro razones:

• Duplicación. Cada equipo resuelve independientemente deployment, observabilidad, secrets y auth.
• Fricción cognitiva. Un desarrollador backend dedica el 30-40% del tiempo a tareas de infraestructura fuera de su especialidad.
• Inconsistencia operativa. Problemas similares resueltos de formas distintas complican incidentes y auditorías.
• Movilidad reducida. Mover un ingeniero entre equipos requiere reaprender su toolchain completo.

IDPs abordan esto consolidando lo común detrás de una interfaz unificada, sin limitar la flexibilidad donde importa.

Qué compone un IDP

Un IDP maduro incluye habitualmente seis componentes:

• Portal de desarrollador: UI unificada para ver, crear y gestionar servicios. Backstage^[1] de Spotify es la referencia open-source.
• Catálogo de servicios: inventario con metadata (equipo responsable, dependencias, SLOs, docs). Es la “base de datos” del IDP.
• Golden paths: templates pre-construidos para casos comunes que reducen la creación de un nuevo servicio a un comando.
• Self-service: los equipos de producto pueden aprovisionar recursos sin tickets manuales al equipo de plataforma.
• Observabilidad por defecto: todo servicio nuevo arranca con métricas, logs y trazas preconfiguradas.
• Guardrails, no gates: políticas que permiten avanzar pero alertan o previenen errores conocidos.

Backstage como referencia

Backstage^[1], open-sourced por Spotify en 2020, ofrece cuatro funciones principales:

• Software catalog: YAML describe servicios, ownership, docs y relaciones. Una entrada por entidad (servicio, librería, website, infraestructura).
• Plugins: ecosistema de más de 100 plugins (CI/CD status, Kubernetes, monitoring, docs) en el mismo portal.
• TechDocs: documentación como código, renderizada dentro del portal.
• Scaffolder: generador de nuevos componentes a partir de templates en un clic.

En la práctica, Backstage es la base de docenas de IDPs internos en empresas grandes, aunque requiere inversión sustancial para adaptarlo al contexto propio.

Golden paths: el valor central

Un golden path responde a: “Quiero crear un microservicio nuevo — ¿cuál es la forma recomendada aquí?”. La respuesta es un template que genera de forma automática:

• Repositorio con estructura estándar.
• Dockerfile y CI configurado.
• Manifiestos Kubernetes con límites de recursos y health checks.
• Dashboard de Grafana pre-creado.
• Alerta básica de error rate sobre SLO.
• Integración con el sistema de auth de la empresa.

Lo clave: el golden path no es mandatorio. Los equipos pueden desviarse cuando lo necesiten. Pero el “camino feliz” es tan claro y está tan subvencionado que la mayoría lo sigue por defecto.

Cuándo invertir en platform engineering

Cuatro señales de que es momento de formalizar un IDP:

• Más de 30-50 desarrolladores trabajando en servicios interconectados.
• Duplicación visible entre equipos en configuración, deployment y observabilidad.
• Incidentes cuyo root cause es “cada equipo lo hace distinto”.
• Onboarding lento — más de dos semanas para que un nuevo ingeniero pueda desplegar algo útil.

Para equipos más pequeños, la inversión suele ser prematura. Mejor empezar con buenas prácticas y scripts compartidos, formalizar plataforma cuando la escala lo justifique.

Antipatrones a evitar

Tres errores frecuentes en implementaciones que no llegan a funcionar:

• Platform team = “DevOps team renombrado”. Si solo se hace infraestructura sin tratar al desarrollador como cliente, no es platform engineering.
• IDP como gate, no como path. Forzar al equipo de producto a pasar por el IDP bloquea la innovación. Ofrecerlo como opción claramente mejor es distinto.
• Construir todo custom. Backstage + plugins + algunas integraciones es suficiente para la mayoría. Reinventar la rueda rara vez justifica el coste.

Platform engineering complementa SRE: SRE opera lo que platform construye. Los costes de la plataforma se gestionan mejor con prácticas de FinOps — el IDP puede exponer el coste por equipo directamente en el portal. La integración de Backstage con Kubernetes permite a los equipos ver el estado de sus pods directamente en el catálogo.

Conclusión

Platform engineering es una disciplina madura para organizaciones de cierta escala. Un IDP bien diseñado libera tiempo de equipos de producto, consolida prácticas y reduce incidentes operativos. Pero solo si se trata como producto real con usuarios reales — los ingenieros internos — y no como proyecto de infraestructura más.

1. Backstage