Kris Beevers, administrerende direktør og medgründer, Netbox Labs – Intervjuserie

Kris Beevers, administrerende direktør og medgründer i NetBox Labs er en teknologientreprenør og veteran innen infrastrukturprogramvare med mer enn to tiår med erfaring i å bygge selskaper og plattformer som fokuserer på nettverk, skyinfrastruktur og automatisering. Før han ledet NetBox Labs, var Beevers medgründer av NS1 i 2013 og fungerte som administrerende direktør i nesten et tiår, og bygde selskapet til en fremtredende leverandør av nettverksautomatisering og applikasjonstrafikkstyringsteknologi før det ble kjøpt opp av IBM i 2023. Som en del av den transaksjonen ble NetBox Labs spunnet ut av NS1 som et uavhengig selskap med IBM som investor. Tidligere i karrieren hadde Beevers senioringeniør‑ og arkitektroller hos Internap Network Services og Voxel, og han var også medgründer av SolidJoint Research.

NetBox Labs utvikler en infrastrukturintelligensplattform designet for å hjelpe organisasjoner med å modellere, drifte, automatisere og styre stadig mer komplekse nettverk og IT‑infrastruktur. Selskapet er den kommersielle forvalteren av NetBox, det bredt adopterte åpne kildekode‑nettverks‑ og infrastruktursystemet som brukes av mer enn 10 000 organisasjoner. Plattformen kombinerer en infrastrukturgraf og sannhetskilde med operasjonell intelligens, automatisering, AI‑assistert orkestrering og styringsfunksjoner som gjør at både ingeniører og AI‑agenter trygt kan samhandle med infrastrukturen. NetBox Labs støtter sky‑, selvadministrerte bedrifts‑, hybride og luft‑avkoblede (air‑gapped) distribusjoner, samtidig som den integreres med verktøy som Ansible, Terraform, Nornir og kontinuerlige integrasjons‑ og distribusjonspipelines.

Du var med på å grunnlegge NS1 i 2013 og tilbrakte nesten et tiår med å bygge selskapet før det ble kjøpt opp av IBM, hvoretter NetBox Labs dukket opp som et uavhengig selskap. Hvilke lærdommer fra byggingen av NS1 påvirket hvorfor du grunnla NetBox Labs, og hvordan har infrastrukturproblemet du prøver å løse endret seg i AI‑æraen?

En ting jeg lærte av å bygge NS1 er at infrastrukturproblemer sjelden forblir pent avgrenset. DNS var vår del av stakken, men kundene våre opererte i disse utrolig komplekse miljøene hvor nettverk, datasentre, applikasjoner og automatisering alle var avhengige av hverandre. Jo mer tid jeg tilbrakte med de teamene, desto klarere ble det at forståelsen av selve infrastrukturen var et langt større problem.

Det var en stor del av det som trakk meg til NetBox. Det fantes allerede dette bredt adopterte åpen‑kildekode‑prosjektet og et fellesskap av ingeniører som brukte det til å modellere hva de hadde, hvordan det var koblet sammen og hvordan det skulle se ut. Vi så en mulighet til å bygge videre på dette fundamentet.

Det som har endret seg med AI er hovedsakelig tempoet og skalaen. Infrastrukturteam blir bedt om å bygge enorme miljøer ekstremt raskt, mens den underliggende teknologien endrer seg like raskt. Samtidig begynner vi å automatisere mer av driften av den infrastrukturen, noe som representerer en spennende fremtid. Når AI anvendes på infrastruktur, innser IT‑team at de må ha gode, sanntidsdata om infrastrukturen for å kunne automatisere, og de må vite hvordan den tiltenkte tilstanden ser ut slik at AI kan hjelpe dem med å identifisere når den operative infrastrukturen avviker fra planen.

Så gjelder lærdommen fra NS1 fortsatt. Før du kan automatisere infrastruktur på en god måte, må du forstå den. AI gjør bare at dette må gjøres mye mer presserende.

I store deler av det siste tiåret har cloud‑computing gjort det mulig for utviklere og infrastrukturteam å abstrahere bort den fysiske maskinvaren under applikasjonene deres. Hvorfor snur AI denne trenden og tvinger DevOps, Site Reliability Engineering (SRE) og nettverksingeniører til å tenke på strøm, kjøling, rack, kabling og fysisk nettverk igjen?

Skyen lærte mange av oss å behandle infrastruktur som i praksis uendelig. Du ba om beregning, og den dukket opp. Du trengte ikke nødvendigvis å bry deg om hvor serveren var, hvordan den ble strømforsynt, hvordan den ble kjølt eller hvordan alle de fysiske komponentene under den ble satt sammen.

