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 (em curto prazo) para mostrar ao cliente potencial exatamente o que é possível na plataforma. Isto nunca foi tão importante como na period da IA, onde uma única semana pode significar uma mudança basic no que é possível. À medida que a Databricks cresceu, tornou-se mais importante – e mais desafiante – permitir a nossa organização no terreno de uma forma rápida, governada e consciente dos custos.
Para resolver esse problema, decidimos construir a Discipline Engineering Merchandising Machine, ou FEVM, para abreviar. Como qualquer boa máquina de venda automática, a ideia é simples: você diz o que precisa, recebe e, quando termina, vai embora. Talvez o mais importante seja que o FEVM é construído com componentes nativos do Databricks em seu núcleo e agentes como cidadãos de primeira classe.
Dores de crescimento em grande escala
Há pouco mais de três anos, a engenharia de campo contava com menos de 1.500 pessoas. Um pequeno número de espaços de trabalho compartilhados cobriu a maioria dos casos de uso, e a manutenção guide manteve tudo funcionando razoavelmente bem. Mas o Databricks cresceu rapidamente. A GTM tem agora mais de 7.000 pessoas, com a engenharia de campo representando uma parcela significativa disso. A infraestrutura que funcionou em um tamanho precisa de um design diferente em outro.
Os espaços de trabalho do 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 empresariais. No entanto, a engenharia de campo tem requisitos diferentes: quase todo mundo precisa de acesso de administrador para realmente realizar seu trabalho. Configurar ambientes de demonstração, testar recursos de visualização, executar cenários específicos do cliente – tudo isso requer o tipo de controle que o acesso de administrador fornece.
Em escala, a coordenação do trabalho em espaços de trabalho compartilhados cria uma complexidade operacional actual. 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 Lakebase e cargas de trabalho simultâneas, por exemplo — tornam-se uma preocupação ativa em vez de uma preocupação em segundo plano. A atribuição de custos fica mais difícil de acompanhar à medida que o uso aumenta e a propriedade se torna menos clara.
O problema da observabilidade também agravou estes desafios. Quando algo inesperado acontecia em um espaço de trabalho compartilhado, rastrear o que ocorreu, quando e por que exigia investigação guide. Precisávamos de um modelo que tornasse cada ação de provisionamento transparente, auditável e atribuível desde o início.
A ideia que moldou a FEVM foi simples: e se cada engenheiro pudesse ter o seu próprio ambiente isolado, aprovisionado em minutos, governado centralmente e limpo automaticamente?
Construindo em Databricks, para Databricks
Quando os aplicativos Databricks foram disponibilizados, a oportunidade ficou clara. Tínhamos mantido ambientes por meio de uma coleção de trabalhos individuais — um trabalho por tarefa, executados separadamente e sempre um pouco atrasados em relação à realidade. Os aplicativos nos deram uma maneira de abstrair tudo isso em uma única interface: diga-nos o que você está tentando realizar em inglês simples e nós descobriremos qual infraestrutura fornecer.
Esse se tornou o princípio central do design do FEVM: provisionamento baseado em casos de uso. Você não solicita “um espaço de trabalho”. Você descreve o que está tentando fazer, seja criar uma demonstração para um cliente de serviços financeiros, reproduzir um problema de suporte, executar uma sessão de hackathon, e obtém 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 atendidos a partir de um único ponto de controle; com o surgimento de ferramentas como Claude, isso significa que adicionar um arquivo de habilidade .md simples 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 front-end React com back-end Python, implantado por meio de aplicativos Databricks. O Terraform é executado em segundo plano para lidar com o provisionamento actual 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 possui, para que serve, quando expira.
A experiência de desenvolvimento do Databricks Apps em si foi simples. O trabalho mais complexo foi a integração no ecossistema mais amplo: conectar lançamentos de fluxo de trabalho baseados em Git, lidar com identidades em sistemas corporativos e garantir que a automatização de ações administrativas contra infraestrutura de back-end actual permanecesse dentro dos nossos limites de segurança. Operamos sob uma série de exceções de segurança exatamente por esse motivo e temos sido deliberados sobre o projeto para uma boa administração em cada etapa; novos modelos são examinados, reforçados e testados repetidamente para garantir que não exponham novos vetores de ameaças.
O que o aplicativo faz
Quando um engenheiro de campo abre o FEVM, ele é recebido por uma interface de pesquisa. Eles podem navegar em um catálogo de modelos para encontrar o tipo de ambiente certo – estável sem servidor na AWS, uma configuração multinuvem, um ambiente com escalonamento automático Lakebase pré-configurado, por exemplo – e configurar a partir daí. Eles escolhem um provedor de nuvem e uma região, descrevem o que estão construindo, dão um nome (ou aceitam um nome aleatório) e implantam.
Mais recentemente, habilitamos fluxos de trabalho que priorizam o agente, permitindo que os usuários aproveitem as habilidades de claude publicadas centralmente; esta é uma opção cada vez mais fashionable que permite aos agentes automatizar a UI e ir diretamente para as APIs FEVM subjacentes. Isso se torna especialmente poderoso em fluxos de trabalho com várias etapas e várias ferramentas; por exemplo, um usuário pode instruir seu agente a criar um novo espaço de trabalho, implantar vários DABs desenvolvidos localmente e fazer add de alguns dados que possui no S3 e, em seguida, executar um script de hidratação para preencher um painel. Este tipo de configuração hiperpersonalizada não seria possível sem uma estrutura de agente forte – e o Databricks Apps torna isso trivial.
Quando um usuário ou agente solicita um novo recurso, nos bastidores o aplicativo busca o modelo de terraform apropriado, alimenta-o em um Git Runner, ajusta as permissões e, em seguida, adiciona quaisquer “complementos” de solicitação do usuário, como Lakebase, notebooks ou ativos pré-empacotados hospedados em um quantity UC. Os ambientes do construtor 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 for concluído, uma notificação do Slack chegará. Quando o recurso está prestes a expirar, outra notificação é enviada. Quando for excluído, você será notificado novamente. A transparência foi um objetivo central do projeto desde o primeiro dia: todos os eventos do ciclo de vida são visíveis e os engenheiros sempre sabem o estado de seus recursos.
Também gerenciamos recursos compartilhados através da mesma interface. Catálogos autônomos, por exemplo, carregam ciclos de vida independentes dos espaços de trabalho aos quais estão anexados. Exclua um espaço de trabalho e o catálogo persistirá; crie um novo espaço de trabalho na mesma região e o catálogo será reconectado automaticamente. Esse tipo de gerenciamento do ciclo de vida no nível dos recursos é 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 international – ajustando os limites do espaço de trabalho por nuvem, auditando implantações ativas, ajustando padrões – diretamente da UI.
Escala que não esperávamos provar tão rapidamente
Durante a BuildCon — um de nossos eventos internos de engenharia — a FEVM atendeu cerca de 1.200 solicitações de provisionamento em um único dia. Os engenheiros de toda a organização criaram ambientes, fizeram seu trabalho e os deixaram expirar, sem sobrecarga de coordenação ou contenção de recursos. Até o momento, não encontramos nenhum problema de escalabilidade, mesmo com mais de 5.000 usuários ativos; No momento em que escrevemos, gerenciamos mais de 2.600 implantações ativas em 3 nuvens!
Esse número é importante para nós não apenas como um teste de resistência, mas como uma prova de conceito. A hipótese por trás do FEVM period que o provisionamento isolado e just-in-time poderia substituir o atrito de ambientes compartilhados em escala. Uma contagem de invocações de um dia como essa confirma que a demanda sempre existiu e que os engenheiros só precisavam de uma ferramenta que facilitasse a ação.
O futuro agente que estamos construindo
A visão mais ampla que estamos abordando na Databricks é uma organização de engenharia de campo que prioriza o agente: um engenheiro descreve uma situação do cliente em linguagem simples, um agente cria um ambiente configurado adequadamente, recupera o contexto da conta relevante, tenta reproduzir o problema ou construir a demonstração e retorna um resumo pronto para ser levado ao cliente. FEVM é a camada de infraestrutura que torna isso possível.
Reestruturamos o aplicativo duas vezes para chegar até aqui: redesenhando o esquema do banco de dados, reconstruindo o frontend, 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 funcionar em grande escala.
O que aprendemos
Alguns princípios que moldaram esta construção:
- Crie pensando no usuário – seja ele um humano ou um agente. Trabalhamos muito para começar com um CUJ e recursos de design que resolveram essa jornada – isso nos mantém honestos sobre o que realmente precisa ser feito e o que é apenas preconceito interno.
- A transparência é um recurso, não uma reflexão tardia. Tornar visíveis todos os eventos do ciclo de vida — provisionamento, expiração, exclusão — é o que gera confiança entre os engenheiros que dependem da ferramenta para trabalhar em tempo actual com o cliente.
- A integração do ecossistema é um trabalho árduo. 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 multinuvem foi para onde foi a maior parte do esforço de engenharia e de onde veio a maior parte do valor.
Construa para Databricks em Databricks. Quase tudo no FEVM roda na própria plataforma. Isso nos dá uma visão em primeira mão do que funciona em grande escala e nos mantém próximos da experiência do produto que vendemos.
O que vem a seguir
Estamos focados em três coisas: expandir a interface de provisionamento de linguagem pure, fornecer a integração MCP para acesso baseado em ferramentas e ampliar o suporte em toda a organização GTM mais ampla. À medida que os agentes assumem mais o trabalho que os engenheiros de campo realizam hoje, o FEVM se tornará a camada de recursos na qual esses agentes operam – não apenas uma ferramenta de provisionamento, mas uma infraestrutura central para um fluxo de trabalho de agente.
Assista à sessão de discussão do Knowledge and AI Summit 2026 Provisionamento para a period Agentic: como a Databricks construiu uma máquina de venda automática de infraestrutura de autoatendimento para mais detalhes sobre a máquina de venda automática FE.
Para saber mais sobre como criar aplicativos de nível de produção no Databricks, confira Aplicativos de blocos de dados, Base do lago e Agente Tijolos.