Por qué las plataformas abiertas son importantes en las operaciones de red

[0:03] – Presentador: [música] Hola, soy Johna Till Johnson, directora ejecutiva de Nemertes, y estoy aquí con mi copresentador, John Burke, director técnico de Nemertes. Estás escuchando «Heavy Strategy», el programa que intenta plantear las preguntas adecuadas, no dar las respuestas correctas. Estamos aquí con Ronny Wolf, director técnico de campo para EMEA en BlueCat, para hablar de por qué las plataformas abiertas son importantes en las operaciones de red.

[0:20] – Presentador: Y Ronny, las operaciones de red son un ámbito enorme, y sé que este es el ámbito en el que opera BlueCat. Sé que mucha gente está familiarizada con BlueCat, al menos desde hace un par de años, pero puede que algunos oyentes no lo estén. ¿Podrías ofrecernos una breve descripción general del ámbito en el que opera BlueCat concretamente?

[0:40] – Ronny: Oh, sí, sin duda. Quiero decir, BlueCat Networks proviene tradicionalmente del negocio principal de DDI. Es decir, DNS, DHCP, gestión de direcciones IP. Básicamente, todas esas cosas aburridas, ¿verdad? Con lo que todo el mundo tiene que lidiar. Sin embargo, hemos visto en el mercado la demanda, o la necesidad, de ampliar esa plataforma. Así que no solo los servicios básicos de red. Me refiero a que las operaciones de red consisten en mantener todo en marcha, ¿verdad? Así que no solo se trata de proporcionar el servicio, sino también de saber qué ocurre dentro de la red.

[1:20] – Ronny: Y, a través de un par de adquisiciones en los últimos años, hemos ampliado nuestra cartera en observabilidad de redes, captura de paquetes de red y soluciones de garantía de infraestructura, y hemos creado una plataforma en torno a ello, a la que ahora denominamos «operaciones de red inteligentes». Lo que, básicamente, combina ambos aspectos: proporcionar el servicio básico y no limitarse simplemente a mantener el sistema en funcionamiento, sino saber exactamente qué hay dentro de la red y cuál es la causa raíz de lo que ocurre.

[1:55] – Presentador: Entendido. Así que se está ampliando más allá del DDI básico para comprender lo que realmente está sucediendo en la red. Y antes de hablar de cómo lo hacéis, ¿podrías explicarnos brevemente qué hace realmente un director técnico de campo? ¿A qué te dedicas día tras día?

[2:06] – Ronny: Sí. Yo definiría el puesto de director técnico (CTO) aquí en BlueCat como un puente entre el cliente y nuestra oficina de estrategia. Así que no estoy vinculado a un departamento de ventas ni nada por el estilo. Así que sí, por supuesto que también tenemos una estrategia de ventas dentro de BlueCat; de lo contrario, no podríamos ganar dinero. Sin embargo, estamos ahí para escuchar a los clientes, para comprender realmente sus necesidades, y no solo en lo que ofrecemos como BlueCat, sino también en lo que les motiva. Lo que motiva a las diferentes entidades o unidades de negocio: la seguridad, de nuevo, las operaciones de red, los arquitectos y cosas por el estilo. Intentamos escuchar eso y, básicamente, incorporarlo a la dirección estratégica de BlueCat: hacia dónde se dirigen nuestros productos, qué tenemos que cambiar y cómo podemos ayudar a nuestros clientes.

[3:05] – Presentador: Así que tu trabajo consiste, básicamente, en comprender los retos a los que se enfrentan tus clientes y animar a la empresa a desarrollar soluciones antes de que esos retos se agraven demasiado.

[3:13] – Ronny: Correcto.

[3:19] – Presentador: De acuerdo. Y sé que hablamos un poco durante las sesiones de planificación de que uno de los componentes clave de las redes abiertas es el uso de API y dar prioridad a las API. Y mencionaste que, a nivel interno, mientras integrabais esas adquisiciones que realizasteis, BlueCat comenzó a utilizar API para el desarrollo modular, de modo que pudierais desarrollar a partir de las API y mantener todo bien integrado. Y vas a hablar un poco sobre eso en relación con las operaciones de red. Entonces, ¿cómo funcionó eso dentro de BlueCat y cuáles fueron algunas de las lecciones aprendidas de BlueCat que ahora estás aplicando con tus clientes?

