Kris Beevers, CEO i współzałożyciel, Netbox Labs – seria wywiadów

Kris Beevers, CEO i współzałożyciel NetBox Labs jest przedsiębiorcą technologicznym i weteranem oprogramowania infrastrukturalnego z ponad dwudziestoletnim doświadczeniem w budowaniu firm i platform skoncentrowanych na sieciach, infrastrukturze chmurowej i automatyzacji. Przed kierowaniem NetBox Labs, Beevers współzałożył NS1 w 2013 roku i pełnił funkcję jej CEO przez niemal dekadę, rozwijając firmę w znaczącego dostawcę technologii automatyzacji sieci i zarządzania ruchem aplikacji, zanim została przejęta przez IBM w 2023 roku. W ramach tej transakcji NetBox Labs odłączył się od NS1 jako niezależna spółka, a IBM został inwestorem. Wcześniej w swojej karierze Beevers pełnił wysokie stanowiska inżynieryjne i architektoniczne w Internap Network Services i Voxel, a także współzałożył SolidJoint Research.

NetBox Labs opracowuje platformę inteligencji infrastrukturalnej zaprojektowaną, aby pomagać organizacjom modelować, zarządzać, automatyzować i kontrolować coraz bardziej złożone sieci oraz infrastrukturę IT. Firma jest komercyjnym opiekunem NetBox, szeroko przyjętego otwarto‑źródłowego systemu rejestru sieci i infrastruktury używanego przez ponad 10 000 organizacji. Jej platforma łączy graf infrastruktury i źródło prawdy z inteligencją operacyjną, automatyzacją, orkiestracją wspomaganą AI oraz funkcjami zarządzania, które pozwalają zarówno inżynierom, jak i agentom AI bezpiecznie współdziałać z infrastrukturą. NetBox Labs obsługuje wdrożenia w chmurze, w środowiskach zarządzanych samodzielnie, hybrydowych i odizolowanych, integrując się jednocześnie z narzędziami takimi jak Ansible, Terraform, Nornir oraz pipeline’ami ciągłej integracji i dostarczania.

Współzałożyłeś NS1 w 2013 roku i spędziłeś prawie dekadę budując tę firmę przed jej przejęciem przez IBM, po czym NetBox Labs stał się niezależną spółką. Jakie lekcje z budowania NS1 wpłynęły na to, dlaczego założyłeś NetBox Labs, i jak problem infrastruktury, który starasz się rozwiązać, zmienił się w erze AI?

Jedną rzeczą, którą nauczyłem się budując NS1, jest to, że problemy infrastrukturalne rzadko pozostają ładnie odseparowane. DNS był naszą częścią stosu, ale nasi klienci operowali w tych niezwykle złożonych środowiskach, w których sieci, centra danych, aplikacje i automatyzacja wzajemnie na siebie zależały. Im więcej czasu spędzałem z tymi zespołami, tym wyraźniej uświadamiałem sobie, że zrozumienie samej infrastruktury jest znacznie większym problemem.

To był duży powód, dla którego zainteresowało mnie NetBox. Istniał już szeroko przyjęty projekt open‑source oraz społeczność inżynierów używających go do modelowania tego, co posiadali, jak było połączone i jak powinno wyglądać. Dostrzegliśmy szansę, aby rozbudować tę podstawę.

To, co zmieniło się dzięki AI, to głównie tempo i skala. Zespoły infrastrukturalne są proszone o budowanie ogromnych środowisk w niezwykle szybkim tempie, podczas gdy podstawowa technologia zmienia się równie szybko. Jednocześnie zaczynamy automatyzować coraz więcej operacji tej infrastruktury, co reprezentuje ekscytującą przyszłość. Gdy AI jest stosowane do infrastruktury, zespoły IT zdają sobie sprawę, że muszą mieć dobre, bieżące dane o swojej infrastrukturze, aby móc ją automatyzować, i muszą znać pożądany stan, aby AI mogło pomóc im zidentyfikować, kiedy infrastruktura operacyjna odbiega od planu.

