Kris Beevers, CEO en mede-oprichter, Netbox Labs – Interviewreeks

Kris Beevers, CEO en mede-oprichter van NetBox Labs, is een technologie‑ondernemer en infrastructuur‑software‑veteraan met meer dan twee decennia ervaring in het bouwen van bedrijven en platformen die zich richten op netwerken, cloud‑infrastructuur en automatisering. Voor hij NetBox Labs leidde, richtte Beevers in 2013 NS1 op en was bijna tien jaar lang CEO, waarbij hij het bedrijf uitbouwde tot een vooraanstaande leverancier van netwerk‑automatisering en applicatie‑verkeersbeheer‑technologie, voordat het in 2023 werd overgenomen door IBM. In het kader van die transactie werd NetBox Labs afgesplitst van NS1 als een onafhankelijk bedrijf met IBM als investeerder. Vroeger in zijn loopbaan bekleedde Beevers senior engineering‑ en architectuurfuncties bij Internap Network Services en Voxel, en hij richtte ook SolidJoint Research op.

NetBox Labs ontwikkelt een infrastructuur‑intelligentieplatform dat organisaties helpt om steeds complexere netwerken en IT‑infrastructuur te modelleren, te exploiteren, te automatiseren en te beheren. Het bedrijf is de commerciële beheerder van NetBox, het breed geadopteerde open‑source netwerk‑ en infrastructuursysteem dat door meer dan 10.000 organisaties wordt gebruikt. Het platform combineert een infrastructuur‑grafiek en bron‑van‑waarheid met operationele intelligentie, automatisering, AI‑ondersteunde orkestratie en governance‑functionaliteiten die zowel engineers als AI‑agenten in staat stellen veilig met de infrastructuur te interageren. NetBox Labs ondersteunt cloud‑, zelf‑beheerde enterprise‑, hybride‑ en air‑gapped‑implementaties, terwijl het integreert met tools zoals Ansible, Terraform, Nornir en continue integratie‑ en implementatie‑pijplijnen.

U richtte NS1 op in 2013 en heeft bijna een decennium besteed aan het opbouwen van het bedrijf voordat het werd overgenomen door IBM, waarna NetBox Labs als een onafhankelijk bedrijf voortkwam. Welke lessen uit het bouwen van NS1 hebben uw beslissing om NetBox Labs op te richten beïnvloed, en hoe is het infrastructuurprobleem dat u probeert op te lossen veranderd in het AI‑tijdperk?

Een ding dat ik leerde tijdens het bouwen van NS1 is dat infrastructuurproblemen zelden netjes geïsoleerd blijven. DNS was ons onderdeel van de stack, maar onze klanten exploiteerden deze ongelooflijk complexe omgevingen waarin netwerken, datacenters, applicaties en automatisering allemaal van elkaar afhankelijk waren. Hoe meer tijd ik met die teams doorbracht, hoe duidelijker werd dat het begrijpen van de infrastructuur zelf een veel groter probleem was.

Dat was een groot deel van wat mij aantrok tot NetBox. Er bestond al dit breed geadopteerde open‑source project en een gemeenschap van engineers die het gebruikten om te modelleren wat ze hadden, hoe het verbonden was en hoe het eruit zou moeten zien. Wij zagen een kans om op die basis voort te bouwen.

Wat AI heeft veranderd, is voornamelijk het tempo en de schaal. Infrastructuurteams krijgen de opdracht om enorme omgevingen buitengewoon snel op te zetten, terwijl de onderliggende technologie even snel verandert. Tegelijkertijd beginnen we meer van de werking van die infrastructuur te automatiseren, wat een veelbelovende toekomst vertegenwoordigt. Naarmate AI op infrastructuur wordt toegepast, realiseren IT‑teams zich dat ze goede, realtime gegevens over hun infrastructuur nodig hebben om te automatiseren, en ze moeten weten hoe de beoogde toestand eruitziet zodat AI hen kan helpen te identificeren wanneer de operationele infrastructuur afwijkt van het plan.

