Aprovisionamiento para la era agéntica: cómo Databricks construyó una máquina expendedora de infraestructura de autoservicio

En Databricks, nuestra organización de ingeniería de campo existe para ayudar a los clientes a tener éxito. Eso significa crear demostraciones, reproducir problemas, probar funciones con cargas de trabajo reales y estar listos (con poco aviso) para mostrar a un cliente potencial exactamente qué es posible en la plataforma. Esto nunca ha sido más importante que en la era de la IA, donde una sola semana puede significar un cambio fundamental en lo que es posible. A medida que Databricks ha crecido, se ha vuelto más importante —y más desafiante— capacitar a nuestra organización de campo de una manera rápida, gobernada y consciente de los costos.

Para resolver ese problema, nos propusimos crear la Field Engineering Vending Machine, o FEVM para abreviar. Como cualquier buena máquina expendedora, la idea es simple: dices lo que necesitas, lo obtienes y, cuando terminas, desaparece. Quizás lo más importante es que FEVM está construida con componentes nativos de Databricks en su núcleo, y con agentes como ciudadanos de primera clase.

Dificultades de crecimiento a escala

Hace poco más de tres años, el equipo de ingeniería de campo tenía menos de 1,500 personas. Un pequeño número de espacios de trabajo compartidos cubría la mayoría de los casos de uso, y el mantenimiento manual mantenía las cosas funcionando razonablemente bien. Pero Databricks creció rápido. GTM cuenta ahora con más de 7,000 personas, y la ingeniería de campo representa una parte significativa de esa cifra. Una infraestructura que funcionaba a una escala determinada necesita un diseño diferente a otra.

Los espacios de trabajo de Databricks están optimizados para que un número reducido de administradores gestione a muchos usuarios, lo cual tiene sentido para la mayoría de las implementaciones empresariales. Sin embargo, la ingeniería de campo tiene requisitos diferentes: casi todos necesitan acceso de nivel de administrador para hacer su trabajo. Configurar entornos de demostración, probar funciones en vista previa, ejecutar escenarios específicos de clientes... todo ello requiere el tipo de control que proporciona el acceso de administrador.

A escala, coordinar el trabajo en espacios de trabajo compartidos genera una complejidad operativa real. El hecho de que varios ingenieros trabajen en el mismo entorno durante un momento crítico de una demostración puede interferir con el trabajo de los demás, y los límites de la plataforma (en catálogos, instancias de Lakebase y cargas de trabajo concurrentes, por ejemplo) se convierten en una preocupación activa en lugar de secundaria. La atribución de costos se vuelve más difícil de rastrear a medida que aumenta el uso y la propiedad se vuelve menos clara.

El problema de la observabilidad también agravó estos desafíos. Cuando ocurría algo inesperado en un espacio de trabajo compartido, rastrear qué pasó, cuándo y por qué requería una investigación manual. Necesitábamos un modelo que hiciera que cada acción de aprovisionamiento fuera transparente, auditable y atribuible desde el principio.

La idea clave que dio forma a FEVM fue sencilla: ¿qué pasaría si cada ingeniero pudiera tener su propio entorno aislado, aprovisionado en minutos, gobernado de forma centralizada y limpiado automáticamente?

Construyendo sobre Databricks, para Databricks

Cuando Databricks Apps estuvo disponible, la oportunidad fue clara. Habíamos estado manteniendo los entornos a través de una colección de trabajos individuales: un trabajo por tarea, ejecutándose por separado y siempre un poco por detrás de la realidad. Apps nos dio una forma de abstraer todo eso detrás de una única interfaz: dinos qué estás intentando lograr en un lenguaje sencillo y nosotros descubriremos qué infraestructura aprovisionar.

Ese se convirtió en el principio de diseño central de FEVM: aprovisionamiento basado en casos de uso. No solicitas "un espacio de trabajo". Describes lo que estás intentando hacer, ya sea crear una demostración para un cliente de servicios financieros, reproducir un problema de soporte o ejecutar una sesión de hackatón, y obtienes un entorno configurado para ese propósito. Todo esto está abstraído con un MCP en su núcleo, lo que significa que el chat, los servicios externos y los agentes se sirven desde un único punto de control; con el auge de herramientas como Claude, esto significa que agregar un archivo de habilidades .md simple te permite solicitar un nuevo entorno en la línea de comandos en lenguaje sencillo e iniciar sesión minutos después. Los flujos de trabajo más complejos se vuelven igualmente triviales desde la perspectiva del usuario.

