Kris Beevers, CEO y Co-Fundador, Netbox Labs – Serie de entrevistas

Kris Beevers, CEO y Co-Fundador de NetBox Labs es un emprendedor tecnológico y veterano del software de infraestructura con más de dos décadas de experiencia creando empresas y plataformas centradas en redes, infraestructura en la nube y automatización. Antes de dirigir NetBox Labs, Beevers cofundó NS1 en 2013 y se desempeñó como su CEO durante casi una década, convirtiendo a la empresa en un proveedor destacado de tecnología de automatización de redes y gestión de tráfico de aplicaciones antes de su adquisición por IBM en 2023. Como parte de esa transacción, NetBox Labs se escindió de NS1 como una compañía independiente con IBM como inversor. En etapas anteriores de su carrera, Beevers ocupó cargos senior de ingeniería y arquitectura en Internap Network Services y Voxel, y también cofundó SolidJoint Research.

NetBox Labs desarrolla una plataforma de inteligencia de infraestructura diseñada para ayudar a las organizaciones a modelar, operar, automatizar y gobernar redes e infraestructuras de TI cada vez más complejas. La empresa es la responsable comercial de NetBox, el sistema de registro de red e infraestructura de código abierto ampliamente adoptado y utilizado por más de 10 000 organizaciones. Su plataforma combina un grafo de infraestructura y una fuente de verdad con inteligencia operativa, automatización, orquestación asistida por IA y capacidades de gobernanza que permiten tanto a ingenieros como a agentes de IA interactuar de forma segura con la infraestructura. NetBox Labs admite implementaciones en la nube, empresariales autogestionadas, híbridas y aisladas, al tiempo que se integra con herramientas como Ansible, Terraform, Nornir y pipelines de integración y despliegue continuo.

Co-fundaste NS1 en 2013 y pasaste casi una década construyendo la empresa antes de su adquisición por IBM, tras lo cual NetBox Labs surgió como una compañía independiente. ¿Qué lecciones de la construcción de NS1 influyeron en por qué fundaste NetBox Labs, y cómo ha cambiado el problema de infraestructura que intentas resolver en la era de la IA?

Una cosa que aprendí al construir NS1 es que los problemas de infraestructura rara vez permanecen bien contenidos. DNS era nuestra parte del stack, pero nuestros clientes operaban entornos increíblemente complejos donde redes, centros de datos, aplicaciones y automatización dependían unos de otros. Cuanto más tiempo pasaba con esos equipos, más claro se volvía que comprender la propia infraestructura era un problema mucho mayor.

Eso fue una gran parte de lo que me atrajo a NetBox. Ya existía este proyecto de código abierto ampliamente adoptado y una comunidad de ingenieros que lo utilizaba para modelar lo que tenían, cómo estaba conectado y cómo se suponía que debía verse. Vimos una oportunidad de construir sobre esa base.

Lo que ha cambiado con la IA es principalmente el ritmo y la escala. A los equipos de infraestructura se les pide construir entornos enormes de forma increíblemente rápida, mientras la tecnología subyacente cambia a la misma velocidad. Al mismo tiempo, estamos comenzando a automatizar más la operación de esa infraestructura, lo que representa un futuro prometedor. A medida que la IA se aplica a la infraestructura, los equipos de TI se dan cuenta de que deben contar con datos buenos y en tiempo real sobre su infraestructura para automatizar, y necesitan saber cómo se ve el estado deseado para que la IA pueda ayudarles a identificar cuándo la infraestructura operativa se desvía del plan.

Así que la lección de NS1 sigue siendo válida. Antes de poder automatizar la infraestructura de manera eficaz, debes comprenderla. La IA simplemente hace que lograr eso sea mucho más urgente.

Durante gran parte de la última década, la computación en la nube permitió a los desarrolladores y equipos de infraestructura abstraer el hardware físico subyacente a sus aplicaciones. ¿Por qué la IA está invirtiendo esa tendencia y obligando a DevOps, Site Reliability Engineering (SRE) y a los ingenieros de redes a volver a pensar en energía, refrigeración, bastidores, cableado y redes físicas?

La nube nos enseñó a muchos a tratar la infraestructura como efectivamente infinita. Pedías capacidad de cómputo y aparecía. No tenías que preocuparte necesariamente de dónde estaba el servidor, cómo se alimentaba, cómo se refrigeraba o cómo se ensamblaban todas las piezas físicas subyacentes.