De les van NS1 blijft dus van toepassing. Voordat u infrastructuur goed kunt automatiseren, moet u deze eerst begrijpen. AI maakt het alleen nog urgenter om dat goed te doen.

Voor een groot deel van het afgelopen decennium stelde cloud computing ontwikkelaars en infrastructuurteams in staat om de fysieke hardware onder hun applicaties te abstraheren. Waarom keert AI die trend nu om en dwingt DevOps, Site Reliability Engineering (SRE) en netwerk‑engineers om opnieuw na te denken over stroom, koeling, racks, bekabeling en fysieke netwerken?

Cloud leerde velen van ons om infrastructuur te beschouwen als praktisch oneindig. U vroeg om rekenkracht en die verscheen. U hoefde zich niet per se zorgen te maken waar de server zich bevond, hoe deze werd gevoed, gekoeld of hoe al die fysieke onderdelen eronder samenkwamen.

AI‑infrastructuur laat dat eigenlijk niet meer toe.

Wanneer u deze omgevingen opbouwt, begint u met nogal fysieke vragen. Hoeveel grond heb ik beschikbaar? Hoeveel stroom kan ik krijgen? Wat voor soort koeling kan ik ondersteunen? Vanaf daar gaat het om racks, GPU‑servers, switches, glasvezelbekabeling en uiteindelijk de logische laag: IP‑adressen, configuraties en software.

Al die zaken hangen van elkaar af. U kunt niet bepalen hoeveel racks u gaat inzetten zonder inzicht in stroom‑ en koel‑dichtheid. U kunt niet over de GPU’s nadenken los van het netwerk dat ze verbindt.

Dat dwingt disciplines die jaren hebben geprobeerd zich van de fysieke laag te verwijderen om er weer mee bezig te gaan. De abstractie is niet verdwenen, maar de fysieke beperkingen eronder zijn ineens veel belangrijker.

AI‑datacenters worden steeds vaker besproken op gigawatt‑schaal. Wat verandert er fundamenteel operationeel wanneer infrastructuur verschuift van conventionele enterprise‑ of cloud‑omgevingen naar faciliteiten die zijn ontworpen rond enorme GPU‑clusters?

Gigawatt‑schaal is absoluut astronomisch. Maar hoewel de schaal duidelijk anders is, denk ik dat het interessantere verschil de hoeveelheid coördinatie is die nodig is.

Denk aan wat er moet gebeuren om een datacenter van 300 megawatt operationeel te krijgen. Je hebt grond en stroom nodig. Vervolgens moet je de faciliteit ontwerpen en racks, GPU-servers, switches, glasvezel, stroominfrastructuur en koelingsapparatuur aanschaffen, vaak van volledig verschillende leveranciers met totaal verschillende manieren om hun producten te beschrijven. Al die apparatuur moet aankomen, worden ontvangen, in racks worden geplaatst, bekabeld, geconfigureerd, getest en uiteindelijk worden overgedragen voor training of inferentie.

En de grond verandert onder je voeten terwijl je dat doet. GPU-architecturen veranderen. Netwerken veranderen. Koelingseisen veranderen. De componenten die over zes maanden beschikbaar zijn, zijn mogelijk niet dezelfde als die je vandaag hebt ontworpen.

Kleine inefficiënties stapelen zich dus heel snel op. Ik heb onlangs tijd doorgebracht bij een van de grootste fabrikanten van glasvezelkabels ter wereld, en ze vertelden me dat een van hun grootste zakelijke problemen retourzendingen zijn omdat klanten de verkeerde kabellengtes bestellen. Dat klinkt bijna triviaal totdat je honderden duizenden kabels bestelt.

Op deze schaal wordt infrastructuurbeheer een gigantisch logistiek en constraint‑satisfactie‑probleem. De bedrijven die dit goed doen, zijn degenen die zeer goed worden in het meenemen van nauwkeurige ontwerpinformatie gedurende de gehele inkoop, uitrol en exploitatie.

