¿Qué es platform engineering? Guía práctica para equipos
Resumen
¿Qué es platform engineering? Es la práctica de construir una plataforma interna que da a los desarrolladores autoservicio para entornos, pipelines, servicios y guardarraíles. En lugar de que cada equipo monte el mismo stack, un equipo pequeño entrega caminos pavimentados y trata a los desarrolladores como clientes. Aquí tienes qué construye, en qué se diferencia de DevOps y SRE, y cuándo empieza a compensar.
¿Qué es platform engineering en la práctica? Es la forma de construir y mantener una plataforma interna que da a los desarrolladores acceso de autoservicio a lo que necesitan para enviar software: entornos, pipelines, servicios, documentación y guardarraíles. Un equipo pequeño trata el camino entre «tengo una idea» y «corre en producción» como un producto, y los desarrolladores son sus clientes. El objetivo es esperar menos, abrir menos tickets y tener que aprender menos herramientas.
Seguro que ya conoces el problema. Un servicio nuevo necesita un repo, un pipeline, una base de datos, secretos, dashboards y una guardia, y cada una de esas cosas vive detrás de una página distinta de la wiki o de una persona distinta en Slack.
¿Por qué apareció la ingeniería de plataforma?
«Tú lo construyes, tú lo operas» funcionaba bien cuando un equipo tenía un solo servicio y un puñado de herramientas. Dejó de escalar cuando el stack creció hasta incluir Kubernetes, Terraform, tres sistemas de CI, un gestor de secretos, un service mesh y una pila de observabilidad. De pronto, cada desarrollador de producto debía ser también, a media jornada, ingeniero de infraestructura.
El coste no aparece como una línea en el presupuesto, sino como carga cognitiva. Un desarrollador que necesita 90 minutos para averiguar cuál es el chart de Helm «correcto» no ha ido lento por falta de habilidad. Ha ido lento por falta de valores por defecto.
La ingeniería de plataforma es la corrección. En lugar de pedir a cada equipo que monte el mismo stack desde cero, un equipo dedicado lo monta una vez, lo convierte en la opción fácil y lo mantiene sano. Los analistas ven la misma tendencia: Gartner prevé que el 80 % de las grandes organizaciones de ingeniería de software tendrá equipos de platform engineering para 2026, frente al 45 % de 2022.
¿Qué construye realmente un equipo de plataforma?
Dejemos un momento los diagramas de los proveedores. En la mayoría de empresas, un equipo de plataforma entrega cuatro cosas.
Una plataforma interna para desarrolladores (IDP). El conjunto de herramientas y flujos de autoservicio encima de tu nube y de tu CI. Puede ser un portal de Backstage, un producto de un proveedor o un repo bien cuidado con plantillas y una CLI.
Caminos dorados. Rutas opinadas y soportadas para tareas comunes, como «crear un servicio de API» o «añadir una cola».
Guardarraíles. Políticas, escaneos y límites de coste aplicados por defecto, de modo que la opción segura sea también la cómoda.
Documentación y descubrimiento. Un catálogo que responde a «¿quién es el dueño de este servicio, dónde está su runbook y de qué depende?».
Nada de esto exige una categoría de producto nueva. Muchas buenas plataformas empezaron como una plantilla de cookiecutter y un README que alguien mantenía al día.
¿Qué es un camino dorado y por qué los equipos lo ignoran?
La CNCF describe un camino dorado como una «composición con plantillas de código y capacidades bien integradas para el desarrollo rápido de proyectos», una definición que Google Cloud explica con un ejemplo en Spring Boot. Dicho en simple, es una plantilla que da a un servicio nuevo un repo, un pipeline, logging y configuración de despliegue desde el primer día.
El modo de fallo es igual de simple. Un camino que nadie pidió, construido sin hablar con los equipos que lo van a usar, se queda con una adopción de un solo dígito mientras el equipo de plataforma se pregunta por qué los desarrolladores siguen abriendo tickets. El camino tiene que ser más corto que el atajo, o la gente se irá por el atajo.
Dos reglas mantienen vivos los caminos dorados:
Pavimentado, no vallado. Los desarrolladores pueden salirse del camino, pero asumen el soporte de lo que construyan fuera de él.
Gestionado como un producto. Alguien lee el feedback, sigue la adopción y elimina los caminos que nadie usa.
¿La ingeniería de plataforma es solo DevOps con otro nombre?
En parte, y la respuesta honesta es más útil que la del marketing. DevOps es una cultura: propiedad compartida entre desarrollo y operaciones, y ciclos de retroalimentación cortos. La ingeniería de plataforma es una forma de hacer sostenible esa cultura a escala, convirtiendo el trabajo operativo repetido en un producto.
SRE es otra disciplina distinta. Los SRE definen objetivos de fiabilidad, los miden y deciden cuándo dejar de desplegar para protegerlos. El equipo de plataforma ofrece el camino pavimentado. El equipo SRE te dice cuánto riesgo puedes permitirte en él.
DevOps es una cultura y un conjunto de prácticas. Su resultado es la propiedad compartida y la automatización, y suele fracasar convirtiéndose en un cargo y una cola de tickets.
SRE es una disciplina de fiabilidad. Su resultado son los SLO, los presupuestos de error y un proceso de incidentes, y suele fracasar convirtiéndose en una guardia sin autoridad.
Ingeniería de plataforma es un equipo de producto interno. Su resultado es una plataforma de autoservicio y caminos dorados, y suele fracasar convirtiéndose en una plataforma que nadie usa.
Los modos de fallo son la parte que conviene leer dos veces. Un equipo de plataforma que recibe tickets y construye lo que le piden es un equipo de operaciones con otro nombre, y hereda todos los problemas de la cola de siempre.
¿Cuándo merece la pena el equipo de plataforma?
Sáltatelo si tienes menos de unos 30 ingenieros y uno o dos servicios. A ese tamaño, un buen repo de plantillas y un módulo compartido de Terraform hacen el trabajo, y un equipo de plataforma a tiempo completo es sobrecoste. Es normal que varias personas de un equipo de diez acaben haciendo de plataforma sin que nadie lo decida, y no pasa nada.
Empieza a rendir cuando se repiten las mismas señales:
Los servicios nuevos tardan semanas en llegar a producción, sobre todo esperando a otras personas.
Tres equipos han resuelto el mismo problema de despliegue de tres formas distintas.
Incorporar a un ingeniero nuevo significa un montón de conocimiento tribal y muchos «pregúntale a Priya, ella lo sabe».
Las revisiones de seguridad y cumplimiento se hacen al final, por equipo y a mano.
La versión mínima útil es lo que Team Topologies llama la plataforma viable más fina: lo justo para quitar el mayor dolor repetido, bien documentado, y nada más. Empieza por el flujo de trabajo que más horas cuesta entre equipos, normalmente «crear un servicio nuevo» o «obtener un entorno de preview».
La gestión de funcionalidades es un buen ejemplo de capacidad que sale más barata como servicio compartido que como diez servicios privados.
Un servicio de flags al que todos los equipos llaman, con el mismo registro de auditoría y las mismas reglas de limpieza, evita que cada equipo escriba su propio sistema de toggles a medio hacer. Lo compres o lo construyas, debe vivir en la plataforma y no en cada repo.
¿Qué tiene que ver la plataforma con leer código?
Más de lo que admiten los diagramas. Una plataforma solo es tan útil como el conocimiento que la rodea. Cuando un desarrollador pregunta «¿cómo se autentica el servicio A con el servicio B?», la respuesta está en el código, en la configuración y en un runbook que quizá tiene seis meses.
Aquí es donde los equipos de plataforma pierden tiempo sin darse cuenta. Son quienes reciben la pregunta de Slack que empieza por «¿dónde está configurado X?» y la responden de memoria, otra vez, por quinta vez esta semana. El efecto se nota cuando un repo supera las 80K líneas y el equipo de plataforma se convierte en un índice de búsqueda humano.
Algunas herramientas ayudan aquí, y resuelven mitades distintas del problema. Las herramientas de documentación como código mantienen la parte escrita cerca del código fuente.
Los asistentes que entienden el código responden preguntas sobre el propio código. El asistente de Sourcegraph está pensado para organizaciones grandes con muchos repos y se vende a empresas con presupuesto negociado, así que encaja mejor con un equipo de plataforma en un entorno grande que con un equipo de quince personas.
Para el trabajo diario dentro del editor, un asistente generalista cubre mucho terreno, con la salvedad de que solo conoce el contexto que le das.
El patrón que copiaríamos: juntar en el mismo sitio las plantillas de los caminos dorados, el catálogo de propietarios y un índice buscable del código, y dejar que los ingenieros nuevos hagan sus preguntas ahí antes de preguntar a una persona. Se mide en horas, también. Si después de hacerlo, tu equipo de plataforma responde menos de diez preguntas del tipo «¿dónde está configurado esto?» a la semana, funcionó.
¿Cómo empezar sin construir una catedral?
La mayoría de los esfuerzos de plataforma que fracasan empiezan por la herramienta. El orden mejor es personas, luego caminos y después herramientas.
Entrevista a diez desarrolladores. Pregunta dónde pierden tiempo entre un PR fusionado y una funcionalidad corriendo. Oirás las mismas tres respuestas.
Elige un camino y entrégalo en un mes. Una sola plantilla de «servicio nuevo» que funcione de principio a fin vale más que un portal con 40 casillas vacías.
Mide antes y después. Registra el tiempo hasta el primer despliegue de un servicio nuevo y el tiempo hasta el primer PR fusionado de un empleado nuevo. Esos dos números dicen más que cualquier encuesta de satisfacción.
Publica una hoja de ruta y un changelog. El trabajo de plataforma es invisible si no lo haces visible.
Elimina cosas. Retira caminos y herramientas que nadie usa. Una plataforma más pequeña en la que la gente confía vale más que una grande que todos esquivan.
Resiste la tentación de comprar primero un portal. Un portal encima de un conjunto de flujos desordenados te da un desorden más bonito, y un catálogo con 247 entradas, la mitad obsoletas, es peor que no tener catálogo.
¿Qué sale mal, y cómo detectarlo a tiempo?
Hay tres patrones de fallo que se repiten una y otra vez.
La plataforma mesa de ayuda. Las peticiones llegan por ticket, el equipo las resuelve a mano y lo llama autoservicio. Prueba: ¿puede un desarrollador terminar la tarea común sin hablar con nadie?
La plataforma por decreto. La dirección obliga a todos los equipos a usar la plataforma antes de que esté lista. Las cifras de adopción salen muy bien y el ánimo de la gente se hunde. Deja que el uso se gane durante los primeros seis meses.
La plataforma para todo. Cada petición se convierte en una funcionalidad, la superficie crece sin control y la calidad cae. Di que no, por escrito y con motivos.
Una señal temprana útil es la proporción entre preguntas en Slack y respuestas documentadas. Si la misma pregunta aparece tres veces en un mes y no hay doc, ni plantilla, ni automatización para ella, ese es tu siguiente elemento del backlog.
¿Qué haríamos realmente el lunes?
Elige lo que más tiempo se pierde entre equipos y hazlo aburrido. En la mayoría de empresas, eso es crear un servicio nuevo o conseguir un entorno de pruebas. Escribe el camino, ponlo donde la gente lo encuentre, cuenta las horas que ahorra y solo entonces decide si necesitas un equipo más grande.
La ingeniería de plataforma no es una cadena de herramientas que se instala. Es la decisión de tratar a los desarrolladores internos como clientes, y la prueba de que la tomaste es que la distancia entre el primer día de un empleado nuevo y su primer cambio fusionado sea cada vez más corta.