Kris Beevers, VD och medgrundare, Netbox Labs – Intervjuserie

Kris Beevers, VD och medgrundare av NetBox Labs är en teknikentreprenör och veteran inom infrastrukturprogramvara med mer än två decennier av erfarenhet av att bygga företag och plattformar inriktade på nätverk, molninfrastruktur och automatisering. Innan han ledde NetBox Labs grundade Beevers NS1 år 2013 och var dess VD i nästan ett decennium, och byggde företaget till en framstående leverantör av nätverksautomatisering och teknik för hantering av applikationstrafik innan det förvärvades av IBM år 2023. Som en del av den transaktionen spinades NetBox Labs ut från NS1 som ett självständigt företag med IBM som investerare. Tidigare i sin karriär hade Beevers seniora ingenjörs- och arkitektroller på Internap Network Services och Voxel, och han var även medgrundare till SolidJoint Research.

NetBox Labs utvecklar en infrastruktur‑intelligensplattform avsedd att hjälpa organisationer att modellera, driva, automatisera och styra allt mer komplexa nätverk och IT‑infrastruktur. Företaget är den kommersiella förvaltaren av NetBox, det mycket använda öppna källkods‑nätverks‑ och infrastruktursystemet som används av mer än 10 000 organisationer. Plattformen kombinerar en infrastrukturgraf och sanningskälla med operativ intelligens, automatisering, AI‑assisterad orkestrering och styrningsfunktioner som möjliggör för både ingenjörer och AI‑agenter att säkert interagera med infrastrukturen. NetBox Labs stödjer moln‑, självhanterade företags‑, hybrid‑ och luftgap‑distributioner, samtidigt som den integreras med verktyg som Ansible, Terraform, Nornir och pipelines för kontinuerlig integration och distribution.

Du medgrundade NS1 år 2013 och tillbringade nästan ett decennium med att bygga företaget innan det förvärvades av IBM, varpå NetBox Labs uppstod som ett självständigt företag. Vilka lärdomar från att bygga NS1 påverkade varför du grundade NetBox Labs, och hur har infrastrukturproblemet du försöker lösa förändrats i AI‑eran?

En sak jag lärde mig när jag byggde NS1 är att infrastrukturproblem sällan förblir tydligt avgränsade. DNS var vår del av stacken, men våra kunder drev dessa otroligt komplexa miljöer där nätverk, datacenter, applikationer och automatisering alla var beroende av varandra. Ju mer tid jag tillbringade med dessa team, desto tydligare blev det att förstå själva infrastrukturen var ett mycket större problem.

Det var en stor del av det som lockade mig till NetBox. Det fanns redan detta mycket använda open‑source‑projekt och en gemenskap av ingenjörer som använde det för att modellera vad de hade, hur det var kopplat och hur det skulle se ut. Vi såg en möjlighet att bygga vidare på den grunden.

Det som har förändrats med AI är främst takten och skalan. Infrastrukturteam blir ombedda att bygga enorma miljöer otroligt snabbt, samtidigt som den underliggande tekniken förändras lika snabbt. Samtidigt börjar vi automatisera mer av driften av den infrastrukturen, vilket innebär en spännande framtid. När AI tillämpas på infrastruktur inser IT‑team att de måste ha bra, realtidsdata om sin infrastruktur för att kunna automatisera, och de behöver veta hur det avsedda tillståndet ser ut så att AI kan hjälpa dem att identifiera när den operativa infrastrukturen avviker från planen.

Så lärdomen från NS1 gäller fortfarande. Innan du kan automatisera infrastruktur på ett bra sätt måste du förstå den. AI gör bara att det blir mycket mer brådskande att få det rätt.

Under större delen av det senaste decenniet gjorde molnberäkning det möjligt för utvecklare och infrastrukturteam att abstrahera bort den fysiska hårdvaran under sina applikationer. Varför vänder AI den trenden och tvingar DevOps, Site Reliability Engineering (SRE) och nätverksingenjörer att återigen tänka på ström, kylning, rack, kablage och fysisk nätverkning?

Molnet lärde många av oss att behandla infrastruktur som i praktiken oändlig. Du bad om beräkningskapacitet och den dök upp. Du behövde inte nödvändigtvis bry dig om var servern var, hur den fick ström, hur den kyldes eller hur alla fysiska komponenter under den sattes ihop.

