Kris Beevers, CEO og medstifter, Netbox Labs – Interviewserie

Kris Beevers, CEO og medstifter af NetBox Labs er en teknologientreprenør og veteran inden for infrastruktursoftware med mere end to årtier erfaring med at bygge virksomheder og platforme, der fokuserer på netværk, cloud‑infrastruktur og automatisering. Før han gik i ledelsen af NetBox Labs, medstiftede Beevers NS1 i 2013 og var CEO i næsten et årti, hvor han byggede virksomheden til en fremtrædende leverandør af netværksautomatisering og applikationstrafficstyringsteknologi, inden den blev opkøbt af IBM i 2023. Som en del af den transaktion blev NetBox Labs spundet ud af NS1 som et selvstændigt selskab med IBM som investor. Tidligere i sin karriere havde Beevers senior‑ingeniør‑ og arkitektroller hos Internap Network Services og Voxel, og han medstiftede også SolidJoint Research.

NetBox Labs udvikler en infrastruktur‑intelligensplatform designet til at hjælpe organisationer med at modellere, drive, automatisere og styre stadig mere komplekse netværk og IT‑infrastruktur. Virksomheden er den kommercielle forvalter af NetBox, det bredt adopterede open‑source netværks‑ og infrastruktursystem, der anvendes af mere end 10.000 organisationer. Platformen kombinerer en infrastruktur‑graf og sandhedskilde med operationel intelligens, automatisering, AI‑assisteret orkestrering og governance‑funktioner, som gør det muligt for både ingeniører og AI‑agenter at interagere sikkert med infrastrukturen. NetBox Labs understøtter cloud, selvadministrerede enterprise‑miljøer, hybride og luft‑afsondrede implementeringer, samtidig med at den integrerer med værktøjer såsom Ansible, Terraform, Nornir og CI/CD‑pipelines.

Du medstiftede NS1 i 2013 og brugte næsten et årti på at bygge virksomheden, inden den blev opkøbt af IBM, hvorefter NetBox Labs opstod som et selvstændigt selskab. Hvilke erfaringer fra opbygningen af NS1 påvirkede, hvorfor du grundlagde NetBox Labs, og hvordan har det infrastrukturproblem, du forsøger at løse, ændret sig i AI‑æraen?

En ting, jeg lærte ved at bygge NS1, er, at infrastrukturproblemer sjældent forbliver pænt afgrænsede. DNS var vores del af stakken, men vores kunder opererede i disse utroligt komplekse miljøer, hvor netværk, datacentre, applikationer og automatisering alle var afhængige af hinanden. Jo mere tid jeg tilbragte med de teams, jo tydeligere blev det, at forståelsen af selve infrastrukturen var et langt større problem.

Det var en stor del af, hvad der trak mig til NetBox. Der var allerede dette bredt adopterede open‑source‑projekt og et fællesskab af ingeniører, der brugte det til at modellere, hvad de havde, hvordan det var forbundet, og hvordan det skulle se ud. Vi så en mulighed for at bygge videre på dette fundament.

Det, der har ændret sig med AI, er primært tempoet og skalaen. Infrastruktur‑teams bliver bedt om at bygge enorme miljøer utroligt hurtigt, mens den underliggende teknologi ændrer sig lige så hurtigt. Samtidig begynder vi at automatisere mere af driften af den infrastruktur, hvilket repræsenterer en spændende fremtid. Når AI anvendes på infrastruktur, indser IT‑teams, at de skal have gode, real‑tidsdata om deres infrastruktur for at kunne automatisere, og de skal vide, hvordan den ønskede tilstand ser ud, så AI kan hjælpe dem med at identificere, hvornår den operationelle infrastruktur afviger fra planen.

Så er lektien fra NS1 stadig gældende. Før du kan automatisere infrastruktur effektivt, skal du forstå den. AI gør blot at få dette rigtigt endnu mere presserende.

I størstedelen af det sidste årti gjorde cloud computing det muligt for udviklere og infrastruktur‑teams at abstrahere den fysiske hardware under deres applikationer. Hvorfor vender AI denne tendens og tvinger DevOps, Site Reliability Engineering (SRE) og netværks‑ingeniører til at tænke på strøm, køling, rack‑systemer, kabler og fysisk netværk igen?

Cloud lærte mange af os at behandle infrastruktur som praktisk talt uendelig. Du bad om beregning, og den dukkede op. Du behøvede ikke nødvendigvis at bekymre dig om, hvor serveren var, hvordan den blev strømforsynet, kølet, eller hvordan alle de fysiske komponenter under den blev samlet.

