Todo sobre platform engineering: por qué se necesita, cómo se construye y qué aspecto tiene el éxito

• Como una disciplina organizacional que construye y opera productos internos teniendo a los ingenieros internos como usuarios, es un ámbito esencialmente distinto de un simple rebranding de DevOps o de la administración de clústeres de Kubernetes
• Según el informe DORA 2025, el 90% de las organizaciones ya adoptó al menos una plataforma interna, y la calidad de la plataforma está surgiendo como un indicador que predice directamente si las herramientas de IA generan valor
• A medida que la nube y el open source ofrecen infinitos primitivos, la razón central de su existencia es resolver el problema del "pantano de sobre-generalización (over-general swamp)", donde cada equipo construye pipelines por su cuenta
• Tratar la plataforma como un producto real, y contar con abstracciones de software, un registro de metadatos y SLO operativos para el desarrollador mediano, son condiciones estructurales para el éxito
• Una buena plataforma funciona con tanta naturalidad que el desarrollador se olvida de que existe; una mala plataforma hace que las herramientas de IA amplifiquen el caos, mientras que una buena amplifica el throughput

---

Por qué existe platform engineering

• Pantano de sobre-generalización (Over-General Swamp)

  • A medida que la nube y el OSS ofrecen infinitos primitivos como colas, object stores, bases de datos, runners de CI y service mesh, cada equipo de aplicaciones termina tomando decisiones distintas
  • Un año después, todo deriva en un pantano de glue code donde cada servicio tiene su propio pipeline de despliegue, lógica de reintentos, convenciones de monitoreo y bindings de IAM sutilmente incorrectos
  • Las dos causas de este pantano son la explosión de opciones y unas expectativas operativas más altas: disponibilidad 24/7, seguridad, compliance y control de costos
  • En proyectos reales de landing zones, hubo casos donde 20 equipos reinventaron por separado módulos de Terraform casi idénticos para VPC, IAM y alertas de presupuesto, cada uno con bugs distintos

• Las cuatro cosas que realmente hace platform engineering

  • Limita los primitivos que ven los desarrolladores para guiarlos a usar solo formas curadas
  • Absorbe el trabajo repetitivo de plomería en servicios compartidos para reducir el glue code por aplicación
  • Cuando cambian los primitivos de base, el equipo de plataforma lo resuelve una sola vez para centralizar el costo de migración
  • Permite que los desarrolladores operen directamente lo que construyen sin tener que volverse expertos en el kernel de Linux
  • DevOps era “que los desarrolladores se hagan cargo de operaciones”, mientras que platform engineering dice “vamos a ofrecer, como un producto real, buenas herramientas para esas operaciones”
  • Incluso en la página de capacidades de DORA 2025 se define como una disciplina sociotécnica, no como una categoría de herramientas

Cinco pilares (Pillars)

• Enfoque de producto curado (Curated Product Approach)

  • Decidir con intención qué soporta la plataforma y qué no
  • Cuando un equipo quiere Kafka en vez de Pub/Sub, no responder “aquí está el link a la documentación”, sino explicar el alcance de soporte, por qué, y cuál es la vía de salida si no encaja
  • Decir que no también es parte del trabajo

• Abstracciones basadas en software (Software-Based Abstractions)

  • La plataforma es software, no una wiki, y sus interfaces son API, CLI y SDK
  • El desarrollador debería poder aprovisionar servicios de nivel producción con solo escribir un pequeño archivo declarativo
  • Un caso representativo es el proyecto Score de la CNCF, que con una sola especificación de workload aprovisiona automáticamente bases de datos, topics, service accounts y despliegues
    • El desarrollador no necesita saber si por debajo es Cloud SQL, Pub/Sub o Cloud Run

• Personalización de OSS y registro de metadatos

  • No se usa Argo CD o Backstage vanilla tal cual, sino que se operan con plugins, políticas por defecto e integraciones adaptadas a la organización
  • Sin un registro de metadatos (catálogo de servicios), es imposible saber quién es dueño de qué, cómo son las dependencias y qué está corriendo realmente
  • Backstage es el framework OSS de facto estándar en esta capa, operado en producción por más de 270 organizaciones
    • La CNCF lanzó las certificaciones Certified Backstage Associate y Certified Cloud Native Platform Engineering Associate
    • Ya sea que uses Backstage, Port, Cortex u otra cosa, necesitas una fuente única de verdad (single source of truth) sobre “qué servicios existen, quién los posee y cuáles son sus dependencias”