AI‑infrastruktur lar deg egentlig ikke gjøre det.

Når du bygger disse miljøene, starter du med noen ganske fysiske spørsmål. Hvor mye land har jeg? Hvor mye strøm kan jeg få? Hvilken type kjøling kan jeg støtte? Deretter går du inn på rack, GPU‑servere, switcher, fiberoptisk kabling og til slutt det logiske laget, IP‑adresser, konfigurasjoner og programvare.

Alle disse tingene er avhengige av hverandre. Du kan ikke bestemme hvor mange rack du skal distribuere uten å forstå strøm‑ og kjøletetthet. Du kan ikke tenke på GPU‑ene uavhengig av nettverket som kobler dem sammen.

Det tvinger disipliner som har tilbrakt år med å bevege seg bort fra det fysiske laget til å engasjere seg i det igjen. Abstraksjonen er ikke borte, men de fysiske begrensningene under den blir plutselig mye viktigere.

AI‑datasentre blir i økende grad diskutert i gigawatt‑skala. Hva endrer seg fundamentalt operasjonelt når infrastrukturen går fra tradisjonelle bedrifts‑ eller sky‑miljøer til anlegg designet rundt enorme GPU‑klynger?

Gigawatt‑skala er helt astronomisk. Men selv om skalaen åpenbart er forskjellig, tror jeg den mer interessante forskjellen er mengden koordinering som kreves.

Tenk på hva som må skje for å sette et 300-megawatt datasenter i drift. Du trenger land og strøm. Deretter må du designe anlegget og anskaffe rack, GPU‑servere, svitsjer, fiber, strøminfrastruktur og kjøleutstyr, ofte fra helt forskjellige leverandører med helt ulike måter å representere produktene sine på. Allt dette utstyret må ankomme, mottas, monteres i rack, kables, konfigureres, testes og til slutt overleveres for trening eller inferens.

Og bakken beveger seg under deg mens du gjør det. GPU‑arkitekturer endrer seg. Nettverk endrer seg. Kjølekrav endrer seg. Komponentene som er tilgjengelige om seks måneder, kan være andre enn de du har designet rundt i dag.

Så små ineffektiviteteter bygger seg opp veldig raskt. Jeg tilbrakte nylig tid med en av verdens største produsenter av fiberoptiske kabler, og de fortalte meg at et av deres største forretningsproblemer er returvarer fordi kundene bestiller feil kabellengder. Det høres nesten trivielt ut inntil du bestiller hundretusener av kabler.

I denne skalaen blir infrastrukturdrift et gigantisk logistikk- og restriksjonsløsningsproblem. De selskapene som gjør dette bra, er de som blir svært dyktige til å føre nøyaktige designdata gjennom hele anskaffelses-, implementerings- og driftsprosessen.

Du har sagt at det i praksis ikke finnes noen etablert håndbok eller talentpipeline for å drive infrastruktur i denne skalaen. Hvilke ferdigheter er for øyeblikket vanskeligst å finne, og hvor forventer du at de største talentmanglene vil oppstå når AI‑infrastruktur vokser?

Det er sannsynligvis bare noen få hundre personer i verden akkurat nå som virkelig vet hvordan man bygger denne typen infrastruktur i denne hastigheten og skalaen. Og de fleste av dem er ganske opptatt med faktisk å gjøre det.

Det er en del av det som gjør dette øyeblikket uvanlig. Det finnes ingen moden kunnskapsbase du bare kan gå og studere. Folk som gjør dette lærer av hverandre og finner ut av ting i sanntid. Og fordi teknologien endrer seg så raskt, blir noen av disse lærdommene foreldet ganske fort.

Jeg tror mangelen derfor er større enn noen enkelt stillingstittel. Vi trenger folk som forstår nettverk, beregning og automatisering, men i økende grad også forstår det fysiske miljøet disse systemene lever i. Strøm, kjøling, anleggsdesign, forsyningskjede og feltoperasjoner blir en del av samme samtale.

Personer som kan krysse noen av disse grensene vil bli utrolig verdifulle. Men jeg tror ikke vi engang har blitt enige om hvordan alle disse rollene ser ut ennå. Talentmodellen bygges parallelt med infrastrukturen.

Når grensene mellom programvare, nettverk, fasiliteter, energi og datasenter‑ingeniørkunst begynner å bli uklare, hvilke nye tekniske roller eller hybride ferdighetssett forventer du vil dukke opp?