AI‑infrastruktur tillader dig egentlig ikke at gøre det.

Når du bygger disse miljøer, starter du med nogle ret fysiske spørgsmål. Hvor meget jord har jeg? Hvor meget strøm kan jeg få? Hvilken type køling kan jeg understøtte? Derfra kommer du ind i rack‑systemer, GPU‑servere, switches, fiberoptisk kabling og til sidst det logiske lag med IP‑adresser, konfigurationer og software.

Alle disse ting afhænger af hinanden. Du kan ikke beslutte, hvor mange rack‑systemer du vil implementere, uden at forstå strøm‑ og køletæthed. Du kan ikke tænke på GPU‑erne uafhængigt af netværket, der forbinder dem.

Det tvinger discipliner, der har brugt år på at bevæge sig væk fra det fysiske lag, til at engagere sig i det igen. Abstraktionen er ikke væk, men de fysiske begrænsninger under den betyder pludselig meget mere.

AI‑datacentre diskuteres i stigende grad i gigawatt‑skala. Hvad ændrer sig grundlæggende operationelt, når infrastrukturen flyttes fra konventionelle enterprise‑ eller cloud‑miljøer til faciliteter designet omkring enorme GPU‑klynger?

Gigawatt‑skala er absolut astronomisk. Men selvom skalaen naturligvis er anderledes, tror jeg, at den mere interessante forskel er den mængde koordinering, der kræves.

Tænk på, hvad der skal ske for at bringe et 300-megawatt datacenter i drift. Du har brug for jord og strøm. Så skal du designe faciliteten og anskaffe racke, GPU‑servere, switches, fiber, strøm‑infrastruktur og køleudstyr, ofte fra helt forskellige leverandører med helt forskellige måder at repræsentere deres produkter på. Alt dette udstyr skal ankomme, modtages, monteres i racke, kables, konfigureres, testes og til sidst overleveres til træning eller inferens.

Og jorden bevæger sig under dig, mens du gør det. GPU‑arkitekturer ændrer sig. Netværk ændrer sig. Kølekrav ændrer sig. De komponenter, der er tilgængelige om seks måneder, er måske ikke de samme, som du har designet omkring i dag.

Så små ineffektiviteter akkumuleres meget hurtigt. Jeg har for nylig tilbragt tid med en af de største fiberoptiske kabelproducenter i verden, og de fortalte mig, at et af deres største forretningsproblemer er returneringer, fordi kunder bestiller forkerte kabel længder. Det lyder næsten trivielt, indtil du bestiller hundredtusinder af kabler.

I denne skala bliver infrastrukturdrift et gigantisk logistik‑ og constraint‑satisfaction‑problem. De virksomheder, der gør det godt, er dem, der bliver meget dygtige til at bære præcise designdata hele vejen gennem indkøb, implementering og drift.

Du har sagt, at der i praksis ikke findes nogen etableret playbook eller talent‑pipeline til at drive infrastruktur i denne skala. Hvilke færdigheder er i øjeblikket sværest at finde, og hvor forventer du, at de største talentmangel vil opstå, efterhånden som AI‑infrastruktur udvides?

Der er sandsynligvis kun et par hundrede mennesker i verden lige nu, som virkelig ved, hvordan man bygger denne type infrastruktur med denne hastighed og skala. Og de fleste af dem er ret travlt optaget af faktisk at gøre det.

Det er en del af, hvad der gør dette øjeblik usædvanligt. Der findes ikke et modent vidensgrundlag, du bare kan gå og studere. De mennesker, der gør dette, lærer af hinanden og finder ud af tingene i realtid. Og fordi teknologien ændrer sig så hurtigt, bliver nogle af de lektioner hurtigt forældede.

Jeg tror, at manglen derfor er større end nogen enkelt jobtitel. Vi har brug for folk, der forstår netværk, beregning og automatisering, men i stigende grad også forstår det fysiske miljø, som disse systemer lever i. Strøm, køling, facilitedesign, forsyningskæde og feltoperationer bliver en del af den samme samtale.

De personer, der kan krydse nogle af disse grænser, vil blive utrolig værdifulde. Men jeg tror ikke, vi overhovedet har besluttet, hvordan alle disse roller ser ud endnu. Talentmodellen bygges sideløbende med infrastrukturen.

Efterhånden som grænserne mellem software, netværk, faciliteter, energi og datacenter‑engineering begynder at udviske, hvilke nye tekniske roller eller hybride færdighedssæt forventer du, at vil opstå?