AI‑infrastruktur tillåter dig egentligen inte att göra så.

När du bygger dessa miljöer börjar du med några ganska fysiska frågor. Hur mycket mark har jag? Hur mycket ström kan jag få? Vilken typ av kylning kan jag stödja? Därefter går du in på rack, GPU‑servrar, switchar, fiberoptisk kablage och så småningom det logiska lagret, IP‑adresser, konfigurationer och mjukvara.

Dessa saker är alla beroende av varandra. Du kan inte bestämma hur många rack du ska distribuera utan att förstå ström- och kylningstäthet. Du kan inte tänka på GPU:erna oberoende av nätverket som kopplar dem.

Det tvingar discipliner som i åratal har rört sig bort från det fysiska lagret att åter engagera sig i det. Abstraktionen är inte försvunnen, men de fysiska begränsningarna under den blir plötsligt mycket viktigare.

AI‑datacenter diskuteras i allt högre grad i gigawatt‑skala. Vad förändras i grunden operativt när infrastrukturen går från konventionella företags‑ eller molnmiljöer till anläggningar som är utformade kring enorma GPU‑kluster?

Gigawatt‑skala är helt astronomisk. Men medan skalan uppenbarligen är annorlunda tror jag att den mer intressanta skillnaden är den mängd samordning som krävs.

Tänk på vad som måste ske för att sätta ett 300‑megawatt‑datacenter i drift. Du behöver mark och el. Sedan måste du designa anläggningen och anskaffa rack, GPU‑servrar, switchar, fiber, kraftinfrastruktur och kylutrustning, ofta från helt olika leverantörer med helt olika sätt att beskriva sina produkter. All den utrustningen måste levereras, tas emot, monteras i rack, kablas, konfigureras, testas och slutligen överlämnas för träning eller inferens.

Och marken rör sig under dig medan du gör det. GPU‑arkitekturer förändras. Nätverk förändras. Kylkrav förändras. De komponenter som är tillgängliga om sex månader kanske inte är samma som du designade kring idag.

Så små ineffektiviteter multipliceras mycket snabbt. Jag tillbringade nyligen tid med en av världens största tillverkare av fiberoptiska kablar, och de berättade att ett av deras största affärsproblem är returer eftersom kunder beställer fel kabellängder. Det låter nästan trivialt tills du beställer hundratusentals kablar.

I den här skalan blir infrastrukturdrift ett enormt logistik- och restriktionsuppfyllande problem. De företag som lyckas med detta är de som blir mycket skickliga på att föra med sig korrekt designdata genom hela inköps-, implementerings- och driftsprocessen.

Du har sagt att det i praktiken inte finns någon etablerad spelbok eller talangpipeline för att driva infrastruktur i denna skala. Vilka färdigheter är för närvarande svårast att hitta, och var förväntar du dig att de största talangbristen kommer att uppstå när AI‑infrastrukturen expanderar?

Det finns förmodligen bara några hundra personer i världen just nu som verkligen vet hur man bygger den här typen av infrastruktur i denna hastighet och skala. Och de flesta av dem är ganska upptagna med att faktiskt göra det.

Det är en del av det som gör detta ögonblick ovanligt. Det finns ingen mogen kunskapsbas som du bara kan gå och studera. Personerna som gör detta lär sig av varandra och löser problem i realtid. Och eftersom tekniken förändras så snabbt blir vissa av dessa lärdomar föråldrade ganska fort.

Jag tror att bristen därför är större än någon enskild befattning. Vi behöver personer som förstår nätverk, beräkning och automation, men i allt högre grad också förstår den fysiska miljö där dessa system lever. Kraft, kylning, anläggningsdesign, leveranskedja och fältoperationer blir en del av samma samtal.

De personer som kan överskrida några av dessa gränser kommer att vara otroligt värdefulla. Men jag tror inte att vi ens har fastställt hur alla dessa roller ser ut ännu. Talangmodellen byggs parallellt med infrastrukturen.

När gränserna mellan mjukvara, nätverk, anläggningar, energi och datacenter‑engineering börjar suddas ut, vilka nya tekniska roller eller hybridkompetenser förväntar du dig att uppstå?