U heeft gezegd dat er feitelijk geen vastgesteld playbook of talent‑pipeline bestaat voor het exploiteren van infrastructuur op deze schaal. Welke vaardigheden zijn momenteel het moeilijkst te vinden, en waar verwacht u de grootste tekorten aan talent te zien ontstaan naarmate AI‑infrastructuur uitbreidt?

Er zijn waarschijnlijk slechts enkele honderden mensen in de wereld die echt weten hoe ze dit soort infrastructuur op deze snelheid en schaal moeten bouwen. En de meesten van hen zijn behoorlijk druk met het daadwerkelijk doen ervan.

Dat is deels wat dit moment zo ongewoon maakt. Er is geen volwassen kennisbasis die je gewoon kunt bestuderen. De mensen die dit doen, leren van elkaar en vinden dingen in realtime uit. En omdat de technologie zo snel verandert, raken sommige van die lessen al snel verouderd.

Ik denk dat het tekort daarom groter is dan één functietitel. We hebben mensen nodig die netwerken, compute en automatisering begrijpen, maar steeds vaker ook de fysieke omgeving waarin die systemen leven. Stroom, koeling, faciliteitsontwerp, toeleveringsketen en veldoperaties worden onderdeel van hetzelfde gesprek.

De mensen die enkele van die grenzen kunnen overstijgen, zullen ongelooflijk waardevol zijn. Maar ik denk niet dat we al hebben vastgesteld hoe al die rollen er precies uitzien. Het talentmodel wordt gebouwd parallel aan de infrastructuur.

Naarmate de grenzen tussen software, netwerken, faciliteiten, energie en datacenter‑engineering vervagen, welke nieuwe technische rollen of hybride vaardigheidssets verwacht u dat zullen ontstaan?

Ik denk niet dat we weten hoe al die rollen er uiteindelijk uit zullen zien. Wat we wel weten is dat de mensen die deze infrastructuur bouwen, over een veel breder scala aan problemen moeten nadenken dan voorheen.

U denkt niet alleen aan compute of netwerken in isolatie. Stroom, koeling, fysiek ontwerp, toeleveringsketen, netwerken en automatisering moeten allemaal samenkomen om deze omgevingen operationeel te krijgen en draaiende te houden.

Ik blijf denken dat we mensen nodig zullen hebben met diepgaande expertise in elk van die gebieden. Maar steeds vaker moeten ze ook begrijpen hoe beslissingen in hun domein de rest van de infrastructuur beïnvloeden. En omdat zoveel van dit werk sneller moet gebeuren, zal het vermogen om te automatiseren een rol spelen in meer van die disciplines.

AI‑agents beginnen problemen te diagnosticeren, configuraties te genereren en delen van infrastructuuroperaties te automatiseren. Welke verantwoordelijkheden denkt u dat AI realistisch zal overnemen van infrastructuur‑engineers, en welke zullen nog meer afhankelijk worden van diepgaande menselijke expertise?

Ik denk dat veel van het werk waarbij de inputs, het gewenste resultaat en de grenzen duidelijk zijn, steeds meer door AI zal worden afgehandeld. Het genereren van configuraties is een voor de hand liggend voorbeeld. Ook het diagnosticeren van veelvoorkomende problemen, controleren of de infrastructuur overeenkomt met het beoogde ontwerp, of uiteindelijk bepaalde issues oplossen wanneer er voldoende vertrouwen is over wat er mis ging en wat de veilige reactie is, valt hieronder.

Waar mensen belangrijker worden, is wanneer het antwoord niet voor de hand ligt.

