Atulpriya Sharma, en su calidad de embajador de la CNCF y organizador del TCG de Platform Engineering, considera que la pregunta más importante en la ingeniería de plataformas no es si la organización ha construido una plataforma, sino cómo interactúan realmente los desarrolladores con sus capacidades. Las organizaciones que aún no cuentan con una plataforma oficial suelen depender de scripts dispersos y del conocimiento individual, mientras que otras pueden tener un portal para desarrolladores, una interfaz CLI y rutas preparadas, pero seguir procesando las solicitudes manualmente. En ambos casos, el problema reside en la madurez de la interfaz a través de la cual los equipos consumen las capacidades de la plataforma.
El artículo se basa en el modelo de madurez de la ingeniería de plataformas de la CNCF, que mide cinco aspectos de forma independiente: inversión, adopción, interfaces, operaciones y medición. Cada aspecto tiene cuatro niveles: provisional, operativo, escalable y optimizado. Según el modelo, la organización no avanza como una unidad única; puede progresar en un aspecto mientras permanece rezagada en otro. El análisis se centra en el aspecto de las interfaces, es decir, los formularios, las interfaces CLI, los portales y las API que utilizan los desarrolladores.
Cuatro etapas para la interfaz de la plataforma
En el primer nivel, la organización depende de procedimientos personalizados: solicitudes manuales, procesos que varían entre equipos y conocimientos que pasan de una persona a otra. La ausencia de un nombre oficial para la plataforma no significa que esta no exista en la práctica; los mensajes repetidos a un ingeniero concreto para configurar una base de datos representan la interfaz actual de la plataforma, aunque no esté gestionada.
El segundo nivel recibe el nombre de herramientas estandarizadas. Aquí aparecen las rutas doradas o caminos pavimentados, junto con documentación, plantillas e interfaces coherentes para proporcionar y supervisar capacidades. Los resultados suelen parecer positivos: mayor adopción, incorporación más rápida de los nuevos empleados y mejora de los indicadores. Sin embargo, las solicitudes que quedan fuera de la ruta prevista siguen necesitando la intervención del equipo de plataforma, por lo que la interfaz está unificada, pero no es autosuficiente.
En el tercer nivel aparecen las soluciones de autoservicio, mediante las cuales el desarrollador puede ejecutar la mayoría de las solicitudes rutinarias sin pasar por el equipo de plataforma. Este nivel mide el comportamiento de los equipos más que su dependencia exclusiva de los indicadores: disminuyen los tickets de aprovisionamiento rutinario, los nuevos ingenieros empiezan a utilizar directamente la plataforma y el trabajo del equipo de plataforma pasa de ejecutar solicitudes individuales a mejorar el marco que las gestiona. Según los ejemplos citados por el autor, algunas organizaciones informaron de una reducción de las solicitudes de excepción de entre el 40 % y el 60 % después de añadir opciones de configuración de autoservicio.
El cuarto nivel, los servicios integrados, convierte las capacidades de la plataforma en una parte transparente de las herramientas de trabajo cotidianas. Al crear un nuevo servicio, la supervisión, el registro y la seguridad pueden integrarse automáticamente, mientras que las políticas de seguridad hacen cumplir sus reglas a través de la plataforma, en lugar de exigir al desarrollador que las negocie manualmente. La plataforma se vuelve casi invisible, y su éxito se mide por la poca frecuencia con la que los desarrolladores tienen que pensar en la infraestructura.
¿Por qué las organizaciones se detienen en el segundo nivel?
El análisis identifica cuatro problemas recurrentes. El primero es el problema de las colas: las rutas doradas cubren los casos habituales, pero los casos excepcionales pueden representar el 30 % del trabajo en las organizaciones grandes. El autor cita el ejemplo de una organización minorista que utilizó una ruta dorada para desplegar Kubernetes mediante charts de Helm y ArgoCD. La adopción alcanzó el 85 % en seis meses, pero se acumularon 40 casos de excepción y el equipo terminó dedicando el 60 % de su tiempo a configuraciones fuera de la ruta.
El segundo es la brecha de experiencia; los equipos de plataforma pueden crear capacidades generales que no se ajustan por completo a las necesidades de los equipos especializados, lo que lleva a estos últimos a desarrollar sus propias alternativas. El tercero es la trampa del mantenimiento: cada nueva capacidad implica una superficie adicional que actualizar, probar y corregir cuando aparece una vulnerabilidad o se actualiza Kubernetes. El autor menciona un caso en el que se acumularon charts de Helm antiguos, dependencias de un proveedor de nube y supuestos de red, hasta que su actualización se volvió arriesgada.
El cuarto problema es la rigidez. La ruta dorada refleja supuestos correctos cuando se diseña, pero estos pueden convertirse en restricciones a medida que cambian las tecnologías, los procesos y las necesidades de los equipos. Entonces proliferan las excepciones y la infraestructura paralela, y el equipo de plataforma se convierte en una fábrica de soluciones individuales en lugar de mejorar la interfaz principal.
¿Qué cambia en la práctica?
Para pasar del primer nivel al segundo, el autor propone poner nombre a lo que ya existe antes de construir un nuevo portal: identificar las solicitudes más frecuentes, las que más tiempo consumen y las que más fácilmente pueden estandarizarse; después, seleccionar una única ruta dorada y mejorarla realmente antes de ampliar el catálogo.
Para pasar del segundo nivel al tercero, el equipo de plataforma debe dejar de ser un eslabón humano obligatorio. Esto requiere que las rutas doradas sean configurables, con opciones validadas y restricciones impuestas por políticas en lugar de valores rígidos, además de ofrecer salidas para los casos legítimos. El análisis también recomienda medir las solicitudes antes de automatizarlas; en un ejemplo del sector de los medios de comunicación, registrar las solicitudes durante tres meses permitió descubrir que el 20 % de los tipos de solicitud representaba el 80 % del volumen. Primero se creó el autoservicio para esos patrones y la acumulación se redujo un 60 % en seis meses.
También conviene tratar la interfaz como un producto, y no únicamente las capacidades de backend. La capacidad de descubrimiento, las reglas de validación, los contratos y la forma de gestionar las solicitudes inesperadas forman parte del producto. Al acercarse al cuarto nivel, la automatización pasa de ser una acción que el desarrollador elige a basarse en supuestos inteligentes impuestos por las políticas dentro de Git, el entorno de desarrollo y los sistemas de CI/CD, con una distribución de la propiedad de las capacidades entre los equipos de seguridad, bases de datos y supervisión mediante contratos claros.
La lectura de certi.news
El cambio real que destaca el artículo es el desplazamiento del criterio de éxito de una plataforma para desarrolladores: deja de ser el número de herramientas y rutas lanzadas y pasa a ser el grado de autonomía que obtienen los usuarios, y posteriormente el nivel de integración de esas capacidades en el flujo de trabajo. Esto es importante para los equipos de plataforma, porque pueden aumentar aparentemente la adopción mientras trasladan la carga de ejecución a una cola de excepciones y mantenimiento.
Sin embargo, el autor presenta los ejemplos y las cifras incluidas aquí como observaciones derivadas de interacciones con organizaciones, no como un estudio cuantitativo independiente que demuestre que los mismos porcentajes se aplican a todas las organizaciones. Además, alcanzar el cuarto nivel presupone madurez en los contratos, las políticas y la distribución de la propiedad, aspectos que por sí solos no proporciona la compra de un portal ni la incorporación de un agente de inteligencia artificial. La conclusión plantea una importante pregunta abierta: la interfaz de autoservicio diseñada para desarrolladores no es necesariamente una interfaz consumible por agentes de inteligencia artificial, que interactúan con las API con una frecuencia y unos patrones distintos de los del flujo de trabajo humano. Por ello, la madurez de las interfaces legibles por máquinas podría ser la siguiente etapa que los equipos de plataforma deban medir.