Kris Beevers, CEO e Co-Fondatore, Netbox Labs – Serie di Interviste

Kris Beevers, CEO e Co-Fondatore di NetBox Labs è un imprenditore tecnologico e veterano del software di infrastruttura con oltre due decenni di esperienza nella creazione di aziende e piattaforme focalizzate su networking, infrastruttura cloud e automazione. Prima di guidare NetBox Labs, Beevers ha co-fondato NS1 nel 2013 e ne è stato CEO per quasi un decennio, trasformando l’azienda in un fornitore di spicco di tecnologie di automazione di rete e gestione del traffico applicativo prima della sua acquisizione da parte di IBM nel 2023. Come parte di quella transazione, NetBox Labs è stata scorporata da NS1 come società indipendente con IBM come investitore. All’inizio della sua carriera, Beevers ha ricoperto ruoli senior di ingegneria e architettura presso Internap Network Services e Voxel, ed ha anche co-fondato SolidJoint Research.

NetBox Labs sviluppa una piattaforma di intelligenza infrastrutturale progettata per aiutare le organizzazioni a modellare, operare, automatizzare e governare reti e infrastrutture IT sempre più complesse. L’azienda è il gestore commerciale di NetBox, il sistema di registrazione di rete e infrastruttura open source ampiamente adottato da più di 10.000 organizzazioni. La sua piattaforma combina un grafo infrastrutturale e una fonte di verità con intelligenza operativa, automazione, orchestrazione assistita dall’IA e capacità di governance che consentono sia agli ingegneri sia agli agenti IA di interagire in modo sicuro con l’infrastruttura. NetBox Labs supporta implementazioni cloud, enterprise auto-gestite, ibride e isolate (air-gapped), integrandosi con strumenti come Ansible, Terraform, Nornir e pipeline di integrazione e distribuzione continue.

Hai co-fondato NS1 nel 2013 e hai trascorso quasi un decennio a costruire l’azienda prima della sua acquisizione da parte di IBM, dopo la quale NetBox Labs è emersa come società indipendente. Quali lezioni apprese dalla costruzione di NS1 hanno influenzato la decisione di fondare NetBox Labs, e in che modo il problema infrastrutturale che stai cercando di risolvere è cambiato nell’era dell’IA?

Una cosa che ho imparato costruendo NS1 è che i problemi di infrastruttura raramente rimangono ben contenuti. Il DNS era la nostra parte dello stack, ma i nostri clienti gestivano ambienti incredibilmente complessi in cui reti, data center, applicazioni e automazione dipendevano tutti l’uno dall’altro. Più tempo trascorrevo con quei team, più diventava chiaro che comprendere l’infrastruttura stessa era un problema molto più grande.

Questa è stata una parte importante di ciò che mi ha attratto verso NetBox. Esisteva già questo progetto open source ampiamente adottato e una comunità di ingegneri che lo usava per modellare ciò che possedevano, come era collegato e come doveva apparire. Abbiamo visto un’opportunità per costruire su quella base.

Ciò che è cambiato con l’IA riguarda principalmente il ritmo e la scala. Ai team di infrastruttura viene chiesto di costruire ambienti enormi in modo incredibilmente rapido, mentre la tecnologia sottostante sta cambiando altrettanto velocemente. Allo stesso tempo, stiamo iniziando ad automatizzare una parte sempre maggiore del funzionamento di quell’infrastruttura, il che rappresenta un futuro entusiasmante. Quando l’IA viene applicata all’infrastruttura, i team IT si rendono conto di dover disporre di dati accurati e in tempo reale sulla loro infrastruttura per poter automatizzare, e hanno bisogno di conoscere lo stato desiderato affinché l’IA possa aiutarli a identificare quando l’infrastruttura operativa devia dal piano.

Quindi la lezione di NS1 è ancora valida. Prima di poter automatizzare bene l’infrastruttura, è necessario comprenderla. L’IA rende semplicemente il fare ciò in modo corretto molto più urgente.

Per gran parte dell’ultimo decennio, il cloud computing ha permesso a sviluppatori e team di infrastruttura di astrarre l’hardware fisico sottostante le loro applicazioni. Perché l’IA sta invertendo questa tendenza e costringe DevOps, Site Reliability Engineering (SRE) e ingegneri di rete a pensare nuovamente a potenza, raffreddamento, rack, cablaggio e networking fisico?

Il cloud ha insegnato a molti di noi a trattare l’infrastruttura come praticamente infinita. Hai richiesto capacità di calcolo e questa è apparsa. Non dovevi necessariamente preoccuparti di dove si trovasse il server, come fosse alimentato, come fosse raffreddato o di come tutti i componenti fisici sottostanti fossero assemblati.

