El concepto de platform engineering y la evolución hacia un DevOps 2.0 están colocando el “Golden Path” en el centro de cómo los equipos modernos diseñan, despliegan y operan software. Para responsables TIC y perfiles técnicos, esto significa pasar de gestionar herramientas sueltas y pipelines dispersos a pensar en plataformas internas que ofrecen caminos pavimentados, opinados y seguros para que los desarrolladores trabajen sin fricción.
De DevOps clásico a DevOps 2.0
Durante años, DevOps se ha centrado en integrar desarrollo y operaciones mediante automatización, CI/CD y cultura colaborativa, pero la explosión de microservicios, nubes híbridas y requisitos de seguridad ha disparado la complejidad. Muchos equipos han acabado con stacks sobredimensionados: múltiples herramientas de CI, pipelines diferentes por squad, configuraciones ad hoc y una carga cognitiva que frena la entrega de valor. DevOps 2.0 surge como respuesta a ese desorden, poniendo el foco no solo en automatizar, sino en estandarizar y productizar la propia plataforma sobre la que se ejecutan los flujos de desarrollo.
En este contexto aparece el platform engineering: equipos dedicados a construir y mantener un Internal Developer Platform (IDP) que actúa como capa común para CI/CD, infraestructura como código, observabilidad, seguridad y gestión de entornos. En lugar de que cada equipo invente su solución, la plataforma ofrece servicios reutilizables, APIs internas y templates, reduciendo el “impuesto de integración” que tantas organizaciones han sufrido en los últimos años.
Qué es el “Golden Path”
El “Golden Path” —también llamado paved road— es la manifestación práctica de esa plataforma: un flujo de trabajo preconfigurado, probado y recomendado para abordar las tareas más frecuentes dentro de la organización. No es un conjunto rígido de reglas, sino un camino que el equipo de plataforma ha diseñado para que, si un desarrollador lo sigue, tenga por defecto seguridad, observabilidad, despliegue automatizado y buenas prácticas incorporadas.
Un ejemplo típico de Golden Path para crear un nuevo microservicio incluye: estructura de repositorio estándar, pipeline de CI con tests, análisis estático y escaneos de seguridad, manifiestos de Kubernetes con límites de recursos y probes ya definidos, y logging/tracing conectado al stack de observabilidad. El desarrollador no tiene que decidir qué herramientas usar ni cómo configurarlas; simplemente arranca desde una plantilla y se centra en escribir código de negocio.
La clave está en que desviarse del Golden Path es posible, pero se convierte en una decisión explícita, con implicaciones conocidas y visibilidad para el equipo de plataforma. De este modo, la organización gana consistencia técnica sin matar la flexibilidad necesaria para casos especiales.
Cómo está redefiniendo el desarrollo de software
El impacto en el día a día del desarrollo es profundo. En primer lugar, se reduce drásticamente el tiempo de onboarding: los nuevos ingenieros pueden desplegar su primer servicio siguiendo el Golden Path en cuestión de días o incluso horas. En segundo lugar, se estabiliza la calidad de las entregas: todos los servicios comparten un mínimo común de pruebas, seguridad y observabilidad, lo que se traduce en menos incidencias y una mejor capacidad de diagnóstico.
Además, el Golden Path introduce una forma más madura de gestionar la complejidad de herramientas. En lugar de dejar que cada equipo escoja su propio stack de CI/CD, la plataforma ofrece integraciones por defecto con las herramientas corporativas y abstrae su uso mediante plantillas y componentes reutilizables. Esto libera a los desarrolladores de tener que ser expertos en cada pieza de la cadena y reduce la dependencia de unos pocos perfiles “héroes” de DevOps que acaban siendo cuellos de botella.
La llegada de la IA al ciclo de desarrollo refuerza aún más este modelo. Los IDP modernos incorporan recomendaciones contextuales, políticas como código y agentes de IA para tareas como revisión de infraestructura, optimización de costes o generación de tests, y lo hacen integrando estas capacidades directamente en los Golden Paths autorizados. Así se evitan integraciones ad hoc y se garantiza que el uso de IA cumple las políticas de seguridad y compliance de la organización.
DevOps 2.0 como producto, no como soporte
Una diferencia crucial de esta nueva etapa es que la plataforma interna se gestiona como un producto, con su propio roadmap, métricas de experiencia del desarrollador y roles específicos como Platform Product Manager o Developer Experience Engineer. El éxito no se mide solo en uptime, sino en indicadores como time-to-first-deploy, ciclo de entrega, carga cognitiva percibida y tiempo medio de resolución de incidencias.
Al tratar la plataforma como producto, las decisiones sobre el Golden Path dejan de ser puramente técnicas y se alinean con objetivos de negocio: reducir costes de infraestructura, acelerar lanzamientos, mejorar seguridad o facilitar la adopción de nuevas capacidades como IA generativa o agentic AI. Las mejoras se priorizan en función del impacto en los equipos consumidores y no solo de la elegancia arquitectónica.
Tres ejemplos concretos de Golden Path en acción
- Golden Path para microservicios cloud-native
Una empresa con decenas de equipos de producto define un Golden Path para servicios en Kubernetes: repositorio basado en plantilla estándar, CI con tests unitarios y escaneo SAST, despliegues declarativos mediante IaC y dashboards de observabilidad preconfigurados en Prometheus y Grafana. Al adoptar este camino, los equipos reducen en semanas la puesta en marcha de nuevos servicios y homogeneizan métricas de rendimiento, lo que facilita comparar y optimizar el conjunto de la plataforma. - Golden Path para aplicaciones de datos y ML
Una organización data-driven establece un Golden Path para pipelines de datos y modelos de machine learning: definición de datasets mediante catálogos internos, orquestación estándar, entornos de entrenamiento definidos con plantillas y registro obligatorio de modelos en un repositorio central. Esto evita que cada equipo monte su propio “stack de ML” y reduce el riesgo de arquitecturas de IA caóticas, facilitando el gobierno de datos y la trazabilidad de modelos en producción. - Golden Path para APIs externas y productos digitales
Una empresa que ofrece APIs públicas crea un Golden Path para nuevos endpoints: diseño siguiendo una guía de estilo, pruebas contractuales automatizadas, documentación generada desde código y políticas de rate limiting y seguridad integradas desde el primer momento. Los equipos que siguen este camino consiguen lanzar APIs más consistentes, reducir incidencias con clientes y consolidar una experiencia de desarrollador externa mucho más sólida.