Empiezo este enero de 2022 con una convicción que vengo madurando desde hace meses en conversaciones con líderes de tecnología en México y Bogotá: DevOps nos trajo hasta aquí, pero ya no alcanza por sí solo. Donde antes celebrábamos pipelines de despliegue continuo y equipos autónomos, hoy escucho otra historia. Los desarrolladores pasan más tiempo peleando con YAML, configuraciones de nube y permisos que escribiendo el código que aporta valor al negocio. Esa fricción tiene un nombre nuevo que está ganando terreno en la conversación de la industria: platform engineering.
En corto: DevOps prometió que cada equipo fuera dueño de su ciclo de vida, pero a escala eso multiplicó la carga cognitiva de cada desarrollador. Platform engineering responde construyendo una plataforma de desarrollo interna (IDP) con un "camino pavimentado" de autoservicio. El objetivo no es quitar autonomía, sino hacer que lo correcto sea también lo más fácil.
La premisa original de DevOps fue derribar el muro entre quienes escribían el código y quienes lo operaban. "You build it, you run it" se volvió mantra. Y funcionó: ganamos velocidad, despliegues más frecuentes y dueños claros de cada servicio. El problema aparece cuando una organización pasa de cinco equipos a cincuenta.
En ese punto, cada equipo termina reinventando lo mismo: cómo provisionar un clúster, cómo configurar observabilidad, cómo cumplir con seguridad, cómo conectar una base de datos. Lo que era autonomía empieza a sentirse como abandono. He visto equipos brillantes de producto convertidos, sin quererlo, en administradores de infraestructura a tiempo parcial.
DevOps no falla; simplemente no estaba pensado para absorber la complejidad de la nube moderna multiplicada por decenas de equipos.
Una plataforma de desarrollo interna, o IDP por sus siglas en inglés (Internal Developer Platform), es el conjunto de herramientas, servicios y automatizaciones que una organización ofrece a sus propios desarrolladores para que construyan, desplieguen y operen software sin tener que entender cada capa de infraestructura por debajo.
Conviene aclarar algo: una IDP no es una sola herramienta que se compra e instala. Es un producto interno. Tiene usuarios (los desarrolladores), tiene un equipo que la mantiene (el equipo de plataforma) y tiene un ciclo de vida. La diferencia de mentalidad es enorme: en lugar de tratar la infraestructura como un servicio que se solicita por ticket, la tratamos como un producto que se diseña pensando en la experiencia de quien lo usa.
Una IDP típica integra capacidades de aprovisionamiento de entornos, gestión de configuración, despliegue, observabilidad y control de acceso, todo expuesto a través de una interfaz coherente. Sobre estos cimientos de infraestructura y servicios en la nube se construye la capa que realmente importa: la experiencia del desarrollador.
El concepto que mejor captura el espíritu de platform engineering es el del paved road o camino pavimentado. La idea, popularizada por equipos de plataforma en empresas de gran escala, es sencilla y poderosa.
En vez de obligar a cada desarrollador a abrirse paso por la selva de opciones de infraestructura, la plataforma ofrece una ruta recomendada, bien señalizada y pavimentada: la forma soportada de crear un servicio, desplegarlo y monitorearlo. Quien toma ese camino obtiene de regalo las buenas prácticas integradas.
Un punto clave: el camino pavimentado es opcional, no obligatorio. Un equipo con una necesidad muy particular puede salirse de él. Pero como el camino está tan bien hecho, la enorme mayoría elige quedarse. Ahí está la elegancia: la plataforma gana adopción por su calidad, no por imposición.
La carga cognitiva es la cantidad de cosas que una persona debe sostener en la cabeza para hacer su trabajo. Cuando un desarrollador tiene que dominar su dominio de negocio, el lenguaje, el framework, además de Kubernetes, redes, IAM, certificados y pipelines, esa carga se vuelve insostenible. La calidad del código y la velocidad de entrega se resienten.
Platform engineering ataca este problema deliberadamente. La plataforma absorbe la complejidad accidental, esa que no aporta valor al producto, para que el desarrollador se concentre en la complejidad esencial: resolver el problema del negocio. La pregunta que guía a un buen equipo de plataforma no es "¿qué herramientas tenemos?", sino "¿qué necesita saber un desarrollador para entregar valor, y cómo le quitamos todo lo demás de encima?".
Aquí la arquitectura empresarial juega un papel decisivo: definir los estándares, los límites de los dominios y las interfaces correctas es lo que permite que la plataforma esconda complejidad sin esconder también el control.
Si tuviera que elegir una sola palabra para describir una buena plataforma interna, sería autoservicio. El día en que un desarrollador necesita un nuevo entorno, una base de datos o un servicio desplegado y lo obtiene en minutos a través de un portal o un comando, sin abrir un ticket ni esperar a otro equipo, es el día en que la plataforma demuestra su valor.
El autoservicio cambia la dinámica organizacional por completo:
El autoservicio bien hecho mantiene la autonomía que prometió DevOps, pero le quita el peso operativo que la hacía impracticable a escala.
Una advertencia que repito a menudo: no se empieza construyendo una plataforma gigante. Se empieza tratando la plataforma como un producto y escuchando a sus usuarios. El error más común que observo es que un equipo de infraestructura construye lo que cree que los desarrolladores necesitan, sin preguntarles, y termina con una herramienta sofisticada que nadie adopta.
Recomiendo identificar el punto de mayor fricción en el flujo diario de los desarrolladores y pavimentar primero ese tramo. Un solo camino bien hecho, que ahorre tiempo real y genere confianza, vale más que un catálogo enorme de funciones a medias.
¿Platform engineering reemplaza a DevOps?
No. Es su evolución natural. DevOps sigue siendo la cultura de colaboración y propiedad; platform engineering es la disciplina que la hace sostenible a escala mediante una plataforma de autoservicio.
¿Necesito un equipo dedicado de plataforma?
A cierta escala, sí. Cuando varios equipos empiezan a duplicar esfuerzos de infraestructura, conviene un equipo que trate la plataforma como producto. En organizaciones pequeñas puede empezar siendo una responsabilidad compartida.
¿Una IDP es una herramienta que se compra?
No exactamente. Existen componentes y soluciones que ayudan, pero una IDP es la integración coherente de varias piezas alrededor de la experiencia de sus desarrolladores. La integración y las decisiones son propias de cada organización.
¿El camino pavimentado limita la libertad de los equipos?
No debería. Está pensado para ser opcional: ofrece la ruta recomendada con buenas prácticas incluidas, pero permite salirse cuando hay una necesidad legítima. Gana por calidad, no por obligación.
Platform engineering no es una moda pasajera de este 2022; es la respuesta madura a un problema real que muchas organizaciones en LATAM ya están sintiendo. La buena noticia es que no exige una transformación total de un día para otro. Exige cambiar la mentalidad: ver la infraestructura como un producto al servicio de sus desarrolladores.
En SUMāTO acompañamos a equipos de tecnología a diseñar este camino pavimentado, definir la arquitectura que lo sostiene y construir plataformas internas que reducen la fricción sin sacrificar el control. Si en su organización los desarrolladores pelean más con la infraestructura que con los problemas del negocio, conversemos. Escríbanos en https://sumatogroup.com/contacto y demos juntos el primer paso.