Kris Beevers, CEO und Mitbegründer, Netbox Labs – Interviewreihe

Kris Beevers, CEO und Mitbegründer, NetBox Labs ist ein Technologieunternehmer und Veteran im Bereich Infrastruktur‑Software mit mehr als zwei Jahrzehnten Erfahrung im Aufbau von Unternehmen und Plattformen, die sich auf Netzwerk, Cloud‑Infrastruktur und Automatisierung konzentrieren. Vor seiner Leitung von NetBox Labs gründete Beevers 2013 NS1 und war fast ein Jahrzehnt lang dessen CEO, wobei er das Unternehmen zu einem führenden Anbieter von Netzwerkautomatisierung und Anwendungs‑Traffic‑Management‑Technologie ausbaute, bevor es 2023 von IBM übernommen wurde. Im Rahmen dieser Transaktion wurde NetBox Labs als eigenständiges Unternehmen aus NS1 ausgegliedert, wobei IBM als Investor auftritt. Früher in seiner Laufbahn hatte Beevers leitende Ingenieur‑ und Architekturpositionen bei Internap Network Services und Voxel inne und gründete zudem SolidJoint Research.

NetBox Labs entwickelt eine Infrastruktur‑Intelligenz‑Plattform, die Organisationen dabei unterstützt, immer komplexere Netzwerke und IT‑Infrastrukturen zu modellieren, zu betreiben, zu automatisieren und zu steuern. Das Unternehmen ist der kommerzielle Betreiber von NetBox, dem weit verbreiteten Open‑Source‑Netzwerk‑ und Infrastruktursystem, das von mehr als 10.000 Organisationen genutzt wird. Seine Plattform kombiniert einen Infrastrukturgrafen und eine Wahrheitsquelle mit operativer Intelligenz, Automatisierung, KI‑unterstützter Orchestrierung und Governance‑Funktionen, die sowohl Ingenieuren als auch KI‑Agenten eine sichere Interaktion mit der Infrastruktur ermöglichen. NetBox Labs unterstützt Cloud‑, selbstverwaltete Unternehmens‑, Hybrid‑ und air‑gapped‑Bereitstellungen und integriert sich in Werkzeuge wie Ansible, Terraform, Nornir sowie kontinuierliche Integrations‑ und Bereitstellungspipelines.

Sie haben NS1 im Jahr 2013 mitbegründet und fast ein Jahrzehnt damit verbracht, das Unternehmen aufzubauen, bevor es von IBM übernommen wurde, woraufhin NetBox Labs als eigenständiges Unternehmen entstand. Welche Lehren aus dem Aufbau von NS1 haben Sie dazu bewogen, NetBox Labs zu gründen, und wie hat sich das Infrastrukturproblem, das Sie lösen wollen, in der KI-Ära verändert?

Eine Sache, die ich beim Aufbau von NS1 gelernt habe, ist, dass Infrastrukturprobleme selten sauber abgegrenzt bleiben. DNS war unser Teil des Stacks, aber unsere Kunden betrieben diese unglaublich komplexen Umgebungen, in denen Netzwerke, Rechenzentren, Anwendungen und Automatisierung alle voneinander abhingen. Je mehr Zeit ich mit diesen Teams verbrachte, desto klarer wurde, dass das Verständnis der Infrastruktur selbst ein viel größeres Problem darstellt.

Das war ein großer Teil dessen, was mich zu NetBox zog. Es gab bereits dieses weit verbreitete Open‑Source‑Projekt und eine Community von Ingenieuren, die es nutzten, um zu modellieren, was sie hatten, wie es verbunden war und wie es aussehen sollte. Wir sahen die Gelegenheit, auf dieser Grundlage aufzubauen.

Was sich mit KI geändert hat, ist vor allem das Tempo und das Ausmaß. Infrastruktur‑Teams werden aufgefordert, riesige Umgebungen unglaublich schnell aufzubauen, während die zugrunde liegende Technologie ebenso rasch im Wandel ist. Gleichzeitig beginnen wir, mehr von dem Betrieb dieser Infrastruktur zu automatisieren, was eine spannende Zukunft darstellt. Wenn KI auf Infrastruktur angewendet wird, erkennen IT‑Teams, dass sie gute, Echtzeit‑Daten über ihre Infrastruktur benötigen, um darauf zu automatisieren, und sie müssen wissen, wie der gewünschte Zustand aussieht, damit KI ihnen helfen kann, zu erkennen, wann die operative Infrastruktur vom Plan abweicht.