Infrastructuur faalt op vreemde manieren. Een glasvezel wordt doorgesneden. Een apparaat gedraagt zich anders dan het ontwerp voorschrijft. Een wijziging heeft een onverwacht effect ergens anders in de omgeving. AI kan een engineer helpen die situaties veel sneller te begrijpen, maar je hebt nog steeds mensen nodig die het systeem diep genoeg kennen om te beslissen wat er vervolgens moet gebeuren.

Ik denk dat dat de interessante verschuiving is. Engineers zullen waarschijnlijk minder tijd besteden aan repetitieve configuratie en probleemoplossing en meer tijd aan het definiëren van intentie, het ontwerpen van systemen, het stellen van grenzen voor automatisering en het afhandelen van echt nieuwe problemen. Al dat werk zal worden aangevuld door AI, maar wordt gedreven door mensen.

Dat maakt expertise waardevoller, niet minder. De engineer die echt begrijpt waarom de infrastructuur werkt zoals hij werkt, zal ongelooflijk belangrijk worden wanneer de automatisering geen voor de hand liggend antwoord heeft.

NetBox Labs heeft betoogd dat AI‑systemen die infrastructuur beheren een gezaghebbend model van apparaten, verbindingen, afhankelijkheden en andere fysieke en logische relaties nodig hebben. Waarom is dit type infrastructuur‑context zo belangrijk bij de overgang van AI‑assistenten die aanbevelingen doen naar agenten die daadwerkelijk acties kunnen uitvoeren?

Het grote verschil is dat zodra een agent kan handelen, fouten echte consequenties hebben.

Een infrastructuur‑agent heeft meer nodig dan een momentopname van wat een apparaat op dit moment doet. Hij moet de omgeving eromheen begrijpen: wat er bestaat, hoe zaken met elkaar verbonden zijn, wat recent is veranderd en, belangrijker nog, hoe de infrastructuur eruit zou moeten zien.

Neem bijvoorbeeld het oplossen van een verbindingsprobleem. Het is niet voldoende om te weten dat een apparaat niet bereikbaar is. Je wilt dat de agent het kabelpad kan volgen, de afhankelijkheden rond dat apparaat begrijpt, recente wijzigingen bekijkt en bepaalt wat nog meer getroffen kan worden voordat hij voorstelt wat er vervolgens moet gebeuren.

Dat is echt de basis waaraan we bij NetBox Labs jaren hebben gewerkt, door teams een nauwkeurig model te bieden van zowel de fysieke als logische infrastructuur, samen met de intentie achter hoe deze moet functioneren.

Maar alleen de gegevens zijn niet voldoende. Je moet ook bepalen wat de agent zelfstandig mag doen, wat een goedkeuring door een persoon vereist, en hoe elke actie wordt bijgehouden en gevalideerd.

Infrastructuur is niet zoals code, waarbij een slechte wijziging altijd netjes kan worden teruggedraaid. Een slechte wijziging kan een operatie stilleggen. Dus naarmate we overstappen van AI die een engineer vertelt wat hij denkt naar AI die het werk daadwerkelijk kan uitvoeren, worden zowel context als controle veel belangrijker.

In uw recente CIO‑artikel, “Why I, the CEO, am personally building our AI strategy,” u betoogde dat AI te belangrijk is voor bedrijfsleiders om simpelweg te delegeren en beschreef dat u persoonlijk prototypeert met AI‑tools. Hoe heeft het hands‑on werken met deze systemen uw denken veranderd over wat AI realistisch kan automatiseren in infrastructuur‑operaties?

Hands‑on werken maakt je veel minder geïnteresseerd in de theoretische discussie.

Ik heb veel tijd besteed aan het daadwerkelijk bouwen met deze tools, tegenwoordig meestal aan prototypen of zelfs het bouwen van volledige producten met Claude Code. Je leert al snel dat er een enorm verschil is tussen het zien van een indrukwekkende demo en het bouwen van iets waar je echt op vertrouwt om nuttig werk te verrichten.