Zatem lekcja z NS1 wciąż obowiązuje. Zanim będziesz mógł skutecznie automatyzować infrastrukturę, musisz ją zrozumieć. AI po prostu sprawia, że zrobienie tego poprawnie jest znacznie pilniejsze.

Przez większą część ostatniej dekady przetwarzanie w chmurze pozwalało programistom i zespołom infrastrukturalnym abstrahować od fizycznego sprzętu leżącego pod ich aplikacjami. Dlaczego AI odwraca ten trend i zmusza DevOps, Site Reliability Engineering (SRE) oraz inżynierów sieci do ponownego myślenia o zasilaniu, chłodzeniu, szafach, okablowaniu i fizycznych sieciach?

Chmura nauczyła wielu z nas traktować infrastrukturę jako praktycznie nieskończoną. Prosiłeś o moc obliczeniową i ona się pojawiała. Nie musiałeś koniecznie dbać o to, gdzie znajduje się serwer, jak jest zasilany, jak jest chłodzony ani jak wszystkie fizyczne elementy pod nim się łączą.

Infrastruktura AI naprawdę nie pozwala na to.

Kiedy budujesz te środowiska, zaczynasz od kilku dość fizycznych pytań. Ile ziemi mam do dyspozycji? Ile mocy mogę uzyskać? Jakiego rodzaju chłodzenia mogę zapewnić? Od tego przechodzisz do szaf, serwerów GPU, przełączników, światłowodowego okablowania i w końcu warstwy logicznej – adresów IP, konfiguracji i oprogramowania.

Wszystko to zależy od siebie nawzajem. Nie możesz zdecydować, ile szaf zamierzasz wdrożyć, nie rozumiejąc gęstości mocy i chłodzenia. Nie możesz myśleć o GPU niezależnie od sieci, która je łączy.

To zmusza dyscypliny, które spędziły lata, odchodząc od warstwy fizycznej, by ponownie się z nią zająć. Abstrakcja nie zniknęła, ale fizyczne ograniczenia pod nią nagle stają się znacznie ważniejsze.

Centra danych AI są coraz częściej omawiane w skali gigawatkowej. Co fundamentalnie zmienia się operacyjnie, gdy infrastruktura przechodzi z tradycyjnych środowisk korporacyjnych lub chmurowych do obiektów zaprojektowanych wokół ogromnych klastrów GPU?

Skala gigawatkowa jest absolutnie astronomiczna. Ale choć skala jest oczywiście inna, myślę, że bardziej interesująca różnica to ilość wymaganej koordynacji.

Pomyśl o tym, co musi się wydarzyć, aby uruchomić centrum danych o mocy 300 megawatów. Potrzebujesz terenu i energii. Następnie musisz zaprojektować obiekt i zamówić szafy, serwery GPU, przełączniki, światłowody, infrastrukturę zasilania oraz sprzęt chłodzący, często od zupełnie różnych dostawców, którzy prezentują swoje produkty w zupełnie odmienny sposób. Wszystkie te urządzenia muszą przyjechać, zostać przyjęte, zamontowane w szafach, okablowane, skonfigurowane, przetestowane i ostatecznie przekazane do treningu lub inferencji.

A pod twoimi stopami ziemia się przemieszcza, gdy to robisz. Architektury GPU się zmieniają. Sieci zmieniają się. Wymagania dotyczące chłodzenia się zmieniają. Komponenty dostępne za sześć miesięcy mogą nie być takimi samymi, które dziś projektowałeś.

Tak więc drobne nieefektywności szybko się kumulują. Niedawno spędziłem czas z jednym z największych na świecie producentów kabli światłowodowych i powiedziano mi, że jednym z ich największych problemów biznesowych są zwroty, ponieważ klienci zamawiają niewłaściwe długości kabli. Brzmi to prawie trywialnie, dopóki nie zamawiasz setek tysięcy kabli.

W tej skali operacje infrastrukturalne stają się ogromnym problemem logistycznym i spełniania ograniczeń. Firmy, które radzą sobie z tym dobrze, są tymi, które doskonale przenoszą dokładne dane projektowe przez cały proces – od zamówień, przez wdrożenie, aż po eksploatację.