Die Lehre aus NS1 gilt also weiterhin. Bevor Sie Infrastruktur gut automatisieren können, müssen Sie sie verstehen. KI macht es nur noch dringender, dies richtig zu machen.

In weiten Teilen des letzten Jahrzehnts ermöglichte Cloud‑Computing Entwicklern und Infrastruktur‑Teams, die physische Hardware unter ihren Anwendungen zu abstrahieren. Warum kehrt KI diesen Trend um und zwingt DevOps, Site Reliability Engineering (SRE) und Netzwerk‑Ingenieure dazu, wieder über Strom, Kühlung, Racks, Verkabelung und physisches Networking nachzudenken?

Die Cloud lehrte viele von uns, Infrastruktur als praktisch unendlich zu betrachten. Man forderte Rechenleistung an und sie erschien. Man musste sich nicht unbedingt darum kümmern, wo der Server stand, wie er versorgt, gekühlt wurde oder wie all die physischen Komponenten darunter zusammenwirkten.

KI‑Infrastruktur lässt das eigentlich nicht zu.

Wenn Sie diese Umgebungen aufbauen, beginnen Sie mit ziemlich konkreten Fragen. Wie viel Land habe ich? Wie viel Strom kann ich beziehen? Welche Art von Kühlung kann ich unterstützen? Von dort aus geht es weiter zu Racks, GPU‑Servern, Switches, Glasfaserkabeln und schließlich zur logischen Ebene mit IP‑Adressen, Konfigurationen und Software.

All diese Dinge hängen voneinander ab. Man kann nicht entscheiden, wie viele Racks man einsetzen will, ohne die Leistungs‑ und Kühlungsdichte zu verstehen. Man kann die GPUs nicht unabhängig vom Netzwerk, das sie verbindet, betrachten.

Das zwingt Fachbereiche, die Jahre damit verbracht haben, sich von der physischen Schicht zu entfernen, wieder damit zu beschäftigen. Die Abstraktion ist nicht verschwunden, aber die physischen Zwänge darunter werden plötzlich viel bedeutender.

KI‑Rechenzentren werden zunehmend im Gigawatt‑Maßstab diskutiert. Was ändert sich grundlegend im operativen Bereich, wenn Infrastruktur von herkömmlichen Unternehmens‑ oder Cloud‑Umgebungen zu Einrichtungen wechselt, die um riesige GPU‑Cluster herum gebaut sind?

Der Gigawatt‑Maßstab ist absolut astronomisch. Während der Umfang offensichtlich anders ist, halte ich den interessanteren Unterschied für das erforderliche Maß an Koordination.

Denken Sie darüber nach, was geschehen muss, um ein 300‑Megawatt‑Rechenzentrum in Betrieb zu nehmen. Sie benötigen Land und Strom. Dann müssen Sie die Anlage planen und Racks, GPU‑Server, Switches, Glasfaser, Strominfrastruktur und Kühlgeräte beschaffen, oft von völlig unterschiedlichen Anbietern mit völlig unterschiedlichen Produktdarstellungen. All diese Geräte müssen ankommen, empfangen, eingerackt, verkabelt, konfiguriert, getestet und schließlich für Training oder Inferenz übergeben werden.

Und während Sie das tun, bewegt sich der Boden unter Ihnen. GPU‑Architekturen ändern sich. Netzwerke ändern sich. Kühlungsanforderungen ändern sich. Die Komponenten, die in sechs Monaten verfügbar sind, können andere sein als die, die Sie heute einplanen.

Kleine Ineffizienzen summieren sich daher sehr schnell. Ich habe kürzlich Zeit mit einem der größten Glasfaserkabelhersteller der Welt verbracht, und sie sagten mir, dass eines ihrer größten Geschäftsprobleme Rücksendungen sind, weil Kunden die falschen Kabellängen bestellen. Das klingt fast trivial, bis man Hunderte von Tausenden Kabel bestellt.

In diesem Maßstab werden Infrastruktur‑Operationen zu einem riesigen Logistik‑ und Constraint‑Satisfaction‑Problem. Die Unternehmen, die das gut meistern, sind diejenigen, die sehr gut darin werden, genaue Designdaten durch den gesamten Beschaffungs‑, Bereitstellungs‑ und Betriebsprozess zu tragen.