La infraestructura de IA realmente no permite hacer eso.

Cuando construyes estos entornos, comienzas con preguntas bastante físicas. ¿Cuánta tierra tengo? ¿Cuánta energía puedo obtener? ¿Qué tipo de refrigeración puedo soportar? A partir de ahí pasas a los bastidores, servidores GPU, switches, cableado de fibra óptica y, finalmente, a la capa lógica: direcciones IP, configuraciones y software.

Todas esas cosas dependen unas de otras. No puedes decidir cuántos bastidores vas a desplegar sin entender la densidad de energía y refrigeración. No puedes pensar en las GPU de forma independiente de la red que las conecta.

Eso está obligando a disciplinas que pasaron años alejándose de la capa física a volver a involucrarse con ella. La abstracción no ha desaparecido, pero las limitaciones físicas subyacentes de repente importan mucho más.

Los centros de datos de IA se discuten cada vez más a escala de gigavatios. ¿Qué cambia fundamentalmente a nivel operativo cuando la infraestructura pasa de entornos empresariales o de nube convencionales a instalaciones diseñadas alrededor de enormes conglomerados de GPU?

La escala de gigavatios es absolutamente astronómica. Pero aunque la escala es evidentemente diferente, creo que la diferencia más interesante es la cantidad de coordinación requerida.

Piense en lo que tiene que suceder para poner en marcha un centro de datos de 300 megavatios. Necesita terreno y energía. Luego debe diseñar la instalación y adquirir bastidores, servidores GPU, conmutadores, fibra, infraestructura eléctrica y equipos de refrigeración, a menudo de proveedores completamente diferentes con formas totalmente distintas de representar sus productos. Todo ese equipamiento debe llegar, ser recibido, montado en bastidores, cableado, configurado, probado y, en última instancia, entregado para entrenamiento o inferencia.

Y el terreno se está moviendo bajo sus pies mientras lo hace. Las arquitecturas de GPU están cambiando. Las redes están cambiando. Los requisitos de refrigeración están cambiando. Los componentes disponibles dentro de seis meses pueden no ser los mismos que diseñó hoy.

Así que las pequeñas ineficiencias se acumulan muy rápido. Recientemente pasé tiempo con uno de los mayores fabricantes de cables de fibra óptica del mundo, y me dijeron que uno de sus mayores problemas de negocio son las devoluciones porque los clientes solicitan longitudes de cable incorrectas. Eso parece casi trivial hasta que está pidiendo cientos de miles de cables.

A esta escala, las operaciones de infraestructura se convierten en un enorme problema logístico y de satisfacción de restricciones. Las empresas que lo hacen bien son las que logran mantener datos de diseño precisos a lo largo de todo el proceso de adquisición, despliegue y operación.

Usted ha dicho que, en efecto, no existe un manual establecido ni una vía de talento para operar infraestructura a esta escala. ¿Qué habilidades son actualmente las más difíciles de encontrar y dónde espera que surjan las mayores escaseces de talento a medida que la infraestructura de IA se expanda?

Probablemente solo haya unos pocos cientos de personas en el mundo que realmente sepan cómo construir este tipo de infraestructura a esta velocidad y escala. Y la mayoría de ellas están bastante ocupadas haciéndolo.

Eso es parte de lo que hace que este momento sea inusual. No hay un cuerpo de conocimiento maduro que pueda simplemente estudiar. Las personas que hacen esto están aprendiendo unas de otras y resolviendo problemas en tiempo real. Y como la tecnología cambia tan rápido, algunas de esas lecciones quedan obsoletas bastante pronto.

Creo que la escasez es, por lo tanto, mayor que cualquier título de trabajo. Necesitamos personas que comprendan redes, cómputo y automatización, pero cada vez más también el entorno físico en el que viven esos sistemas. La energía, la refrigeración, el diseño de instalaciones, la cadena de suministro y las operaciones de campo se están convirtiendo en parte de la misma conversación.

Las personas que pueden cruzar algunas de esas fronteras serán increíblemente valiosas. Pero no creo que ya hayamos definido cómo serán todos esos roles. El modelo de talento se está construyendo junto con la infraestructura.

A medida que las fronteras entre software, redes, instalaciones, energía y la ingeniería de centros de datos comienzan a difuminarse, ¿qué nuevos roles técnicos o combinaciones de habilidades híbridas espera que surjan?

