Provisionamento para a Era dos Agentes: Como a Databricks Criou uma 'Vending Machine' de Infraestrutura Self-Service

Na Databricks, nossa organização de engenharia de campo existe para ajudar os clientes a terem sucesso. Isso significa criar demonstrações, reproduzir problemas, testar recursos em cargas de trabalho reais e estar pronto (com pouca antecedência) para mostrar a um cliente em potencial exatamente o que é possível na plataforma. Isso nunca foi tão importante quanto na era da IA, onde uma única semana pode significar uma mudança fundamental no que é possível. À medida que a Databricks cresceu, tornou-se mais importante — e mais desafiador — capacitar nossa organização de campo de uma forma rápida, governada e consciente dos custos.

Para resolver esse problema, decidimos criar a Field Engineering Vending Machine, ou FEVM. Como qualquer boa máquina de vendas, a ideia é simples: você diz o que precisa, recebe e, quando terminar, ela desaparece. Talvez o mais importante seja que a FEVM foi criada com componentes nativos da Databricks em sua essência e com agentes como cidadãos de primeira classe.

Dores de crescimento em escala

Há pouco mais de três anos, a engenharia de campo tinha menos de 1.500 pessoas. Um pequeno número de workspaces compartilhados cobria a maioria dos casos de uso, e a manutenção manual mantinha as coisas funcionando razoavelmente bem. Mas a Databricks cresceu rápido. O GTM agora conta com mais de 7.000 pessoas, com a engenharia de campo representando uma parte significativa disso. Uma infraestrutura que funcionava em um determinado tamanho precisa de um design diferente em outro.

Os workspaces da Databricks são otimizados para um pequeno número de administradores que gerenciam muitos usuários, o que faz sentido para a maioria das implantações corporativas. No entanto, a engenharia de campo tem requisitos diferentes: quase todo mundo precisa de acesso em nível de administrador para realmente fazer seu trabalho. Configurar ambientes de demonstração, testar recursos em versão prévia, executar cenários específicos do cliente — tudo isso exige o tipo de controle que o acesso de administrador oferece.

Em escala, coordenar o trabalho em workspaces compartilhados cria uma complexidade operacional real. Vários engenheiros trabalhando no mesmo ambiente durante um momento crítico de demonstração podem interferir no trabalho uns dos outros, e os limites da plataforma — em catálogos, instâncias do Lakebase e cargas de trabalho simultâneas, por exemplo — tornam-se uma preocupação ativa, em vez de secundária. A atribuição de custos torna-se mais difícil de rastrear à medida que o uso aumenta e a propriedade se torna menos clara.

O problema de observabilidade também agravou esses desafios. Quando algo inesperado acontecia em um workspace compartilhado, rastrear o que ocorreu, quando e por que exigia uma investigação manual. Precisávamos de um modelo que tornasse cada ação de provisionamento transparente, auditável e atribuível desde o início.

O insight que moldou a FEVM foi simples: e se cada engenheiro pudesse ter seu próprio ambiente isolado, provisionado em minutos, governado centralmente e limpo automaticamente?

Desenvolvendo na Databricks, para a Databricks

Quando o Databricks Apps ficou disponível, a oportunidade ficou clara. Vínhamos mantendo ambientes por meio de uma coleção de jobs individuais — um job por tarefa, sendo executados separadamente e sempre um pouco desatualizados em relação à realidade. O Apps nos deu uma maneira de abstrair tudo isso por trás de uma única interface: diga-nos o que você está tentando realizar em inglês simples, e nós descobriremos qual infraestrutura provisionar.

Esse se tornou o princípio de design central da FEVM: provisionamento baseado em casos de uso. Você não solicita "um workspace". Você descreve o que está tentando fazer, seja criar uma demonstração para um cliente de serviços financeiros, reproduzir um problema de suporte ou realizar uma sessão de hackathon, e recebe um ambiente configurado para essa finalidade. Tudo isso é abstraído com um MCP em sua essência, o que significa que chat, serviços externos e agentes são todos servidos a partir de um único ponto de controle; com o surgimento de ferramentas como o Claude, isso significa que adicionar um arquivo simples de habilidade .md permite que você solicite um novo ambiente na linha de comando em inglês simples e faça login minutos depois. Fluxos de trabalho mais complexos tornam-se igualmente triviais do ponto de vista do usuário.