Jeg tror ikke vi vet hvordan alle disse rollene vil se ut ennå. Det vi vet er at folk som bygger denne infrastrukturen må tenke på et mye bredere spekter av problemer enn de gjorde før.

Du tenker ikke bare på beregning eller nettverk isolert. Strøm, kjøling, fysisk design, forsyningskjede, nettverk og automatisering må alle samles for å få disse miljøene i drift og holde dem i gang.

Jeg tror fortsatt at vi vil trenge folk med dyp ekspertise innen hver av disse områdene. Men i økende grad må de også forstå hvordan beslutninger i deres område påvirker resten av infrastrukturen. Og fordi så mye av dette arbeidet må skje raskere, vil evnen til å automatisere bli viktig på tvers av flere av disse disiplinene.

AI‑agenter begynner å diagnostisere problemer, generere konfigurasjoner og automatisere deler av infrastrukturdriften. Hvilke ansvarsområder tror du AI realistisk vil overta fra infrastruktur‑ingeniører, og hvilke vil bli enda mer avhengige av dyp menneskelig ekspertise?

Jeg tror mye av arbeidet der innganger, ønsket resultat og grenser er klare, i økende grad vil bli håndtert av AI. Å generere konfigurasjoner er et åpenbart eksempel. Det samme gjelder diagnostisering av vanlige problemer, sjekking av om infrastrukturen samsvarer med den tiltenkte designen, eller eventuelt å fikse enkelte feil når man har tilstrekkelig sikkerhet om hva som gikk galt og hva den trygge responsen er.

Der mennesker blir viktigere er når svaret ikke er åpenbart.

Infrastruktur svikter på merkelige måter. En fiber blir kuttet. En enhet begynner å oppføre seg annerledes enn designen sier den skal. En endring får en uventet effekt et annet sted i miljøet. AI kan hjelpe en ingeniør med å forstå disse situasjonene mye raskere, men du trenger fortsatt folk som forstår systemet grundig nok til å bestemme hva som skal skje videre.

Jeg tror det er den interessante endringen. Ingeniører vil sannsynligvis bruke mindre tid på repeterende konfigurasjon og feilsøking og mer tid på å definere intensjon, designe systemer, sette grenser for automatisering og håndtere virkelig nye problemer. Alt dette arbeidet vil bli styrket av AI, men drevet av mennesker.

Det gjør ekspertise mer verdifull, ikke mindre. Ingeniøren som virkelig forstår hvorfor infrastrukturen fungerer som den gjør, vil bli utrolig viktig når automatiseringen ikke har et åpenbart svar.

NetBox Labs har argumentert for at AI‑systemer som styrer infrastruktur trenger en autoritativ modell av enheter, tilkoblinger, avhengigheter og andre fysiske og logiske relasjoner. Hvorfor er denne typen infrastrukturkontekst så viktig når man går fra AI‑assistenter som gir anbefalinger til agenter som faktisk kan utføre handlinger?

Den store forskjellen er at når en agent kan handle, får feil reelle konsekvenser.

En infrastruktur‑agent trenger mer enn et øyeblikksbilde av hva en enhet gjør akkurat nå. Den må forstå omgivelsene rundt seg: hva som finnes, hvordan ting er koblet sammen, hva som har endret seg nylig og, viktigst, hvordan infrastrukturen skal se ut.

Ta for eksempel feilsøking av et tilkoblingsproblem. Det er ikke nok å vite at en enhet er utilgjengelig. Du vil at agenten skal kunne spore kabelstien, forstå avhengighetene rundt den enheten, se på nylige endringer og fastslå hva annet kan bli påvirket før den foreslår hva som skal gjøres videre.

Det er egentlig fundamentet vi har brukt år på å bygge hos NetBox Labs, som gir teamene en nøyaktig modell av både den fysiske og logiske infrastrukturen, samt intensjonen bak hvordan den skal fungere.

Men dataene alene er ikke nok. Du må også bestemme hva agenten får lov til å gjøre på egen hånd, hva som krever godkjenning fra en person, og hvordan hver handling blir sporet og validert.

Infrastruktur er ikke som kode der en dårlig endring alltid kan rulles tilbake på en ren måte. En dårlig endring kan sette en operasjon ned. Så når vi går fra AI som forteller en ingeniør hva den tror, til AI som faktisk kan utføre arbeidet, blir både kontekst og kontroll mye viktigere.