No creo que sepamos aún cómo serán todos esos roles. Lo que sí sabemos es que las personas que construyen esta infraestructura deben pensar en un conjunto mucho más amplio de problemas que antes.

No solo se trata de cómputo o redes de forma aislada. La energía, la refrigeración, el diseño físico, la cadena de suministro, las redes y la automatización deben converger para poner en marcha estos entornos y mantenerlos operativos.

Sigo pensando que necesitaremos personas con profunda experiencia en cada una de esas áreas. Pero cada vez más, también deberán comprender cómo las decisiones en su ámbito afectan al resto de la infraestructura. Y dado que gran parte de este trabajo debe realizarse más rápido, la capacidad de automatizar será relevante en más disciplinas.

Los agentes de IA están comenzando a diagnosticar problemas, generar configuraciones y automatizar partes de las operaciones de infraestructura. ¿Qué responsabilidades cree que la IA asumirá de manera realista de los ingenieros de infraestructura, y cuáles dependerán aún más de la profunda experiencia humana?

Creo que gran parte del trabajo donde los insumos, el resultado deseado y los límites son claros será manejado cada vez más por la IA. Generar configuraciones es un ejemplo obvio. También lo es diagnosticar problemas comunes, verificar si la infraestructura coincide con el diseño previsto, o eventualmente corregir ciertos incidentes cuando haya suficiente confianza sobre qué falló y cuál es la respuesta segura.

Donde los humanos se vuelven más importantes es cuando la respuesta no es evidente.

La infraestructura falla de maneras extrañas. Una fibra se corta. Un dispositivo comienza a comportarse de forma diferente a lo que el diseño indica. Un cambio tiene un efecto inesperado en otro punto del entorno. La IA puede ayudar a un ingeniero a comprender esas situaciones mucho más rápido, pero aún se necesitan personas que comprendan el sistema lo suficientemente a fondo como para decidir qué debe ocurrir a continuación.

Creo que ese es el cambio interesante. Los ingenieros probablemente pasarán menos tiempo realizando configuraciones y soluciones de problemas repetitivas y más tiempo definiendo la intención, diseñando sistemas, estableciendo los límites para la automatización y abordando los problemas verdaderamente novedosos. Todo ese trabajo será complementado por la IA, pero impulsado por personas.

Eso hace que la experiencia sea más valiosa, no menos. El ingeniero que realmente entienda por qué la infraestructura funciona como lo hace será increíblemente importante cuando la automatización no tenga una respuesta evidente.

NetBox Labs ha argumentado que los sistemas de IA que gestionan la infraestructura necesitan un modelo autoritario de dispositivos, conexiones, dependencias y otras relaciones físicas y lógicas. ¿Por qué es tan importante este tipo de contexto de infraestructura al pasar de asistentes de IA que hacen recomendaciones a agentes que pueden realmente tomar acciones?

La gran diferencia es que, una vez que un agente puede actuar, equivocarse tiene consecuencias reales.

Un agente de infraestructura necesita más que una captura instantánea de lo que un dispositivo está haciendo en este momento. Necesita comprender el entorno que lo rodea: qué existe, cómo están conectadas las cosas, qué cambió recientemente y, lo que es importante, cómo se supone que debe ser la infraestructura.

Tome algo como la resolución de un problema de conectividad. No basta con saber que un dispositivo es inaccesible. Se desea que el agente pueda rastrear la ruta del cable, entender las dependencias alrededor de ese dispositivo, revisar los cambios recientes y determinar qué más podría verse afectado antes de proponer qué hacer a continuación.

Eso es realmente la base en la que hemos trabajado durante años en NetBox Labs, proporcionando a los equipos un modelo preciso tanto de la infraestructura física como lógica, junto con la intención de cómo debe operar.

Pero los datos por sí solos no son suficientes. También hay que decidir qué acciones puede realizar el agente por sí mismo, qué requiere la aprobación de una persona y cómo se registra y valida cada acción.

La infraestructura no es como el código, donde un cambio erróneo siempre puede revertirse limpiamente. Un cambio erróneo puede derribar una operación. Así que, a medida que pasamos de una IA que le dice a un ingeniero lo que piensa a una IA que realmente puede hacer el trabajo, tanto el contexto como el control se vuelven mucho más importantes.

