Qué es platform engineering y cuándo necesitas uno

que es platform engineering: la práctica de construir una infraestructura interna que permite a los desarrolladores trabajar sin depender de especialistas, sin esperar semanas a que alguien les configure un entorno. Es el trabajo de crear la carretera asfaltada interna para que nadie tenga que abrirse paso a través de la jungla solo, y tratarla como un producto con usuarios. Son las 22:10 y una recién incorporada lleva dos días intentando conseguir un entorno de prueba. Ha abierto tres tickets, ha pegado el mismo error de Terraform en Slack dos veces, y todavía no sabe cuál de los cuatro templates de CI es el correcto. Esa escena es la respuesta completa.

En la práctica, un equipo de platform construye una plataforma interna de desarrollador (IDP): herramientas de autoservicio que permiten a otros devs crear servicios, desplegar y ver qué está ejecutándose sin esperar a una persona. Aquí es lo que se rompe en la práctica cuando lo omites: cada equipo reinventa el despliegue, y el conocimiento vive en la cabeza de tres personas.

Qué es platform engineering, sin el ruido de las palabras de moda

La definición más clara que conozco viene de la comunidad platformengineering.org: diseñar y construir plataformas que den a los equipos capacidades de autoservicio para las partes recurrentes de su trabajo. Si quitamos el vocabulario, obtenemos tres componentes en movimiento.

Primero, una plataforma interna de desarrollador. Esto no es un producto único que compres. Es una capa delgada de templates, pipelines, APIs y documentación que se sienta encima de las herramientas que ya ejecutas (cuenta en la nube, Kubernetes, CI, secretos, monitoreo) y oculta los bordes afilados.

Segundo, un equipo de platform. Un pequeño grupo de ingenieros cuyos clientes son otros ingenieros. Su salida no son features para usuarios finales. Su salida es qué tan rápido pueden los demás lanzar código.

Tercero, una mentalidad de producto. La plataforma tiene usuarios, un backlog, números de adopción y un turno de guardia. Si nadie la usa, fracasó, sin importar cuán elegante sea la arquitectura.

Gartner predijo que para 2026, el 80% de las grandes organizaciones de ingeniería de software tendrían equipos de platform, frente al 45% en 2022. Tómalo como un marcador de tendencia, no como una promesa. El mismo rumor de la industria dice que una gran parte de esos equipos luchan por demostrar impacto, que es exactamente por qué el resto de este artículo pasa tiempo en qué sale mal.

Cómo es diferente de DevOps y SRE

Versión corta: DevOps es una cultura, SRE es una disciplina de confiabilidad, platform engineering es una forma de equipo que convierte ambas en producto.

DevOps dijo que los desarrolladores y las operaciones debían compartir la responsabilidad de ejecutar software. Buena idea. En una empresa de 15 personas funciona porque todos pueden verlo todo. En una empresa de 300 personas se convierte silenciosamente en "cada squad también debe convertirse en un experto en Kubernetes", que no es para lo que nadie se apuntó.

SRE se enfoca en objetivos de confiabilidad: presupuestos de error, respuesta ante incidentes, capacidad. Un equipo de platform también se preocupa por la confiabilidad, pero su métrica principal es diferente. Mide cuánto tiempo espera un dev entre "tengo una idea para un servicio" y "está ejecutándose en producción con logs y alertas".

Platform engineering es la respuesta a la carga cognitiva que DevOps dejó atrás. En lugar de pedirle a cada dev que aprenda toda la cadena de herramientas, le das un defecto soportado y mantienes el conocimiento experto dentro de la plataforma. Tres razones para hacerlo, una razón para no: solo compensa una vez que el número de equipos o servicios es lo suficientemente grande como para que la duplicación duela. Llegaremos a ese umbral a continuación.

Qué envía realmente un equipo de platform

Olvida los diagramas de arquitectura. Así es como se ve el backlog de un equipo de platform trabajando en un martes normal.

