Platform engineering es la disciplina de construir y operar una plataforma interna como un producto, para que los equipos de desarrollo puedan desplegar y operar su software sin tener que dominar toda la infraestructura de abajo. La CNCF la define como «una colección integrada de capacidades definidas y presentadas según las necesidades de los usuarios de la plataforma», y esa última parte es lo que la separa de un catálogo de herramientas. Una Internal Developer Platform o IDP es esa plataforma puesta al servicio de quien desarrolla: entornos, despliegue, telemetría, secretos y datos disponibles con autoservicio. El objetivo declarado no es estandarizar por gusto, sino reducir la carga cognitiva de los equipos de producto.
Ver índice de contenidos
El problema que la origina
Durante años la recomendación fue que cada equipo se hiciera cargo de su software de punta a punta, incluida la operación. Resolvió un problema real —tirar código por encima del muro y que otro lo sufriera— pero trajo una factura que al principio no se vio.
Esa factura es la carga cognitiva. Llevar hoy un servicio a producción exige decidir sobre contenedores, orquestación, redes, certificados, secretos, pipelines, políticas de seguridad, métricas, trazas, costos y respaldos. Cada uno de esos temas tiene profundidad propia. Multiplicado por la cantidad de equipos, el resultado previsible es que todos resuelvan lo mismo de forma distinta, ninguna del todo bien, y que el tiempo del producto se vaya en infraestructura.
Platform engineering es la respuesta a ese desborde. El documento de la CNCF lo plantea como continuación de la cooperación que trajo DevOps, donde las plataformas «seleccionan y presentan capacidades fundamentales, marcos de trabajo y experiencias para facilitar y acelerar el trabajo de los clientes internos». La palabra que importa es clientes: hay alguien que usa esto y puede estar conforme o no.
Los beneficios que la CNCF le atribuye
Reducir la carga cognitiva de los equipos de producto, mejorar la fiabilidad y la resiliencia, acelerar el desarrollo por medio de la reutilización, reducir el riesgo de seguridad y cumplimiento, y permitir un uso de la nube eficiente en costos. Notá que ninguno de los cinco es «tener una plataforma»: todos son resultados medibles fuera del equipo que la construye.
Qué es una plataforma
La definición del documento de plataformas de la CNCF es corta y cada palabra descarta un malentendido habitual:
«Una colección integrada de capacidades definidas y presentadas según las necesidades de los usuarios de la plataforma.»
Integrada descarta el catálogo: cinco herramientas excelentes que no se hablan entre sí son cinco herramientas. Definidas y presentadas descarta la instalación cruda: que el clúster exista no significa que haya una capacidad consumible. Y según las necesidades de los usuarios descarta el proyecto de infraestructura hecho de espaldas a quien lo va a usar, que es el modo más común de fracasar.
Una Internal Developer Platform —IDP, plataforma interna de desarrollo— es el caso concreto de esa idea cuando los usuarios son los equipos que construyen y operan software. El nombre está tan cargado de marketing que conviene volver a una prueba práctica: ¿puede un equipo obtener lo que necesita sin abrir un ticket y sin aprender la infraestructura completa? Si la respuesta es sí, hay plataforma; si es no, hay herramientas y buena voluntad.
Los siete atributos
El mismo documento enumera los atributos que caracterizan a una plataforma. Leídos sueltos suenan a obviedades; en la práctica son decisiones que se toman o no se toman:
- Plataforma como productoTiene hoja de ruta, versiones, notas de cambio y alguien responsable. No es un proyecto que termina.
- Foco en la experiencia de usoSe mide cuánto tarda alguien en lograr su objetivo, no cuántas funciones hay disponibles.
- Documentación y puesta en marchaSi hace falta preguntarle a una persona para empezar, el autoservicio no existe todavía.
- AutoservicioEl equipo obtiene lo que pide sin intervención humana intermedia. Este es el atributo que más cuesta.
- Carga cognitiva reducidaEl propósito de todo lo demás. Si la plataforma agrega conceptos nuevos sin quitar ninguno, falló.
- Oferta opcional y componibleSe puede usar una parte sin adoptar el conjunto. Lo obligatorio genera resistencia y rodeos.
- Segura por defectoLo correcto es el camino de menor esfuerzo: permisos mínimos, secretos gestionados, dependencias verificadas.
El cuarto y el sexto están en tensión, y ahí se juega buena parte del resultado: el autoservicio empuja a estandarizar, lo componible empuja a dejar puertas abiertas. La salida no es elegir uno, sino hacer que el camino estándar sea tan cómodo que salirse de él sea una decisión deliberada y no un escape.
Qué capacidades ofrece
El documento de la CNCF lista las capacidades que una plataforma suele proveer. Sirve como inventario para preguntarse, capacidad por capacidad, cómo se pide hoy en tu organización:
| Capacidad | Resuelta significa que… |
|---|---|
| Automatización de compilación y pruebas | Un repositorio nuevo tiene pipeline funcionando sin que nadie lo escriba |
| Entrega y verificación automatizadas | Desplegar es una operación normal, reversible y auditada |
| Entornos de desarrollo | Se pide un entorno y llega, con datos de prueba y sin pisar a otro equipo |
| Observabilidad de aplicaciones | La telemetría aparece sola: no hay que instrumentar desde cero cada servicio |
| Servicios de infraestructura | Cómputo, red y almacenamiento se declaran, no se tramitan |
| Servicios de datos | Una base de datos se solicita con respaldo y credenciales rotables incluidos |
| Mensajería y eventos | Existe una forma recomendada de comunicar servicios entre sí |
| Gestión de identidad y secretos | Ningún secreto vive en un repositorio ni en un mensaje de chat |
| Servicios de seguridad | El análisis de dependencias y la firma de artefactos son parte del camino, no un extra |
| Almacenamiento de artefactos | Hay un lugar único y confiable de donde sale lo que se despliega |
Nadie tiene las diez resueltas al principio, ni hace falta. El valor de la lista es de diagnóstico: donde la respuesta sea «se pide por ticket y lo hace una persona», ahí está el trabajo.
Golden paths
La CNCF menciona entre las capacidades las «plantillas de golden path y documentación». Un golden path —camino dorado, o pavimentado— es la forma recomendada y ya resuelta de hacer algo habitual. No es una regla: es una comodidad tan grande que se elige sola. Un golden path para «crear un servicio nuevo» entrega de una vez la estructura del repositorio, el pipeline, la telemetría, los permisos mínimos y el manifiesto de despliegue: lo que sin plataforma son dos semanas de decisiones repetidas pasa a ser un comando.
# La forma de un golden path, sea cual sea la herramienta que lo implemente
plataforma servicio nuevo \
--nombre=facturacion \
--plantilla=api-http \
--equipo=pagos
# Lo que debería quedar hecho sin que nadie lo pida:
# repositorio con estructura y dueños definidos
# pipeline de compilación, pruebas y análisis de dependencias
# telemetría instrumentada y tablero base
# secretos gestionados, sin credenciales en el código
# entorno de pruebas propio y despliegue reversibleDos advertencias separan un golden path de una jaula. Tiene que haber salida: un equipo con un requisito legítimamente distinto debe poder apartarse, aunque le cueste más trabajo. Y la plantilla envejece: una que genera proyectos con la configuración del año pasado es peor que no tener plantilla, porque propaga lo viejo con sello oficial.
Las interfaces
Acá aparece el malentendido más frecuente. El documento de la CNCF nombra los portales web para aprovisionar y observar capacidades, las APIs y las interfaces de línea de comandos para automatizar, y las plantillas documentadas. Son cuatro maneras de consumir lo mismo, y ninguna es la plataforma:
| Interfaz | Para qué sirve | Su límite |
|---|---|---|
| Portal web | Descubrir qué existe, ver el estado, hacer lo ocasional | No sirve para automatizar ni para repetir |
| API | Que otros sistemas —y los pipelines— pidan capacidades | Requiere pensar la plataforma como producto versionado |
| Línea de comandos | El uso diario de quien desarrolla, sin salir de su terminal | Hay que mantenerla y distribuirla como cualquier herramienta |
| Plantillas y repositorios | El golden path, y la configuración declarada en Git | Envejecen sin aviso si nadie las revisa |
El orden importa. Empezar por el portal es tentador porque se ve y se demuestra en una reunión, pero un portal sobre capacidades que no existen es una vitrina con enlaces muertos. Conviene el orden inverso: primero una capacidad real con autoservicio —una sola, la que más duela—, después la interfaz mínima para pedirla, y el portal cuando haya varias cosas que valga la pena mostrar juntas.
El modelo de madurez
La CNCF publicó además un modelo de madurez de platform engineering más útil que la mayoría, por una razón concreta: separa cinco aspectos y aclara que no hace falta estar en el mismo nivel en todos. Los cuatro niveles van de provisional a operativo, escalable y en optimización, y los aspectos son:
- Inversión: «¿Cómo se asignan personas y fondos a las capacidades de plataforma?»
- Adopción: «¿Por qué y cómo descubren y usan los usuarios las plataformas internas y sus capacidades?»
- Interfaces: «¿Cómo interactúan los usuarios con las capacidades de la plataforma y cómo las consumen?»
- Operación: «¿Cómo se planifican, priorizan, desarrollan y mantienen las plataformas y sus capacidades?»
- Medición: «¿Cuál es el proceso para recoger e incorporar opiniones y aprendizajes?»
El modelo advierte además que más madurez exige más inversión y solo tiene sentido cuando el contexto lo justifica: una organización de tres equipos que apunta al nivel de optimización está construyendo la plataforma de una empresa que no es. De los cinco aspectos, el que más se olvida es medición, y es justo el que evita el escenario donde el equipo de plataforma entrega mucho y nadie usa nada.
Antipatrones
Los modos conocidos de que el proyecto falle, como lista de comprobación incómoda:
- Operaciones con nombre nuevo. Se renombra el equipo de infraestructura y se mantiene el flujo por tickets. Si sigue habiendo una persona en el medio de cada pedido, no cambió nada.
- La plataforma como portero. Si el único camino a producción pasa por la aprobación del equipo de plataforma, se reconstruyó el muro que DevOps vino a derribar, con mejor herramienta.
- Construir y esperar que vengan. Dieciocho meses sin un equipo piloto real terminan en una plataforma correcta que resuelve problemas que nadie tenía.
- Adopción obligatoria por decreto. Fuerza el número y destruye la señal: ya no se sabe si sirve. Y aparecen los rodeos, peores que la diversidad original porque son clandestinos.
- Abstraer todo. Ocultar la infraestructura está bien hasta que algo falla y nadie puede entender por qué. Una buena abstracción tiene ventanas: registros accesibles, estado visible, errores que apuntan al problema real.
- No versionar los cambios. Una plataforma que cambia de comportamiento de golpe y rompe pipelines ajenos pierde la confianza que tardó un año en ganar.
Cómo empezar sin equipo dedicado
La mayoría de las organizaciones no tiene un equipo de plataforma ni necesita crearlo mañana. Lo que sí puede hacer es empezar por donde duele:
- Encontrar la duplicación¿Qué escribió cada equipo por su cuenta? Pipelines, manejo de secretos, tableros. Ahí está el candidato.
- Elegir una sola capacidadLa que más tiempo consume o más riesgo genera. Una, no cinco.
- Resolverla con autoservicio realQue se pida sin intervención humana. Si necesita aprobación manual, no cuenta todavía.
- Conseguir un equipo pilotoQue la use de verdad y se queje de verdad. Sin piloto no hay señal.
- Convertirla en plantillaRecién cuando funciona para alguien, se vuelve el camino recomendado para el resto.
- Medir adopción voluntariaCuántos la eligen sin que se les pida. Ese número es el único que importa al principio.
Preguntas frecuentes
¿Qué es platform engineering en una frase?
Es la disciplina de construir y operar una plataforma interna como un producto, para que los equipos de desarrollo puedan desplegar y operar su software sin dominar toda la infraestructura de abajo. La CNCF define plataforma como «una colección integrada de capacidades definidas y presentadas según las necesidades de los usuarios de la plataforma», y esa última parte la distingue de un conjunto de herramientas: las capacidades se eligen a partir de lo que los equipos internos necesitan, no de lo que le resulta cómodo al equipo de infraestructura.
¿Una plataforma interna es lo mismo que un portal para desarrolladores?
No. El portal es una de las interfaces posibles, no la plataforma. El documento de la CNCF menciona los portales web junto con las APIs, las interfaces de línea de comandos y las plantillas documentadas como formas de consumir las capacidades. El error es frecuente y caro: se instala un portal, se lo llena de tarjetas que enlazan a documentación desactualizada y nada cambia, porque abajo no hay capacidades reales que se puedan pedir con autoservicio. Primero la capacidad, después la vitrina.
¿Hace falta Kubernetes para tener una plataforma interna?
No. Kubernetes es una implementación posible de algunas capacidades, no un requisito: una plataforma interna puede estar construida sobre máquinas virtuales o sobre servicios administrados de una nube. El criterio no es la tecnología sino el resultado. Si un equipo puede pedir un entorno, desplegar, ver sus registros y sus métricas y rotar un secreto sin abrir un ticket ni aprender la infraestructura completa, hay plataforma. Si para cualquiera de esas cosas hay que pedirle a otra persona, todavía no.
¿Qué es un golden path?
Es el camino recomendado y ya resuelto para hacer algo habitual: crear un servicio nuevo, publicar una API, agregar una base de datos. Se materializa en una plantilla que trae lo que la organización considera correcto —estructura del repositorio, pipeline, pruebas, telemetría, permisos mínimos— de modo que arrancar bien sea más fácil que arrancar mal. La clave es que sea un camino y no una vía única: tiene que existir la posibilidad de salirse para los casos que lo justifiquen.
¿Cuándo conviene armar un equipo de plataforma?
Cuando el mismo trabajo de infraestructura se repite en varios equipos con soluciones distintas y ya se nota en el tiempo de entrega. Con dos o tres equipos, un conjunto de plantillas y convenciones compartidas suele alcanzar. La señal a mirar no es la cantidad de gente sino la duplicación: si cada equipo escribió su propio pipeline, su propia forma de manejar secretos y su propio tablero, ya se está pagando una plataforma sin tenerla, en horas dispersas y configuraciones que nadie audita.
¿Cómo se mide si la plataforma sirve?
Por adopción voluntaria y reducción de trabajo repetido, no por cantidad de funciones entregadas. Dan señal tres preguntas: qué porcentaje de servicios nuevos arranca con la plantilla oficial, cuánto tarda un equipo desde que quiere un entorno hasta que lo tiene, y cuántos tickets manuales siguen existiendo para tareas que la plataforma dice cubrir. El modelo de madurez agrega la dimensión que suele faltar: sin un proceso para recoger la opinión de quienes la usan, la plataforma se optimiza sola y se separa de las necesidades reales.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Cl0udswX, foro de Underc0de. Contenedores Docker for dummies, 26 de mayo de 2016. Introducción de la comunidad a los contenedores, la pieza sobre la que se apoya buena parte de las capacidades descritas acá.
- Underc0de, foro. Sección GNU/Linux. Material sobre administración de sistemas y servidores, la base operativa de cualquier plataforma interna.
Documentación oficial
- CNCF, TAG App Delivery. CNCF Platforms White Paper, versión 1.0. Definición de plataforma, atributos, capacidades e interfaces, citados textualmente.
- CNCF, TAG App Delivery. Platform Engineering Maturity Model, versión 1.0. Los cuatro niveles y los cinco aspectos, con las preguntas de cada aspecto citadas textualmente.
- DORA. DORA: DevOps Research and Assessment. Investigación sobre rendimiento en entrega de software, referencia para las métricas de resultado.