• Servicio para una base amplia de usuarios

  • Las plataformas internas tienen unos pocos clientes muy ruidosos, pero su objetivo es dar buen soporte al trabajo mediano del desarrollador mediano
  • Si construyes solo para usuarios élite, el resto de los equipos termina rodeando la plataforma y nacen plataformas en la sombra

• Operar como foundation

  • Si la plataforma se cae, la empresa se cae, así que implica guardias 24/7, SLO reales, gestión real de cambios y carga de soporte
  • No cumple el rol de una “herramienta”, sino de un “piso (floor)”, y todo lo que se construye encima asume que ese piso va a resistir

Cuándo y cómo empezar

• No crear el equipo de plataforma demasiado pronto

  • Con una organización de 10 ingenieros, lo que hace falta no es un equipo de plataforma sino cooperación
    • Basta con que una persona maneje los scripts de despliegue, otra Terraform, y que acuerden convenciones
  • Si armas un equipo demasiado pronto con 1 o 2 personas, ellos se convierten en una cola de tickets y el resto de la organización se vuelve pasiva
  • Por lo general, después de 50 ingenieros, cuando ya hay múltiples destinos de despliegue y nadie sabe cuál es la respuesta correcta a “cómo desplegar un nuevo servicio”, ahí sí tiene sentido formar el equipo

• Transformar la organización de infraestructura existente

  • Al convertir un equipo de infraestructura/SRE en una organización de plataforma, la parte más difícil no es la tecnología sino la cultura
  • Quienes están a cargo de infraestructura están acostumbrados al rol de guardianes del “no se puede”, pero quienes están a cargo de plataforma deben convertirse en “las personas que ofrecen un sí fácil”
    • Hablar mucho con los clientes
    • Contratar y desarrollar no solo operadores, sino también ingenieros de software que disfruten construir herramientas
    • Actualizar el sistema de incentivos para que se reconozca más “hicimos que 200 equipos fueran 5% más rápidos” que “desplegamos un clúster nuevo”
  • El modo de fracaso más común es echarle un PM encima y darlo por resuelto; eso produce no una plataforma sino teatro (theater)

Construcción del equipo de plataforma

• Cuatro roles

  • Software Engineer: construye la superficie de producto de la plataforma, como API, SDK y portales
  • Systems Engineer: domina los primitivos de base, como Kubernetes, Linux, networking y cloud control planes
  • Reliability Engineer: se enfoca en calidad operativa, guardias, SLO y observabilidad
  • Systems Specialist: especialista profundo en dominios como bases de datos, seguridad o networking
  • Si hay demasiado foco en software, un portal hermoso se cae bajo carga real; si hay demasiado foco en sistemas, terminas con clústeres sólidos que nadie puede usar sin abrir un ticket

• Contratación

  • Hay que contratar priorizando por encima de todo la empatía con el cliente (customer empathy)
  • Un ingeniero que, después de hablar con un desarrollador de aplicaciones frustrado, no puede salir entendiendo claramente el problema, no es adecuado
  • La excelencia técnica sin empatía produce una plataforma correcta pero que nadie usa
  • Para roles de software se puede usar la misma matriz de niveles, pero para especialistas de sistemas conviene permitir títulos flexibles, porque su valor de mercado y sus skills no se mapean limpiamente a la carrera de software engineer

• Managers y otros roles

  • Tres rasgos comunes de un gran manager de platform engineering: experiencia operando plataformas reales, experiencia desplegando proyectos de largo plazo que abarcan varios trimestres y obsesión por el detalle
    • Las plataformas recompensan el detalle, y ese 1% de casos que parece raro y se salta termina representando el 80% del tiempo de soporte
  • PM, technical writer, developer advocate y support engineer son todos importantes, pero hay que contratarlos solo después de que el equipo de ingeniería haya madurado lo suficiente
  • Un PM metido demasiado pronto en un equipo de plataforma de 4 personas no pasa de ser una silla con forma de roadmap