Un template de servicio. Un comando o un botón en un portal crean un repositorio con un pipeline funcional, un Dockerfile, health checks, una configuración de logging y un dashboard básico. El dev cambia la lógica de negocio, no la fontanería.

Una ruta de despliegue. Push a main, los tests corren, el artefacto se construye y se promociona a través de entornos con los mismos pasos cada vez. Sin snowflakes por equipo.

Entorno bajo demanda. Un entorno de vista previa por pull request, destruido automáticamente. Esta es la feature por la que los desarrolladores realmente te dan las gracias.

Secretos y acceso. Credenciales de corta vida, un lugar para solicitarlos, una pista de auditoría. Aburrido, y la cosa que te salva en una revisión de seguridad.

Observabilidad por defecto. Cada servicio creado desde el template envía métricas, logs y trazas sin que nadie tenga que conectarlos. Un stack como Grafana usualmente se sienta detrás de esta capa, y su opción gratuita y de código abierto se adaptan bien a un equipo pequeño.

Observa qué falta de esa lista: un portal construido a medida con un roadmap de tres meses. El portal es lo último que agregas, no lo primero.

Rutas doradas: la idea que hace que el resto funcione

Una ruta dorada es la forma soportada y opinada de hacer una tarea común. Es más rápida que hacerlo manualmente y más segura que improvisar, y críticamente es opcional. Los desarrolladores pueden dejar la ruta cuando tengan una razón real. Solo asumen la responsabilidad que conlleva.

Hay una distinción útil en la descripción de Octopus sobre rutas pavimentadas vs. doradas: una carretera pavimentada es la superficie amplia y bien mantenida, mientras que una ruta dorada es la recomendación específica para una tarea dada. En mi experiencia la diferencia importa menos que el principio subyacente. Ganas haciendo la forma correcta la forma fácil, no prohibiendo las otras formas.

Esto es lo que parece la ruta dorada más pequeña posible. Es un comando de scaffold único que un dev ejecuta una vez:

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Detrás de esa línea se sienta un repo, un pipeline, DNS, un stub de base de datos, alertas y un registro de propiedad. El comando es trivial. La parte difícil es los seis meses acordando qué significa "node-api" y manteniéndolo actual cuando Node, tu imagen base o tu proveedor de nube cambian.

Probado, no optimal, y aquí está por qué lo hacemos de todos modos: una ruta dorada mediocre que el 80% de los equipos usan le gana a una perfecta que el 10% adopta, porque la primera te da el apalancamiento para mejorar todo de una sola vez.

Cuándo vale la pena y cuándo es una distracción

Esta es la sección que la mayoría de posts se saltan. Platform engineering no es gratis, y para muchos equipos es el movimiento equivocado.

La descripción de platformengineering.org sugiere que las organizaciones típicamente comienzan a beneficiarse una vez que pasan aproximadamente 20 a 30 usuarios de platform. Leería eso como un piso aproximado, no una regla. Debajo de él, un README compartido, un buen template de CI y una persona que se importa hará más que un equipo formal.

Vale la pena cuando:

• Tienes más que un puñado de equipos, y cada uno ha construido su propio pipeline de despliegue.

• Los nuevos devs tardan semanas, no días, en lanzar su primer cambio.

• El mismo tipo de incidente se repite porque cada servicio configuró sus propias alertas.

• Seguridad o cumplimiento pide consistencia que no puedes entregar pidiendo por favor.

Omítelo cuando:

• Eres un equipo de cinco. Escribe un script, no una plataforma.

• Todavía no sabes cómo se ven tus servicios. Estandarizar demasiado pronto congela las decisiones incorrectas.

• La propuesta es "construir un portal" sin una lista de dolores que elimina.

Para builders solitarios y equipos de side projects pequeños, la conclusión honesta es más simple. No necesitas un equipo de platform, pero sí necesitas los hábitos: un script de despliegue repetible, un template para nuevos proyectos, un dashboard que chequeas. Eso es una plataforma de uno, y te ahorrará un fin de semana cada mes.