L’infrastruttura IA non ti consente davvero di fare ciò.

Quando costruisci questi ambienti, inizi con alcune domande molto concrete. Quanta terra ho a disposizione? Quanta potenza posso ottenere? Che tipo di raffreddamento posso supportare? Da lì si passa ai rack, ai server GPU, agli switch, al cablaggio in fibra ottica e, infine, al livello logico, indirizzi IP, configurazioni e software.

Tutte queste cose dipendono l’una dall’altra. Non puoi decidere quanti rack distribuire senza comprendere la densità di potenza e raffreddamento. Non puoi considerare le GPU indipendentemente dalla rete che le collega.

Ciò costringe le discipline che hanno trascorso anni a distanziarsi dallo strato fisico a interagire nuovamente con esso. L’astrazione non è scomparsa, ma le limitazioni fisiche sottostanti diventano improvvisamente molto più rilevanti.

I data center IA vengono sempre più discussi su scala gigawatt. Cosa cambia fondamentalmente a livello operativo quando l’infrastruttura passa da ambienti enterprise o cloud convenzionali a strutture progettate attorno a enormi cluster di GPU?

La scala gigawatt è assolutamente astronomica. Ma sebbene la scala sia ovviamente diversa, penso che la differenza più interessante sia la quantità di coordinamento richiesto.

Pensate a cosa deve accadere per mettere in funzione un data center da 300 megawatt. Serve terreno e energia. Poi bisogna progettare la struttura e approvvigionare rack, server GPU, switch, fibra, infrastruttura elettrica e apparecchiature di raffreddamento, spesso da fornitori completamente diversi con modalità di rappresentazione dei loro prodotti altrettanto diverse. Tutta quella attrezzatura deve arrivare, essere ricevuta, installata nei rack, cablata, configurata, testata e, infine, consegnata per l’addestramento o l’inferenza.

E il terreno si muove sotto i vostri piedi mentre lo fate. Le architetture GPU stanno cambiando. Anche le reti stanno cambiando. I requisiti di raffreddamento stanno cambiando. I componenti disponibili tra sei mesi potrebbero non essere gli stessi di quelli su cui avete progettato oggi.

Quindi le piccole inefficienze si accumulano molto rapidamente. Recentemente ho trascorso del tempo con uno dei più grandi produttori mondiali di cavi in fibra ottica, e mi hanno detto che uno dei loro maggiori problemi di business sono i resi, perché i clienti ordinano lunghezze di cavo sbagliate. Sembra quasi banale finché non si ordinano centinaia di migliaia di cavi.

A questa scala, le operazioni di infrastruttura diventano un enorme problema di logistica e di soddisfacimento dei vincoli. Le aziende che lo fanno bene sono quelle che riescono a mantenere dati di progettazione accurati lungo tutto il percorso, dalla fase di approvvigionamento, al deployment e alle operazioni.

Hai affermato che, di fatto, non esiste un playbook consolidato né un canale di talenti per gestire infrastrutture a questa scala. Quali competenze sono attualmente più difficili da trovare e dove prevedi che emergeranno le più grandi carenze di talenti con l’espansione dell’infrastruttura AI?

Probabilmente ci sono solo poche centinaia di persone al mondo in questo momento che sanno davvero come costruire questo tipo di infrastruttura a questa velocità e scala. E la maggior parte di loro è piuttosto occupata a farlo concretamente.

Questo è parte di ciò che rende questo momento insolito. Non esiste un corpus di conoscenze maturo che si possa semplicemente studiare. Le persone che lo fanno stanno imparando gli uni dagli altri e risolvendo i problemi in tempo reale. E poiché la tecnologia cambia così rapidamente, alcune di queste lezioni diventano obsolete piuttosto in fretta.

Ritengo che la carenza sia quindi più ampia di qualsiasi singolo titolo professionale. Abbiamo bisogno di persone che comprendano networking, calcolo e automazione, ma sempre più anche l’ambiente fisico in cui questi sistemi operano. Energia, raffreddamento, progettazione delle strutture, catena di approvvigionamento e operazioni sul campo stanno diventando parte della stessa discussione.

Le persone che riescono a superare alcune di queste barriere saranno incredibilmente preziose. Tuttavia, non credo che ci siamo ancora decisi su come saranno tutti questi ruoli. Il modello di talento si sta costruendo parallelamente all’infrastruttura.

Man mano che i confini tra software, networking, strutture, energia e ingegneria dei data center iniziano a sfumarsi, quali nuovi ruoli tecnici o competenze ibride ti aspetti che emergano?