Je ontwikkelt ook een gevoel voor waar de technologie naartoe gaat, veel sneller dan je kunt afleiden uit lezen. Dingen die ik zes maanden geleden nog als moeilijk te automatiseren beschouwde, kunnen plotseling tamelijk eenvoudig zijn. Tegelijkertijd zie je heel duidelijk waar context, oordeel en structuur nog ontbreken.

Dat heeft mijn manier van denken over infrastructuur‑operaties beïnvloed. Ik ben zeer optimistisch over hoeveel operationeel werk we kunnen automatiseren, maar ik denk dat we nog ver verwijderd zijn van pure autonomie als einddoel.

De vraag die mij bezighoudt is veel basaler. Helpt dit ons om infrastructuur sneller, betrouwbaarder of effectiever te beheren? Als dat zo is, geweldig. Als dat niet zo is, maakt het niet uit hoe geavanceerd de AI erachter is.

Naarmate AI‑datacenters steeds meer beperkt worden door de beschikbaarheid van elektriciteit en koelvereisten, zou infrastructuur‑engineering kunnen evolueren van voornamelijk het beheren van rekenresources naar het actief coördineren van workloads met energie en fysieke capaciteit?

Ja, en we beginnen het al te zien. We hebben intern een uitdrukking, “turbines in the parking lot”, die voortkwam uit een echt gesprek met een van de teams die hyperscale AI‑infrastructuur bouwen. Ze brachten de infrastructuur zo snel online dat het net niet kon bijhouden, dus kochten ze letterlijk turbines en plaatsten die op de parkeerplaats om snel genoeg stroom te krijgen.

Dat is het soort omgeving waarin deze teams opereren. Wanneer stroom een van je belangrijkste beperkingen wordt, moet je veel slimmer omgaan met wat beschikbaar is. Vraag‑zijde respons, waarbij operators AI‑workloads actief coördineren als reactie op verschuivingen in het elektriciteitsnet, gebeurt al en wordt een steeds belangrijkere capaciteit voor teams die energie‑intensieve infrastructuur beheren.

Niet elke workload heeft dezelfde eisen. Latentie‑gevoelige inferentie moet mogelijk online blijven, terwijl sommige trainings‑ of batch‑workloads kunnen worden verplaatst of gepauzeerd wanneer de stroom beperkt is. Ik denk dat we steeds vaker zullen zien dat infrastructuur‑teams compute, stroom en fysieke capaciteit beheren als onderdelen van hetzelfde operationele probleem.

Kijkend naar de toekomst, denk je dat de grootste bottleneck voor het opschalen van AI uiteindelijk GPUs en modelontwikkeling zal zijn, of de veel bredere uitdaging om voldoende stroom, fysieke infrastructuur, netwerkcapaciteit, automatisering en bekwame engineers te vinden om alles erachter te laten functioneren?

Ik denk niet dat er één bottleneck zal zijn.

Het bouwen van AI‑infrastructuur op de snelheid en schaal die de markt nu verlangt, is in wezen een constraint‑satisfaction‑probleem. Op elk moment is er iets dat de primaire beperking vormt.

Een tijdje sprak iedereen over GPU’s. Vermogen is uiteraard nu een enorme knelpunt. Maar het kan ook netwerkinfrastructuur, koeling, grond, glasvezel, inkoop, bouw of simpelweg het vinden van voldoende mensen die weten hoe al dit samen te brengen, zijn.

En zodra je één beperking oplost, wordt een andere duidelijker zichtbaar. Dat gebeurt wanneer de vraag veel groter is dan het aanbod.

Dus ik zou niet op één permanent knelpunt inzetten. Ik denk dat de belangrijkere eigenschap is om zich aan te kunnen passen terwijl de beperking verschuift.

Dat is ook waarom ik niet denk dat er momenteel iemand een definitieve handleiding voor AI-infrastructuur heeft. De mensen die het bouwen, komen erachter terwijl ze opschalen, en ze doen beide ongelooflijk snel.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen NetBox Labs bezoeken.