La plataforma como producto

• Los clientes internos son más difíciles

  • Los clientes internos son usuarios cautivos a quienes les cuesta irse, con opiniones fuertes y una débil sensibilidad de producto
  • Dicen lo que quieren (want), pero muchas veces eso no coincide con lo que realmente necesitan (need)
  • Exigen que la plataforma haga su trabajo por ellos, en vez de pedir herramientas que les permitan hacer mejor su trabajo
  • El backlog real consiste en sentarte a su lado y observar cuántas veces cambian de contexto para desplegar un solo cambio

• Discovery, roadmap y modos de falla

  • El discovery de plataforma se hace con pilotos, no con pruebas A/B, junto a equipos afines y midiendo la reducción del lead time después de desplegar de verdad
  • Los cuatro horizontes temporales del roadmap
    • Vision (multianual): la dirección de la plataforma
    • Strategy (anual): las apuestas de este año
    • Goals and Metrics (trimestral a anual): la definición de éxito
    • Milestones (trimestral): lo que realmente se va a desplegar
  • Modos de falla que con frecuencia hunden a los equipos
    • Subestimar el costo de migración (siempre es 2 a 3 veces más de lo esperado)
    • Sobreestimar el presupuesto de cambio de los usuarios para nuevas funciones
    • Enfocarse en agregar funciones cuando el problema real es la estabilidad
    • Demasiados PM para el tamaño del equipo de ingeniería (si hay 2 PM para 5 ingenieros, hay un problema)

Operación de plataforma

• El on-call no es opcional

  • Como se opera como una base fundamental, la cobertura 24/7 no es negociable
  • Aquí también aplica el principio de "you build it, you run it", y no como castigo sino como bucle de retroalimentación
  • Si un solo ingeniero recibe páginas varias veces por semana, hay que arreglar el sistema, no el horario
  • Un ingeniero de plataforma quemado termina desplegando una mala plataforma

• Soporte: la mitad oculta del trabajo

  • Casi no se habla de esto en conferencias, pero es la mitad central de la ingeniería de plataforma
  • Framework de cuatro etapas
    • Etapa 1: formalizar los niveles de soporte (P0 vs P3, tiempos de respuesta, etc.)
    • Etapa 2: separar el soporte no crítico del on-call para que preguntas como "cómo agregar un CronJob" no despierten a alguien
    • Etapa 3: cuando el volumen lo justifique, contratar a un especialista de soporte dedicado
    • Etapa 4: construir una organización de soporte de ingeniería acorde a la escala
  • Si te saltas la etapa 1, los ingenieros pasan la mitad del tiempo respondiendo DMs de Slack y la otra mitad quejándose

• Retroalimentación operativa

  • SLO y SLA son obligatorios; los error budgets son útiles, pero opcionales
  • El monitoreo sintético detecta modos de falla antes de que los usuarios envíen un ticket
  • Las revisiones operativas no consisten en echar un vistazo a dashboards en verde, sino en forzar la revisión de datos reales
  • En los datos de DORA 2025, la capacidad de plataforma con mayor correlación con la experiencia de usuario fue la de dar retroalimentación clara sobre el resultado del trabajo: si algo falla, el usuario debe saber exactamente qué falló y qué hacer

Planeación y entrega

• Los proyectos de largo plazo necesitan un documento de propuesta

  • Los proyectos de plataforma como migraciones, rearquitecturas o un nuevo control plane toman trimestres completos
  • Elementos esenciales de una buena propuesta: el problema que se quiere resolver, quiénes se benefician, el alcance, lo que queda explícitamente fuera de alcance y la definición de éxito
  • Antes de escribir código, primero se escribe el documento, se revisa y luego se convierte en un plan de ejecución con hitos concretos
  • El modo de falla del "long slog" —proyectos que se arrastran por años y de los que nadie recuerda por qué existen— es casi siempre el resultado de haberse saltado este paso

• Planeación bottom-up del roadmap

  • Los cuatro tipos de trabajo en un roadmap de plataforma: KTLO (keep-the-lights-on), mandatos de liderazgo, mejoras del sistema decididas por el propio equipo y solicitudes directas de clientes
  • No se puede priorizar solo con base en la demanda del cliente; KTLO va primero y los mandatos van segundo, y el resto requiere conversaciones honestas con los stakeholders