Jag tror inte att vi vet hur alla dessa roller kommer att se ut ännu. Vad vi vet är att de som bygger denna infrastruktur måste tänka över ett mycket bredare spektrum av problem än de gjorde tidigare.

Du tänker inte bara på beräkning eller nätverk isolerat. Kraft, kylning, fysisk design, leveranskedja, nätverk och automation måste alla samverka för att få dessa miljöer i drift och hålla dem igång.

Jag tror fortfarande att vi kommer att behöva personer med djup expertis inom var och en av dessa områden. Men i allt högre grad måste de också förstå hur beslut inom deras område påverkar resten av infrastrukturen. Och eftersom så mycket av detta arbete måste gå snabbare kommer förmågan att automatisera att bli viktigare inom fler av dessa discipliner.

AI‑agenter börjar diagnostisera problem, generera konfigurationer och automatisera delar av infrastrukturdriften. Vilka ansvarsområden tror du att AI realistiskt kommer att ta över från infrastrukturingenjörer, och vilka kommer att bli ännu mer beroende av djup mänsklig expertis?

Jag tror att mycket av det arbete där indata, önskat resultat och gränser är tydliga kommer i allt högre grad att hanteras av AI. Att generera konfigurationer är ett uppenbart exempel. Detsamma gäller att diagnostisera vanliga problem, kontrollera om infrastrukturen stämmer överens med den avsedda designen, eller så småningom åtgärda vissa problem när man har tillräcklig säkerhet kring vad som gick fel och vad som är ett säkert svar.

Där människor blir viktigare är när svaret inte är uppenbart.

Infrastrukturen kan gå sönder på märkliga sätt. En fiber blir avklippt. En enhet börjar bete sig annorlunda än vad designen föreskriver. En förändring får en oväntad effekt någon annanstans i miljön. AI kan hjälpa en ingenjör att förstå dessa situationer mycket snabbare, men du behöver fortfarande personer som förstår systemet tillräckligt djupt för att kunna besluta vad som ska göras härnäst.

Jag tror att det är den intressanta förändringen. Ingenjörer kommer sannolikt att spendera mindre tid på repetitiv konfiguration och felsökning och mer tid på att definiera avsikt, designa system, sätta gränser för automation och hantera de genuint nya problemen. Allt detta arbete kommer att förstärkas av AI, men drivas av människor.

Det gör expertis mer värdefull, inte mindre. Ingenjören som verkligen förstår varför infrastrukturen fungerar som den gör kommer att vara otroligt viktig när automationen saknar ett uppenbart svar.

NetBox Labs har argumenterat för att AI‑system som hanterar infrastruktur behöver en auktoritativ modell av enheter, anslutningar, beroenden och andra fysiska och logiska relationer. Varför är den här typen av infrastrukturkontext så viktig när man går från AI‑assistenter som ger rekommendationer till agenter som faktiskt kan vidta åtgärder?

Den stora skillnaden är att när en agent kan agera, får fel verkliga konsekvenser.

En infrastruktur‑agent behöver mer än ett ögonblicksbild av vad en enhet gör just nu. Den måste förstå omgivningen: vad som finns, hur saker är anslutna, vad som förändrats nyligen och, viktigast av allt, hur infrastrukturen förväntas se ut.

Ta exempelvis felsökning av ett anslutningsproblem. Det räcker inte att veta att en enhet är oåtkomlig. Du vill att agenten ska kunna spåra kabelvägen, förstå beroendena kring den enheten, titta på senaste förändringarna och avgöra vad mer kan påverkas innan den föreslår nästa steg.

Det är egentligen grunden som vi har byggt i åratal på NetBox Labs, att ge team en exakt modell av både den fysiska och logiska infrastrukturen, tillsammans med avsikten bakom hur den ska fungera.

Men data ensam räcker inte. Du måste också bestämma vad agenten får göra på egen hand, vad som kräver godkännande av en person, och hur varje åtgärd spåras och valideras.

Infrastruktur är inte som kod där en dålig förändring alltid kan återställas rent. En felaktig förändring kan slå ner en verksamhet. Så när vi går från AI som bara talar om för en ingenjör vad den tror till AI som faktiskt kan utföra arbetet, blir både kontext och kontroll mycket viktigare.