La aplicación está construida sobre un frontend de React con un backend de Python, implementada a través de Databricks Apps. Terraform se ejecuta en segundo plano para encargarse del aprovisionamiento real de recursos en la nube en AWS, Azure y GCP. Una base de datos de estado y configuración, que se ejecuta en Lakebase, realiza el seguimiento de cada recurso: qué es, quién es el propietario, para qué sirve y cuándo expira.

La experiencia de desarrollo de Databricks Apps en sí fue sencilla. El trabajo más complejo fue la integración en el ecosistema más amplio: conectar lanzamientos de flujos de trabajo basados en Git, gestionar la identidad en los sistemas corporativos y garantizar que la automatización de las acciones administrativas en la infraestructura de backend real se mantuviera dentro de nuestros límites de seguridad. Operamos bajo una serie de excepciones de seguridad exactamente por esta razón y hemos sido deliberados al diseñar para una buena gestión en cada paso; las nuevas plantillas se revisan, se refuerzan y se prueban repetidamente para asegurarnos de que no expongan nuevos vectores de amenazas.

Qué hace la aplicación

Cuando un ingeniero de campo abre FEVM, es recibido con una interfaz de búsqueda. Puede explorar un catálogo de plantillas para encontrar el tipo de entorno adecuado (por ejemplo, serverless estable en AWS, una configuración multinube o un entorno con autoescalado de Lakebase preconfigurado) y configurarlo desde allí. Elige un proveedor de nube y una región, describe lo que está construyendo, le asigna un nombre (o acepta uno aleatorio) y lo implementa.

Más recientemente, hemos habilitado flujos de trabajo centrados en agentes que permiten a los usuarios aprovechar las habilidades de Claude publicadas de forma centralizada; esta es una opción cada vez más popular que permite a los agentes automatizar la UI e ir directamente a las API subyacentes de FEVM. Esto se vuelve especialmente potente en flujos de trabajo de múltiples pasos y herramientas; por ejemplo, un usuario podría decirle a su agente que inicie un nuevo espacio de trabajo, implemente varios DABs que haya desarrollado localmente, cargue algunos datos que tenga en S3 y luego ejecute un script de hidratación para rellenar un tablero. Este tipo de configuración hiperpersonalizada no sería posible sin un marco de agentes sólido, y Databricks Apps hace que esto sea trivial.

Cuando un usuario o agente solicita un nuevo recurso, detrás de escena la aplicación obtiene la plantilla de Terraform adecuada, la envía a un Git Runner, ajusta los permisos y luego agrega cualquier "complemento" solicitado por el usuario, como Lakebase, notebooks o activos empaquetados alojados en un volumen de UC. Los entornos de desarrollo viven durante 90 días de forma predeterminada, con opciones de extensión disponibles, mientras que otros tipos de recursos tienen un TTL configurable.

Cuando se completa el aprovisionamiento, llega una notificación de Slack. Cuando el recurso se acerca a su vencimiento, se envía otra notificación. Cuando se elimina, se te notifica nuevamente. La transparencia fue un objetivo de diseño central desde el primer día: cada evento del ciclo de vida es visible y los ingenieros siempre conocen el estado de sus recursos.

También gestionamos los recursos compartidos a través de la misma interfaz. Los catálogos independientes, por ejemplo, tienen ciclos de vida independientes de los espacios de trabajo a los que están asociados. Si eliminas un espacio de trabajo, el catálogo persiste; si inicias un nuevo espacio de trabajo en la misma región, el catálogo se vuelve a asociar automáticamente. Este tipo de gestión del ciclo de vida a nivel de recurso es importante porque tanto Unity Catalog como Lakebase tienen límites estrictos en la plataforma y, con cientos de ingenieros aprovisionando recursos activamente, el control centralizado es lo que evita que esos límites se conviertan en un techo.