[3:50] – Ronny: Sí, quiero decir que, sobre todo, nuestra oficina de estrategia fue sin duda una parte importante de esa iniciativa. Cuando escuchamos a nuestros clientes… Quiero decir que nosotros también empezamos con una especie de enfoque aislado. Piénsalo: ofrecíamos un servicio básico, nuestro negocio principal, nuestros clientes estaban contentos, etcétera. Sin embargo, nos dimos cuenta de que sus necesidades estaban cambiando, con iniciativas adicionales. Por ejemplo, seguridad, automatización e integración. Quiero decir que hay una amplia gama de elementos que los clientes buscan integrar, sobre todo si queremos ser una única fuente de verdad, si quieren seguir un enfoque de plataforma, etcétera.

[4:38] – Ronny: Y lo que nos dimos cuenta en BlueCat es que, aunque las soluciones estaban probadas y a los clientes les gustaban todas estas funcionalidades y características, habíamos llegado a nuestros límites. En primer lugar, no somos capaces de actuar con la rapidez suficiente para convertir eso en productos o en integraciones. Y, por otro lado, también nos limitábamos al tener esta especie de «casa dividida». Hay una interfaz de usuario, hay una automatización o una API, diferentes plataformas, diferentes usos, diferentes APIs, diferentes interfaces de usuario y cosas por el estilo. No había una identidad corporativa que pudiéramos imponer, porque todo parecía un rompecabezas cuyas piezas no encajaban del todo.

[5:27] – Ronny: Y pusimos en marcha esa iniciativa, diría yo, hace unos tres o cuatro años, más o menos. Quiero decir que empezamos a planificarlo mucho antes, pero luego analizamos a fondo nuestros productos. ¿Qué tenemos que cambiar? ¿Desacoplamos el front-end del back-end, por ejemplo? De modo que todo lo que tiene el usuario final, un proceso de negocio en mente, cómo lo utilizan nuestros usuarios hoy en día, ¿cómo podemos convertir eso en un enfoque automatizado para ayudar a nuestros clientes a integrarlo en su gestión de activos, en su gestión de servicios de TI, en todas esas plataformas adyacentes que tienen en uso? Y a partir de ahí, no desarrollamos la plataforma API pensando solo en nosotros mismos, para crear una interfaz de usuario sobre ella y ya está. También la desarrollamos pensando en que los clientes realmente puedan utilizarla para integrar y automatizar mucho más rápido.

[6:25] – Presentador: Entonces, ¿cómo diferenciáis entre tener productos con API y hacer de las API el centro del desarrollo a nivel interno? ¿Cuál es la diferencia entre tener una API y adoptar un enfoque «API-first»?

[6:47] – Ronny: Sí. [se aclara la garganta] Así que disponer de una API surge básicamente cuando, bueno, quieres añadir un nuevo botón en una interfaz de usuario, o cualquier otra funcionalidad nueva, y entonces, en desarrollo, se plasma el requisito por escrito, se crea un ticket de servicio o un ticket de Jira, tenemos la historia de usuario que lo respalda y, a continuación, empiezan a desarrollar una API. ¿Encaja eso realmente en algún tipo de estándar o en un enfoque verdaderamente combinado y unificado? No. Ahí tienes una API, y tienes un poco de esto por aquí, y quizá, vale, tenemos que combinar eso, y, oh, no podemos convertir eso en una API, así que hagamos que la interfaz de usuario vaya directamente al back-end, y cosas por el estilo.

[7:33] – Ronny: Y ahí radica realmente la diferencia, porque para un cliente, aunque se pueda decir: «Oye, potencialmente hay desarrolladores, o al menos alguien que pueda escribir scripts o algo por el estilo detrás de todo esto», necesitan conocer el lenguaje de programación, el paradigma, los modelos y cosas por el estilo. Se vuelve muy difícil de entender y también muy difícil de mantener. No estamos hablando de un enfoque puntual, ¿verdad? Tienen que mantenerlo básicamente durante todo el ciclo de vida de un producto, de sus plataformas.

[8:03] – Ronny: Y con eso, un enfoque «API-first» consiste básicamente en desarrollar realmente las API. Todo lo que ves, todo lo que puedes hacer con el producto, es una API, y luego construimos la parte frontal sobre ella, ya sea una interfaz de usuario, una línea de comandos o lo que sea. ¿Y puede un cliente percibir realmente esa diferencia de forma directa? Es difícil, ¿verdad? Porque al final todo el mundo dice: «Oye, tenemos una API, claro que puedes conectarte a ella». Y eso es, sin duda, también un reto que vemos con bastante frecuencia cuando hablamos con los clientes, porque la automatización, el enfoque de integración, sí, quizá sea solo una pequeña parte. «Oye, ¿se puede hacer eso con la API?». «Sí». Tachado, y ya está. Pero con bastante frecuencia eso se pasa por alto, o no se analiza en detalle: ¿realmente podemos hacerlo? Y si has comprado el producto, si lo has implementado, y luego te das cuenta de que te topas con los límites, de que no puedes integrarlo, entonces hay que recurrir a soluciones provisionales y cosas por el estilo, o tenemos que pagar una consultoría bastante cara para conseguir algo que realmente necesitábamos para el negocio.