Jeg tror ikke, vi ved, hvordan alle disse roller vil se ud endnu. Det, vi ved, er at de mennesker, der bygger denne infrastruktur, skal tænke på et meget bredere sæt af problemer, end de gjorde før.

Du tænker ikke kun på beregning eller netværk isoleret. Strøm, køling, fysisk design, forsyningskæde, netværk og automatisering skal alle samles for at få disse miljøer i drift og holde dem kørende.

Jeg tror stadig, vi vil have brug for folk med dyb ekspertise inden for hver af disse områder. Men i stigende grad vil de også skulle forstå, hvordan beslutninger i deres område påvirker resten af infrastrukturen. Og fordi så meget af dette arbejde skal ske hurtigere, vil evnen til at automatisere blive vigtig på tværs af flere af disse discipliner.

AI‑agenter begynder at diagnosticere problemer, generere konfigurationer og automatisere dele af infrastrukturdrift. Hvilke ansvarsområder tror du, AI realistisk vil overtage fra infrastruktur‑ingeniører, og hvilke vil blive endnu mere afhængige af dyb menneskelig ekspertise?

Jeg tror, at meget af det arbejde, hvor input, ønsket resultat og grænser er klare, i stigende grad vil blive håndteret af AI. At generere konfigurationer er et indlysende eksempel. Det samme gælder diagnosticering af almindelige problemer, kontrol af om infrastrukturen matcher det tilsigtede design, eller eventuelt at løse visse problemer, når der er tilstrækkelig sikkerhed omkring, hvad der gik galt, og hvad den sikre respons er.

Hvor mennesker bliver vigtigere, er når svaret ikke er indlysende.

Infrastruktur fejler på mærkelige måder. Et fiberkabel bliver skåret. En enhed begynder at opføre sig anderledes end designet foreskriver. En ændring får en uventet effekt et andet sted i miljøet. AI kan hjælpe en ingeniør med at forstå disse situationer meget hurtigere, men du har stadig brug for folk, der forstår systemet dybt nok til at beslutte, hvad der skal ske næste gang.

Jeg tror, det er den interessante forskydning. Ingeniører vil sandsynligvis bruge mindre tid på gentagne konfigurationer og fejlfinding og mere tid på at definere intention, designe systemer, sætte grænser for automatisering og håndtere de virkelig nye problemer. Alt dette arbejde vil blive suppleret af AI, men styret af mennesker.

Det gør ekspertise mere værdifuld, ikke mindre. Den ingeniør, der virkelig forstår, hvorfor infrastrukturen fungerer, som den gør, vil blive utrolig vigtig, når automatiseringen ikke har et indlysende svar.

NetBox Labs har argumenteret for, at AI‑systemer, der håndterer infrastruktur, har brug for en autoritativ model af enheder, forbindelser, afhængigheder og andre fysiske og logiske relationer. Hvorfor er denne type infrastrukturkontekst så vigtig, når man går fra AI‑assistenter, der giver anbefalinger, til agenter, der faktisk kan udføre handlinger?

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

En infrastruktur‑agent har brug for mere end et øjebliksbillede af, hvad en enhed laver lige nu. Den skal forstå miljøet omkring den: hvad der findes, hvordan ting er forbundet, hvad der for nylig er ændret, og vigtigst af alt, hvordan infrastrukturen skal se ud.

Tag for eksempel fejlfinding af et forbindelsesproblem. Det er ikke nok at vide, at en enhed er utilgængelig. Du vil have, at agenten kan spore kabelstien, forstå afhængighederne omkring den enhed, se på nylige ændringer og afgøre, hvad der ellers kan blive påvirket, før den foreslår, hvad der skal gøres næste gang.

Det er virkelig den grundlag, vi har brugt år på at bygge hos NetBox Labs, som giver teams en præcis model af både den fysiske og logiske infrastruktur samt intentionen bag, hvordan den skal fungere.

Men dataene alene er ikke nok. Du skal også beslutte, hvad agenten må gøre på egen hånd, hvad der kræver godkendelse fra en person, og hvordan hver handling spores og valideres.

Infrastruktur er ikke som kode, hvor en dårlig ændring altid kan rulles tilbage på en ren måde. En dårlig ændring kan bringe en drift ned. Så når vi går fra AI, der fortæller en ingeniør, hvad den tror, til AI, der faktisk kan udføre arbejdet, bliver både kontekst og kontrol meget vigtigere.

