Provisioning per l'era agentica: come Databricks ha creato un distributore automatico di infrastruttura self-service

In Databricks, la nostra organizzazione di field engineering esiste per aiutare i clienti ad avere successo. Ciò significa creare demo, riprodurre problemi, testare funzionalità con carichi di lavoro reali ed essere pronti (con breve preavviso) a mostrare a un potenziale cliente esattamente cosa è possibile fare sulla piattaforma. Questo non è mai stato così importante come nell'era dell'AI, in cui una sola settimana può significare un cambiamento fondamentale in ciò che è realizzabile. Con la crescita di Databricks, è diventato più importante — e più stimolante — abilitare la nostra organizzazione sul campo in modo rapido, governato e attento ai costi.

Per risolvere questo problema, abbiamo deciso di creare la Field Engineering Vending Machine, o FEVM in breve. Come per ogni buon distributore automatico, l'idea è semplice: dici di cosa hai bisogno, lo ottieni e, quando hai finito, scompare. Cosa forse più importante, FEVM è integrata con componenti nativi di Databricks al suo interno e considera gli agenti come cittadini di prima classe.

Difficoltà di crescita su scala

Poco più di tre anni fa, il team di field engineering contava meno di 1.500 persone. Un piccolo numero di workspace condivisi copriva la maggior parte dei casi d'uso e la manutenzione manuale manteneva le cose in funzione discretamente bene. Ma Databricks è cresciuta rapidamente. Il team GTM conta ora oltre 7.000 persone, di cui il field engineering costituisce una parte significativa. Un'infrastruttura che funzionava per una determinata dimensione richiede un design diverso per un'altra.

I workspace di Databricks sono ottimizzati per un numero limitato di amministratori che gestiscono molti utenti, il che ha senso per la maggior parte delle distribuzioni aziendali. Il field engineering ha tuttavia requisiti diversi: quasi tutti hanno bisogno di un accesso a livello di amministratore per svolgere effettivamente il proprio lavoro. La configurazione di ambienti demo, il test di funzionalità in anteprima, l'esecuzione di scenari specifici per il cliente: tutto ciò richiede il tipo di controllo fornito dall'accesso amministratore.

Su scala, il coordinamento del lavoro tra workspace condivisi crea una reale complessità operativa. Più ingegneri che lavorano nello stesso ambiente durante un momento cruciale di una demo possono interferire con il lavoro degli altri, e i limiti della piattaforma (ad esempio su cataloghi, istanze Lakebase e carichi di lavoro simultanei) diventano una preoccupazione attiva anziché di secondo piano. L'attribuzione dei costi diventa più difficile da tracciare con l'aumentare dell'utilizzo e la proprietà diventa meno chiara.

Anche il problema dell'osservabilità ha aggravato queste sfide. Quando accadeva qualcosa di imprevisto in un workspace condiviso, tracciare cosa fosse accaduto, quando e perché richiedeva un'indagine manuale. Avevamo bisogno di un modello che rendesse ogni azione di provisioning trasparente, verificabile e attribuibile fin dall'inizio.

L'intuizione che ha dato forma a FEVM è stata semplice: e se ogni ingegnere potesse avere il proprio ambiente isolato, fornito in pochi minuti, governato centralmente e ripulito automaticamente?

Costruire su Databricks, per Databricks

Quando Databricks Apps è diventato disponibile, l'opportunità è stata chiara. Avevamo gestito gli ambienti attraverso una serie di singoli job: un job per ogni attività, eseguiti separatamente e sempre leggermente in ritardo rispetto alla realtà. Le app ci hanno offerto un modo per astrarre tutto questo dietro un'unica interfaccia: dicci cosa stai cercando di fare in un linguaggio semplice e noi capiremo quale infrastruttura predisporre.

Questo è diventato il principio di progettazione fondamentale per FEVM: il provisioning basato sui casi d'uso. Non richiedi "un workspace". Descrivi cosa stai cercando di fare, che si tratti di creare una demo per un cliente di servizi finanziari, riprodurre un problema di supporto o gestire una sessione di hackathon, e ottieni un ambiente configurato per tale scopo. Tutto questo è astratto con un MCP al suo interno, il che significa che chat, servizi esterni e agenti sono tutti gestiti da un unico punto di controllo; con la diffusione di strumenti come Claude, ciò significa che l'aggiunta di un semplice file di skill .md consente di richiedere un nuovo ambiente sulla riga di comando in un linguaggio semplice e di accedere pochi minuti dopo. I flussi di lavoro più complessi diventano altrettanto banali dal punto di vista dell'utente.