[9:19] – Presentador: Parece que podría ser una diferencia que se haga más evidente con el tiempo, cuando se compruebe: ¿se mantiene coherente la API? ¿Se mantiene coherente el uso del producto dentro de una suite junto con sus otros productos? Cosas así empiezan a hacerse evidentes. Vale, lo entiendo.

[9:38] – Presentador: Háblame un poco de las API, no para la integración, sino para la automatización. Últimamente oímos hablar mucho de eso por parte de los equipos de redes.

[9:51] – Ronny: Sí. Sí. La automatización es hoy en día un elemento clave, quizá un requisito clave; al menos, como ya se ha mencionado, suele aparecer en una solicitud de propuesta (RFP) o en cualquier requisito o iniciativa dentro del entorno del cliente, ¿verdad? La automatización consiste precisamente en automatizar nuestros flujos de trabajo empresariales. Y también en este caso, como se ha mencionado antes, si un cliente tiene una plataforma como BlueCat —o da igual qué tipo de plataforma utilice—, conoce su proceso empresarial. Hay varias plataformas diferentes implicadas. Por ejemplo, en la gestión de servicios de TI: se abre un ticket. A continuación, pasa a la propia plataforma para que se convierta en algún tipo de acción. Y quizá no se trate de una sola acción; quizá haya varias acciones que deban realizarse. Por ejemplo, en el caso de BlueCat, hay que crear una red y, además, hay que aprovisionar la máquina virtual, o algo por el estilo, como paso adicional. Y este tipo de procesos empresariales deben automatizarse, con la menor intervención manual posible.

[11:08] – Ronny: Si lo pienso bien, hace diez años, cuando era administrador de TI y cosas por el estilo, cuando creábamos un ticket de servicio para que se realizara un cambio, solía tardar fácilmente entre 24 y 48 horas hasta que se ponía en práctica. ¿Es eso realmente lo que esperan hoy en día los usuarios y los clientes, en la era de la nube, en la que se obtienen capacidades bajo demanda? Por lo tanto, es necesario automatizarlo, para que los cambios se produzcan más rápido y también para aplicar algún tipo de estandarización.

[11:48] – Presentador: Claro. Bueno, y además, por lo que entiendo, parte de la ventaja de automatizar de esta forma es que no se limita a realizar una única tarea, sino que cualquier cambio conlleva una serie de flujos de trabajo secundarios que deben llevarse a cabo para garantizar que el cambio se aplique correctamente. Así que, aunque sea algo muy básico, se realiza un único cambio y luego se comprueba que ha funcionado, o que no ha alterado nada más. Y, en muchos casos, no es tan básico. Hay muchas otras pruebas que hay que realizar. Y contar con las API facilita llevar a cabo ese conjunto de procesos cuando se realiza un único cambio. ¿Lo he entendido bien?

[12:28] – Ronny: Por supuesto. Lo has entendido perfectamente. Y, sobre todo aquí, se ve la diferencia entre una plataforma «API-first» y «sí, tenemos una API en la plataforma», que luego se automatiza hasta cierto punto. Y, como también hemos visto con los clientes, no se trata solo del equipo con el que hablamos. Son diferentes equipos que tienen diferentes requisitos. En nuestro negocio, este flujo de trabajo no parte del administrador de DDI ni del administrador de red. Son los responsables de seguridad, es la propia empresa, el propietario de la aplicación, lo que sea: la base de datos, el front-end, la tienda web, lo que sea, ¿verdad? Son ellos quienes tienen ese requisito. Un administrador de DDI no puede supervisar por completo cómo funciona ese proceso. Conoce su ámbito de competencia, pero desconoce todo lo que lo rodea. Pero las plataformas deben dar soporte a eso. Y si empiezas con eso y luego llegas a un límite en el que dices: «Vaya, nuestra plataforma no puede hacer eso, tenemos que hacerlo de otra manera», quizá, en primer lugar, resulte costoso, o quizá nos perjudique automatizarlo realmente de principio a fin.