• Biweekly Wins and Challenges

  • Cada dos semanas, redactar un documento breve: lo que se desplegó (logros), lo que está bloqueado (retos), corto, público y sin exageraciones
  • Produce tres efectos al mismo tiempo: el equipo expresa con claridad el progreso, los stakeholders entienden la situación real y los retos se visibilizan temprano para provocar apoyo del liderazgo
  • Un documento con solo logros es un documento en el que nadie confía, así que no omitas los retos

Rearquitectura y migración

• Rearquitectura en vez de v2

  • Cuando una plataforma envejece, el impulso de decir "hagamos una v2" es casi siempre la respuesta equivocada
  • Razones por las que fallan los proyectos de v2: se congela la inversión en v1, toman más tiempo de lo esperado y el costo de migrar a v2 termina siendo mayor que el costo de rearquitectura que se intentó evitar
  • Rearquitectura dentro de la plataforma existente, manteniendo compatibilidad siempre que sea posible, y usando entornos inferiores, rollouts lentos y migraciones por tramos
  • Cuatro etapas de planeación
    • Pensar en grande sobre la arquitectura objetivo final
    • Incorporar el costo de migración (siempre 2 a 3 veces más)
    • Identificar logros clave a 12 meses que justifiquen la inversión continua
    • Obtener el acuerdo del liderazgo y estar listo para esperar

• La seguridad es arquitectónica

  • Es imposible agregar seguridad después; la arquitectura debe imponer mínimo privilegio, aislamiento y trazabilidad desde el momento del diseño
  • Si la plataforma requiere que todos los equipos recuerden el binding correcto de IAM, entonces el bug no está en los equipos sino en la plataforma

• Migración: un problema difícil y subestimado

  • Los antipatrones más comunes
    • Darle a todos los equipos un portapapeles y una fecha límite y pedirles que migren por su cuenta
    • Dar mandatos sin un on-ramp ni un off-ramp claros
    • Subestimar la cola larga de casos de uso particulares
  • Formas sencillas de hacer ingeniería de migración
    • Rastrear metadatos de uso para identificar exactamente quiénes siguen usando la versión anterior
    • Si 200 equipos tienen que migrar, que el equipo de plataforma escriba los scripts, no los equipos de aplicación
    • Diseñar una arquitectura de migración transparente en la que el nuevo sistema use la API antigua
    • Documentar con claridad el on-ramp para que los equipos nuevos puedan hacer self-service
  • Los mandatos (mandate) solo funcionan una o dos veces; después de eso, se vuelven ruido
  • En la mayoría de los casos, lo mejor es hacer que la ruta nueva sea lo bastante buena para que la ruta antigua se marchite sola

• Retiro de servicios (Sunsetting)

  • No hay que tener miedo de eliminar productos
  • Un solo sistema de despliegue sólido es superior a siete sistemas de despliegue medio soportados, y retirar servicios es una señal de un equipo maduro

Relación con stakeholders

• Power-Interest Grid

  • Mapear a los stakeholders en dos ejes: poder (power) e interés (interest)
    • Alto poder y alto interés: actualizaciones regulares y consulta
    • Bajo poder y bajo interés: con una página de estado basta
  • No desperdicien tiempo del equipo compartiendo información sobre upgrades de Kubernetes con un VP de bajo interés

• Comunicación sin sobrecompartir

  • Hay que ser transparente sin excederse: los líderes senior no necesitan enterarse de un debate sobre tres estrategias de reintento de gRPC, sino de si se están cumpliendo los hitos y cuáles son los riesgos
  • Usar con cuidado las reuniones 1:1 y llevar seguimiento visible de expectativas y compromisos

• Cómo decir que no sin dañar la relación

  • Dejar claro el impacto de negocio, por ejemplo: "si agregamos esta función, la migración se retrasa un trimestre y eso le cuesta $X a la empresa"
  • Puede ser mejor "decir que sí con concesiones", "decir que no pero mostrar un camino" o, a veces, permitir una shadow platform en lugar de pagar el costo de pelear
  • En temporada de presupuesto, presentar las necesidades agrupadas por equipo y capacidad, no por persona, y tener una postura firme sobre qué se va a recortar y qué se va a mantener; de lo contrario, finanzas decidirá por ustedes y decidirá mal