L'app è basata su un frontend React con un backend Python, distribuita tramite Databricks Apps. Terraform viene eseguito in background per gestire il provisioning effettivo delle risorse cloud su AWS, Azure e GCP. Un database di stato e configurazione, eseguito su Lakebase, tiene traccia di ogni risorsa: cos'è, a chi appartiene, a cosa serve, quando scade.

L'esperienza di sviluppo di Databricks Apps in sé è stata semplice. Il lavoro più complesso è stato l'integrazione nel più ampio ecosistema: configurare l'avvio di flussi di lavoro basati su Git, gestire l'identità tra i sistemi aziendali e garantire che l'automazione delle azioni amministrative sull'infrastruttura di backend reale rimanesse entro i nostri confini di sicurezza. Operiamo in base a una serie di eccezioni di sicurezza proprio per questo motivo e abbiamo progettato intenzionalmente ogni fase all'insegna di una gestione responsabile; i nuovi modelli vengono esaminati, protetti e testati ripetutamente per garantire che non espongano nuovi vettori di minaccia.

Cosa fa l'app

Quando un ingegnere sul campo apre FEVM, viene accolto da un'interfaccia di ricerca. Può sfogliare un catalogo di modelli per trovare il tipo di ambiente corretto (ad esempio, serverless stabile su AWS, una configurazione multi-cloud o un ambiente con scalabilità automatica Lakebase preconfigurata) e configurarlo da lì. Sceglie un provider cloud e una regione, descrive cosa sta creando, gli assegna un nome (o ne accetta uno casuale) e avvia la distribuzione.

Più di recente, abbiamo abilitato flussi di lavoro incentrati sugli agenti che consentono agli utenti di sfruttare le skill di Claude pubblicate centralmente; si tratta di un'opzione sempre più diffusa che consente agli agenti di automatizzare l'interfaccia utente e passare direttamente alle API FEVM sottostanti. Questo diventa particolarmente potente nei flussi di lavoro multifase e multistumento; ad esempio, un utente potrebbe dire al proprio agente di avviare un nuovo workspace, distribuire diversi DAB sviluppati localmente, caricare alcuni dati presenti in S3 e quindi eseguire uno script di popolamento per riempire una dashboard. Questo tipo di configurazione iper-personalizzata non sarebbe possibile senza un solido framework di agenti, e Databricks Apps rende tutto questo banale.

Quando un utente o un agente richiede una nuova risorsa, dietro le quinte l'app recupera il modello Terraform appropriato, lo invia a un Git Runner, regola le autorizzazioni e quindi aggiunge eventuali "componenti aggiuntivi" richiesti dall'utente, come Lakebase, notebook o asset preconfezionati ospitati in un volume UC. Gli ambienti di sviluppo durano per impostazione predefinita 90 giorni, con opzioni di estensione disponibili, mentre altri tipi di risorse hanno un TTL configurabile.

Al termine del provisioning, arriva una notifica su Slack. Quando la risorsa si avvicina alla scadenza, viene inviata un'altra notifica. Quando viene eliminata, ricevi un'ulteriore notifica. La trasparenza è stata un obiettivo di progettazione fondamentale fin dal primo giorno: ogni evento del ciclo di vita è visibile e gli ingegneri conoscono sempre lo stato delle proprie risorse.

Gestiamo anche le risorse condivise tramite la stessa interfaccia. I cataloghi autonomi, ad esempio, hanno cicli di vita indipendenti dai workspace a cui sono associati. Se elimini un workspace, il catalogo persiste; se avvii un nuovo workspace nella stessa regione, il catalogo si ricollega automaticamente. Questo tipo di gestione del ciclo di vita a livello di risorsa è importante perché sia Unity Catalog che Lakebase hanno limiti di piattaforma rigidi e, con centinaia di ingegneri che eseguono attivamente il provisioning delle risorse, il controllo centralizzato è ciò che impedisce a tali limiti di diventare un ostacolo.