I ditt senaste CIO-artikeln, “Varför jag, VD:n, personligen bygger vår AI‑strategi,” hävdade du att AI är för viktig för företagsledare att bara delegera och beskrev att du personligen prototypade med AI‑verktyg. Hur har ditt praktiska arbete med dessa system förändrat ditt tänkande kring vad AI realistiskt kan automatisera i infrastruktur‑operationer?

Att vara praktiskt involverad gör att du blir mycket mindre intresserad av den teoretiska diskussionen.

Jag har lagt mycket tid på att faktiskt bygga med dessa verktyg, oftast nuförtiden genom att prototypa eller till och med bygga kompletta produkter med Claude Code. Man lär sig snabbt att det är en enorm skillnad mellan att se en imponerande demo och att bygga något man faktiskt litar på för att utföra användbart arbete.

Du får också en känsla för var tekniken rör sig mycket snabbare än vad du kan få genom att bara läsa om den. Saker som jag för sex månader sedan skulle ha ansett svåra att automatisera kan plötsligt vara ganska enkla. Samtidigt ser du mycket tydligt var kontext, omdöme och struktur fortfarande saknas.

Det har påverkat hur jag tänker kring infrastruktur‑operationer. Jag är mycket optimistisk kring hur mycket operativt arbete vi kan automatisera, men jag tror att vi fortfarande är långt ifrån ren autonomi som slutmål.

Frågan jag bryr mig om är mycket mer grundläggande. Hjälper detta oss att driva infrastrukturen snabbare, mer pålitligt eller mer effektivt? Om ja, fantastiskt. Om nej, spelar det ingen roll hur sofistikerad AI:n bakom den är.

Allt eftersom AI‑datacenter blir alltmer begränsade av tillgänglig el och kylbehov, kan infrastruktur‑engineering utvecklas från att främst hantera beräkningsresurser till aktivt samordna arbetsbelastningar med energi och fysisk kapacitet?

Ja, och vi börjar redan se det. Vi har ett internt uttryck, “turbiner på parkeringsplatsen”, som kom från ett riktigt samtal med ett av teamen som bygger hyperskala‑AI‑infrastruktur. De tog i bruk infrastruktur så snabbt att elnätet inte kunde hålla jämna steg, så de köpte bokstavligen turbiner och placerade dem på parkeringsplatsen för att få tillräckligt med ström snabbt.

Det är den typ av miljö som dessa team arbetar i. När el blir en av dina primära begränsningar måste du bli mycket smartare i hur du använder det som finns tillgängligt. Efterfråge‑respons, där operatörer aktivt samordnar AI‑arbetsbelastningar som svar på förändringar i elnätet, sker redan och blir en allt viktigare förmåga för team som driver energikrävande infrastruktur.

Inte alla arbetsbelastningar har samma krav. Latenskänslig inferens kan behöva vara online, medan viss träning eller batch‑arbetsbelastning kan flyttas eller pausas när elen är begränsad. Jag tror att vi i allt högre grad kommer att se infrastrukturteam som hanterar beräkning, el och fysisk kapacitet som delar av samma operativa problem.

Ser du framåt, tror du att den största flaskhalsen för att skala AI i slutändan kommer att vara GPU:er och modellutveckling, eller den mycket bredare utmaningen att hitta tillräckligt med el, fysisk infrastruktur, nätverkskapacitet, automation och kompetenta ingenjörer för att driva allt bakom dem?

Jag tror inte att det blir en enda flaskhals.

Att bygga AI‑infrastruktur i den hastighet och skala som marknaden kräver just nu är i princip ett problem med att tillfredsställa begränsningar. Vid varje givet ögonblick är något den primära begränsningen.

Under en period pratade alla om GPU:er. Ström är uppenbarligen en enorm flaskhals nu. Men det kan också vara nätverksutrustning, kylning, mark, fiber, inköp, byggnation eller helt enkelt att hitta tillräckligt många personer som vet hur man sätter ihop allt detta.

Och när du löser en begränsning blir en annan mer synlig. Det är vad som händer när efterfrågan är så mycket större än utbudet.

Så jag skulle inte satsa på en enda permanent flaskhals. Jag tror att den viktigare förmågan är att kunna anpassa sig när begränsningen förflyttar sig.

Det är också därför jag inte tror att någon har den definitiva spelboken för AI-infrastruktur just nu. De som bygger den löser detta medan de skalar, och de gör båda delarna otroligt snabbt.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka NetBox Labs.