Non credo che sappiamo ancora come saranno tutti questi ruoli. Quello che sappiamo è che le persone che costruiscono questa infrastruttura devono considerare un insieme di problemi molto più ampio rispetto al passato.

Non si tratta solo di pensare al calcolo o al networking in isolamento. Energia, raffreddamento, progettazione fisica, catena di approvvigionamento, networking e automazione devono tutti convergere per mettere online questi ambienti e mantenerli operativi.

Continuo a credere che avremo bisogno di persone con una profonda esperienza in ciascuna di queste aree. Ma sempre più spesso dovranno anche comprendere come le decisioni nella loro zona influenzino il resto dell’infrastruttura. E poiché gran parte di questo lavoro deve avvenire più rapidamente, la capacità di automatizzare sarà rilevante in un numero maggiore di discipline.

Gli agenti AI stanno iniziando a diagnosticare problemi, generare configurazioni e automatizzare parti delle operazioni di infrastruttura. Quali responsabilità pensi che l’AI prenderà realisticamente in carico dagli ingegneri di infrastruttura, e quali diventeranno ancora più dipendenti da una profonda competenza umana?

Ritengo che gran parte del lavoro in cui gli input, il risultato desiderato e i limiti sono chiari sarà sempre più gestito dall’AI. Generare configurazioni è un esempio ovvio. Lo stesso vale per diagnosticare problemi comuni, verificare se l’infrastruttura corrisponde al progetto previsto, o eventualmente risolvere determinati problemi quando si ha sufficiente fiducia su cosa sia andato storto e quale sia la risposta sicura.

Gli esseri umani diventano più importanti quando la risposta non è ovvia.

L’infrastruttura può guastarsi in modi strani. Una fibra si rompe. Un dispositivo inizia a comportarsi diversamente da quanto previsto dal progetto. Una modifica ha un effetto inatteso altrove nell’ambiente. L’AI può aiutare un ingegnere a comprendere queste situazioni molto più rapidamente, ma è comunque necessario personale che conosca il sistema a fondo per decidere cosa fare successivamente.

Credo che questo sia il cambiamento interessante. Gli ingegneri probabilmente trascorreranno meno tempo in configurazioni e risoluzioni di problemi ripetitivi e più tempo a definire l’intento, progettare i sistemi, stabilire i limiti per l’automazione e gestire i problemi realmente nuovi. Tutto questo lavoro sarà potenziato dall’AI, ma guidato dalle persone.

Ciò rende l’expertise più preziosa, non meno. L’ingegnere che comprende davvero perché l’infrastruttura funziona come funziona sarà incredibilmente importante quando l’automazione non avrà una risposta ovvia.

NetBox Labs ha sostenuto che i sistemi di IA che gestiscono l’infrastruttura hanno bisogno di un modello autorevole di dispositivi, connessioni, dipendenze e altre relazioni fisiche e logiche. Perché questo tipo di contesto infrastrutturale è così importante quando si passa da assistenti IA che forniscono raccomandazioni ad agenti che possono effettivamente compiere azioni?

La grande differenza è che, una volta che un agente può agire, sbagliare ha conseguenze reali.

Un agente dell’infrastruttura ha bisogno di più di un’istantanea di ciò che un dispositivo sta facendo in questo momento. Deve comprendere l’ambiente circostante: cosa esiste, come le cose sono collegate, cosa è cambiato di recente e, soprattutto, come dovrebbe apparire l’infrastruttura.

Prendiamo, ad esempio, la risoluzione di un problema di connettività. Non basta sapere che un dispositivo è irraggiungibile. Si desidera che l’agente sia in grado di tracciare il percorso del cavo, comprendere le dipendenze intorno a quel dispositivo, esaminare le modifiche recenti e determinare cosa altro potrebbe essere influenzato prima di proporre cosa fare successivamente.

È davvero questa la base su cui abbiamo lavorato per anni in NetBox Labs, fornendo ai team un modello accurato sia dell’infrastruttura fisica sia di quella logica, insieme all’intento su come dovrebbe funzionare.

Ma i dati da soli non bastano. È necessario anche decidere cosa l’agente può fare autonomamente, cosa richiede l’approvazione di una persona e come ogni azione venga tracciata e convalidata.

L’infrastruttura non è come il codice, dove una modifica errata può sempre essere annullata pulitamente. Una modifica errata può interrompere un’operazione. Quindi, man mano che passiamo da IA che indica a un ingegnere ciò che pensa a IA che può effettivamente svolgere il lavoro, sia il contesto sia il controllo diventano molto più importanti.

