Come lo sviluppo di software agentivo cambierà i database

Nel nostro precedente post, abbiamo introdotto Lakebase, l'architettura di database di terza generazione che separa fondamentalmente storage e compute. In questo post, esploriamo una conseguenza critica di questo cambiamento: come gli agenti AI stanno cambiando il ciclo di vita dello sviluppo software e di quali tipi di database hanno realmente bisogno gli agenti AI?

Il ciclo di vita dello sviluppo software sta subendo una trasformazione radicale. Gli LLM hanno abilitato una nuova generazione di framework agentici in grado di analizzare requisiti, scrivere codice, eseguire test, distribuire servizi e perfezionare iterativamente le applicazioni, tutto a una velocità record. Di conseguenza, il costo marginale di creazione e distribuzione di applicazioni sta crollando.

Anche se siamo ancora nelle prime fasi dello sviluppo software agentico, abbiamo osservato costantemente, sia all'interno di Databricks che tra la nostra base di clienti, che il tasso di sperimentazione sta accelerando e il volume di applicazioni in fase di sviluppo sta esplodendo. Mentre il mondo transita dal software creato manualmente allo sviluppo software agentico, identifichiamo tre tendenze emergenti che ridefiniranno congiuntamente i requisiti dei moderni sistemi di database:

1. Lo sviluppo software passerà da un processo convenzionale, lento e lineare, a un processo evolutivo rapido.
2. Il software diventerà complessivamente più prezioso, ma il valore di ogni singola applicazione diminuirà drasticamente poiché il costo marginale per sviluppare software si riduce. Ciò significa che abbiamo bisogno di un'infrastruttura in grado di supportare lo sviluppo software a costi marginali minimi. Fondamentalmente, l'architettura deve anche tenere conto del fatto che uno qualsiasi di questi database piccoli ed effimeri può diventare un sistema di produzione con molto traffico, rendendo la capacità di supportare una crescita fluida ed elastica un requisito architetturale fondamentale.
3. Gli ecosistemi aperti diventeranno un requisito operativo rigoroso, non solo una preferenza.

Ecco un'analisi più approfondita di ciascuna di queste tendenze e di come Lakebase è architettato in modo univoco per supportarle.

Sviluppo Software Evolutivo Rapido

Poiché gran parte del ciclo di vita dello sviluppo software era storicamente molto costosa (scrittura di codice, test, operazioni), la creazione e la gestione di una nuova applicazione richiedevano un significativo investimento di ingegneria. Di conseguenza, lo sviluppo software tradizionale era ottimizzato per una pianificazione attenta e un processo relativamente lineare.

Gli agenti cambiano questa dinamica. Le applicazioni possono ora essere generate, modificate e ridistribuite in pochi minuti. Invece di costruire un unico sistema attentamente progettato, sviluppatori e agenti esplorano sempre più ampi spazi di implementazioni possibili. Lo sviluppo inizia ad assomigliare a un algoritmo evolutivo:

1. Genera una versione iniziale di un'applicazione.
2. Crea rapidamente varianti con schemi, prompt o logica diversi.
3. Valuta i risultati.
4. Continua lo sviluppo dalle versioni di maggior successo.