O aplicativo é construído em um frontend React com um backend Python, implantado via Databricks Apps. O Terraform é executado em segundo plano para lidar com o provisionamento real de recursos de nuvem na AWS, Azure e GCP. Um banco de dados de estado e configuração — executado no Lakebase — rastreia cada recurso: o que é, quem é o proprietário, para que serve e quando expira.

A experiência de desenvolvimento do Databricks Apps em si foi direta. O trabalho mais complexo foi a integração ao ecossistema mais amplo: conectar inicializações de fluxo de trabalho baseadas em Git, gerenciar a identidade em sistemas corporativos e garantir que a automação de ações administrativas contra a infraestrutura de backend real permanecesse dentro de nossos limites de segurança. Operamos sob uma série de exceções de segurança exatamente por esse motivo e temos sido deliberados ao projetar para uma boa gestão em cada etapa; novos modelos são avaliados, protegidos e testados repetidamente para garantir que não exponham novos vetores de ameaça.

O que o aplicativo faz

Quando um engenheiro de campo abre a FEVM, ele é recebido com uma interface de busca. Ele pode navegar por um catálogo de modelos para encontrar o tipo de ambiente correto — por exemplo, serverless estável na AWS, uma configuração multicloud ou um ambiente com escalonamento automático do Lakebase pré-configurado — e configurar a partir daí. Ele escolhe um provedor de nuvem e uma região, descreve o que está criando, dá um nome (ou aceita um nome aleatório) e faz a implantação.

Mais recentemente, habilitamos fluxos de trabalho focados em agentes que permitem aos usuários aproveitar habilidades do Claude publicadas centralmente; essa é uma opção cada vez mais popular que permite aos agentes automatizar a UI e ir diretamente para as APIs subjacentes da FEVM. Isso se torna especialmente poderoso em fluxos de trabalho de várias etapas e várias ferramentas; por exemplo, um usuário pode dizer ao seu agente para criar um novo workspace, implantar vários DABs que desenvolveu localmente, fazer upload de alguns dados que possui no S3 e, em seguida, executar um script de hidratação para preencher um dashboard. Esse tipo de configuração hiperpersonalizada não seria possível sem uma estrutura de agentes robusta — e o Databricks Apps torna isso trivial.

Quando um usuário ou agente solicita um novo recurso, nos bastidores o aplicativo busca o modelo do Terraform apropriado, envia-o para um Git Runner, ajusta as permissões e adiciona quaisquer "add-ons" solicitados pelo usuário, como Lakebase, notebooks ou ativos pré-empacotados hospedados em um UC Volume. Os ambientes de compilação duram 90 dias por padrão, com opções de extensão disponíveis, enquanto outros tipos de recursos têm TTL configurável.

Quando o provisionamento é concluído, uma notificação do Slack é enviada. Quando o recurso está próximo de expirar, outra notificação é enviada. Quando ele é excluído, você é notificado novamente. A transparência foi um objetivo de design central desde o primeiro dia: cada evento de ciclo de vida é visível, e os engenheiros sempre sabem o estado de seus recursos.

Também gerenciamos recursos compartilhados por meio da mesma interface. Catálogos independentes, por exemplo, possuem ciclos de vida independentes dos workspaces aos quais estão vinculados. Exclua um workspace e o catálogo persistirá; crie um novo workspace na mesma região e o catálogo será reanexado automaticamente. Esse tipo de gerenciamento de ciclo de vida no nível do recurso é importante porque o Unity Catalog e o Lakebase têm limites rígidos de plataforma e, com centenas de engenheiros provisionando recursos ativamente, o controle centralizado é o que impede que esses limites se tornem um teto.