[13:39] – Presentador: Y parece, entonces, que estáis bien posicionados con una API completa para todo [risas] a la hora de gestionar, como cliente, la evolución de vuestra propia organización y los cambios en las funciones o en los flujos de trabajo. En ese caso, es más fácil ajustar la automatización que tiene acceso tal y como vosotros lo proporcionáis.

[14:04] – Presentador: ¿Cómo distinguís en BlueCat entre las API que queréis poner a disposición de vuestros clientes y las API que solo se utilizan internamente, ya sabéis, de producto a producto o de módulo a módulo?

[14:22] – Ronny: Para ser sincero, no hay ninguna diferencia. En realidad, todo está expuesto. Todo es una llamada a la API. Así que da igual lo que veas. Quiero decir, hay una cosa que tenemos que aclarar un poco desde el punto de vista de la API. Todo está a disposición del cliente. ¿Quieren utilizarlo? Eso depende. Sin duda hay API que, la mayoría de las veces, utiliza nuestra interfaz de usuario, o para la conectividad entre plataformas y cosas por el estilo, pero pueden utilizarlas para un caso de uso concreto del que ni siquiera somos conscientes, ¿verdad? O para un requisito que tengan. Pero lo que sí diferenciamos, sin duda, es que tenemos nuestro sistema back-end —donde está la base de datos o cualquier tipo de back-end—, que está abstraído del cliente, y ahí es precisamente donde entra en juego la API, ¿verdad? Establecemos los límites de lo que pueden hacer con el producto, eso está claro. Sin embargo, todo lo que hacemos también se expone como una API pública, y ellos pueden utilizarla.

[15:26] – Presentador: Lo cual, creo, nos lleva de nuevo a toda esa idea de «API-first», porque si dices: «Oh, tenemos API», eso solo significa que le pones API a cosas que supones que estarán expuestas al cliente. Pero «API-first» significa que has pensado detenidamente en todo el sistema y su modularidad, y te sientes cómodo exponiendo todas las API a un cliente que quizá desee utilizar los módulos de tu sistema de forma diferente.

[15:57] – Ronny: Correcto.

[15:57] – Presentador: Y la imagen que yo… oh, adelante. No, no, no pasa nada. La imagen que no dejo de tener en la cabeza es la del sistema BlueCat actuando como catalizador para el resto de las operaciones de red, porque si el núcleo está bien diseñado, entonces todo lo que se superpone a él también seguirá estando bien diseñado.

[16:15] – Ronny: Sí. Quiero decir, sin duda a veces hay retos para hacerlo, porque tenemos todas nuestras historias de usuario, de automatización y de integración, lo que los clientes podrían querer utilizar, ¿verdad? Donde también tenemos que introducir sistemas de back-end adicionales y cosas por el estilo. Sin duda, eso sigue siendo un reto. Pero ahí es donde el director técnico de campo y la oficina de estrategia están ahí para escuchar a nuestros clientes e impulsar eso, para ser también, al menos, una especie de actor innovador en ese mercado.

[16:55] – Ronny: Pero sí, estoy de acuerdo con eso. El enfoque modular también nos ayuda enormemente en nuestro propio desarrollo. Desarrollamos un nuevo producto y este se registra automáticamente en nuestra pila de API. Queda disponible de inmediato, porque nosotros mismos lo utilizamos, y el cliente puede usarlo. Así que es mucho más rápido. Hemos desarrollado muchísimos módulos adicionales en nuestros productos, es decir, no en la plataforma central, sino funcionalidades adicionales que se suman a ella, o quizá casos de uso específicos para los clientes, o un área concreta que queremos abordar en este momento, y todo ello queda inmediatamente disponible a través de la API.

[17:38] – Presentador: Y algo en lo que pensamos mucho en este contexto es la seguridad, y concretamente el modelo de seguridad «zero-trust». Así que supongo que la gestión del acceso basada en identidades y roles, que determina quién tiene acceso a qué llamadas a la API, viene integrada.

[17:54] – Ronny: Oh, sí. Sí. Quiero decir, eso es, diría yo, lo básico, ¿no?

[18:06] – Presentador: Quiero decir, siempre esperas que eso sea lo básico, pero a veces es un complemento que se añade al final.

[18:06] – Ronny: Sí. Así que, en términos básicos: si se adopta un enfoque «API-first», en el que un front-end —como una interfaz de usuario— es simplemente un consumidor de la API, entonces la interfaz de usuario, el front-end, básicamente no tiene que ocuparse de la autenticación ni de la autorización. Por lo tanto, estas deben integrarse dentro de la propia API. Así que sí, la API completa cuenta con acceso basado en roles. Dispone de todos los diferentes mecanismos de autenticación, desde la autenticación externa, como los proveedores de identidad (IdP), que hay que tener en cuenta. Quiero decir, los clientes empresariales utilizan plataformas de identidad como Azure Entra ID y similares, ¿verdad? Ya no utilizan la autenticación local, o al menos no todos ellos.

