A los equipos de plataforma les encanta construir plataformas. Esa es la trampa. La forma más común de hacer fracasar una iniciativa de plataforma es encerrarse durante dieciocho meses, diseñar «todo a la vez» y presentar un monumento que nadie usa: llegó tarde y resuelve los problemas de ayer. La alternativa se llama thinnest viable platform (TVP) y exige un cambio de mentalidad: de «proyecto de infraestructura» a «producto».
Un golden path no es un scaffolder
Primero, los términos. Un golden path (la paved road de Netflix, la paved path de Thoughtworks) es la forma recomendada y respaldada por el equipo de plataforma de resolver una tarea rutinaria: crear un servicio, conectar una base de datos, configurar el monitoreo. La palabra clave es respaldada. Las desviaciones están permitidas, pero el equipo que se desvía asume el coste de soporte por su cuenta.
Aquí todos tropiezan con el alcance. Un golden path no es «el scaffolder creó un repositorio». Es una ruta de extremo a extremo: código → CI → registry → despliegue → monitoreo → on-call. Si tu «camino dorado» termina en un Dockerfile generado, construiste una plantilla, no un camino. Un camino real lleva a un desarrollador hasta un servicio en producción con HPA, PDB, NetworkPolicy, paneles, alertas de SLO multi-burn-rate y un runbook ya completado — sin una sola decisión que se pueda tomar mal.
Un golden path maduro tiene cuatro propiedades: es opcional (la plataforma hace que el camino correcto sea el más fácil, no el único — la coerción mata la innovación), de extremo a extremo, versionado (go-microservice-v2, -v3; las versiones viejas se deprecian, no se borran) y propiedad de un equipo concreto dentro de la organización de plataforma.
TVP: empezar con un camino para un equipo
La tentación es cubrir todos los lenguajes, todos los escenarios, todas las nubes antes del primer usuario. TVP invierte el orden: elegir un golden path para un equipo, lanzarlo, documentar el dolor, expandirse a partir de él. La métrica de éxito no es «cuántas funciones tiene la plataforma», sino una pregunta simple: ¿el equipo eligió este camino, o lo usa porque lo obligaron? Si lo eligió libremente, el camino funciona. Si no, construiste burocracia interna con un portal bonito.
De ello se deduce que la tasa de adopción importa más que cualquier métrica técnica. La tasa de deriva (cuántos servicios abandonaron el camino tras el lanzamiento) y el time-to-prod son diagnóstico; la elección voluntaria es el diagnóstico.
Estandarizar primero, automatizar después
TVP tiene un seguro incorporado que es fácil de ignorar con prisas: automatizar un proceso roto solo hace que el fallo sea más rápido y consistente. El caso clásico es un script bash de cinco mil líneas para el aprovisionamiento de AWS, reemplazado por Crossplane. Funcionó no «por la automatización», sino porque primero se formalizó el end-state declarativo correcto y solo después se automatizó la transición hacia él.
El síntoma de la violación se reconoce al instante: el golden path describe una secuencia ad-hoc («primero aplica esto, luego edita el ConfigMap, luego reinicia…») en lugar de un end-state declarativo. La cura: fijar primero el end-state (una Composition de Crossplane, un ApplicationSet, un chart de Helm con defaults inteligentes) y solo entonces escribir el pegamento de automatización.
El stack estrecho y aburrido como polo opuesto
Hay una segunda forma de construir una paved road, opuesta al «bufé de autoservicio»: un stack por defecto estrecho, aburrido y opinionado. Los equipos internos de Amazon viven según un árbol de decisión: Lambda por defecto → si chocas con los límites, ECS sobre Fargate → EC2 solo para legacy; el estado es DynamoDB, el pegamento es S3, el IaC es CDK. No «elige cualquier herramienta de un catálogo exhaustivo», sino «aquí tienes dos opciones, ambas las sabemos arreglar a las tres de la madrugada».
La lógica es la misma que la del golden path, llevada al límite: la proliferación (sprawl) es el verdadero enemigo de los sistemas que sobreviven a los equipos que los construyeron. Unos pocos patrones estándar vencen a una multitud de elecciones individualmente justificables. Las restricciones aquí son guardarraíles, no una jaula: los límites de Lambda obligan a pensar en chunking e idempotencia desde temprano. Una anécdota reveladora de la práctica: se levantó una base de datos Aurora para un único investigador; años después el investigador se había ido, la base de datos seguía viva. Eso es deuda operativa que sobrevive a las personas — exactamente lo que un stack estrecho previene.
Qué llevarse
Un golden path es un producto, no una utilidad: tiene un dueño, versiones, usuarios a los que no puedes obligar y una métrica de elección voluntaria. Constrúyelo al estilo TVP — estrecho, para un equipo, expandiéndose desde el dolor — estandariza el proceso antes de automatizarlo y recuerda que a veces el mejor golden path no es el más flexible sino el más aburrido. Una plataforma que la gente usa a regañadientes cuesta más que ninguna plataforma: pagas tanto por la infraestructura como por el rodeo que los equipos construirán de todos modos.