Nel tuo articolo recente del CIO, “Perché io, CEO, sto personalmente costruendo la nostra strategia IA”, hai sostenuto che l’IA è troppo importante perché i leader aziendali la delegano semplicemente e hai descritto il prototipare personalmente con strumenti IA. Come ha cambiato il tuo approccio pratico a questi sistemi il modo in cui pensi a ciò che l’IA può realisticamente automatizzare nelle operazioni di infrastruttura?

Essere pratici ti rende molto meno interessato alla discussione teorica.

Ho trascorso molto tempo a costruire realmente con questi strumenti, più spesso al giorno d’oggi prototipando o addirittura creando prodotti completi con Claude Code. Si apprende rapidamente che c’è una enorme differenza tra vedere una demo impressionante e costruire qualcosa di cui ti fidi davvero per svolgere un lavoro utile.

Si sviluppa anche una sensazione di dove la tecnologia si sta muovendo molto più velocemente di quanto si possa capire leggendo a riguardo. Le cose che consideravo difficili da automatizzare sei mesi fa possono improvvisamente diventare piuttosto semplici. Allo stesso tempo, si vede molto chiaramente dove mancano ancora contesto, giudizio e struttura.

Questo ha influenzato il mio modo di pensare alle operazioni di infrastruttura. Sono molto ottimista su quanto lavoro operativo possiamo automatizzare, ma credo che siamo ancora lontani da una pura autonomia come obiettivo finale.

La domanda che mi interessa è molto più basilare. Questo ci aiuta a gestire l’infrastruttura più velocemente, più affidabilmente o più efficacemente? Se sì, ottimo. Se no, non importa quanto sia sofisticata l’IA che la sostiene.

Man mano che i data center IA diventano sempre più limitati dalla disponibilità di elettricità e dai requisiti di raffreddamento, l’ingegneria dell’infrastruttura potrebbe evolversi dal gestire principalmente le risorse di calcolo al coordinare attivamente i carichi di lavoro con l’energia e la capacità fisica?

Sì, e lo stiamo già vedendo. Abbiamo una frase interna, “turbine nel parcheggio”, che è nata da una vera conversazione con uno dei team che costruiscono infrastrutture IA su scala iper. Stavano mettendo in funzione l’infrastruttura così rapidamente che la rete elettrica non riusciva a tenere il passo, così hanno letteralmente comprato turbine e le hanno messe nel parcheggio per ottenere energia sufficientemente veloce.

Questo è il tipo di ambiente in cui operano questi team. Quando l’energia diventa una delle tue principali limitazioni, devi diventare molto più intelligente su come utilizzi ciò che è disponibile. La risposta alla domanda, dove gli operatori coordinano attivamente i carichi di lavoro IA in reazione ai cambiamenti della rete elettrica, sta già avvenendo ed è una capacità sempre più importante per i team che gestiscono infrastrutture ad alto consumo energetico.

Non tutti i carichi di lavoro hanno gli stessi requisiti. L’inferenza sensibile alla latenza potrebbe dover rimanere online, mentre alcuni carichi di addestramento o batch possono essere spostati o messi in pausa quando l’energia è limitata. Credo che vedremo sempre più i team di infrastruttura gestire calcolo, energia e capacità fisica come parti dello stesso problema operativo.

Guardando al futuro, pensi che il collo di bottiglia più grande per scalare l’IA sarà alla fine le GPU e lo sviluppo dei modelli, o la sfida molto più ampia di trovare energia sufficiente, infrastruttura fisica, capacità di rete, automazione e ingegneri qualificati per gestire tutto ciò che sta dietro?

Non credo che ci sarà un unico collo di bottiglia.

Costruire l’infrastruttura IA alla velocità e scala richieste dal mercato attuale è fondamentalmente un problema di soddisfazione dei vincoli. In ogni momento, qualcosa è il vincolo principale.

Per un po’ tutti parlavano di GPU. La potenza è ovviamente un enorme collo di bottiglia al momento. Ma può anche trattarsi di apparecchiature di rete, raffreddamento, terreni, fibra, approvvigionamento, costruzione o semplicemente di trovare abbastanza persone che sappiano come assemblare il tutto.

E una volta risolto un vincolo, ne appare un altro più evidente. È quello che succede quando la domanda è molto più alta dell’offerta.

Quindi non scommetterei su un unico collo di bottiglia permanente. Credo che la capacità più importante sia sapersi adattare man mano che il vincolo si sposta.

È anche per questo che non credo che esista al momento un manuale definitivo per l’infrastruttura AI. Le persone che la stanno costruendo stanno scoprendo tutto mentre scalano, e lo fanno entrambi in modo incredibilmente rapido.

Grazie per la splendida intervista, i lettori che desiderano saperne di più dovrebbero visitare NetBox Labs.