[19:01] – Ronny: También hay que pensar, no solo desde el punto de vista de la seguridad de tu enfoque «API-first», en lo que pasaría si alguien hiciera un uso indebido de tu API. No solo un usuario, sino un usuario autorizado, porque le estás dando la libertad de, básicamente, romper también tu sistema. Así que tenemos que tener en cuenta las medidas de protección. La limitación de tasa, por ejemplo. Tenemos que asegurarnos de que, si alguien lanza un millón de llamadas a la API, quizá sea porque no es un experto, ¿verdad? Nuestros clientes, especialmente en ese ámbito, los administradores de red, saben crear scripts, pero no son desarrolladores. Quizá introduzcan algo en un agente de IA, y el script genere un resultado, lo ejecuten y toda nuestra plataforma se caiga. Así que sí, tenemos que tener en cuenta las medidas de protección. De nuevo, la limitación de tasa, la postura de seguridad, el seguimiento del comportamiento y cosas por el estilo, para asegurarnos de que nuestra plataforma siga siendo resistente y estable.

[20:06] – Presentador: Y lo único en lo que podía pensar era en algo así como la versión de Clippy para operaciones de red. «Parece que estás a punto de enviar 10 millones de llamadas. ¿Estás seguro de que quieres hacerlo?» [risas]

[20:16] – Ronny: Correcto. Exactamente. Quiero decir que, aunque la plataforma, o al menos nuestra plataforma… y también recomiendo tener en cuenta la escalabilidad si los clientes optan por un enfoque «API-first». Pero sí, también lo hemos visto con los clientes. Cuando lanzamos nuestra primera versión del enfoque «API-first», eso también supuso una curva de aprendizaje para nosotros: cómo utilizan la API, qué tipo de ideas se les ocurren. Porque ahora, básicamente, tienen toda esta libertad, ¿verdad? Antes teníamos unas API limitadas. Quiero decir, teníamos API desde el principio, pero eran limitadas. Era como una casa dividida. Y ahora tenían total libertad para hacer lo que quisieran, básicamente, al estilo de lo que hacemos nosotros, ¿no? Fue interesante verlo, y nos adaptamos.

[21:18] – Presentador: «Interesante de ver», creo, es un eufemismo de «da mucho miedo».

[21:18] – Ronny: Sí. Sí. Quiero decir, hay que tener en cuenta una cosa. En BlueCat nos centramos en las operaciones de red y en los servicios básicos de DDI.

[21:36] – Presentador: Exacto. De lo contrario, todo se viene abajo.

[21:36] – Ronny: Sí, sí. Eso es importante. Por supuesto. Pero también hemos visto que los clientes la están utilizando como una CMDB. La están utilizando como plataforma de monitorización. Así que la plataforma DDI se utilizó como plataforma de monitorización, porque introducían en ella información procedente de otras fuentes. Ni siquiera éramos conscientes de que los clientes estaban utilizando las plataformas de esa manera.

[22:01] – Presentador: Bueno, tiene sentido, porque, en cierta medida, eso no ocurre con otros sistemas de tipo CMDB: lo que hay en vuestros sistemas tiene que ser correcto, [carraspea] ¿sabes? [risas]

[22:15] – Ronny: Claro. Claro. En el ámbito en el que podamos entenderlo. Así que no es que lo convirtieran en un calendario ni nada por el estilo. Sin embargo, fue interesante, ya que ni siquiera habíamos pensado en cómo lo utilizarían. Y con eso, la estrategia «API-first» no ha cambiado, pero la hemos ajustado incorporando más medidas de seguridad. Asegurándonos de que estos servicios básicos críticos sigan pudiendo funcionar, incluso si alguien los está saturando con, como en el ejemplo, un millón de llamadas a la API.

[23:01] – Presentador: Bueno, y has hablado de defender tu funcionalidad principal frente a la IA, al menos en el caso de un uso indebido benigno. ¿Cómo has intentado hacerla más compatible con, digamos, el uso profesional e informado de la IA para ayudar a gestionar una red? ¿Qué tipo de modificaciones o añadidos has realizado para que sea más compatible con la IA y la apoye?