I din nylige CIO-artikkel, «Why I, the CEO, am personally building our AI strategy», argumenterte du for at AI er for viktig for bedriftsledere til å bare delegere, og beskrev hvordan du personlig prototyper med AI‑verktøy. Hvordan har det å være hands‑on med disse systemene endret din tenkning om hva AI realistisk kan automatisere i infrastrukturdrift?

Å være hands‑on gjør at du blir mye mindre interessert i den teoretiske samtalen.

Jeg har brukt mye tid på faktisk å bygge med disse verktøyene, oftest i dag på å prototype eller til og med bygge komplette produkter med Claude Code. Du lærer ganske raskt at det er en enorm forskjell mellom å se en imponerende demo og å bygge noe du faktisk stoler på for å utføre nyttig arbeid.

Du får også en følelse av hvor teknologien beveger seg mye raskere enn du kan få ved bare å lese om den. Ting jeg for seks måneder siden ville ha ansett som vanskelige å automatisere, kan plutselig være ganske enkle. Samtidig ser du veldig tydelig hvor kontekst, skjønn og struktur fortsatt mangler.

Det har påvirket hvordan jeg tenker på infrastrukturdrift. Jeg er veldig optimistisk med tanke på hvor mye operasjonelt arbeid vi kan automatisere, men jeg tror vi er langt fra ren autonomi som endemål.

Spørsmålet jeg bryr meg om er mye mer grunnleggende. Hjeler dette oss med å drive infrastrukturen raskere, mer pålitelig eller mer effektivt? Hvis ja, flott. Hvis nei, spiller det ingen rolle hvor sofistikert AI‑en bak er.

Etter hvert som AI‑datasentre blir stadig mer begrenset av tilgjengelig strøm og kjølekrav, kan infrastruktur‑ingeniørfaget utvikle seg fra primært å håndtere databehandlingsressurser til aktivt å koordinere arbeidsbelastninger med energi‑ og fysisk kapasitet?

Ja, og vi ser allerede dette. Vi har et internt uttrykk, «turbiner på parkeringsplassen», som kom fra en reell samtale med ett av teamene som bygger hyperskala AI‑infrastruktur. De tok i bruk infrastruktur så raskt at strømnettet ikke klarte å holde tritt, så de kjøpte bokstavelig talt turbiner og satte dem på parkeringsplassen for å få nok strøm raskt.

Det er den typen miljø disse teamene opererer i. Når strøm blir en av dine primære begrensninger, må du bli mye smartere på hvordan du bruker det som er tilgjengelig. Etterspørsels‑respons, hvor operatører aktivt koordinerer AI‑arbeidsbelastninger som reaksjon på endringer i strømnettet, skjer allerede og blir en stadig viktigere evne for team som driver strøm‑krevende infrastruktur.

Ikke alle arbeidsbelastninger har de samme kravene. Latens‑sensitiv inferens kan trenge å være online, mens noen trenings‑ eller batch‑oppgaver kan flyttes eller pause når strømmen er begrenset. Jeg tror vi i økende grad vil se infrastrukturteam som håndterer beregning, strøm og fysisk kapasitet som deler av samme operasjonelle problem.

Ser du fremover, tror du den største flaskehalsen for å skalere AI til slutt vil være GPU‑er og modellutvikling, eller den mye bredere utfordringen med å finne nok strøm, fysisk infrastruktur, nettverkskapasitet, automatisering og dyktige ingeniører til å drifte alt som ligger bak?

Jeg tror ikke det blir én enkelt flaskehals.

Å bygge AI‑infrastruktur i den hastigheten og skalaen markedet krever akkurat nå er i bunn og grunn et tilfredsstillings‑problem for begrensninger. På ethvert gitt tidspunkt er noe den primære begrensningen.

En periode snakket alle om GPU-er. Kraft er åpenbart en enorm flaskehals nå. Men det kan også være nettverksutstyr, kjøling, land, fiber, innkjøp, bygging eller ganske enkelt å finne nok folk som vet hvordan man setter alt dette sammen.

Og så snart du løser én flaskehals, blir en annen mer synlig. Det er det som skjer når etterspørselen er så mye større enn tilbudet.

Så jeg ville ikke satse på én permanent flaskehals. Jeg tror den viktigste evnen er å kunne tilpasse seg etter hvert som flaskehalsen flytter seg.

Det er også grunnen til at jeg ikke tror noen har den definitive spilleboken for AI-infrastruktur akkurat nå. Folkene som bygger den, finner dette ut mens de skalerer, og de gjør begge deler utrolig raskt.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke NetBox Labs.