Una capa de administración dentro de la aplicación le permite a nuestro equipo gestionar la configuración global (ajustar los límites del espacio de trabajo por nube, auditar las implementaciones activas y ajustar los valores predeterminados) directamente desde la UI.

Una escala que no esperábamos demostrar tan rápido

Durante BuildCon (uno de nuestros eventos internos de ingeniería), FEVM manejó cerca de 1,200 solicitudes de aprovisionamiento en un solo día. Los ingenieros de toda la organización iniciaron entornos, realizaron su trabajo y dejaron que expiraran, sin sobrecarga de coordinación ni conflicto de recursos. No hemos tenido ningún problema de escalabilidad hasta la fecha, incluso con más de 5,000 usuarios activos; al momento de escribir esto, ¡estamos gestionando más de 2,600 implementaciones activas en 3 nubes!

Ese número nos importa no solo como una prueba de esfuerzo, sino como una prueba de concepto. La hipótesis detrás de FEVM era que el aprovisionamiento aislado y justo a tiempo podría reemplazar la fricción de los entornos compartidos a escala. Un recuento de invocaciones en un solo día como ese confirma que la demanda siempre estuvo ahí y que los ingenieros solo necesitaban una herramienta que facilitara actuar sin fricciones.

El futuro agéntico hacia el que avanzamos

La visión más amplia a la que nos acercamos en Databricks es una organización de ingeniería de campo centrada en agentes: un ingeniero describe la situación de un cliente en un lenguaje sencillo, un agente inicia un entorno configurado adecuadamente, recupera el contexto relevante de la cuenta, intenta reproducir el problema o crear la demostración y devuelve un resumen listo para presentar al cliente. FEVM es la capa de infraestructura que hace que eso sea posible.

Hemos rediseñado la arquitectura de la aplicación dos veces para llegar aquí: rediseñando el esquema de la base de datos, reconstruyendo el frontend y repensando cómo gestionamos el estado. Hemos utilizado IA para acelerar la codificación, pero nos hemos mantenido al mando de la arquitectura en todo momento. El resultado es un sistema en el que confiamos para ejecutarse a escala.

Lo que aprendimos

Algunos principios que dieron forma a esta construcción:

• Construye pensando en el usuario, ya sea un humano o un agente. Nos hemos esforzado por empezar con un CUJ y diseñar funciones que resuelvan ese recorrido; esto nos mantiene honestos sobre lo que realmente se debe hacer y lo que es solo un sesgo interno.
• La transparencia es una funcionalidad, no una ocurrencia tardía. Hacer visible cada evento del ciclo de vida (aprovisionamiento, expiración, eliminación) es lo que genera confianza en los ingenieros que dependen de la herramienta para el trabajo en vivo con los clientes.
• La integración del ecosistema es un trabajo duro. La experiencia de desarrollo de Databricks Apps fue rápida y sencilla, pero conectar FEVM con Git, Slack, correo electrónico, identidad corporativa y Terraform multinube fue donde se destinó la mayor parte del esfuerzo de ingeniería y de donde provino la mayor parte del valor.

Construye para Databricks en Databricks. Casi todo en FEVM se ejecuta en la propia plataforma. Esto nos brinda información de primera mano sobre lo que funciona a escala y nos mantiene cerca de la experiencia de producto que vendemos.

Próximos pasos

Nos enfocamos en tres cosas: expandir la interfaz de aprovisionamiento de lenguaje natural, lanzar la integración de MCP para el acceso basado en herramientas y escalar el soporte en toda la organización de GTM. A medida que los agentes asuman una mayor parte del trabajo que realizan hoy los ingenieros de campo, FEVM se convertirá en la capa de recursos sobre la que se ejecutan esos agentes; no solo una herramienta de aprovisionamiento, sino una infraestructura central para un flujo de trabajo agéntico.

Mira la sesión paralela de Data and AI Summit 2026 Aprovisionamiento para la era agéntica: cómo Databricks construyó una máquina expendedora de infraestructura de autoservicio para obtener más detalles sobre la FE Vending Machine.

Para obtener más información sobre cómo crear aplicaciones de nivel de producción en Databricks, consulta Databricks Apps, Lakebase y Agent Bricks.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original