[23:28] – Ronny: Sí. Si partimos de ahí: el enfoque «API-first» es mucho más sencillo para la IA y, sobre todo, estamos hablando aquí de agentes de IA, no del modelo de lenguaje grande (LLM) que hay detrás ni nada por el estilo. Es mucho más fácil utilizar documentación adecuada, como una especificación OpenAPI o algún tipo de estándar. Es mucho más fácil de leer y comprender para una IA. [resopla] Pero, ¿de verdad quieres dejar que un agente de IA acceda por completo a tu plataforma sin entenderla realmente? Porque solo con leer las especificaciones de cómo funciona una API… sí, las IA hoy en día son bastante buenas entendiéndolas, o al menos interpretándolas. Pero la dificultad es que no tienes ningún control sobre eso.

[24:27] – Ronny: Así que lo que hemos proporcionado es, bueno, ahora es un término muy técnico, un servidor MCP. Es decir, el Protocolo de Contexto de Modelo (Model Context Protocol). Espero que nuestros oyentes lo entiendan. Básicamente se trata de algo… ya hemos hablado de esto… un servidor MCP es algo que se sitúa delante de la API, que modera hasta qué punto una IA, o un agente, puede realizar consultas, y proporciona contexto adicional sobre cómo funciona el modelo, qué es, y quizá también combina ciertas funciones que la API puede realizar, incluyendo medidas de seguridad adicionales.

[25:06] – Ronny: Por ejemplo, iniciamos el proceso de integración y de ayudar a la IA con los servidores MCP y la API en modo de solo lectura. Simplemente para recopilar información, para aprender de nuestros clientes, así como de los perfiles de usuario internos que básicamente creamos y diseñamos, y luego probar cómo podía funcionar. Así que empezamos primero con el modo de solo lectura, con fines de generación de informes, por ejemplo, para recopilar información y, tal vez, ayudar al usuario final a integrarlo en sus plataformas.

[25:56] – Ronny: Pero, por otro lado, ahora que lo hemos abierto, durante nuestra curva de aprendizaje, también podemos realizar cambios. Porque hay que tener en cuenta que la idea de la plataforma inteligente de operaciones de red es también proporcionar una red con capacidad de autorreparación, y una red con capacidad de autorreparación no está pensada para ser de solo lectura, ¿verdad? Si necesitamos una intervención manual cuando detectamos algo y salta una alarma, eso es lo que se conoce como operaciones de red tradicionales, ¿no? Queremos ser inteligentes, o los clientes quieren tener, en definitiva, una red con capacidad de autorreparación. Y, para ello, también debemos permitir que la IA actúe, y los servidores MCP básicamente proporcionan el contexto y también los límites de seguridad para la IA.

[26:40] – Presentador: [resopla] Y perdona, este es un tema del que a veces hemos hablado en otros contextos. ¿Hay alguna forma, dentro de la pila de BlueCat, de decir que, para esto que estás intentando hacer, siempre se requiera algún tipo de confirmación humana de que esto está a punto de suceder, o una aprobación para permitir que suceda? ¿Está eso integrado en la pila, o para vosotros está en la capa MCP?

[27:02] – Ronny: Sí. Lo que tenemos, y los servidores MCP también lo exponen para que un agente de IA —o el modelo— pueda entenderlo, es lo que llamamos «gestión de cambios». Así que, para ciertas acciones, la IA solo puede recomendar, y un humano tiene que dar su aprobación. También hemos introducido algo así como el principio de dos… el principio de dos personas, perdón, el principio de los cuatro ojos…

[27:43] – Presentador: El principio de «una persona». Así que en realidad son tres. Es como esa vieja historia de ciencia ficción, John… ya sabes, «dímelo tres veces». Humano uno, humano dos y la IA.

[27:53] – Ronny: Correcto, correcto. Así que hay ciertas cosas, especialmente cuando se trata de eliminar servicios de red básicos o de realizar cambios significativos en un conmutador o en algún elemento de la red, en las que los clientes aún pueden anular esa decisión si lo desean. Pero, por defecto, los productos de BlueCat incluyen esa medida de seguridad. La IA lo muestra en su razonamiento: «Oye, no puedo hacer eso. Por favor, apruébalo», o bien realiza ahora el paso manual y haz clic en «Aprobar», o bien realiza la aprobación de nuevo mediante una llamada a la API.

[28:34] – Presentador: Un buen complemento para la limitación de velocidad y otras medidas de seguridad que estáis incorporando. Me alegro de oírlo. No siempre se oye eso.

[28:46] – Ronny: Sí. Quiero decir, una cosa son las medidas de protección en los flujos de trabajo y lo que los clientes pretendan hacer. Por otro lado, están los aspectos de seguridad más técnicos, con la limitación de la tasa de llamadas a la API, el control de acceso y cosas por el estilo. Así que se trata de dos cosas distintas que estamos llevando a cabo en paralelo.