Stwierdziłeś, że w praktyce nie istnieje ustalona instrukcja ani kanał talentów do obsługi infrastruktury w tej skali. Które umiejętności są obecnie najtrudniejsze do znalezienia i gdzie spodziewasz się największych niedoborów talentów w miarę rozwoju infrastruktury AI?

Prawdopodobnie na świecie jest tylko kilkaset osób, które naprawdę wiedzą, jak zbudować tego rodzaju infrastrukturę w takiej szybkości i skali. A większość z nich jest dość zajęta faktycznym jej tworzeniem.

To część tego, co czyni tę chwilę wyjątkową. Nie ma dojrzałego zbioru wiedzy, który można po prostu przestudiować. Ludzie, którzy to robią, uczą się od siebie nawzajem i rozwiązują problemy w czasie rzeczywistym. A ponieważ technologia zmienia się tak szybko, niektóre z tych lekcji szybko stają się nieaktualne.

Uważam więc, że niedobór jest większy niż jakikolwiek pojedynczy tytuł zawodowy. Potrzebujemy osób, które rozumieją sieci, obliczenia i automatyzację, a coraz częściej także środowisko fizyczne, w którym te systemy funkcjonują. Zasilanie, chłodzenie, projektowanie obiektów, łańcuch dostaw i operacje terenowe stają się częścią tej samej dyskusji.

Osoby, które potrafią przekraczać niektóre z tych granic, będą niezwykle cenne. Jednak nie sądzę, że już ustaliliśmy, jak będą wyglądały wszystkie te role. Model talentów jest budowany równolegle z infrastrukturą.

W miarę jak granice między oprogramowaniem, sieciami, obiektami, energią a inżynierią centrów danych zaczynają się zacierać, jakie nowe role techniczne lub hybrydowe zestawy umiejętności spodziewasz się pojawić?

Nie sądzę, że wiemy jeszcze, jak będą wyglądały wszystkie te role. To, co wiemy, to że ludzie budujący tę infrastrukturę muszą myśleć o znacznie szerszym zakresie problemów niż dotąd.

Nie myślisz tylko o obliczeniach czy sieciach w izolacji. Zasilanie, chłodzenie, projektowanie fizyczne, łańcuch dostaw, sieci i automatyzacja muszą współgrać, aby uruchomić te środowiska i utrzymać ich działanie.

Wciąż uważam, że będziemy potrzebować osób z głęboką wiedzą w każdej z tych dziedzin. Jednak coraz częściej będą musiały rozumieć, jak decyzje w ich obszarze wpływają na resztę infrastruktury. A ponieważ wiele z tej pracy musi odbywać się szybciej, zdolność do automatyzacji będzie istotna w coraz większej liczbie tych dyscyplin.

Agenci AI zaczynają diagnozować problemy, generować konfiguracje i automatyzować części operacji infrastruktury. Które obowiązki, według Ciebie, AI realistycznie przejmie od inżynierów infrastruktury, a które staną się jeszcze bardziej zależne od głębokiej ludzkiej ekspertyzy?

Uważam, że wiele prac, w których wejścia, pożądany rezultat i granice są jasne, będzie coraz częściej obsługiwane przez AI. Generowanie konfiguracji jest oczywistym przykładem. Także diagnozowanie typowych problemów, sprawdzanie, czy infrastruktura odpowiada zamierzonemu projektowi, czy ostatecznie naprawianie niektórych problemów, gdy istnieje wystarczająca pewność co do przyczyny i bezpiecznej reakcji.

Gdzie ludzie stają się ważniejsi, to wtedy, gdy odpowiedź nie jest oczywista.

Infrastruktura zawodzi w dziwny sposób. Światłowód zostaje przecięty. Urządzenie zaczyna zachowywać się inaczej niż przewiduje projekt. Zmiana wywołuje nieoczekiwany efekt w innym miejscu środowiska. AI może pomóc inżynierowi zrozumieć te sytuacje znacznie szybciej, ale wciąż potrzebni są ludzie, którzy rozumieją system wystarczająco głęboko, aby zdecydować, co zrobić dalej.