En su reciente artículo de CIO, “Por qué yo, el CEO, estoy construyendo personalmente nuestra estrategia de IA”, argumentó que la IA es demasiado importante para que los líderes de la empresa simplemente la deleguen y describió la creación de prototipos personalmente con herramientas de IA. ¿Cómo ha cambiado el estar directamente involucrado con estos sistemas su forma de pensar sobre lo que la IA puede automatizar de manera realista en las operaciones de infraestructura?

Estar directamente involucrado le hace estar mucho menos interesado en la conversación teórica.

He pasado mucho tiempo construyendo realmente con estas herramientas, y hoy en día lo más frecuente es prototipar o incluso crear productos completos con Claude Code. Aprendes rápidamente que hay una gran diferencia entre ver una demostración impresionante y construir algo en lo que realmente confíes para realizar un trabajo útil.

También desarrollas una sensación de hacia dónde se dirige la tecnología mucho más rápido de lo que puedes obtener leyendo al respecto. Cosas que consideraba difíciles de automatizar hace seis meses pueden de repente ser bastante sencillas. Al mismo tiempo, ves con mucha claridad dónde aún faltan contexto, juicio y estructura.

Eso ha influido en cómo pienso sobre las operaciones de infraestructura. Soy muy optimista respecto a cuánto trabajo operativo podemos automatizar, pero creo que estamos lejos de la autonomía pura como objetivo final.

La pregunta que me importa es mucho más básica. ¿Esto nos ayuda a operar la infraestructura más rápido, de forma más fiable o más eficaz? Si lo hace, genial. Si no lo hace, no importa cuán sofisticada sea la IA que hay detrás.

A medida que los centros de datos de IA se vuelven cada vez más limitados por la disponibilidad de electricidad y los requisitos de refrigeración, ¿podría la ingeniería de infraestructura evolucionar de gestionar principalmente recursos informáticos a coordinar activamente cargas de trabajo con la energía y la capacidad física?

Sí, y ya estamos empezando a verlo. Tenemos una frase internamente, “turbinas en el estacionamiento”, que surgió de una conversación real con uno de los equipos que construye infraestructura de IA a gran escala. Estaban poniendo la infraestructura en marcha tan rápido que la red eléctrica no podía seguir el ritmo, así que literalmente estaban comprando turbinas y colocándolas en el estacionamiento para obtener energía lo suficientemente rápido.

Ese es el tipo de entorno en el que operan estos equipos. Cuando la energía se convierte en una de sus principales limitaciones, hay que ser mucho más inteligente con el uso de lo disponible. La respuesta a la demanda, donde los operadores coordinan activamente las cargas de trabajo de IA en reacción a cambios en la red eléctrica, ya está ocurriendo y se está convirtiendo en una capacidad cada vez más importante para los equipos que gestionan infraestructura con alto consumo energético.

No todas las cargas de trabajo tienen los mismos requisitos. La inferencia sensible a la latencia puede necesitar permanecer en línea, mientras que algunas cargas de entrenamiento o por lotes pueden desplazarse o pausarse cuando la energía es limitada. Creo que veremos cada vez más a los equipos de infraestructura gestionando cómputo, energía y capacidad física como partes del mismo problema operativo.

De cara al futuro, ¿crees que el mayor cuello de botella para escalar la IA será finalmente las GPU y el desarrollo de modelos, o el desafío mucho más amplio de encontrar suficiente energía, infraestructura física, capacidad de red, automatización y ingenieros capacitados para operar todo lo que hay detrás?

No creo que haya un único cuello de botella.

Construir infraestructura de IA a la velocidad y escala que el mercado demanda actualmente es básicamente un problema de satisfacción de restricciones. En cualquier momento dado, algo es la restricción principal.

Durante un tiempo, todos hablaban de las GPU. La energía es obviamente un gran cuello de botella ahora. Pero también pueden ser el equipo de redes, la refrigeración, el terreno, la fibra, la adquisición, la construcción, o simplemente encontrar a suficientes personas que sepan cómo ensamblar todo esto.

Y una vez que resuelves una restricción, otra se vuelve más visible. Eso es lo que ocurre cuando la demanda es mucho mayor que la oferta.

Así que no apostaría por un único cuello de botella permanente. Creo que la capacidad más importante es poder adaptarse a medida que la restricción se desplaza.

Eso también explica por qué no creo que nadie tenga la guía definitiva para la infraestructura de IA en este momento. Las personas que la construyen están descubriendo esto mientras escalan, y lo hacen de manera increíblemente rápida.

Gracias por la excelente entrevista, los lectores que deseen obtener más información deberían visitar NetBox Labs.