Sie haben gesagt, dass es praktisch kein etabliertes Playbook oder Talent‑Pipeline für den Betrieb von Infrastruktur in diesem Maßstab gibt. Welche Fähigkeiten sind derzeit am schwersten zu finden, und wo erwarten Sie, dass die größten Fachkräftemangel entstehen, wenn die KI‑Infrastruktur expandiert?

Wahrscheinlich gibt es weltweit nur ein paar hundert Menschen, die wirklich wissen, wie man diese Art von Infrastruktur in diesem Tempo und Umfang baut. Und die meisten von ihnen sind ziemlich beschäftigt damit, es tatsächlich zu tun.

Das ist ein Teil dessen, was diesen Moment ungewöhnlich macht. Es gibt keinen ausgereiften Wissensbestand, den man einfach studieren kann. Die Menschen, die das tun, lernen voneinander und finden Dinge in Echtzeit heraus. Und weil die Technologie so schnell wechselt, werden einige dieser Lektionen ziemlich schnell veraltet.

Ich denke, der Mangel ist daher größer als jede einzelne Berufsbezeichnung. Wir benötigen Menschen, die Netzwerke, Rechenleistung und Automatisierung verstehen, aber zunehmend auch die physische Umgebung, in der diese Systeme leben. Strom, Kühlung, Anlagendesign, Lieferkette und Feldbetrieb werden Teil derselben Diskussion.

Die Menschen, die einige dieser Grenzen überschreiten können, werden unglaublich wertvoll sein. Aber ich glaube nicht, dass wir bereits festgelegt haben, wie all diese Rollen aussehen werden. Das Talentmodell wird parallel zur Infrastruktur aufgebaut.

Da die Grenzen zwischen Software, Netzwerk, Einrichtungen, Energie und Rechenzentrumstechnik zu verschwimmen beginnen, welche neuen technischen Rollen oder hybriden Kompetenzprofile erwarten Sie, dass sie entstehen?

Ich glaube nicht, dass wir bereits wissen, wie all diese Rollen aussehen werden. Was wir wissen, ist, dass die Menschen, die diese Infrastruktur bauen, über ein viel breiteres Spektrum an Problemen nachdenken müssen als zuvor.

Sie denken nicht nur isoliert über Rechenleistung oder Netzwerk nach. Strom, Kühlung, physikalisches Design, Lieferkette, Netzwerk und Automatisierung müssen zusammenkommen, um diese Umgebungen in Betrieb zu nehmen und am Laufen zu halten.

Ich denke immer noch, dass wir Menschen mit tiefem Fachwissen in jedem dieser Bereiche benötigen. Aber zunehmend müssen sie auch verstehen, wie Entscheidungen in ihrem Bereich die restliche Infrastruktur beeinflussen. Und weil ein großer Teil dieser Arbeit schneller erledigt werden muss, wird die Fähigkeit zur Automatisierung in immer mehr dieser Disziplinen wichtig sein.

KI‑Agenten beginnen, Probleme zu diagnostizieren, Konfigurationen zu erzeugen und Teile der Infrastruktur‑Operationen zu automatisieren. Welche Verantwortlichkeiten wird KI Ihrer Meinung nach realistisch von Infrastruktur‑Ingenieuren übernehmen, und welche werden noch stärker von tiefgreifendem menschlichen Fachwissen abhängen?

Ich denke, ein Großteil der Arbeit, bei der Eingaben, gewünschtes Ergebnis und Grenzen klar sind, wird zunehmend von KI übernommen werden. Das Erzeugen von Konfigurationen ist ein offensichtliches Beispiel. Ebenso das Diagnostizieren häufiger Probleme, das Prüfen, ob die Infrastruktur dem beabsichtigten Design entspricht, oder schließlich das Beheben bestimmter Probleme, wenn genug Vertrauen darüber besteht, was schiefgelaufen ist und welche sichere Reaktion zu wählen ist.

Menschen werden wichtiger, wenn die Antwort nicht offensichtlich ist.