Cómo se ve el éxito

• Plataforma alineada (Aligned)

  • Se necesita alineación de propósito (por qué existe), alineación estratégica (que las apuestas sean consistentes entre equipos) y alineación de planificación (sin choques entre hitos)
  • Cuando todos los equipos de runtime quieren Kubernetes y el equipo de observabilidad intenta soportar todos los frameworks, aparece una desalineación
    • Se manifiesta como guías contradictorias para clientes, trabajo duplicado y desarrolladores enfurecidos atrapados en medio
    • No se resuelve con consenso, sino con liderazgo con principios

• Plataforma de confianza (Trusted)

  • La confianza se construye lentamente y puede perderse con una sola mala migración
  • La confianza se forma en la manera de operar (comunicación durante incidentes, cumplimiento de compromisos), la manera de invertir (desplegar de verdad las grandes apuestas vendidas) y las prioridades de entrega
  • Caso de una "plataforma sobreacoplada (overcoupled platform)": poner demasiada lógica personalizada en la plataforma hace que cada cambio tome meses — la solución no es más ingeniería, sino cuestionar los supuestos sobre el alcance
    • A veces, el problema de confianza no es que se esté haciendo demasiado poco, sino demasiado

• Plataforma que gestiona la complejidad

  • La complejidad del software es inevitable, pero la complejidad accidental (accidental complexity) no lo es
  • Hay que distinguir entre la complejidad irreducible del problema, la mala coordinación humana, las plataformas sombra que resuelven dos veces el mismo problema y la complejidad accidental creada por el crecimiento infinito
  • Tres palancas prácticas
    • Controlar el crecimiento: una plataforma que soporta todo no soporta nada bien; hay que dejar explícito el alcance
    • Usar el product discovery no solo para decidir qué agregar, sino también qué dejar de hacer
    • Gestionar las plataformas sombra: si los equipos crean soluciones paralelas, es señal de que a la plataforma realmente le falta algo o de que alguien está expandiendo su territorio — en ambos casos hay que actuar

• Plataforma querida (Loved)

  • Hay tres formas
    • Amor de "simplemente funciona": la mayoría de los usuarios ni nota la plataforma, los despliegues salen y CI pasa — que sea aburrido es el mejor elogio
    • Amor tipo "se siente como un hack": pequeñas alegrías como un comando de CLI que hace lo obviamente correcto sin necesidad de explicación
    • Amor "evidente": puntajes de encuestas, retención, adopción orgánica y recomendación de la plataforma a otros equipos
  • Cuando una plataforma es querida, la gente pelea por ella cuando pides presupuesto; si solo la toleran, un solo mal incidente la pone en riesgo de ser reemplazada

Prioridades prácticas

• Orden aproximado al empezar desde cero o reconstruir
  • Prioridad 1: decidir el alcance de soporte, documentarlo y defenderlo
  • Prioridad 2: invertir en abstracciones de software, no en un wiki (software con APIs reales como Score, Crossplane o un SDK propio)
  • Prioridad 3: construir un registro de metadatos (con Backstage, por ejemplo, para saber qué corre dónde y quién es responsable)
  • Prioridad 4: construir para el equipo promedio, no para el más ruidoso
  • Prioridad 5: tratar las operaciones como una capacidad de primera clase, incluyendo SLO, guardias y niveles de soporte
  • Prioridad 6: contratar por empatía tanto como por capacidad de sistemas
  • Prioridad 7: comunicación implacable: avances y retos quincenales, roadmap transparente y gestión honesta de stakeholders
  • Prioridad 8: dar de baja, consolidar y rechazar lo que no hace falta
• En línea con los datos de DORA, la calidad de la plataforma es un multiplicador de todo, incluida la adopción de AI — una mala plataforma hace que las herramientas de AI amplifiquen el caos; una buena plataforma amplifica el throughput
• Hay que construir el piso antes de construir el cohete

[kalista22]

Creo que la comunicación interna es más importante que cualquier otra cosa.