Uważam, że to interesująca zmiana. Inżynierowie prawdopodobnie spędzą mniej czasu na powtarzalnych konfiguracjach i rozwiązywaniu problemów, a więcej na definiowaniu intencji, projektowaniu systemów, ustalaniu granic automatyzacji i radzeniu sobie z naprawdę nowymi problemami. Cała ta praca będzie wspomagana przez AI, ale napędzana przez ludzi.

To sprawia, że ekspertyza jest cenniejsza, a nie mniej. Inżynier, który naprawdę rozumie, dlaczego infrastruktura działa tak, jak działa, będzie niezwykle ważny, gdy automatyzacja nie będzie miała oczywistej odpowiedzi.

NetBox Labs argumentowało, że systemy AI zarządzające infrastrukturą potrzebują autorytatywnego modelu urządzeń, połączeń, zależności oraz innych relacji fizycznych i logicznych. Dlaczego tego typu kontekst infrastruktury jest tak ważny przy przechodzeniu od asystentów AI, które dają rekomendacje, do agentów, które mogą faktycznie podejmować działania?

Główna różnica polega na tym, że gdy agent może działać, popełnienie błędu ma rzeczywiste konsekwencje.

Agent infrastruktury potrzebuje więcej niż jedynie migawki tego, co urządzenie robi w danej chwili. Musi rozumieć otoczenie: co istnieje, jak elementy są połączone, co zmieniło się ostatnio oraz, co najważniejsze, jak powinna wyglądać infrastruktura.

Weźmy na przykład rozwiązywanie problemu z łącznością. Nie wystarczy wiedzieć, że urządzenie jest nieosiągalne. Chcesz, aby agent mógł prześledzić ścieżkę kabla, zrozumieć zależności wokół tego urządzenia, przyjrzeć się ostatnim zmianom i określić, co jeszcze może być dotknięte, zanim zaproponuje kolejne kroki.

To właśnie jest podstawa, nad którą przez lata pracowaliśmy w NetBox Labs, dostarczając zespołom dokładny model zarówno fizycznej, jak i logicznej infrastruktury, wraz z zamierzeniami dotyczącymi jej działania.

Jednak same dane nie wystarczą. Trzeba także określić, co agent może zrobić samodzielnie, co wymaga zatwierdzenia przez człowieka oraz w jaki sposób każda akcja jest rejestrowana i weryfikowana.

Infrastruktura nie jest jak kod, w którym złą zmianę zawsze można czysto cofnąć. Zła zmiana może sparaliżować operację. Dlatego przechodząc od AI, które mówi inżynierowi, co myśli, do AI, które może faktycznie wykonać pracę, zarówno kontekst, jak i kontrola stają się znacznie ważniejsze.

W twoim niedawnym artykule CIO, „Dlaczego ja, CEO, osobiście buduję naszą strategię AI”, argumentowałeś, że AI jest zbyt ważne, aby liderzy firm po prostu delegowali je, i opisałeś własne prototypowanie przy użyciu narzędzi AI. Jak bycie praktycznym w korzystaniu z tych systemów zmieniło twoje myślenie o tym, co AI może realistycznie zautomatyzować w operacjach infrastruktury?

Praktyczne podejście sprawia, że jesteś znacznie mniej zainteresowany teoretyczną dyskusją.

Spędziłem dużo czasu naprawdę budując z tymi narzędziami, najczęściej obecnie prototypując lub nawet tworząc kompletne produkty przy użyciu Claude Code. Dość szybko uczysz się, że istnieje ogromna różnica między oglądaniem imponującej demonstracji a budowaniem czegoś, czemu naprawdę ufasz w wykonywaniu użytecznej pracy.

Rozwijasz także wyczucie, dokąd zmierza technologia, znacznie szybciej niż można to uzyskać z czytania o niej. Rzeczy, które sześć miesięcy temu uważałem za trudne do automatyzacji, mogą nagle stać się dość proste. Jednocześnie widzisz wyraźnie, gdzie wciąż brakuje kontekstu, osądu i struktury.