A seconda della complessità, ogni iterazione evolutiva può durare da secondi a ore, il che è da 100 a 1000 volte più veloce dei cicli di sviluppo pre-LLM. Infatti, la nostra telemetria dagli ambienti di produzione di Lakebase mostra che, in media, ogni progetto di database ha circa 10 branch e alcuni database con branch nidificati raggiungono profondità superiori a 500 iterazioni (cioè, 500 iterazioni nell'evoluzione).

Infrastrutture di codice come Git supportano già molto bene questo flusso di lavoro. Sviluppatori o agenti possono creare un branch del codebase con git checkout -b istantaneamente. Tuttavia, l'infrastruttura di database legacy non offre un modo rapido ed economico per creare un branch dello stato del database.

Lakebase è progettato per supportare nativamente questo flusso di lavoro evolutivo agentico. Gli agenti possono creare un branch di un database di produzione o di test istantaneamente e a costo quasi zero. Poiché Lakebase utilizza un meccanismo di branching copy-on-write di metadati O(1) a livello di storage, non è necessaria alcuna costosa copia fisica dei dati. Si crea semplicemente un branch dei dati insieme al codice e si paga solo per il compute del database per la durata dell'esperimento.

Sensibilità ai Costi

Come accennato in precedenza, sebbene il software diventerà complessivamente più prezioso, il valore di ogni singola applicazione diminuirà drasticamente poiché il costo marginale per sviluppare software si riduce. Molti servizi generati da agenti sono piccoli strumenti interni, prototipi o flussi di lavoro limitati. Possono essere eseguiti solo occasionalmente o servire carichi di lavoro altamente variabili ed event-driven.

In questo scenario, abbiamo bisogno di un'infrastruttura in grado di supportare il nuovo sviluppo software a costi marginali/incrementali minimi. Qualsiasi database che imponga un prezzo base di centinaia di dollari al mese è impossibile da giustificare se l'applicazione stessa fornisce un valore limitato o sperimentale. I nostri dati mostrano che per circa la metà di queste applicazioni agentiche, la durata del compute del database è inferiore a 10 secondi.

I database tradizionali sono stati progettati come componenti infrastrutturali sempre attivi con overhead di provisioning e operativi fissi. Questo modello si adatta ad applicazioni grandi e stabili, ma fallisce economicamente quando le applicazioni sono numerose, effimere e di breve durata.

La natura serverless ed elastica di Lakebase affronta direttamente questo imperativo di costo. Disaccoppiando completamente le istanze di compute dal livello di storage, Lakebase può scalare automaticamente il compute del database in base al carico in tempi inferiori al secondo. Fondamentalmente, scala anche il database a zero quando non è utilizzato, eliminando completamente il floor dei costi e raggiungendo costi di inattività quasi nulli.

Crescere da Piccolo a Grande

La natura dello sviluppo guidato da agenti implica che un enorme volume di database piccoli ed effimeri viene costantemente creato per test, prototipazione e flussi di lavoro limitati. La sfida architetturale cruciale è che gli sviluppatori, e gli agenti stessi, non possono prevedere quali di queste applicazioni nascenti decolleranno improvvisamente e richiederanno una scala di produzione massiccia.

L'architettura del database deve quindi supportare intrinsecamente una crescita fluida ed elastica da un'istanza minuscola e a basso costo a un sistema di produzione completo con traffico intenso. Questa transizione deve avvenire senza richiedere alcun re-platforming manuale, provisioning o complessi passaggi di migrazione da parte dell'utente. L'architettura da sola dovrebbe gestire l'evoluzione, rendendo la capacità di scalare istantaneamente da quasi zero a capacità massiccia un requisito fondamentale per un mondo in cui l'esplorazione agentica è il modello di sviluppo predefinito.

Ecosistemi Open Source

I sistemi agentici derivano le loro capacità dagli LLM addestrati su estesi corpora di codice sorgente e documentazione tecnica disponibili pubblicamente. Questo bias di addestramento conferisce loro una profonda familiarità operativa con ecosistemi, API e semantiche di errore open source.

Database come Postgres sono profondamente integrati nel mondo open source. Le loro interfacce, comportamenti e codici di errore appaiono nei dati di addestramento da cui i modelli moderni imparano. Di conseguenza, gli agenti possono generare query, schemi e integrazioni per essi in modo molto più affidabile. I database proprietari affrontano uno svantaggio intrinseco perché gli agenti semplicemente non hanno un contesto sufficiente per utilizzarli efficacemente.

Per lo sviluppo guidato da agenti, l'apertura non è più solo una preferenza filosofica, ma un requisito pratico per un'automazione affidabile. Ma questo requisito deve estendersi oltre la semplice interfaccia di query; deve raggiungere il livello di storage stesso. Mentre i database cloud di seconda generazione potrebbero utilizzare motori di esecuzione open source, bloccano ancora i tuoi dati in formati di storage proprietari e interni.

Lakebase è costruito su Postgres, ma porta l'apertura un passo avanti. Memorizza i dati in formati di pagina Postgres standard e aperti direttamente nello storage a oggetti cloud (il data lake). Ciò consente agli agenti, ai motori analitici esterni e ai nuovi strumenti di interagire nativamente con i dati, senza mai essere limitati da un singolo motore di compute proprietario.

Database per l'Era Agentica

Il cambiamento non è ipotetico, è già in atto. Nel servizio Lakebase di Databricks, gli agenti AI creano ora circa 4 volte più database degli utenti umani.

Questo punto dati cattura i trend descritti sopra in un unico grafico. Gli agenti sono creatori prolifici di ambienti di database, creando istanze per esperimenti, ramificandosi per test e scartandole quando hanno finito. L'infrastruttura che serve questi carichi di lavoro deve supportare questo schema in modo economico e operativo.

Proprietà come l'efficienza dei costi, l'agilità e l'apertura sono sempre state desiderabili. Ma l'ascesa dello sviluppo di software agentivo le ha trasformate da caratteristiche desiderabili a requisiti fondamentali. I database che impongono alti costi minimi, mancano di primitive di branching o bloccano i dati in formati proprietari cadranno sempre più in disaccordo con il modo in cui il software viene creato.

Questo è precisamente lo spazio di progettazione di Lakebase. È stato costruito per le specifiche realtà economiche e tecniche che lo sviluppo guidato dall'IA crea: branching evolutivo a costo zero, vera elasticità scale-to-zero, archiviazione Postgres aperta sul lake e operazioni di auto-gestione. Poiché gli agenti partecipano sempre più alla creazione e all'evoluzione del software, i database più adatti a questo nuovo mondo sono quelli progettati fin dall'inizio per la sperimentazione, l'apertura e l'elasticità.

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