Platform engineering: consolidación tras el boom
Actualizado: 2026-05-03
Platform engineering cumple tres años como etiqueta popular a finales de 2025, y el ecosistema que creció a su alrededor está entrando en una fase más tranquila tras el entusiasmo inicial. Los equipos que se montaron con prisas durante 2022 y 2023 han pasado por el filtro real de los últimos dos años. Algunos han producido valor claro y ahora son piezas centrales de sus organizaciones; otros se han disuelto silenciosamente o han quedado reducidos a una persona y un portal que nadie usa. Vale la pena revisar qué ha pasado, qué patrones diferencian los casos buenos de los malos, y cómo pensar hoy la disciplina cuando ya no es una promesa sino una práctica con cicatrices.
Puntos clave
- Los equipos de platform engineering que entregaron valor real entendieron que una plataforma interna es producto, con gestor de producto, investigación de usuario y ciclos de iteración.
- Los tres errores más frecuentes: montar plataformas sin entender para quién, confundir Backstage con plataforma, y tratar la plataforma como proyecto con fecha de entrega en lugar de producto con evolución continua.
- La métrica que mejor captura si una plataforma funciona es el tiempo entre que un equipo empieza a construir un servicio nuevo y lo tiene corriendo en producción con todos los estándares cumplidos.
- Backstage sigue siendo relevante en 2025 pero su posición es más madura: es una opción entre varias, no el estándar obligatorio.
- Una empresa con diez ingenieros no necesita plataforma interna; una con cien empieza a beneficiarse si se hace bien; una con mil probablemente no puede permitirse no tenerla.
Qué prometía y qué entregó
La tesis original de platform engineering era razonable: los equipos de producto pierden demasiado tiempo resolviendo problemas de infraestructura que se repiten, las plataformas internas bien diseñadas pueden capturar ese trabajo común y ofrecerlo como servicio, y una organización que invierte en esa capa entrega más rápido y con menos fricción.
La promesa que muchas empresas escucharon, sin embargo, fue distinta. Se tradujo en “montamos un equipo, instalamos Backstage, ponemos catálogos de servicios y plantillas, y el tiempo que los equipos pierden en infraestructura desaparece”. Esa versión simplificada llevó a muchos fracasos. Montar Backstage sin un equipo disciplinado detrás que mantenga plantillas, documentación y flujos es equivalente a montar un wiki: se llena de páginas que nadie actualiza y se convierte en un cementerio.
Los equipos que han entregado valor real comparten algunos patrones:
- Entendieron que una plataforma interna es producto, con gestor de producto, investigación de usuario y ciclos de iteración.
- Midieron adopción real de sus herramientas, no solo su existencia.
- Priorizaron caminos dorados sobre flexibilidad ilimitada, aceptando que un buen 90 por ciento cubre el caso común.
- Mantuvieron equipos de producto como clientes respetados, no como usuarios cautivos.
Errores repetidos
Hay tres patrones de fracaso que se repitieron con frecuencia:
El primero fue montar plataformas sin entender para quién. Equipos que escribieron plantillas genéricas basadas en su propia intuición de qué servicios se necesitan, sin hablar con los equipos de producto que iban a usarlas. Las plantillas salían, los equipos de producto las probaban una vez, encontraban que no encajaban con su realidad y volvían a construir infraestructura a mano. La plataforma se convertía en decoración.
El segundo fue confundir Backstage con plataforma. Backstage es un portal, una interfaz para descubrir servicios, plantillas y documentación. No resuelve los problemas por sí mismo, solo los organiza y presenta. Equipos que instalaron Backstage sin invertir en los flujos detrás terminaron con un portal vacío o desactualizado, donde la información era menos fiable que un documento compartido.
El tercero fue tratar la plataforma como proyecto y no como producto. Un proyecto tiene fecha de entrega y después pasa a mantenimiento; una plataforma necesita evolución continua mientras tenga usuarios. Cuando el proyecto se declaró terminado y el equipo se disolvió o se redujo drásticamente, la plataforma empezó a envejecer rápido y los equipos de producto empezaron a saltársela.
Qué separa los casos de éxito
Los equipos de platform engineering que están sanos a finales de 2025 tienen varios rasgos en común:
- Están cerca del negocio, no solo de la operación. Conocen qué prioridades tiene la empresa y preparan su plataforma para servir esas cargas antes de que lleguen los equipos de producto a pedirlas.
- Miden: cuántos servicios usan la plantilla oficial, cuántos pipelines pasan por la infraestructura estándar, qué tiempo tarda un equipo nuevo en desplegar su primer servicio.
- Cuidan la experiencia del desarrollador como rasgo de producto: documentación buena, errores claros, flujos consistentes, despliegues predecibles.
El papel cambiante de Backstage
Backstage cumplió cinco años como proyecto de Spotify liberado. Durante 2023 fue la herramienta de moda y todos los equipos de platform engineering lo instalaron. Durante 2024 empezaron las críticas: curva de aprendizaje empinada, plugins de calidad irregular, operación compleja. En 2025 Backstage sigue siendo relevante pero su posición es más madura: es una opción entre varias, no el estándar obligatorio.
Alternativas como Port o Cortex han ganado cuota de mercado ofreciendo experiencia más empaquetada a cambio de menos flexibilidad. Para equipos pequeños que no quieren operar Backstage, estas opciones son pragmáticas. Para equipos grandes con necesidades específicas, Backstage sigue siendo la opción de más recorrido, pero con el entendimiento claro de que requiere inversión continua.
Qué mide realmente el valor
La métrica que mejor captura si una plataforma funciona es el tiempo entre que un equipo empieza a construir un servicio nuevo y lo tiene corriendo en producción con todos los estándares cumplidos. En plataformas sanas ese tiempo es de horas o de un día; en plataformas enfermas es de semanas porque el equipo descubre que la plantilla no aplica, que la infraestructura hay que solicitarla por ticket, que la observabilidad requiere configuración manual.
Otra métrica útil es la proporción de servicios en producción que siguen los estándares de la plataforma. Cuando esa proporción es alta, la plataforma es eficaz; cuando es baja, los equipos están eludiendo la plataforma por algún motivo. Este principio de medir adopción real aplica también a otras herramientas de ingeniería, como describimos en testing con IA: el problema del determinismo: no basta con que la herramienta exista, tiene que usarse y producir resultados.
Una tercera métrica es la satisfacción reportada por los equipos de producto. Encuestas regulares detectan señales tempranas de degradación que los números tardan en mostrar.
Cuándo compensa
La pregunta honesta para una organización es si tiene el tamaño y la complejidad que justifican invertir en platform engineering:
- Una empresa con diez ingenieros no necesita plataforma interna, la plataforma es el propio equipo; lo que necesita es buenas prácticas y algunos scripts compartidos.
- Una empresa con cien ingenieros empieza a beneficiarse si hay suficiente heterogeneidad de servicios; el retorno no es automático pero puede ser significativo si se hace bien.
- Una empresa con mil ingenieros probablemente no puede permitirse no tenerla, porque la pérdida de productividad sin plataforma unificada es enorme.
El error clásico es entrar antes de tiempo, con demasiada ambición y sin entender que la plataforma tiene que ganar a los equipos uno a uno, no imponerse por decreto. Cuando eso se intenta, lo que queda es una plataforma que los equipos esquivan y un equipo de plataforma frustrado porque nadie usa lo que construye.
Mi lectura
Platform engineering como disciplina ha madurado mucho en estos tres años, aunque el camino ha dejado más fracasos que éxitos visibles. Los equipos que entendieron que su función es construir producto para desarrolladores internos, con la misma disciplina que cualquier producto externo, han tenido éxito razonable. Los que confundieron la etiqueta con la solución, o pensaron que instalar herramientas equivalía a entregar valor, han aprendido la lección por la vía dura.
Para 2025 y adelante, la pregunta ya no es si tu organización necesita platform engineering sino cómo ejecutarlo bien. Las recetas están mejor documentadas, las trampas conocidas son más numerosas, y las herramientas disponibles son más variadas. Pero el trabajo sigue siendo difícil y cultural, y la parte técnica sigue siendo la más pequeña del reto.
Conclusión
Quien entienda que la plataforma es un producto y lo opere como tal tiene una probabilidad razonable de éxito; quien piense que es un proyecto de infraestructura renombrado seguirá repitiendo los errores que dominaron la fase de expansión.