Las herramientas que la gente realmente combina

No hay un único "producto de platform engineering". Los equipos ensamblan un stack, y las piezas caen en unos pocos buckets.

Para el portal y el catálogo, muchos equipos usan Backstage o una alternativa alojada, que da una lista buscable de servicios, propietarios y documentación. Para provisioning, Terraform u OpenTofu más una herramienta GitOps como Argo CD o Flux. Para CI y entrega, lo que ya tienes, envuelto en templates compartidos.

Dos buckets merecen una mirada más cercana, porque deciden si la plataforma se siente confiable.

Observabilidad. Si los desarrolladores no pueden ver qué está haciendo su servicio, no confiarán en la plataforma que lo desplegó. Datadog te da una vista única pulida a través de infra, APM y logs, a un precio por host que crece rápidamente. El stack de código abierto de Grafana te cuesta tiempo de operaciones en lugar de honorarios de licencia. Elige basándote en si tu recurso escaso es dinero o atención.

Documentación y calidad. Una plataforma sin buena documentación es una cola de tickets disfrazada. Las herramientas de docs-as-code mantienen las guías junto al repo que describen, y las puertas de calidad de código en CI mantienen los templates honestos.

Ninguno de estos es requerido. Son ejemplos de la capa donde un equipo de platform pasa su tiempo: eligiendo un defecto, conectándolo en el template, y siendo dueño del camino de actualización.

Cómo empezar sin construir la cosa equivocada

La mayoría de los esfuerzos fallidos de platform comparten el mismo patrón. Comienzan demasiado grande, construyen durante meses antes de que un único equipo lo toque, e optimizan para la diapositiva de roadmap en lugar de la adopción. La corrección es sin glamour.

Elige una tarea dolorosa y frecuente. "Crear un nuevo servicio" y "conseguir un entorno de vista previa" son los ganadores habituales. Entrevista a tres desarrolladores y obsérvalos hacerlo. Cuenta los pasos y los minutos.

Construye la versión más delgada que elimine la mayoría del dolor. Un repo de template y un archivo de pipeline compartido cuentan. Dáselo a un equipo amistoso y siéntate junto a ellos mientras lo usan. Arregla lo que se rompe, luego ofrécelo a un segundo equipo.

Rastrea dos números: cuánto tiempo desde "nuevo servicio" hasta "ejecutándose en producción", y cuántos equipos usan la ruta voluntariamente. Si el segundo número es plano, la plataforma es un mandato, y los mandatos se pudren.

Personal como un equipo de producto. Los ingenieros de platform no son DevOps con un título nuevo. El material de platformengineering.org señala que los ingenieros de platform ganan alrededor del 27% más que los profesionales de DevOps, que te dice que el mercado ve la mezcla de producto e ingeniería como un trabajo distinto y más difícil.

Una razón más para hacerlo ahora: el nuevo giro es que el "usuario" de una plataforma ya no es solo un humano. Los agentes de codificación abren pull requests, ejecutan tests y piden entornos. Una plataforma con templates limpios, permisos claros y docs legibles por máquina es un lugar mucho más seguro para que un agente trabaje que un montón de repos de snowflake.

Credenciales de corta vida, entornos de vista previa y un pipeline consistente son lo que mantienen los errores de un agente contenidos en una rama desechable. Si tu plataforma no puede diferenciar un despliegue humano de uno automatizado, añade eso antes de agregar cualquier otra cosa.

Qué deberías construir a continuación

Si diriges un equipo de 30 devs y cada squad tiene su propio pipeline, un pequeño equipo de platform con una ruta dorada es probablemente tu contratación con mayor apalancamiento. Si eres un dev solo con tres side projects, copia el pipeline de tu mejor proyecto en un repo de template este fin de semana y listo.

De cualquier forma, la pregunta que vale la pena llevar a tu próxima sesión de planificación es concreta: cuál es la tarea individual que tus desarrolladores repiten más, y qué se necesitaría para hacerla un trabajo de un comando.