Uma camada de administração dentro do aplicativo permite que nossa equipe gerencie a configuração global — ajustando os limites de workspace por nuvem, auditando implantações ativas e ajustando os padrões — diretamente da UI.

Uma escala que não esperávamos comprovar tão rapidamente

Durante o BuildCon — um de nossos eventos internos de engenharia —, a FEVM lidou com cerca de 1.200 solicitações de provisionamento em um único dia. Engenheiros de toda a organização criaram ambientes, realizaram seus trabalhos e deixaram que expirassem, sem sobrecarga de coordenação ou disputa de recursos. Não tivemos nenhum problema de escalabilidade até o momento, mesmo com mais de 5.000 usuários ativos; no momento em que este texto foi escrito, estamos gerenciando mais de 2.600 implantações ativas em 3 nuvens!

Esse número é importante para nós não apenas como um teste de estresse, mas como uma prova de conceito. A hipótese por trás da FEVM era de que o provisionamento isolado e just-in-time poderia substituir o atrito de ambientes compartilhados em escala. Uma contagem de chamadas em um único dia como essa confirma que a demanda sempre existiu e que os engenheiros só precisavam de uma ferramenta que tornasse a ação sem atritos.

O futuro agêntico que estamos construindo

A visão mais ampla de que estamos nos aproximando na Databricks é uma organização de engenharia de campo focada primeiro em agentes: um engenheiro descreve a situação de um cliente em linguagem simples, um agente cria um ambiente configurado adequadamente, recupera o contexto relevante da conta, tenta reproduzir o problema ou criar a demonstração e retorna um resumo pronto para ser apresentado ao cliente. A FEVM é a camada de infraestrutura que torna isso possível.

Remodelamos a arquitetura do aplicativo duas vezes para chegar aqui: redesenhando o esquema do banco de dados, reconstruindo o frontend e repensando como gerenciamos o estado. Usamos IA para acelerar a codificação, mas permanecemos no controle da arquitetura o tempo todo. O resultado é um sistema em que confiamos para rodar em escala.

O que aprendemos

Alguns princípios que moldaram essa construção:

• Desenvolva pensando no usuário — seja ele um humano ou um agente. Trabalhamos duro para começar com uma CUJ e projetar recursos que resolvessem essa jornada — isso nos mantém realistas sobre o que realmente precisa ser feito e o que é apenas viés interno.
• A transparência é um recurso, não um detalhe tardio. Tornar visível cada evento do ciclo de vida — provisionamento, expiração, exclusão — é o que gera confiança nos engenheiros que dependem da ferramenta para o trabalho ativo com clientes.
• A integração do ecossistema dá trabalho. A experiência de desenvolvimento do Databricks Apps foi rápida e direta, mas conectar o FEVM ao Git, Slack, e-mail, identidade corporativa e Terraform multicloud foi onde a maior parte do esforço de engenharia foi aplicada, e de onde veio a maior parte do valor.

Desenvolva para o Databricks no Databricks. Quase tudo no FEVM roda na própria plataforma. Isso nos dá uma visão direta do que funciona em escala e nos mantém próximos da experiência de produto que estamos vendendo.

O que vem a seguir

Estamos focados em três coisas: expandir a interface de provisionamento em linguagem natural, lançar a integração do MCP para acesso baseado em ferramentas e dimensionar o suporte em toda a organização de GTM. À medida que os agentes assumem mais do trabalho que os engenheiros de campo fazem hoje, o FEVM se tornará a camada de recursos na qual esses agentes são executados — não apenas uma ferramenta de provisionamento, mas a infraestrutura principal para um fluxo de trabalho agêntico.

Assista à sessão técnica do Data and AI Summit 2026 Provisionamento para a Era Agêntica: Como o Databricks Criou uma Máquina de Autoatendimento de Infraestrutura para obter mais detalhes sobre a FE Vending Machine.

Para saber mais sobre como criar aplicativos de nível de produção no Databricks, confira o Databricks Apps, o Lakebase e o Agent Bricks.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original