[29:03] – Presentador: Bueno, y también parece que una de las ventajas de utilizar ese escenario de «dos personas en el bucle» es que puede tender un puente entre esos silos de los que hablábamos. Así que, ya sabes, quizá el operador de red piense que todo está bien, pero tengamos que obtener también la aprobación del departamento de seguridad, o algo por el estilo. Así que te permite tener aquí un contexto más amplio.

[29:26] – Presentador: Voy a volver sobre algo que has dicho antes, porque no he dejado de darle vueltas desde que lo mencionaste. Has comentado que, cuando lanzasteis por primera vez este enfoque «API-first», os sorprendió un poco ver cómo vuestros clientes estaban utilizando el núcleo como una CMDB, por ejemplo. Y pensé: «Claro que lo hacían, y claro que yo también me sorprendería mucho si estuviera en tu lugar». ¿Cuáles son algunas de las cosas que te están sorprendiendo ahora mismo de lo que hacen tus clientes? Por ejemplo, cuando vas a las instalaciones de un cliente y están haciendo algo y piensas: «Vaya, no habíamos pensado en eso, pero realmente queremos tenerlo en cuenta más adelante como parte de nuestra hoja de ruta».

[30:01] – Ronny: Sí. Lo que realmente me sorprende es… si nos centramos ahora en los servicios básicos de red, como el DNS y el DHCP, tradicionalmente BlueCat se ha centrado en proporcionar sus propios servicios de DNS y DHCP de BlueCat. Así que los clientes implementan este tipo de servicios dentro de su entorno. Sin embargo, con el enfoque «API-first» de nuestra plataforma DDI, y también cuando lanzamos los servidores MCP y lo que llamamos LiveAssist —aunque el nombre no importa, se trata de nuestro agente de IA, que se centra en la propia plataforma—, los clientes pasaron a preguntarse: «Oye, ¿por qué no gestionar también otros servidores DNS y DHCP desde aquí?». Así que: «Tengo Azure o AWS Route 53», o «Recientemente he realizado una adquisición y quiero integrar mi entorno de Microsoft», o «Oye, tengo un dispositivo Meraki por ahí. ¿Puedo integrarlo también?». Bueno, acabo de mencionar un par de nombres de proveedores, pero solo son ejemplos.

[31:24] – Ronny: Lo que resultó interesante entonces fue lo siguiente: en nuestra lista de materiales vemos lo que el cliente ha comprado, pero estos entornos eran mucho más amplios, porque lo utilizaban para gestionar plataformas de terceros, y nosotros no éramos conscientes de ello. Lo que nos llevó a ponerlo en práctica directamente, en uno de nuestros productos, fue que lo aprovechamos y colaboramos con el cliente y con el proveedor. Nos pusimos en contacto con el proveedor, en ese caso Meraki, y le dijimos: «Oye, ¿qué estáis haciendo ahí? Suena interesante. Queremos saber más». Aprovechamos esa información y la convertimos en una integración del producto, que ya está disponible.

[32:08] – Presentador: Así que se trata de vuestra integración con Meraki, la funcionalidad de gestión de Meraki.

[32:15] – Ronny: Correcto. Y eso surgió básicamente de una conversación con un cliente que intentó hacerlo. De nuevo, la plataforma era capaz de hacerlo, pero sería mejor que funcionara así de serie.

[32:34] – Presentador: Sí. Exacto. Y eso nos lleva de nuevo a la idea general de «API-first», porque mientras hablabas estaba pensando en las ventajas que estabas detallando, y todo se reduce a que, cuando se diseña algo correctamente desde el principio, muchas cosas surgen de ahí. Una de ellas es que puedes añadir nuevas capacidades mucho más rápido que si estuviera mal diseñada. Y otra es que puede hacer cosas que nunca tuviste la intención de que hiciera, y hacerlas bien y con resiliencia. De hecho, esa es una de las medidas de una buena arquitectura: ¿puede hacer cosas que no habías planeado que hiciera? Es una de las grandes ventajas del TCP/IP. Antes se solía decir que el TCP/UDP nunca transmitiría vídeo porque, sencillamente, no estaba diseñado para ello. Pero estaba tan bien diseñado que, de hecho, lo hizo. Y por eso creo que ese es uno de los retos cuando dices: «Bueno, nuestra prioridad son las API». Es como decir: «Bueno, lo hemos hecho bien», y los beneficios de hacerlo bien solo se verán más adelante. Y creo, John, que incluso tú aludiste a eso: no es invisible, pero solo se nota más tarde.