Un livello amministrativo all'interno dell'app consente al nostro team di gestire la configurazione globale (regolando i limiti dei workspace per cloud, verificando le distribuzioni attive, ottimizzando i valori predefiniti) direttamente dalla UI.

Una scalabilità che non ci aspettavamo di dimostrare così rapidamente

Durante il BuildCon, uno dei nostri eventi interni di ingegneria, FEVM ha gestito quasi 1.200 richieste di provisioning in un solo giorno. Gli ingegneri di tutta l'organizzazione hanno avviato ambienti, svolto il proprio lavoro e li hanno lasciati scadere, senza sovraccarichi di coordinamento o conflitti di risorse. Ad oggi non abbiamo riscontrato alcun problema di scalabilità, anche con oltre 5.000 utenti attivi; al momento della stesura di questo articolo, stiamo gestendo oltre 2.600 distribuzioni attive su 3 cloud!

Questo numero è importante per noi non solo come stress test, ma come proof of concept. L'ipotesi alla base di FEVM era che il provisioning isolato e just-in-time potesse sostituire l'attrito degli ambienti condivisi su scala. Un numero di chiamate in un solo giorno come questo conferma che la domanda c'è sempre stata e che gli ingegneri avevano solo bisogno di uno strumento che rendesse tutto privo di attriti.

Il futuro basato su agenti verso cui ci stiamo orientando

La visione più ampia a cui ci stiamo avvicinando in Databricks è un'organizzazione di field engineering incentrata sugli agenti: un ingegnere descrive la situazione di un cliente in un linguaggio semplice, un agente avvia un ambiente configurato in modo appropriato, recupera il contesto dell'account pertinente, tenta di riprodurre il problema o creare la demo e restituisce un riepilogo pronto da presentare al cliente. FEVM è il livello infrastrutturale che rende possibile tutto questo.

Abbiamo riprogettato l'architettura dell'app due vezes per arrivare a questo punto: riprogettando lo schema del database, ricostruendo il frontend, ripensando a come gestiamo lo stato. Abbiamo utilizzato l'AI per accelerare la scrittura del codice, ma abbiamo mantenuto il controllo completo sull'architettura in ogni fase. Il risultato è un sistema che riteniamo affidabile per l'esecuzione su scala.

Cosa abbiamo imparato

Alcuni principi che hanno plasmato questa build:

• Sviluppa pensando all'utente, che si tratti di un essere umano o di un agente. Abbiamo lavorato sodo per partire da un CUJ e progettare funzionalità che rispondessero a quel percorso: questo ci aiuta a rimanere obiettivi su ciò che deve essere effettivamente fatto e su cosa sia solo un pregiudizio interno.
• La trasparenza è una funzionalità, non un aspetto secondario. Rendere visibile ogni evento del ciclo di vita — provisioning, scadenza, eliminazione — è ciò che crea fiducia nei confronti degli ingegneri che dipendono dallo strumento per il lavoro reale con i clienti.
• L'integrazione dell'ecosistema è un lavoro impegnativo. L'esperienza di sviluppo di Databricks Apps è stata rapida e lineare, ma collegare FEVM a Git, Slack, e-mail, identità aziendale e Terraform multi-cloud è stato l'aspetto che ha richiesto il maggior sforzo ingegneristico e da cui è derivato il valore principale.

Sviluppa per Databricks su Databricks. Quasi tutto in FEVM viene eseguito sulla piattaforma stessa. Questo ci offre una comprensione diretta di ciò che funziona su scala e ci mantiene vicini all'esperienza del prodotto che vendiamo.

I prossimi passi

Ci stiamo concentrando su tre aspetti: espandere l'interfaccia di provisioning in linguaggio naturale, rilasciare l'integrazione MCP per l'accesso basato su strumenti e scalare il supporto in tutta l'organizzazione GTM. Man mano che gli agenti si faranno carico di una parte maggiore del lavoro attualmente svolto dai field engineer, FEVM diventerà il livello di risorse su cui operano tali agenti: non solo uno strumento di provisioning, ma un'infrastruttura fondamentale per un workflow agentico.

Guarda la sessione di approfondimento del Data and AI Summit 2026 Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine per ulteriori dettagli sulla FE Vending Machine.

Per saperne di più sulla creazione di app di livello di produzione su Databricks, consulta Databricks Apps, Lakebase e Agent Bricks.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale