Kris Beevers, CEO și co-fondator, Netbox Labs – Seria de interviuri

Kris Beevers, CEO și co-fondator la NetBox Labs, este un antreprenor în tehnologie și veteran al software-ului de infrastructură, cu peste două decenii de experiență în construirea de companii și platforme axate pe rețelistică, infrastructură cloud și automatizare. Înainte de a conduce NetBox Labs, Beevers a co-fondat NS1 în 2013 și a fost CEO-ul său timp de aproape un deceniu, transformând compania într-un furnizor important de tehnologie de automatizare a rețelelor și gestionare a traficului aplicațiilor, înainte de achiziționarea de către IBM în 2023. Ca parte a acelei tranzacții, NetBox Labs s-a desprins din NS1 ca o companie independentă, cu IBM ca investitor. În perioada timpurie a carierei sale, Beevers a deținut funcții senior de inginerie și arhitectură la Internap Network Services și Voxel și a co-fondat, de asemenea, SolidJoint Research.

NetBox Labs dezvoltă o platformă de inteligență a infrastructurii concepută pentru a ajuta organizațiile să modeleze, să opereze, să automatizeze și să guverneze rețele și infrastructuri IT din ce în ce mai complexe. Compania este responsabilul comercial al NetBox, sistemul open‑source de rețea și infrastructură, adoptat pe scară largă și utilizat de peste 10.000 de organizații. Platforma sa combină un grafic al infrastructurii și o sursă de adevăr cu inteligență operațională, automatizare, orchestrare asistată de AI și capabilități de guvernanță care permit atât inginerilor, cât și agenților AI să interacționeze în siguranță cu infrastructura. NetBox Labs susține implementări în cloud, enterprise auto‑gestionate, hibride și izolate (air‑gapped), integrându-se cu instrumente precum Ansible, Terraform, Nornir și fluxuri de lucru de integrare și livrare continuă.

Ai co-fondat NS1 în 2013 și ai petrecut aproape un deceniu construind compania înainte de achiziționarea acesteia de către IBM, după care NetBox Labs a apărut ca o companie independentă. Ce lecții din construirea NS1 au influențat motivul pentru care ai fondat NetBox Labs și cum s‑a schimbat problema infrastructurii pe care încerci să o rezolvi în era AI?

Un lucru pe care l‑am învățat construind NS1 este că problemele de infrastructură rar rămân bine delimitate. DNS era componenta noastră din stivă, dar clienții noștri operau în medii incredibil de complexe, în care rețelele, centrele de date, aplicațiile și automatizarea depindeau una de alta. Cu cât petreceam mai mult timp cu acele echipe, cu atât devenea mai evident că înțelegerea propriei infrastructuri era o problemă mult mai mare.

Acesta a fost un motiv important pentru care am fost atras de NetBox. Există deja acest proiect open‑source adoptat pe scară largă și o comunitate de ingineri care îl folosește pentru a modela ce dețin, cum este conectat și cum ar trebui să arate. Am văzut o oportunitate de a construi pe această fundație.

Ceea ce s‑a schimbat odată cu AI este în principal ritmul și scala. Echipele de infrastructură sunt solicitate să construiască medii enorme într-un timp extrem de scurt, în timp ce tehnologia de bază evoluează la fel de rapid. În același timp, începem să automatizăm tot mai mult operațiunile acelei infrastructuri, ceea ce reprezintă un viitor incitant. Pe măsură ce AI este aplicat infrastructurii, echipele IT își dau seama că trebuie să aibă date bune, în timp real, despre infrastructura lor pentru a automatiza, și trebuie să știe cum arată starea dorită, astfel încât AI să le poată indica când infrastructura operațională deviază de la plan.

Așadar, lecția învățată de la NS1 se aplică în continuare. Înainte să poți automatiza infrastructura eficient, trebuie să o înțelegi. AI face ca obținerea acestui lucru să fie mult mai urgentă.

În cea mai mare parte a ultimului deceniu, cloud computing a permis dezvoltatorilor și echipelor de infrastructură să abstractizeze hardware‑ul fizic de sub aplicațiile lor. De ce inversează AI această tendință și îi obligă pe DevOps, Site Reliability Engineering (SRE) și inginerii de rețea să se gândească din nou la alimentare, răcire, rack‑uri, cablare și la rețelistică fizică?

Cloud ne-a învățat pe mulți dintre noi să tratăm infrastructura ca fiind practic infinită. Solicitai resurse de calcul și acestea apăreau. Nu trebuia neapărat să-ți pese unde se afla serverul, cum era alimentat, cum era răcit sau cum se îmbinau toate componentele fizice de dedesubt.

Infrastructura AI nu îți permite cu adevărat să faci asta.

Când construiești aceste medii, începi cu niște întrebări destul de concrete. Cât teren am la dispoziție? Câtă putere pot obține? Ce tip de răcire pot susține? De acolo treci la rack‑uri, servere GPU, switch‑uri, cabluri de fibră optică și, în cele din urmă, la stratul logic, adrese IP, configurații și software.

Toate acestea depind una de cealaltă. Nu poți decide câte rack‑uri vei implementa fără să înțelegi densitatea de putere și răcire. Nu poți gândi GPU‑urile independent de rețeaua care le conectează.

Aceasta obligă disciplinele care au petrecut ani de zile să se îndepărteze de stratul fizic să revină să se implice în el. Abstracția nu a dispărut, dar constrângerile fizice de dedesubt devin brusc mult mai importante.

Centrele de date AI sunt din ce în ce mai des discutate la scară de gigawatt. Ce se schimbă fundamental din punct de vedere operațional când infrastructura trece de la medii enterprise sau cloud convenționale la facilități concepute în jurul unor clustere uriașe de GPU‑uri?

Scara de gigawatt este absolut astronomică. Dar, deși scala este evident diferită, cred că diferența mai interesantă este cantitatea de coordonare necesară.

Gândește-te la ce trebuie să se întâmple pentru a pune în funcțiune un centru de date de 300 de megawați. Ai nevoie de teren și de energie. Apoi trebuie să proiectezi instalația și să achiziționezi rack-uri, servere GPU, switch-uri, fibră optică, infrastructură de alimentare și echipamente de răcire, adesea de la furnizori complet diferiți, cu moduri complet diferite de a-și reprezenta produsele. Toate aceste echipamente trebuie să sosească, să fie recepționate, montate în rack-uri, cablate, configurate, testate și, în final, predate pentru antrenare sau inferență.

Și terenul se mișcă sub picioarele tale în timp ce lucrezi. Arhitecturile GPU se schimbă. Rețelele se schimbă. Cerințele de răcire se schimbă. Componentele disponibile peste șase luni s-ar putea să nu fie aceleași cu cele pe care le-ai proiectat astăzi.

Așadar, micile ineficiențe se acumulează foarte repede. Recent am petrecut timp cu unul dintre cei mai mari producători de cabluri cu fibră optică din lume și mi-au spus că una dintre cele mai mari probleme de afaceri ale lor sunt retururile, deoarece clienții comandă lungimi greșite de cablu. Acest lucru pare aproape trivial până când comanzi sute de mii de cabluri.

La această scară, operațiunile de infrastructură devin o problemă gigantică de logistică și de satisfacere a constrângerilor. Companiile care reușesc acest lucru bine sunt cele care devin foarte bune în a transporta datele de proiectare exacte pe tot parcursul achizițiilor, implementării și operațiunilor.

Ai afirmat că practic nu există un manual stabilit sau un flux de talente pentru operarea infrastructurii la această scară. Care sunt abilitățile cele mai greu de găsit în prezent și unde te aștepți să apară cele mai mari penurii de talente pe măsură ce infrastructura AI se extinde?

Probabil există doar câteva sute de persoane în lume în acest moment care știu cu adevărat cum să construiască acest tip de infrastructură la această viteză și scară. Și majoritatea lor sunt destul de ocupați, de fapt, făcând acest lucru.

Acesta este parte din ceea ce face acest moment neobișnuit. Nu există un corp matur de cunoștințe pe care să-l poți studia pur și simplu. Oamenii care fac acest lucru învață unii de la alții și își dau seama de lucruri în timp real. Și, pentru că tehnologia se schimbă atât de repede, unele dintre acele lecții devin învechite destul de rapid.

Cred că deficitul este, prin urmare, mai mare decât orice titlu de post. Avem nevoie de oameni care înțeleg rețelele, calculul și automatizarea, dar din ce în ce mai mult și mediul fizic în care trăiesc aceste sisteme. Alimentarea, răcirea, proiectarea facilităților, lanțul de aprovizionare și operațiunile de teren devin parte a aceleiași discuții.

Persoanele care pot traversa unele dintre aceste granițe vor fi incredibil de valoroase. Dar nu cred că am stabilit încă cum arată toate aceste roluri. Modelul de talente este construit alături de infrastructură.

Pe măsură ce granițele dintre software, rețele, facilități, energie și ingineria centrelor de date încep să se estompeze, ce noi roluri tehnice sau seturi de competențe hibride te aștepți să apară?

Nu cred că știm încă cum vor arăta toate aceste roluri. Ceea ce știm este că oamenii care construiesc această infrastructură trebuie să gândească pe un set mult mai larg de probleme decât făceau înainte.

Nu te gândești doar la calcul sau la rețele în izolare. Alimentarea, răcirea, proiectarea fizică, lanțul de aprovizionare, rețelele și automatizarea trebuie să se combine pentru a pune aceste medii în funcțiune și a le menține în funcțiune.

Încă cred că vom avea nevoie de oameni cu expertiză profundă în fiecare dintre aceste domenii. Dar, din ce în ce mai mult, aceștia vor trebui să înțeleagă cum deciziile din zona lor afectează restul infrastructurii. Și, pentru că o mare parte din această muncă trebuie să se desfășoare mai repede, capacitatea de a automatiza va conta în mai multe dintre aceste discipline.

Agenții AI încep să diagnosticheze probleme, să genereze configurații și să automatizeze părți ale operațiunilor de infrastructură. Ce responsabilități crezi că AI va prelua în mod realist de la inginerii de infrastructură și care vor deveni și mai dependente de expertiza umană profundă?

Cred că o mare parte din munca în care intrările, rezultatul dorit și limitele sunt clare va fi tot mai mult gestionată de AI. Generarea de configurații este un exemplu evident. La fel și diagnosticarea problemelor comune, verificarea dacă infrastructura corespunde designului intenționat sau, în cele din urmă, remedierea anumitor probleme când există suficientă încredere în ce a mers greșit și care este răspunsul sigur.

Unde oamenii devin mai importanți este când răspunsul nu este evident.

Infrastructura eșuează în moduri ciudate. Un cablu de fibră este tăiat. Un dispozitiv începe să se comporte diferit de cum spune designul că ar trebui. O modificare are un efect neașteptat undeva în altă parte a mediului. AI poate ajuta un inginer să înțeleagă aceste situații mult mai repede, dar ai tot nevoie de oameni care înțeleg sistemul suficient de profund pentru a decide ce ar trebui să se întâmple în continuare.

Cred că acesta este schimbarea interesantă. Inginerii vor petrece probabil mai puțin timp făcând configurații repetitive și depanare și mai mult timp definind intenția, proiectând sisteme, stabilind limitele pentru automatizare și gestionând problemele cu adevărat noi. Toată această muncă va fi augmentată de AI, dar condusă de oameni.

Acest lucru face ca expertiza să fie mai valoroasă, nu mai puțin. Inginerul care înțelege cu adevărat de ce infrastructura funcționează așa cum o face va fi incredibil de important atunci când automatizarea nu are un răspuns evident.

NetBox Labs a susținut că sistemele AI care gestionează infrastructura au nevoie de un model autoritar al dispozitivelor, conexiunilor, dependențelor și altor relații fizice și logice. De ce este atât de important acest tip de context al infrastructurii atunci când trecem de la asistenți AI care fac recomandări la agenți care pot acționa efectiv?

Marea diferență este că, odată ce un agent poate acționa, greșeala are consecințe reale.

Un agent de infrastructură are nevoie de mai mult decât o captură a ceea ce face un dispozitiv în acest moment. Trebuie să înțeleagă mediul înconjurător: ce există, cum sunt conectate lucrurile, ce s-a schimbat recent și, în mod important, cum ar trebui să arate infrastructura.

Luați, de exemplu, depanarea unei probleme de conectivitate. Nu este suficient să știi că un dispozitiv este inaccesibil. Vrei ca agentul să poată urmări traseul cablului, să înțeleagă dependențele din jurul acelui dispozitiv, să analizeze modificările recente și să determine ce altceva ar putea fi afectat înainte de a propune ce să facă în continuare.

Aceasta este cu adevărat fundația pe care am petrecut ani de zile construind-o la NetBox Labs, oferind echipelor un model precis atât al infrastructurii fizice, cât și al celei logice, împreună cu intenția din spatele modului în care ar trebui să funcționeze.

Dar datele singure nu sunt suficiente. Trebuie, de asemenea, să decizi ce poate face agentul pe cont propriu, ce necesită aprobarea unei persoane și cum este urmărită și validată fiecare acțiune.

Infrastructura nu este ca codul, unde o modificare greșită poate fi întotdeauna revenită curat. O modificare greșită poate întrerupe o operațiune. Așadar, pe măsură ce trecem de la AI care spune unui inginer ce crede că ar trebui să facă la AI care poate efectiv să realizeze munca, atât contextul, cât și controlul devin mult mai importante.

În articol recent CIO, „Why I, the CEO, am personally building our AI strategy,” ai susținut că AI este prea important pentru ca liderii companiilor să îl delegheze simplu și ai descris prototiparea personală cu instrumente AI. Cum a schimbat abordarea practică a acestor sisteme modul în care te gândești la ceea ce AI poate automatiza în mod realist în operațiunile de infrastructură?

A fi implicat practic te face mult mai puțin interesat de discuția teoretică.

Am petrecut mult timp construind efectiv cu aceste instrumente, cel mai des în prezent prototipând sau chiar dezvoltând produse complete cu Claude Code. Înveți destul de repede că există o diferență uriașă între a vedea o demonstrație impresionantă și a construi ceva în care să ai cu adevărat încredere pentru a îndeplini sarcini utile.

De asemenea, dezvolți o senzație pentru direcția în care tehnologia evoluează mult mai repede decât poți afla citind despre ea. Lucruri pe care le-aș fi considerat dificile de automatizat în urmă cu șase luni pot deveni brusc destul de simple. În același timp, vezi foarte clar unde încă lipsesc contextul, judecata și structura.

Acest lucru a influențat modul în care privesc operațiunile de infrastructură. Sunt foarte optimist în legătură cu cât de multă muncă operațională putem automatiza, dar cred că suntem încă departe de autonomie pură ca scop final.

Întrebarea care mă preocupă este mult mai de bază. Ne ajută acest lucru să operăm infrastructura mai rapid, mai fiabil sau mai eficient? Dacă da, minunat. Dacă nu, nu contează cât de sofisticat este AI-ul din spatele lui.

Pe măsură ce centrele de date AI devin din ce în ce mai limitate de disponibilitatea electricității și de cerințele de răcire, ar putea ingineria infrastructurii să evolueze de la gestionarea în principal a resurselor de calcul la coordonarea activă a sarcinilor de lucru cu energia și capacitatea fizică?

Da, și deja începem să observăm acest lucru. Avem o expresie internă, „turbine în parcarea”, care a apărut dintr-o discuție reală cu una dintre echipele care construiesc infrastructura AI de hiperscală. Ei aduceau infrastructura în funcțiune atât de repede încât rețeaua nu putea ține pasul, așa că literalmente cumpărau turbine și le puneau în parcarea pentru a obține suficientă putere.

Acesta este tipul de mediu în care operează aceste echipe. Când energia devine una dintre constrângerile tale principale, trebuie să devii mult mai inteligent în modul în care folosești ceea ce este disponibil. Răspunsul la cerere, în care operatorii coordonează activ sarcinile de lucru AI ca reacție la schimbările din rețeaua electrică, se întâmplă deja și devine o capacitate din ce în ce mai importantă pentru echipele care operează infrastructuri cu consum ridicat de energie.

Nu toate sarcinile de lucru au aceleași cerințe. Inferența sensibilă la latență poate necesita să rămână online, în timp ce unele sarcini de antrenament sau batch pot fi mutate sau întrerupte când energia este limitată. Cred că vom vedea din ce în ce mai mult echipele de infrastructură gestionând calculul, energia și capacitatea fizică ca părți ale aceleiași probleme operaționale.

Privind spre viitor, crezi că cel mai mare blocaj în scalarea AI va fi în final GPU‑urile și dezvoltarea modelelor, sau provocarea mult mai largă de a găsi suficientă energie, infrastructură fizică, capacitate de rețea, automatizare și ingineri calificați pentru a opera tot ce se află în spatele lor?

Nu cred că va exista un singur blocaj.

Construirea infrastructurii AI la viteza și scară pe care piața le cere în prezent este practic o problemă de satisfacere a constrângerilor. În orice moment, ceva este constrângerea principală.

Pentru o perioadă, toată lumea vorbea despre GPU-uri. Puterea este evident un blocaj imens în prezent. Dar poate fi și echipamentul de rețea, răcirea, terenul, fibra optică, achizițiile, construcția sau pur și simplu găsirea suficientor oameni care știu cum să asambleze toate acestea.

Și odată ce rezolvi o constrângere, alta devine mai vizibilă. Asta se întâmplă când cererea depășește cu mult oferta.

Așadar, nu aș paria pe un singur blocaj permanent. Cred că abilitatea mai importantă este să poți să te adaptezi pe măsură ce constrângerea se mută.

De aceea nu cred că există în prezent un ghid definitiv pentru infrastructura AI. Cei care o construiesc descoperă acest lucru în timp ce scalează și fac ambele lucruri incredibil de repede.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze NetBox Labs.