[33:37] – Presentador: Sí. Propiedades emergentes de un sistema bien diseñado.

[33:43] – Ronny: Por supuesto. Por supuesto.

[33:43] – Presentador: Sí. Oh, me encanta cómo lo has dicho. «Propiedades emergentes». [risas]

[33:49] – Presentador: Bueno, ¿hay algo más que quieras destacar, Ronny? Ya hemos hablado de muchas cosas. Hemos hablado de las ventajas de un sistema abierto en las operaciones de red y de las ventajas del enfoque «API-first». ¿Hay algo más que quieras destacar?

[34:01] – Ronny: Sí, si tuviera que pedir algo a la audiencia —y, de nuevo, esto se basa en mi experiencia tras numerosas conversaciones con clientes y en los entornos en los que trabajamos—, sería que lo tuvieran en cuenta a la hora de evaluar productos y plataformas. No lo consideren solo desde el punto de vista del departamento del que son responsables, donde quizá tengan ese requisito en este momento. Pensad con un poco más de amplitud: ¿qué tipo de unidades de negocio, qué otro tipo de públicos dentro de la empresa necesito involucrar para comprender realmente cómo lo utilizan y qué requisitos adicionales tienen? Y luego echad un vistazo más a fondo a cómo funciona realmente la plataforma. No os limitéis a marcar la casilla: «Ah, cumple su función».

[34:51] – Presentador: Eso es… [se aclara la garganta] Te estoy escuchando y pienso exactamente lo mismo, porque es muy fácil para cualquier proveedor decir: «Ah, sí, somos API-first. Marca esa casilla». ¿Qué preguntas interesantes se podrían plantear para descubrir la diferencia entre alguien que realmente da prioridad a las API y alguien que no lo hace, pero que simplemente afirma hacerlo? Es decir, cuando miro «bajo el capó», ¿qué es lo que debo buscar?

[35:15] – Ronny: Sí. Así que, en primer lugar, les preguntaría si cumplen con ciertas especificaciones de OpenAPI o algo por el estilo. Lo segundo, sin duda: si se trata de una conversación, no de una solicitud de propuestas (RFP) ni nada por el estilo… es un poco diferente con las hojas de proceso de RFP y cosas así. Pero si estás en una conversación, pon a prueba al proveedor: «¿Cómo abordarías la integración con la plataforma XYZ? Ese es mi caso de uso. ¿Cómo puedo hacerlo?». Y si simplemente dicen: «Ah, sí, podemos hacerlo», pregúntales cómo. «Muéstrame paso a paso cómo es el proceso».

[36:05] – Presentador: Sí, tiene mucho sentido. Y además, si das un paso atrás, quizá tengas, como criterio de selección, «se integra bien con otras plataformas», lo cual es un poco vago. Puede que ni siquiera lo tengas como criterio de selección, porque quizá creas que no es necesario. Pero sigue siendo una buena idea preguntar al respecto, porque todo lo que crees que es necesario o innecesario puede cambiar si tu empresa compra otra empresa, por ejemplo, o si es adquirida por otra empresa.

[36:37] – Ronny: Sí. Exactamente.

[36:42] – Presentador: De acuerdo. Bueno, esto ha sido muy informativo, y gracias por dedicar tu tiempo a explicarnos todo esto, porque creo que es muy útil tanto para nosotros como para nuestros oyentes. Ronny, ¿dónde pueden encontrarte las personas si quieren ponerse en contacto contigo personalmente?

[36:55] – Ronny: Lo más fácil es ir a LinkedIn y buscar «Ronny Wolf, BlueCat Networks», y seguro que será el primer resultado de la búsqueda, la primera coincidencia. Allí me encontrarás. Sí, conéctate conmigo, envíame un mensaje e intentaré responderte lo antes posible.

[37:16] – Presentador: Y cuéntanos cuáles son tus mayores retos, porque de eso te ganas la vida: de entender los retos de los clientes.

[37:23] – Ronny: Exacto.

[37:23] – Presentador: De acuerdo. Y al resto de vosotros, por favor, echad un vistazo a bluecatnetworks.com para obtener más información. Además, BlueCat os pide que rellenéis el formulario de contacto para concertar una cita con un miembro del equipo y hablar sobre vuestra red, así como para conocer un poco mejor BlueCat. De nuevo, es bluecatnetworks, con una «s», .com. Rellenad el formulario de contacto para obtener más información. [música] Muchas gracias.