I din seneste CIO‑artikel, “Why I, the CEO, am personally building our AI strategy,” argumenterede du for, at AI er for vigtig for virksomhedsledere til blot at delegere, og beskrev, hvordan du personligt prototyper med AI‑værktøjer. Hvordan har den hands‑on tilgang til disse systemer ændret din tænkning om, hvad AI realistisk kan automatisere i infrastrukturdrift?

At være hands‑on gør dig meget mindre interesseret i den teoretiske samtale.

Jeg har brugt meget tid på faktisk at bygge med disse værktøjer, for tiden oftest på at prototype eller endda bygge komplette produkter med Claude Code. Man lærer hurtigt, at der er en enorm forskel mellem at se en imponerende demo og at bygge noget, man faktisk kan stole på til at udføre nyttigt arbejde.

Du udvikler også en fornemmelse for, hvor teknologien bevæger sig, meget hurtigere end du kan få ved at læse om den. Ting, jeg for seks måneder siden ville have betragtet som svære at automatisere, kan pludselig være ret ligetil. Samtidig ser du meget tydeligt, hvor kontekst, dømmekraft og struktur stadig mangler.

Det har påvirket, hvordan jeg tænker på infrastrukturdrift. Jeg er meget optimistisk omkring, hvor meget operationelt arbejde vi kan automatisere, men jeg mener, at vi er langt fra ren autonomi som slutmål.

Det spørgsmål, jeg bekymrer mig om, er meget mere grundlæggende. Hjælper dette os med at drive infrastrukturen hurtigere, mere pålideligt eller mere effektivt? Hvis ja, så fantastisk. Hvis nej, betyder det ikke noget, hvor sofistikeret AI’en bag den er.

Efterhånden som AI‑datacentre bliver mere og mere begrænset af tilgængelig elektricitet og kølekrav, kan infrastruktur‑engineering så udvikle sig fra primært at styre computerressourcer til aktivt at koordinere arbejdsbelastninger med energi og fysisk kapacitet?

Ja, og vi begynder allerede at se det. Vi har internt et udtryk, “turbines in the parking lot,” som opstod i en reel samtale med et af holdene, der bygger hyperskala AI‑infrastruktur. De bragte infrastrukturen i drift så hurtigt, at elnettet ikke kunne følge med, så de bogstaveligt talt købte turbiner og placerede dem på parkeringspladsen for at få strøm hurtigt nok.

Det er den slags miljø, disse hold opererer i. Når strøm bliver en af dine primære begrænsninger, skal du blive meget klogere på, hvordan du bruger det, der er tilgængeligt. Efterspørgsels‑respons, hvor operatører aktivt koordinerer AI‑arbejdsbelastninger som reaktion på ændringer i elnettet, sker allerede og bliver en stadig vigtigere evne for hold, der driver strømkrævende infrastruktur.

Ikke alle arbejdsbelastninger har de samme krav. Latens‑følsom inferens kan have brug for at forblive online, mens noget træning eller batch‑arbejde kan flyttes eller pauses, når strømmen er begrænset. Jeg tror, vi i stigende grad vil se infrastruktur‑teams, der håndterer beregning, strøm og fysisk kapacitet som dele af det samme operationelle problem.

Set fremad, tror du, at den største flaskehals for at skalere AI i sidste ende vil være GPU’er og modeludvikling, eller den meget bredere udfordring med at finde tilstrækkelig strøm, fysisk infrastruktur, netværkskapacitet, automatisering og dygtige ingeniører til at drive alt bagved?

Jeg tror ikke, der vil være én enkelt flaskehals.

At bygge AI‑infrastruktur i den hastighed og skala, markedet ønsker lige nu, er i bund og grund et problem med at opfylde begrænsninger. På ethvert givet tidspunkt er noget den primære begrænsning.

I et stykke tid talte alle om GPU’er. Effekt er åbenlyst en enorm flaskehals nu. Men det kan også være netværksudstyr, køling, jord, fiber, indkøb, konstruktion eller blot at finde nok folk, der ved, hvordan man samler alt dette.

Og når du løser én flaskehals, bliver en anden mere synlig. Det er, hvad der sker, når efterspørgslen er så meget større end udbuddet.

Så jeg vil ikke satse på én permanent flaskehals. Jeg tror, den vigtigere evne er at kunne tilpasse sig, efterhånden som flaskehalsen skifter.

Det er også grunden til, at jeg ikke tror, nogen har den endelige spillebog for AI-infrastruktur lige nu. Folkene, der bygger den, finder ud af det, mens de skalerer, og de gør begge dele utroligt hurtigt.

Tak for det gode interview, læsere, der ønsker at lære mere, bør besøge NetBox Labs.