Infrastrukturen versagen auf seltsame Weise. Ein Glasfaserkabel wird geschnitten. Ein Gerät verhält sich anders, als das Design es vorsieht. Eine Änderung hat an einer anderen Stelle in der Umgebung unerwartete Auswirkungen. KI kann einem Ingenieur helfen, diese Situationen viel schneller zu verstehen, aber Sie benötigen weiterhin Menschen, die das System tief genug verstehen, um zu entscheiden, was als Nächstes geschehen soll.

Ich denke, das ist die interessante Verschiebung. Ingenieure werden wahrscheinlich weniger Zeit mit wiederholender Konfiguration und Fehlersuche verbringen und mehr Zeit damit, Absichten zu definieren, Systeme zu entwerfen, die Grenzen für die Automatisierung festzulegen und wirklich neuartige Probleme zu bearbeiten. All diese Arbeit wird durch KI unterstützt, aber von Menschen gesteuert.

Das macht Fachwissen wertvoller, nicht weniger. Der Ingenieur, der wirklich versteht, warum die Infrastruktur so funktioniert, wie sie es tut, wird unglaublich wichtig sein, wenn die Automatisierung keine offensichtliche Antwort hat.

NetBox Labs hat argumentiert, dass KI‑Systeme, die Infrastruktur verwalten, ein autoritatives Modell von Geräten, Verbindungen, Abhängigkeiten und anderen physischen und logischen Beziehungen benötigen. Warum ist dieser Art von Infrastruktur‑Kontext so wichtig, wenn man von KI‑Assistenten, die Empfehlungen geben, zu Agenten übergeht, die tatsächlich Aktionen ausführen können?

Der große Unterschied besteht darin, dass, sobald ein Agent handeln kann, ein Fehler reale Konsequenzen hat.

Ein Infrastruktur‑Agent benötigt mehr als einen Schnappschuss davon, was ein Gerät gerade tut. Er muss die Umgebung verstehen: was existiert, wie Dinge verbunden sind, was sich kürzlich geändert hat und – vor allem – wie die Infrastruktur aussehen soll.

Betrachten wir zum Beispiel die Fehlersuche bei einem Verbindungsproblem. Es reicht nicht zu wissen, dass ein Gerät nicht erreichbar ist. Der Agent soll in der Lage sein, den Kabelweg nachzuvollziehen, die Abhängigkeiten rund um das Gerät zu verstehen, die jüngsten Änderungen zu prüfen und zu bestimmen, was sonst noch betroffen sein könnte, bevor er vorschlägt, was als Nächstes zu tun ist.

Das ist wirklich das Fundament, an dem wir bei NetBox Labs jahrelang gearbeitet haben: den Teams ein genaues Modell sowohl der physischen als auch der logischen Infrastruktur zu geben, einschließlich der Absicht, wie sie funktionieren soll.

Aber die Daten allein reichen nicht aus. Man muss auch festlegen, was der Agent eigenständig tun darf, was einer Genehmigung durch eine Person bedarf und wie jede Aktion nachverfolgt und validiert wird.

Infrastruktur ist nicht wie Code, bei dem eine fehlerhafte Änderung immer sauber rückgängig gemacht werden kann. Eine falsche Änderung kann den Betrieb lahmlegen. Wenn wir also von KI, die einem Ingenieur sagt, was sie denkt, zu KI übergehen, die die Arbeit tatsächlich ausführen kann, werden sowohl Kontext als auch Kontrolle viel wichtiger.

In Ihrem aktuellen CIO‑Artikel, “Why I, the CEO, am personally building our AI strategy,” Sie argumentierten, dass KI für Unternehmensleiter zu wichtig sei, um sie einfach zu delegieren, und beschrieben, dass Sie persönlich mit KI‑Werkzeugen prototypisieren. Wie hat das praktische Arbeiten mit diesen Systemen Ihre Sicht darauf verändert, was KI in Infrastruktur‑Operationen realistisch automatisieren kann?

Praktisches Arbeiten lässt Sie deutlich weniger an theoretischen Diskussionen interessiert sein.

Ich habe viel Zeit damit verbracht, diese Werkzeuge tatsächlich zu nutzen, heutzutage am häufigsten beim Prototyping oder sogar beim Erstellen vollständiger Produkte mit Claude Code. Man lernt ziemlich schnell, dass es einen riesigen Unterschied gibt zwischen einer beeindruckenden Demo und dem Bau von etwas, dem man wirklich vertraut, um nützliche Arbeit zu leisten.

