La mayoría de los programas de automatización de redes se estancan en el mismo punto. La computación, la configuración de red y el despliegue de aplicaciones se ejecutan mediante código, mientras que la gestión del DNS, el DHCP y las direcciones IP sigue dependiendo de los tickets. La razón rara vez radica en la cadena de herramientas de automatización. Se debe a que la «infraestructura como código» gestiona el estado de la configuración, mientras que la DDI mantiene un inventario dinámico y controvertido que debe ser arbitrado en lugar de simplemente declarado. Para cerrar esa brecha se necesita una capa de DDI diseñada para la automatización, y hay tres formas de conseguirla. BlueCat Micetro coordina los servidores DNS y DHCP que ya están en producción a través de una única API. BlueCat Integrity consolida el DNS, el DHCP y la gestión de direcciones IP (IPAM) en una sola plataforma, donde cada acción de la interfaz tiene un equivalente documentado en la API. BlueCat Horizon coordina todo el entorno desde un plano de control alojado, mientras que los servicios de protocolo siguen ejecutándose localmente.
· 01 — Por qué los programas de automatización de redes se limitan al DNS, el DHCP y las direcciones IP
¿Por qué se estancan los programas de automatización de redes cuando llegan a la gestión de DNS, DHCP y direcciones IP?
Los programas de automatización de redes se estancan en el DDI porque la gestión del DNS, el DHCP y las direcciones IP suele seguir realizándose mediante herramientas heredadas, fragmentadas y manuales que se encuentran fuera de la cadena de herramientas de automatización.
Esos sistemas ofrecen una visión limitada de la actividad de la red, no mantienen ningún registro oficial que la automatización pueda consultar y obligan a que cada cambio pase por una persona, por lo que la única dependencia que comparten todos los demás flujos de trabajo automatizados sigue siendo manual.
Los sistemas y procesos DDI heredados crean puntos ciegos que hacen que la automatización sea insegura, y no solo lenta. Las herramientas fragmentadas consumen hasta un 30 % del tiempo del personal de TI en operaciones rutinarias, y esa misma fragmentación aumenta el riesgo de interrupciones del servicio, ya que no existe una visión única que permita detectar un cambio conflictivo antes de que llegue a producción. La automatización construida sobre esa base hereda los puntos ciegos en lugar de resolverlos.
La unificación de DDI cambia la economía del trabajo, más allá de la mera interfaz. Las organizaciones que pasan de una gestión de DDI heredada a una plataforma unificada registran una resolución de incidencias un 75 % más rápida y una reducción del 86,8 % en el tiempo dedicado a las operaciones de DDI, además de la eliminación de las interrupciones relacionadas con el DNS. Estas ventajas se derivan de tres características de las que depende realmente la automatización: visibilidad y control totales, automatización de procesos de extremo a extremo y fiabilidad de la infraestructura.
86,8 %
86,8 %
Las organizaciones que pasan de una gestión de DDI heredada a una plataforma unificada registran una reducción del 86,8 % en el tiempo dedicado a las operaciones de DDI y una resolución de incidencias un 75 % más rápida.
Learn with BlueCat how visibility and control, process automation, and infrastructure reliability offer three reasons to adopt Unified DDI.
5 min·Blog
Leer más →
· 02 — Donde las herramientas de automatización de uso general alcanzan su límite
¿Pueden Ansible y Terraform gestionar el DNS, el DHCP y el espacio de direcciones IP por sí mismos?
Ansible, Terraform y herramientas similares pueden gestionar cambios en el DNS y las direcciones IP, pero no pueden servir como sistema de registro para el espacio de direcciones.
La «infraestructura como código» declara el estado de configuración deseado, mientras que el DDI tiene que arbitrar un inventario en tiempo real, finito y disputado entre equipos y entornos. Sin una plataforma que albergue ese inventario y lo exponga a través de una API, la automatización acaba declarando direcciones sin poder verificar que estén libres.
El límite práctico se manifiesta primero en la escala y, después, en la cobertura. Las organizaciones que gestionan miles de cambios de DNS diarios en entornos dinámicos en la nube necesitan una resolución automatizada de conflictos y una aplicación coherente de las políticas, no por canal. Las herramientas de uso general no tienen un concepto nativo de grupo de direcciones, conflicto o límite de política, por lo que cada canal vuelve a implementar esas reglas y cada implementación se desvía de las demás.
La segunda limitación es la propia plataforma DDI. Muchos sistemas DDI heredados carecen de las capacidades de API que requieren los flujos de trabajo de automatización modernos, lo que significa que la limitación no radica en absoluto en la herramienta de automatización. Cuando la plataforma solo expone una parte de lo que su interfaz es capaz de hacer, la automatización se detiene en ese límite y la excepción manual se convierte en permanente. La seguridad desde el diseño, la integración en la nube y la programabilidad de las API son los factores que determinan si una capa DDI puede participar en una práctica de automatización o si simplemente queda al margen de ella.
Learn with BlueCat how security by design, cloud integration, and API programmability offer three technical reasons to adopt Unified DDI.
6 min·Blog
Leer más →
· 03 — Las tres formas de cerrar la brecha y en qué se diferencian
¿Cuáles son los enfoques para automatizar el DNS, el DHCP y el IPAM, y en qué se diferencian?
Existen tres vías prácticas.
Orquestar los servidores DNS y DHCP que ya están en producción desde un único plano de control, sin necesidad de modificarlos. Consolide el DNS, el DHCP y el IPAM en una única plataforma «API-first», en la que cada acción de la interfaz tenga un equivalente API documentado. O coordine todo el entorno desde un plano de control alojado, mientras los servicios de protocolo siguen ejecutándose localmente. Las tres opciones dan lugar a una capa DDI automatizable; se diferencian en lo que ocurre con la infraestructura que ya tiene en funcionamiento y en qué parte de la plataforma gestiona usted mismo.
La orquestación es adecuada para entornos en los que los servidores existentes deben permanecer donde están. Un plano de control se sitúa por encima de Microsoft, BIND, Kea y los servicios en la nube, presenta una única API para todos ellos y deja intacta la infraestructura subyacente, de modo que los patrones de automatización se establecen sin necesidad de una migración. La consolidación es adecuada para entornos que, de todos modos, se están estandarizando. Sustituir las herramientas fragmentadas por una única plataforma elimina por completo la capa de traducción y proporciona a la automatización un registro único y fiable con cobertura programática completa, a costa de una migración.
La tercera vía cambia quién opera el plano de control, más que lo que este hace. Un plano de control alojado centraliza las políticas, la identidad, la generación de informes y la automatización, mientras que el DNS y el DHCP siguen resolviéndose localmente en cada entorno, lo que se adapta a entornos cuyo peso se ha desplazado a la nube o a equipos sin capacidad para ejecutar otra plataforma. Lo que las tres opciones tienen en común es el requisito subyacente: unas API completas que conecten el DDI con los flujos de trabajo de DevOps, las herramientas de seguridad, las plataformas de ITSM y las prácticas de infraestructura como código, de modo que los flujos de trabajo de extremo a extremo se ejecuten sobre datos fiables en lugar de sobre una copia de los mismos.
Unify DNS, DHCP, and IPAM (DDI) to boost visibility, automation, and security. Explore nine reasons to modernize DDI and streamline network operations.
19 min·Blog
Leer más →
· 04 — Lo que tu infraestructura actual decide por ti
¿Cómo se determina qué vía de automatización de DDI se adapta mejor a la infraestructura con la que ya se cuenta?
El camino a seguir viene determinado por dos factores que puedes comprobar hoy mismo: qué parte del entorno ya se ejecuta en la nube pública fuera del control del equipo de DDI, y qué grado de completitud tiene la cobertura de la API de tu plataforma actual.
La fragmentación entre cuentas en la nube apunta hacia un plano de control coordinador. Una plataforma cuya interfaz puede hacer más que su API apunta hacia la consolidación. Un entorno que funciona pero al que no se puede acceder mediante programación apunta hacia la orquestación.
Empiece por la postura de la nube, ya que normalmente ya está decidida por usted. Una investigación de EMA realizada entre 333 profesionales de TI reveló que el 44 % de los equipos de DDI cree que no tiene suficiente influencia sobre cómo se implementa y gestiona la DDI en la nube pública, y que los equipos que carecen de esa influencia suelen calificar su estrategia de DDI como infructuosa. El 79 % de las empresas ya integra la gestión de direcciones IP locales en sus entornos en la nube, y las organizaciones multicloud son aún más propensas a hacerlo.
A continuación, comprueba la cobertura de las API, ya que es el indicador más fiable de los datos. El 89 % de las organizaciones considera el DDI como la fuente de referencia para la automatización de la red, y el 83 % cuenta con soluciones DDI con API, pero menos del 44 % está plenamente satisfecho con ellas. Esa brecha de satisfacción está estrechamente relacionada con el éxito: el 70 % de las organizaciones con estrategias de DDI muy exitosas están plenamente satisfechas con sus API, frente al 17 % de aquellas cuyas estrategias están teniendo dificultades. Si una acción existe en la interfaz pero no tiene un equivalente documentado en la API, la automatización se detiene en ese límite.
70 %
70 %
El 70 % de las organizaciones con estrategias de DDI muy exitosas están plenamente satisfechas con sus API de DDI, frente al 17 % de aquellas cuyas estrategias están atravesando dificultades.
Only 40% of enterprises believe they are fully successful with their DDI solution. Learn how to find greater success with new research from EMA and BlueCat.
8 min·Blog
Leer más →
Habla con un experto de BlueCat sobre cómo ampliar la automatización a la gestión de DNS, DHCP y direcciones IP en tu entorno.
· 05 — Orquestación de los servidores DNS y DHCP que ya están en producción
¿Cómo consigue la orquestación que los servidores DNS y DHCP existentes sean automatizables sin necesidad de sustituirlos?
La orquestación sitúa un plano de control por encima de los servidores DNS y DHCP que ya están en funcionamiento y ofrece una única API para todos ellos.
Microsoft, BIND, Kea, Cisco Meraki y los servicios basados en la nube siguen funcionando como hasta ahora, mientras que el espacio de direcciones, los registros y las políticas se gestionan de forma centralizada. De este modo, un único flujo de trabajo de automatización abarca todos los back-ends, en lugar de un flujo de trabajo por plataforma, lo que supone la laguna específica que deja sin cubrir la infraestructura como código de uso general.
BlueCat Micetro desempeña esta función como una capa superpuesta no disruptiva, integrando y orquestando la infraestructura actual de DNS, DHCP e IPAM a través de una única interfaz web con acceso REST, SOAP y JSON-RPC, así como módulos de Ansible para crear flujos de trabajo. Dado que los servidores subyacentes no se modifican, los modelos operativos y las inversiones existentes permanecen intactos, y los patrones de automatización se establecen sin que una migración se interponga entre el equipo y su primer flujo de trabajo operativo.
El aspecto de la gobernanza es tan importante como la API. Que varios administradores realicen cambios en el DNS sin una supervisión coherente es un modo de fallo habitual, y los flujos de trabajo de aprobación, el acceso basado en roles y el seguimiento detallado de los cambios son lo que permite que la automatización funcione sin perder el control. Para los entornos que modernizan el DNS heredado de Microsoft, los dispositivos MDDS, el registro mejorado y las capacidades de conmutación por error proporcionan una ruta de transición gradual en lugar de una migración brusca.
BlueCat Micetro is an easy, intuitive DDI orchestration solution that overlays your existing DNS, DHCP, and IPAM services to provide centralized visibility…
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
5 min·Page
Ver Micetro →
· 06 — Consolidación en una única plataforma «API-first»
¿Qué aporta una plataforma DDI «API-first» a una práctica de automatización que una «overlay» no ofrece?
La consolidación elimina la capa de traducción.
Una única plataforma agrupa DNS, DHCP e IPAM en un único registro de referencia, y cada acción disponible en la interfaz está disponible como una llamada a la API documentada, por lo que ninguna funcionalidad queda fuera del alcance de la automatización. Esto cobra mayor importancia cuando la automatización debe extenderse más allá de la propia DDI hacia las herramientas de seguridad, la observabilidad y la gestión de servicios de TI (ITSM), ya que el límite de la API se convierte en el límite de lo que se puede correlacionar.
BlueCat Integrity responde a la cuestión de la cobertura de forma estructural, en lugar de mediante meras afirmaciones. Integrity X ejecuta su propia interfaz en la misma API REST v2 que expone a los clientes, definida en OpenAPI y consultable en Swagger, de modo que el trabajo manual se convierte en una especificación para la automatización, en lugar de una vía alternativa que la eluda. La gestión centralizada de DNS, DHCP e IP viene acompañada de una gobernanza basada en políticas, un control de acceso basado en roles, auditorías de cumplimiento y un seguimiento automatizado de los cambios ya integrados.
Ese alcance va más allá de la DDI. Integrity está diseñada para integrarse con las herramientas de observabilidad de red de LiveAction, y los equipos que utilizan ambas encuentran que el trabajo resulta más sencillo que si utilizaran cada una por separado, ya que ninguna de las plataformas acaba reteniendo datos a los que la otra no pueda acceder. Esa es la prueba práctica de una afirmación de «API-first»: si los sistemas que no pertenecen al proveedor de DDI pueden acceder a los datos de una plataforma.
1:1Paridad entre la interfaz de usuario y la API
1:1 Paridad entre la interfaz de usuario y la API
Cada acción en la interfaz de Integrity X se ejecuta como una llamada real y documentada a la API REST v2, por lo que ninguna funcionalidad de la interfaz queda fuera del alcance de la automatización.
Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.
9 min·Page
Ver Integrity →
· 07 — Coordinación de la automatización desde un plano de control SaaS
¿Cuándo debería coordinarse la automatización de DDI desde un plano de control alojado en lugar de uno que se ejecute en tus propias instalaciones?
Un plano de control alojado resulta adecuado cuando el entorno está repartido entre distintas nubes y entornos, y la restricción determinante es la coordinación más que la capacidad.
Las políticas, la identidad, la generación de informes y la automatización se centralizan, mientras que el DNS y el DHCP siguen ejecutándose localmente, con lo que se consigue coherencia sin sacar los servicios de protocolo ni la telemetría de gran volumen de los entornos que los generan.
BlueCat Horizon proporciona ese plano de control como un conjunto de servicios de plataforma basados en SaaS que abarcan tanto el DDI como las soluciones de observabilidad de red adquiridas con LiveAction. Ofrece pasarelas de API compartidas, autenticación, gestión de credenciales, coherencia de interfaces y análisis centralizados mediante IA en todos los productos de BlueCat, lo que hace que la automatización sea coherente en toda la cartera, en lugar de limitarse a funcionar correctamente en cada una de sus partes. EMA identifica la unificación de DDI y la observabilidad como un cambio estratégico en la forma en que las organizaciones crean y consumen servicios de red.
Centralizar el control no es lo mismo que centralizar la ejecución. El plano de control, las capacidades de IA y la lógica de orquestación se ejecutan en la nube, mientras que los servicios de protocolo y la telemetría de gran volumen permanecen en las instalaciones o en los propios entornos en la nube del cliente. Esa separación permite una automatización entre productos que antes era imposible: los datos de DDI sobre la ubicación y la criticidad de los servicios enriquecen los flujos de trabajo de incidentes; la información sobre el rendimiento en tiempo real impulsa el redireccionamiento del tráfico DNS; y la detección de amenazas basada en el DNS activa la contención automática.
BlueCat Horizon is a SaaS-first Intelligent NetOps platform unifying DNS, DHCP, IPAM, security, and observability to automate modern network operations AI
6 min·Page
Ver Horizon →
· 08 — Caminos a seguir
¿Qué vía hacia la automatización de DNS, DHCP e IPAM se adapta mejor a tu práctica de automatización de redes?
El camino se adapta a las limitaciones. Si los servidores deben permanecer, orquestadlos. Si la plataforma ya se está sustituyendo, consolidadla en una que ofrezca una cobertura completa de la API. Si el entorno está repartido entre varias nubes y el problema es la coherencia, coordinadlo desde un plano de control alojado. Si aún faltan meses para tomar la decisión, definid los requisitos ahora mismo para que la evaluación compruebe los aspectos adecuados.
PATH 01
Cuando los servidores existentes se mantienen y la migración queda descartada
Orquestar los servidores que ya están en producción
Coloca Micetro por encima del entorno existente para que una sola API cubra todos los back-ends y, a continuación, dirige la automatización del aprovisionamiento hacia esa API en lugar de escribir un flujo de trabajo por cada plataforma. Los flujos de trabajo de aprobación y el acceso basado en roles mantienen intacta la gobernanza a medida que se expande la automatización. Esto establece patrones de automatización funcionales sin necesidad de rediseñar la arquitectura y sin tener que esperar a que se tome una decisión sobre la plataforma.
Cuando la plataforma ya se está sustituyendo, o la automatización tiene que ir más allá de la DDI
Consolidar en una plataforma con cobertura completa de API
Traslada el DNS, el DHCP y el IPAM a Integrity para que un único registro oficial dé servicio a todos los flujos de trabajo y cada acción de la interfaz tenga un equivalente API documentado. Valida la paridad de cobertura antes de definir el alcance del trabajo, ya que ese límite es donde suelen estancarse los proyectos de automatización de DDI. La integración con herramientas de observabilidad cobra sentido una vez que se puede acceder al registro de DDI mediante programación.
Cuando el entorno está distribuido y el problema es la coherencia, no la capacidad
Coordinar el parque de equipos desde un plano de control alojado
Conecta el DDI existente a través de Horizon para que las políticas, la identidad, la generación de informes y el análisis sean coherentes, mientras que los servicios de protocolo siguen ejecutándose localmente. La automatización entre productos, entre el DDI y la observabilidad, pasa a estar disponible sin necesidad de mover la telemetría ni de reconfigurar manualmente cada integración. Opta por esta solución cuando el entorno esté distribuido y ninguna decisión sobre una única plataforma pueda solucionarlo.
Cuando se avecina una actualización de DDI, pero aún no se ha tomado la decisión
Define los requisitos de «automatización primero» antes de la evaluación
Redacta primero los requisitos relativos a la paridad de cobertura de las API, la visibilidad híbrida, la aplicación de políticas y las garantías de migración; a continuación, utilízalos para orientar la evaluación. Pregunta si cada acción de la interfaz tiene un equivalente documentado en la API, y hazlo antes de la presentación de las funcionalidades. Los requisitos definidos a posteriori tienden a describir la demostración más que el entorno real.
Estas respuestas abordan las dudas más habituales de los equipos que amplían una práctica de automatización de red ya existente a la gestión de DNS, DHCP y direcciones IP.
Terraform puede crear y modificar registros DNS y asignaciones de IP cuando existe un proveedor, pero no puede actuar como sistema de registro para el espacio de direcciones. Declara el estado deseado a partir de un repositorio, mientras que el IPAM tiene que gestionar un inventario finito y compartido entre equipos y flujos de trabajo en tiempo real. BlueCat Integrity está diseñado para desempeñar esa función, albergando el DNS, el DHCP y el IPAM como un único registro autoritativo accesible a través de una API REST documentada. Sin una plataforma que haga eso, Terraform puede declarar una dirección sin tener forma alguna de verificar que esté libre.
Ansible es muy adecuado para impulsar cambios en la DDI una vez que una autoridad competente decide cuáles deben ser esos cambios. Lo que le falta de forma nativa es el concepto de un grupo de direcciones, un conflicto o un límite de política, por lo que esas reglas se reimplementan en cada playbook y se van desviando con el tiempo. BlueCat Micetro está diseñado para esa combinación: almacena las reglas una sola vez y las expone a través de REST y módulos de Ansible para que los playbooks existentes lleguen a todos los back-ends, razón por la cual ambos suelen combinarse en lugar de sustituirse.
Depende de lo que ocurra con los servidores DNS y DHCP que ya están en producción y de quién gestione la capa superior a ellos. Micetro orquesta los servicios existentes de Microsoft, BIND, Kea, Meraki y en la nube como una superposición sin interrupciones, por lo que se adapta a entornos en los que esos servidores se mantienen. Integrity consolida el DNS, el DHCP y el IPAM en una única plataforma centrada en las API, lo que resulta adecuado para entornos en proceso de estandarización o cuya automatización debe extenderse a las herramientas de seguridad y observabilidad. Horizon coordina un entorno distribuido desde un plano de control alojado, mientras que los servicios de protocolo siguen ejecutándose localmente. Se trata de alternativas seleccionadas en función de las circunstancias, no de etapas de una secuencia.
Pregunte si cada acción disponible en la interfaz tiene un equivalente documentado en la API, y solicite ver la especificación en lugar de un resumen. Las lagunas de cobertura son el motivo por el que se estancan los proyectos de automatización, ya que una sola acción no expuesta se convierte en una excepción manual permanente en un flujo de trabajo que, por lo demás, estaría automatizado. BlueCat Integrity responde a esto de forma estructural: Integrity X ejecuta su propia interfaz en la misma API REST v2 que expone a los clientes, por lo que cada acción de la interfaz de usuario es una llamada a la API documentada. Los datos de las encuestas muestran que la satisfacción con las API de DDI sigue de cerca el éxito general de DDI, lo que convierte esta cuestión en un tema clave más que en un simple detalle técnico.
No. Una capa de orquestación se sitúa por encima de los servicios existentes de Microsoft, BIND, Kea y en la nube, y presenta una única API para todos ellos, dejando los servidores en su lugar. BlueCat Micetro desempeña ese papel como una superposición no disruptiva, de modo que se pueden establecer patrones de automatización sin que un proceso de migración se interponga en el camino. Vale la pena plantearse la migración cuando el objetivo es disponer de un único registro oficial en lugar de una interfaz unificada, o cuando la cobertura de la API de la plataforma existente es lo que impide la automatización.
El DDI contiene el registro oficial de qué es una dirección y a qué servicio pertenece, mientras que las herramientas de observabilidad ofrecen una visión de cómo se ha comportado realmente la red. Los equipos que utilizan ambas soluciones conjuntamente suelen sacar más partido de cada una de ellas que el que ofrece cada una por separado. BlueCat Horizon se basa en esa combinación, integrando la DDI y la observabilidad de la red en una única plataforma SaaS. Lo que hace que funcione en cualquier caso es que se pueda acceder a la plataforma DDI mediante programación, razón por la cual la cobertura de la API determina si ambas soluciones pueden utilizarse juntas.
Empieza por comprobar dos cosas: qué parte del entorno se ejecuta en la nube pública fuera del control del equipo de DDI, y si la API de la plataforma actual cubre todas las funciones que su interfaz puede realizar. Esas dos respuestas suelen apuntar, por sí solas, a Micetro, Integrity u Horizon. A partir de ahí, automatice primero los flujos de trabajo que bloquean otras tareas; por lo general, se trata de la asignación de direcciones y la creación de registros durante el aprovisionamiento, y amplíe la automatización una vez que los patrones hayan demostrado su eficacia.
¿Todavía tienes dudas?
Obtén respuestas reales de un representante de BlueCat.
We’re using cookies on this website to improve your experience. Cookies help us learn how you interact with our website and remember you when you come back so we can tailor it to your interests.
To learn more about cookies and how we use them, read our cookie notice.
Some cookies are essential, while others help us to improve your experience by giving us insight into how you are using our website. You may adjust your preferences for non-essential cookies below.
To learn more about cookies and how we use them, read our cookie notice. You can also review our privacy policy for more details on the personal data we collect, use, hold, and disclose when you visit our website or use our products and services.
Functional cookies
Functional cookies are essential cookies that allow us to remember choices or changes you have made (such as to language settings or your choices regarding the use of cookies). These cookies cannot be turned off since they are essential for the operation of our Websites.
Analytics cookies
Analytics cookies are non-essential cookies that collect information on how visitors use our Websites. We use this information with your consent to measure the number of visitors to our Websites, determine whether specific content or communication has been viewed, and to help us improve our Websites and communication. These cookies can be turned off.
Personalisation Storage
Personalisation cookies are non-essential cookies that collect information when you fill out a form on this website. We only use this information with your consent to pre-fill other forms on the site. These cookies can be turned off.
Marketing cookies
Marketing cookies are cookies that are placed by third parties to collect information about your visits and actions on our Websites so that they or we can deliver ads to you later, such as when you are on certain third-party sites or platforms. These cookies may be used by those third parties to build a profile of your interests and show you relevant ads on other websites. These cookies also enable visitors to our Websites to share content on social networks and to enable and evaluate interactions with our communication and social media tools. These cookies can be turned off.