To wpłynęło na moje myślenie o operacjach infrastruktury. Jestem bardzo optymistyczny co do tego, ile pracy operacyjnej możemy zautomatyzować, ale uważam, że jesteśmy daleko od czystej autonomii jako ostatecznego celu.

Pytanie, które mnie interesuje, jest znacznie bardziej podstawowe. Czy to pomaga nam zarządzać infrastrukturą szybciej, bardziej niezawodnie lub skuteczniej? Jeśli tak, świetnie. Jeśli nie, nie ma znaczenia, jak zaawansowane jest AI stojące za tym.

W miarę jak centra danych AI stają się coraz bardziej ograniczone dostępnością energii elektrycznej i wymaganiami chłodzenia, czy inżynieria infrastruktury może ewoluować z głównie zarządzania zasobami obliczeniowymi do aktywnego koordynowania obciążeń z energią i pojemnością fizyczną?

Tak, i już zaczynamy to zauważać. Mamy wewnętrzne określenie “turbines in the parking lot”, które powstało w wyniku rzeczywistej rozmowy z jednym z zespołów budujących infrastrukturę AI w skali hiperskalowej. Wprowadzali infrastrukturę tak szybko, że sieć nie nadążała, więc dosłownie kupowali turbiny i stawiali je na parkingu, aby uzyskać wystarczającą moc.

To jest rodzaj środowiska, w którym działają te zespoły. Gdy energia staje się jednym z głównych ograniczeń, musisz być znacznie mądrzejszy w wykorzystaniu dostępnych zasobów. Odpowiedź po stronie popytu, w której operatorzy aktywnie koordynują obciążenia AI w reakcji na zmiany w sieci elektrycznej, już ma miejsce i staje się coraz ważniejszą zdolnością dla zespołów zarządzających infrastrukturą o dużym zapotrzebowaniu na energię.

Nie każde obciążenie ma te same wymagania. Inferencja wrażliwa na opóźnienia może wymagać ciągłej dostępności, podczas gdy niektóre zadania treningowe lub wsadowe mogą być przesunięte lub wstrzymane przy ograniczonej energii. Myślę, że coraz częściej zobaczymy zespoły infrastruktury zarządzające obliczeniami, energią i pojemnością fizyczną jako elementami tego samego problemu operacyjnego.

Patrząc w przyszłość, czy uważasz, że największym wąskim gardłem w skalowaniu AI będą ostatecznie GPU i rozwój modeli, czy znacznie szersze wyzwanie polegające na znalezieniu wystarczającej ilości energii, infrastruktury fizycznej, pojemności sieciowej, automatyzacji i wykwalifikowanych inżynierów do obsługi wszystkiego, co za nimi stoi?

Nie sądzę, że będzie jedno wąskie gardło.

Budowanie infrastruktury AI w tempie i skali, jakiej obecnie wymaga rynek, to w zasadzie problem spełniania ograniczeń. W dowolnym momencie coś jest głównym ograniczeniem.

Przez pewien czas wszyscy rozmawiali o GPU. Zasilanie jest oczywiście teraz ogromnym wąskim gardłem. Ale może to być także sprzęt sieciowy, chłodzenie, grunt, światłowód, zamówienia, budowa lub po prostu znalezienie wystarczającej liczby osób, które wiedzą, jak to wszystko połączyć.

A gdy rozwiązujesz jedno ograniczenie, kolejne staje się bardziej widoczne. Tak dzieje się, gdy popyt jest znacznie większy niż podaż.

Dlatego nie obstawiałbym jednego trwałego wąskiego gardła. Uważam, że ważniejszą zdolnością jest umiejętność dostosowywania się, gdy ograniczenie się zmienia.

To także dlatego nie uważam, że ktoś ma obecnie ostateczny podręcznik dotyczący infrastruktury AI. Ludzie, którzy ją budują, rozwiązują te kwestie w trakcie skalowania i robią to niezwykle szybko.

Dziękujemy za świetny wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić NetBox Labs.