Man entwickelt zudem ein Gespür dafür, wohin sich die Technologie bewegt, viel schneller, als man es durch Lesen erfahren könnte. Dinge, die ich vor sechs Monaten noch als schwer automatisierbar angesehen hätte, können plötzlich recht einfach sein. Gleichzeitig erkennt man sehr deutlich, wo Kontext, Urteilskraft und Struktur noch fehlen.

Das hat meine Sicht auf Infrastruktur‑Operationen geprägt. Ich bin sehr optimistisch, wie viel operative Arbeit wir automatisieren können, aber ich denke, wir sind noch weit entfernt von reiner Autonomie als Endziel.

Die Frage, die mir wichtig ist, ist viel grundsätzlicher. Hilft uns das, die Infrastruktur schneller, zuverlässiger oder effektiver zu betreiben? Wenn ja, großartig. Wenn nicht, ist es egal, wie ausgeklügelt die dahinterstehende KI ist.

Da KI‑Rechenzentren zunehmend durch Stromverfügbarkeit und Kühlungsanforderungen eingeschränkt werden, könnte sich das Infrastruktur‑Engineering von der primären Verwaltung von Rechenressourcen zu einer aktiven Koordination von Workloads mit Energie‑ und physischer Kapazität entwickeln?

Ja, und wir sehen das bereits. Intern verwenden wir den Ausdruck “turbines in the parking lot”, der aus einem echten Gespräch mit einem der Teams stammt, die hyperskalige KI‑Infrastruktur aufbauen. Sie brachten die Infrastruktur so schnell online, dass das Stromnetz nicht mithalten konnte, sodass sie buchstäblich Turbinen kauften und sie auf dem Parkplatz aufstellten, um schnell genug Strom zu erhalten.

Das ist die Art von Umgebung, in der diese Teams arbeiten. Wenn Strom zu einer Ihrer Hauptbeschränkungen wird, müssen Sie viel intelligenter damit umgehen, was verfügbar ist. Demand‑Side‑Response, bei dem Betreiber AI‑Workloads aktiv in Reaktion auf Schwankungen im Stromnetz koordinieren, findet bereits statt und wird zu einer immer wichtigeren Fähigkeit für Teams, die stromhungrige Infrastruktur betreiben.

Nicht jede Workload hat dieselben Anforderungen. Latenz‑sensible Inferenz muss möglicherweise online bleiben, während einige Trainings‑ oder Batch‑Workloads bei Stromengpässen verschoben oder pausiert werden können. Ich denke, wir werden zunehmend sehen, dass Infrastruktur‑Teams Compute, Strom und physische Kapazität als Teile desselben operativen Problems verwalten.

Wenn wir in die Zukunft blicken, glauben Sie, dass der größte Engpass für die Skalierung von KI letztlich GPUs und Modellentwicklung sein wird, oder die weitaus breitere Herausforderung, genügend Strom, physische Infrastruktur, Netzwerk‑Kapazität, Automatisierung und qualifizierte Ingenieure zu finden, um alles dahinter zu betreiben?

Ich glaube nicht, dass es einen einzigen Engpass geben wird.

Der Aufbau von KI‑Infrastruktur in dem Tempo und Umfang, den der Markt derzeit verlangt, ist im Grunde ein Problem der Constraint‑Satisfaction. Zu jedem Zeitpunkt ist etwas die primäre Beschränkung.

Eine Zeit lang redete jeder über GPUs. Leistung ist offensichtlich jetzt ein riesiger Engpass. Aber es kann auch Netzwerkgeräte, Kühlung, Land, Glasfaser, Beschaffung, Bau oder einfach das Finden ausreichend qualifizierter Personen sein, die wissen, wie man all das zusammenbringt.

Und sobald man ein Hindernis gelöst hat, wird ein weiteres deutlicher sichtbar. Das passiert, wenn die Nachfrage so viel größer ist als das Angebot.

Ich würde also nicht auf einen dauerhaften Engpass setzen. Ich denke, die wichtigere Fähigkeit besteht darin, sich anpassen zu können, wenn sich der Engpass verschiebt.

Deshalb glaube ich auch nicht, dass es derzeit ein definitives Handbuch für KI-Infrastruktur gibt. Die Menschen, die sie aufbauen, finden das heraus, während sie skalieren, und sie tun beides unglaublich schnell.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten NetBox Labs besuchen.