3. Pensamiento Arquitectónico#

Este capítulo introduce los fundamentos de este libro. Explica por qué necesitas adoptar esta mentalidad, introduce un marco de referencia propuesto por el Network Automation Forum (NAF), y muestra cómo aprovecharlo en tus proyectos.

La Parte 2 profundiza en estos temas. En este capítulo, solo los presentaremos para dar una visión de alto nivel antes de entrar en los detalles. Esto importa porque una vez que describamos cada bloque de construcción, tener la imagen general te ayuda a conectar los puntos.

Pero soy un firme creyente en entender el POR QUÉ antes del QUÉ, así que primero entendamos las razones para aprovechar una arquitectura.

3.1. Por qué importa una arquitectura de referencia#

“Solo los educados son libres.” de Epicteto

Una solución de automatización de redes es una combinación de múltiples piezas, cada una jugando un papel. En redes, estamos acostumbrados a soluciones simples o monolíticas que intentan comportarse como cajas todo-en-uno para resolver todos los problemas. Esto puede ser cierto hasta cierto punto, pero nada puede resolver por sí solo todos los desafíos y casos de uso tan diversos. Por eso, si tu caso de uso no es uno de los más populares, puede que necesites personalizar o extender.

Sin una arquitectura de referencia clara, los equipos a menudo enfrentan un conjunto predecible de problemas:

• Esfuerzo Duplicado: Múltiples equipos construyen herramientas similares (fuentes de datos, scripts duplicados, sistemas de monitoreo redundantes) de forma independiente, desperdiciando recursos y creando interfaces inconsistentes.
• Brechas de Integración: Las herramientas no se comunican entre sí de forma limpia, lo que obliga a costosos trabajos de integración personalizados.
• Responsabilidades Poco Claras: No está claro qué herramienta debe manejar la observabilidad, la orquestación o la gestión del estado, lo que lleva a confusión.
• Difícil de Extender: Añadir nuevas capacidades o herramientas requiere repensar todo el sistema.
• Silos de Conocimiento: Diferentes equipos usan diferentes modelos mentales, lo que dificulta incorporar nuevas personas o mantener soluciones.

Una arquitectura de referencia resuelve estos problemas proporcionando un único modelo mental claro sobre cómo deben organizarse los sistemas de automatización. Define:

• Qué debe hacer cada componente -> sus responsabilidades
• Cómo interactúan los componentes -> sus interfaces y flujos de datos
• Dónde puedes tomar decisiones -> qué herramientas usar
• Dónde necesitas consistencia -> cómo se comunican los componentes entre sí

Una arquitectura de referencia no es nueva para los ingenieros de red. Todos hemos crecido con nuestro querido modelo OSI. Usar el modelo OSI proporciona un enfoque por capas, paso a paso, para diagnosticar y comprender los problemas de red porque cada capa tiene diferentes responsabilidades y preocupaciones. Los profesionales de redes entienden intuitivamente que esta separación de responsabilidades hace que los sistemas complejos sean manejables.

En la automatización de redes, necesitamos algo similar que pueda guiar cómo desarrollar e interconectar soluciones que funcionen juntas. Ayuda a los equipos a tomar decisiones consistentes, reutilizar componentes en proyectos y evolucionar sus capacidades de automatización sin reinventar la rueda cada vez.

3.2. Una Arquitectura de Automatización de Redes#

En consecuencia, necesitamos una arquitectura. Pero nota la ‘A’ en el título de la sección: no hay solo una arquitectura, hay muchas. Una arquitectura es simplemente un marco de referencia: una forma de estructurar el pensamiento y guiar decisiones consistentes. He contribuido a tres iniciativas:

• Arquitectura de referencia de Network to Code, un esfuerzo colectivo liderado por el equipo de Arquitectura de NTC (del que formé parte durante cuatro años), diseñado para soportar automatización de redes eficiente y comprensible en una amplia gama de casos de uso.
• Network Automation and Programmability 2nd Edition de O’Reilly, un esfuerzo para conectar los puntos de todo el contenido del libro con mis coautores: Matt Oswalt, Scott S. Lowe y Jason Edelman.
• Marco NAF fue un proyecto comunitario bajo el paraguas del NAF liderado junto con Wim Henderickx, Dinesh Dutt, Claudia de Luna, Ryan Shaw y Damien Garros con el objetivo de ayudar tanto a los recién llegados como a los profesionales experimentados a construir soluciones de automatización de manera estructurada y repetible.

A través de estas iteraciones, me enfoqué en mantener la consistencia y aprender de cada evolución. Los tres enfoques son útiles. Sin embargo, propongo usar el NAF Framework como la mejor práctica actual: es impulsado por la comunidad, agnóstico al proveedor y ampliamente aplicable. Consolida años de aprendizaje colectivo y es mantenido activamente por una comunidad comprometida y en crecimiento.

Los tres son complementarios en lugar de competitivos. Una breve comparación ayuda a aclarar cuándo es más relevante cada uno:

El Marco NAF define los contratos entre bloques y deja abiertas las opciones de implementación. La arquitectura NTC llena esas opciones con recomendaciones específicas de herramientas. Si tu equipo usa herramientas NTC, ambas se aplican simultáneamente sin conflicto.

El NAF Framework propone la siguiente arquitectura:

block-beta
    columns 7
    
	space:1	
    block:layer1:5
        Presentation["Presentación"]
    end
	space:1

    space:7

    
    block:Observability:2
        columns 2
        ObservedState[("Estado Observado")]:1
        ObservedLogic["Lógica Observada"]:1
    end

	space
    
	block:Orchestration:1
		columns 1
		OrchLabel["Orquestación"]:1
	end

	space
    
    block:Intent:2
        columns 2
        IntendedState[("Estado Previsto")]:1
        IntendedLogic["Lógica Prevista"]:1
    end
    
    space:7

	space

    
    Collector["Recopilador"]:2
	space
    Executor["Ejecutor"]:2
	space
    
	space:7
	space:1
    
    block:layer4:5
        NetworkInfra["Infraestructura de Red"]
    end
    
    Presentation <--> Observability
    Presentation <--> Orchestration
    Presentation <--> Intent
    
    Observability <--> Orchestration
    Orchestration <--> Intent
    
    Collector --> Observability
    Collector <--> Orchestration
	NetworkInfra --> Collector
    
    Orchestration --> Executor
    Intent --> Executor
    Executor --> NetworkInfra
    
    classDef darkStyle fill:#5a4149,stroke:#4a9eff,stroke-width:2px,color:#e8e8e8,font-size:20px,font-weight:bold
    
    class Presentation,NetworkInfra,ObsLabel,IntLabel,Collector,Executor,ObservedState,ObservedLogic,IntendedState,IntendedLogic,OrchLabel darkStyle

Esta arquitectura contiene los siguientes bloques, usando las definiciones del documento:

• Intent (Architectural Block): Define la lógica para manejar y la capa de persistencia para almacenar el Desired State de la red, incluyendo tanto la configuración como las expectativas operacionales.
• Executor: Abarca las tareas reales aplicadas a la red para impulsar cambios (actualizando la configuración) según guía el estado previsto.
• Collector: En contraste con el Executor, este componente se enfoca en recuperar (leer) el Actual State de la red.
• Observability: Persiste el Actual State de la red y define la lógica para procesarlo.
• Orchestrator: Define cómo se coordinan y ejecutan las tareas de automatización en respuesta a eventos.
• Presentation (Layer): Proporciona las interfaces a través de las cuales los usuarios interactúan con el sistema, incluyendo dashboards, interfaces gráficas de usuario (ITSM) y herramientas Command Line Interface (CLI).

Esta arquitectura no es arbitraria; es la consecuencia natural de aplicar principios de ingeniería de software a las operaciones de red.

El marco NAF tiene como objetivo ayudar a los arquitectos de automatización de redes a organizar sus soluciones referenciando las funcionalidades de cada módulo, y definiendo MUSTs, SHOULDs y MAYs (usando el estilo RFC). Luego, puedes decidir cómo implementarlos para resolver tus propios casos de uso.

Tener múltiples componentes no significa que tengas que elegir una herramienta por componente. En muchos casos, podrías usar una herramienta que implementa diferentes funcionalidades, pero esto viene con compromisos que tienes que entender (y reconocer).

Ahora, repasaremos los diferentes bloques para presentarlos.

3.2.1. Intención o Fuente de Verdad#

La Intención son todos los datos que definen toda la información necesaria para llevar tu red de nada a completamente operativa, abarcando todos los diferentes estados del ciclo de vida, desde el pre-aprovisionamiento hasta el bootstrap, hasta completamente operativa, y la retirada final de todo tipo de servicios de red.

La arquitectura la llama Intención, pero la relaciono con otro término popular: Fuente de Verdad (SoT). El término SoT a veces se malentiende, y quiero comenzar aclarando qué es el SoT o la Intención (los usaré indistintamente a lo largo del libro).

Como puedes imaginar, esto podría representar datos muy diversos incluyendo dispositivos, direccionamiento IP, infraestructura de centro de datos (bastidores, cables), protocolos de enrutamiento, servicios virtualizados, secretos, límites operacionales, plantillas de configuración, y abstracciones de servicios o políticas. Un aspecto clave es que estos datos deben estar estructurados para ser entendidos por máquinas. Luego, deben soportar operaciones de crear, leer, actualizar y eliminar y ser accesibles a través de una Application Programming Interface (API) estandarizada y bien documentada como Representational State Transfer (REST) o GraphQL.

Por analogía con la gestión manual de redes, esto coincide principalmente con el papel del arquitecto de red que define el diseño, el esquema de red, o el planificador de red que define la lista de materiales para un nuevo despliegue de red.

Idealmente, este componente debería proporcionar una vista consistente y unificada del estado deseado, incluso cuando los datos están distribuidos en múltiples fuentes de datos. Estas fuentes de datos, que llamo Sistemas de Registro (SoR), son los propietarios reales de los datos. Así que, esto es una de las primeras cosas a aclarar: es extremadamente raro tener solo una fuente de datos, pero los datos deben ser consistentes cuando se consolidan. La gestión de datos es un tema complejo que requiere características de gobernanza de datos, incluyendo alguna forma de metadatos como marcas de tiempo, origen de los datos, propiedad de los datos y períodos válidos, para facilitar la comprensión y gestión de estos datos.

Además, conectado con las características que permiten la automatización de redes confiable, este bloque debería ofrecer acceso transaccional y versionado a los datos que permite procesos de automatización de redes predecibles y fiables.

Si estás intentando entender qué herramientas reales podrían encajar en esta categoría, aquí hay algunos ejemplos: archivos CSV/YAML/JavaScript Object Notation (JSON), Git, NetBox, Nautobot, Infrahub, Infoblox, o cualquier base de datos de propósito general.

Consulta el Capítulo 4 para una inmersión profunda en la construcción y gestión de tu Fuente de Verdad.

3.2.2. Ejecutor#

El ejecutor está a cargo de implementar (escribir) el estado deseado proveniente de la Intención en el estado real de la red, interactuando con la red a través de diferentes interfaces como SSH, NETCONF, gNMI/gNOI y APIs REST.

Continuando con la analogía a la gestión manual de redes, el ejecutor sería el ingeniero de red que prepara la configuración de red final y se conecta al dispositivo de red a través de CLI para introducir los comandos de configuración.

Sin embargo, esto no es tan simple como copiar y pegar datos de un lugar (la intención) a otro (la red). Hay muchas operaciones a tener en cuenta, desde cambios de red hasta reiniciar o actualizar sistemas. Además, aunque la mayoría de las veces los datos de referencia provienen del bloque de Intención, en algunos casos, los datos observados provenientes de Observabilidad pueden influir en este componente, por lo que ambos tienen que combinarse.

Por ejemplo, el Ejecutor podría validar la accesibilidad del dispositivo antes de intentar cambios, adaptar la lógica de failover según el estado actual de la red, u omitir la ejecución si Observabilidad muestra que un servicio de dependencia crítica está caído. Esta retroalimentación de Observabilidad asegura que las decisiones de automatización estén informadas por las condiciones reales de la red, no solo por la Intención.

Similar a la Intención, este componente debería proporcionar características como dry-run, cambios transaccionales e idempotencia (a través de enfoques declarativos o imperativos) que ayudan a construir sistemas de automatización en los que los ingenieros de red puedan confiar. Este es usualmente el componente del que los ingenieros de red se preocupan más (inicialmente) porque es el que realmente “cambia” la red.

Las herramientas que mayormente encajan en esta categoría son Ansible, Terraform/OpenTofu, o cualquier tipo de scripts que aprovechen bibliotecas como Netmiko, Scrapli o Napalm, o incluso un Kubernetes CRD (Custom Resource).

Dirígete al Capítulo 5 para explorar marcos de ejecución, patrones de idempotencia y estrategias de implementación.

3.2.3. Recopilador#

Análogo al Ejecutor, el Recopilador está a cargo de recuperar los datos operativos reales de la red a través de diferentes interfaces y protocolos (las mismas interfaces que el Ejecutor, más otras como SNMP, Syslogs u otras telemetrías basadas en flujo).

El destino de todos estos datos es el bloque de Observabilidad, donde los datos se usan para impulsar las decisiones de automatización.

Un tema importante aquí, no considerado habitualmente, es la necesidad de datos normalizados para ser comparables. Por eso, obtener nombres de métricas consistentes para todos los proveedores (system_version definiendo la versión del SO independientemente de la plataforma) y metadatos consistentes para permitir el procesamiento avanzado de datos es crucial.

Ejemplos de herramientas que encajan en esta categoría son Telegraf, Vector, gNMIc, PMACCT, goFlow, Akvorado, o cualquier tipo de script que aproveche bibliotecas para obtener datos de la red.

Por afinidad, cubriré el Recopilador junto con el siguiente bloque de construcción, Observabilidad, en el Capítulo 6. El Recopilador y la Observabilidad son arquitectónicamente distintos pero operativamente inseparables: cada decisión de diseño sobre cómo recopilar datos está impulsada por lo que la capa de Observabilidad necesita procesar. Cubrirlos juntos preserva esa dependencia.

3.2.4. Observabilidad#

Estrechamente relacionada con el Recopilador (en muchos casos vistos juntos), la Observabilidad recibe los datos recopilados, soporta su persistencia y ofrece acceso programático para soportar análisis avanzados, informes y flujos de trabajo de resolución de problemas, idealmente usando lenguajes de consulta capaces (como PromQL).

Los datos de este bloque deben exponer discrepancias relevantes entre el Desired State y el Actual State de la red, generando eventos (o alertas) que podrían desencadenar sistemas de mitigación.

Continuando con la analogía de la gestión manual de redes, esto encaja con el papel del centro de operaciones de red, que verifica el estado real de la red y reacciona en consecuencia.

Además, los datos observados pueden enriquecerse con información contextual del estado previsto, incluyendo otras fuentes de terceros (por ejemplo, información de EoL, CVEs, notificaciones de mantenimiento, etc.), mejorando el análisis y habilitando una correlación de datos más precisa.

En el monitoreo de red tradicional, todas las funcionalidades de Observabilidad (y recopilación) se han integrado en una gran caja (herramientas como Nagios, LibreNMS, Spectrum, etc.).

Actualmente, sistemas más diversos que se integran están ganando popularidad, siendo Prometheus e InfluxDB Time Series Database (TSDB) populares o Elasticsearch, y otros sistemas relacionados que gestionan las alertas (Alertmanager) y visualizan (Grafana, Kibana). Esto ha llevado a algunas pilas populares: ELK, TIG o TPG.

Aprende más sobre arquitectura de monitoreo, estrategias de alertas y mejores prácticas de observabilidad en el Capítulo 6.

3.2.5. Orquestador#

Hasta ahora, has visto muchos componentes diferentes, y existe la necesidad de coordinarlos: integrando los procesos de los diferentes bloques de construcción y creando sofisticados flujos de trabajo de automatización de extremo a extremo. Por eso, el orquestador debe soportar múltiples formas de interactuar, desde la activación manual hasta flujos de trabajo completamente impulsados por eventos, tanto de forma síncrona como asíncrona.

Los flujos de trabajo que implementa el orquestador deberían proporcionar formas de definir múltiples pasos, y también deben soportar funciones de reversión y dry-run, basándose en los otros componentes (por ejemplo, usando instantáneas versionadas del bloque de intención).

En las operaciones manuales, esto suele estar definido de forma vaga en una lista de verificación de un proceso que hay que seguir.

Este componente proporciona a los usuarios una visualización completa de lo que está sucediendo en toda la automatización de red, mostrando cómo se unen los diferentes procesos, a través de un registro claro y trazabilidad.

Ejemplos son AAP o AWX (Ansible Automation Platform), Windmill o Prefect.

Dónde encajan la IA y los agentes en la arquitectura: La toma de decisiones asistida por IA se sitúa principalmente en la intersección de los bloques de Orquestador y Observabilidad. Un agente de IA sigue un bucle de sentido-lógica-acción: observa el estado de la red a través del bloque de Observabilidad, aplica razonamiento para decidir qué acción se necesita, y activa el Ejecutor a través del Orquestador. Esto es distinto del papel tradicional del Orquestador (seguir un flujo de trabajo predefinido) pero usa la misma infraestructura. El Capítulo 7 (Orquestación, sección 7.2.7) cubre el enfoque agéntico como un patrón de coordinación; los Capítulos 15-17 lo exploran como la base para redes autónomas. Por ahora, piensa en la automatización agéntica como un enfoque de coordinación que reemplaza las definiciones de flujo de trabajo estáticas con toma de decisiones dinámica impulsada por modelos.

Sumérgete en el Capítulo 7 para aprender sobre diseño de flujos de trabajo, automatización impulsada por eventos y plataformas de orquestación.

3.2.6. Presentación#

A veces olvidamos lo importante que es exponer la interfaz adecuada a los usuarios de la automatización de redes. Esta es usualmente un área difusa porque todas las herramientas que ya hemos presentado tienen algún tipo de interfaz: CLI, API o basada en web. En algunos casos, puede que decidas que es suficiente. En otros casos, puede que crees tu propia interfaz de usuario para obtener lo mejor de todos los mundos y simplificar la experiencia de usuario. Depende.

Tradicionalmente, esto ha sido limitado para los usuarios externos a llamadas telefónicas o correo electrónico, y para los equipos de red, CLI.

De una forma u otra, esta capa debe permitir autenticación y autorización flexibles (es el punto de entrada de tu sistema), y luego ajustarse a las necesidades reales. A veces, esto podría ser una plataforma específica de red, o en otros casos podría integrarse con sistemas de toda la empresa (ServiceNow, Slack, etc.).

Podría cubrir operaciones de escritura o lectura, dependiendo del rol, pero siempre considera las necesidades de tus diferentes tipos de usuarios para obtener los mejores resultados.

Explora la experiencia de usuario, el diseño de interfaces y los patrones de integración en el Capítulo 8.

3.2.7. La Red#

Por último, pero no menos importante, tenemos que entender las capacidades de la red para soportar la automatización, y la red ya no son solo dispositivos y cables conectados. En la década de 2020, la virtualización y las soluciones de red basadas en la nube hacen que la accesibilidad de extremo a extremo (la red) sea un entorno híbrido y diverso.

La red en sí misma es tanto una restricción como un facilitador para toda tu arquitectura de automatización. A diferencia de los seis bloques anteriores sobre los que tienes control, la infraestructura de red (tus dispositivos, plataformas, servicios y conectividad) puede tener limitaciones que afectan lo que es posible.

Las capacidades de red caen en varias categorías:

• Interfaces y Protocolos: ¿Qué interfaces de gestión soporta tu red? ¿SSH CLI? ¿NETCONF? ¿gNMI? ¿APIs REST? ¿SNMP? Algunas plataformas soportan muchas, algunas pocas. Estas opciones restringen directamente lo que el Recopilador y el Ejecutor pueden hacer.
• Modelos de Datos: Incluso si un dispositivo soporta gNMI, los modelos YANG que expone pueden ser incompletos. Por ejemplo, tu dispositivo puede afirmar soporte gNMI pero no exponer la configuración específica que necesitas gestionar. Entender estas brechas es crítico durante la planificación.
• Madurez Operacional: Las plataformas más nuevas pueden tener APIs modernas pero comportamientos no documentados. Las plataformas más antiguas pueden ser estables pero carecer completamente de APIs. Necesitas evaluar la madurez real, no solo las características promocionadas.

Para soportar efectivamente la automatización, tu infraestructura de red debería idealmente proporcionar:

• Entornos de Desarrollo y Pruebas: Como el desarrollo de software, la automatización requiere lugares seguros para probar. Esto podría significar: redes de laboratorio (a menudo caras y limitadas), entornos de red virtuales (Containerlab, GNS3), o simuladores proporcionados por el proveedor (Cisco DevNet, Arista EOS-lite).
• Interfaces Consistentes: Si el 90% de tus dispositivos soportan NETCONF pero el 10% solo soportan SSH, necesitarás estandarizar o construir múltiples Ejecutores. Cada inconsistencia aumenta la complejidad.
• Telemetría Adecuada: Si no puedes obtener los datos que necesitas de tus dispositivos, la Observabilidad se vuelve sin sentido. Asegúrate de que tus dispositivos puedan transmitir telemetría (telemetría de streaming, SNMP, syslog) con la granularidad e información que necesitas.

La red es la parte más difícil de la arquitectura de cambiar. No puedes intercambiar fácilmente tus routers. Así que entiende sus restricciones temprano, y diseña tu automatización dentro de ellas. Por eso el bloque de Red merece una atención cuidadosa durante la planificación de la arquitectura.

Entiende las capacidades de red, las APIs de dispositivos y los entornos de prueba en el Capítulo 9.

A continuación, para resumir esta sección, repasemos un caso de uso muy simple y cómo la arquitectura se mapea a él.

3.2.8. Un Ejemplo Práctico#

Antes de sumergirnos en cada bloque, veamos un escenario concreto que muestra cómo funciona la arquitectura en conjunto.

Problema: Un equipo de aplicaciones ha enviado una solicitud para un nuevo segmento de aplicación: una nueva VLAN, subred IP, política de enrutamiento y zona de control de acceso en una red de campus heterogénea que ejecuta aproximadamente 800 switches de acceso y distribución de Cisco, Arista y HPE. El equipo de operaciones necesita cumplirlo de extremo a extremo sin trabajo manual de CLI en cientos de dispositivos.

Cómo puede resolverlo la arquitectura:

1. Intención (Fuente de Verdad): Un ingeniero de red introduce la nueva definición de servicio en Nautobot: ID de VLAN, subred, política de enrutamiento, plantillas de configuración por proveedor, y a qué grupos de switches se aplica. Esto se almacena como el Desired State, el único lugar de verdad para 800 dispositivos.
2. Orchestrator: AWX recibe un webhook de Nautobot sobre el cambio y activa el flujo de trabajo de ejecución, coordinando los pasos en el orden correcto y manejando los fallos por dispositivo.
3. Executor: Un playbook de Ansible lee de la Application Programming Interface (API) de Nautobot, renderiza la configuración específica del dispositivo por proveedor (Cisco, Arista y HPE requieren cada uno una sintaxis diferente), y envía los cambios a través de NETCONF. Cada ejecución es idempotente: ejecutarla de nuevo en switches ya configurados no produce ningún cambio.
4. Collector: Después del despliegue, un recopilador gNMIc se conecta a cada switch y recupera la membresía real de VLAN, el estado de la interfaz y las entradas de enrutamiento.
5. Observability: Los datos recopilados fluyen hacia un Time Series Database (TSDB) Prometheus. Una consulta compara el Desired State (de Intención) contra el Actual State (del Collector). Los switches donde falta la VLAN se exponen como métricas y activan alertas.
6. Orchestrator: Cuando se activa una alerta (“VLAN 210 no presente en access-switch-b3-07”), un flujo de trabajo AWX vuelve a ejecutar automáticamente el Executor en ese switch, vuelve a recopilar datos y valida la corrección.
7. Presentation (Layer): Un dashboard muestra los 800 switches agrupados por edificio y proveedor, destacando cuáles son conformes (✅) y cuáles han derivado (❌). El equipo de aplicaciones puede rastrear el despliegue sin acceso a CLI. Las operaciones de TI pueden activar remediaciones manuales sin escribir código.
8. La Red: El éxito de este flujo depende de lo que los dispositivos realmente soportan. En Cisco y Arista, NETCONF funciona limpiamente. Varios switches HPE solo soportan SSH CLI, por lo que un camino de Ejecutor separado los maneja, menos elegante pero necesario. Ninguna arquitectura elimina las restricciones del proveedor; simplemente las hace explícitas.

La Visión Clave: Ninguna herramienta única hizo esto. Nautobot (Intención), Ansible (Ejecutor), gNMIc (Recopilador), Prometheus (Observabilidad), AWX (Orquestador) y un dashboard de Grafana (Presentación) trabajaron juntos. La arquitectura proporcionó el modelo mental para cómo integrarlos.

Esto es lo que permite el pensamiento arquitectónico: automatización sistemática y composable.

A lo largo de la Parte 2 (Capítulos 4-9) volvemos a esta misma red de campus para explorar cada bloque de construcción en profundidad: el SoT almacena la definición del servicio VLAN (Capítulo 4), el Ejecutor lo despliega (Capítulo 5), la Observabilidad lo monitorea (Capítulo 6), el Orquestador coordina el ciclo de vida completo (Capítulo 7), la capa de Presentación lo expone a diferentes audiencias (Capítulo 8), y el capítulo de La Red cierra con una puerta de pre-producción basada en simulación (Capítulo 9). Donde los ejemplos hacen referencia a una herramienta de Fuente de Verdad, Nautobot y NetBox se usan indistintamente; los patrones arquitectónicos son los mismos independientemente de cuál elijas.

3.3. Cómo Usar una Arquitectura#

Ahora que entiendes los diferentes bloques de construcción de la arquitectura de automatización de redes NAF, quizás te estés preguntando: “¿Cómo empiezo realmente con esto en mis proyectos?”

3.3.1. Enfoque Secuencial para la Adopción#

La arquitectura de referencia no es una prescripción. Es un marco para pensar y organizar tus soluciones de automatización. Aquí hay un enfoque práctico y secuencial para aplicarla:

flowchart LR
    A[Entender el Estado Actual]:::phase1 --> B[Planificar el Camino de Automatización]:::phase2
    B --> C[Tomar Mejores Decisiones de Herramientas y Diseño]:::phase3
    C --> D[Diseñar para la Integración]:::phase4
    D --> E[Comunicar con las Partes Interesadas]:::phase5
    E --> F[Evolucionar Incrementalmente]:::phase6

    classDef phase1 fill:#e0f7fa,stroke:#333,stroke-width:2px;
    classDef phase2 fill:#b2ebf2,stroke:#333,stroke-width:2px;
    classDef phase3 fill:#80deea,stroke:#333,stroke-width:2px;
    classDef phase4 fill:#4dd0e1,stroke:#333,stroke-width:2px;
    classDef phase5 fill:#26c6da,stroke:#333,stroke-width:2px;
    classDef phase6 fill:#00bcd4,stroke:#333,stroke-width:2px;

Fase 1: Entender Tu Estado Actual

Comienza mapeando tus herramientas y procesos existentes a los bloques arquitectónicos. Este ejercicio de evaluación te ayuda a identificar brechas, solapamientos y áreas potenciales de mejora:

• ¿Están tus datos dispersos en múltiples sistemas?
• ¿Estás recopilando el estado de la red efectivamente, o estás volando a ciegas?
• ¿Cómo ejecutas actualmente los cambios? ¿Manualmente? ¿Scripts ad-hoc? ¿Marcos organizados?

Si descubres excelentes capacidades de ejecución pero poca observabilidad, has identificado un problema de alto impacto a resolver a continuación.

Fase 2: Planificar Tu Camino de Automatización

Usa la arquitectura para guiar tu hoja de ruta de automatización. No necesitas implementar todos los bloques a la vez. Comienza con los componentes que abordan tus puntos de dolor más críticos:

• Si estás luchando con la deriva de configuración, enfócate en Intención/Fuente de Verdad y Ejecución.
• Si no puedes detectar problemas rápidamente, prioriza el Recopilador y la Observabilidad.
• Si tu automatización es fragmentada y poco fiable, invierte en Orquestación.
• Si los usuarios están confundidos sobre cómo solicitar cambios, mejora la Presentación.

Prioriza por impacto en el negocio, no por completitud arquitectónica.

Fase 3: Tomar Mejores Decisiones de Herramientas y Diseño

Al evaluar nuevas herramientas o construir soluciones personalizadas, pregúntate:

• ¿A qué bloque arquitectónico sirve esto?
• ¿Se integra bien con mis otros componentes?
• ¿Qué flujos de datos necesito entre bloques?

Esto previene la proliferación de herramientas y garantiza que tu ecosistema de automatización siga siendo cohesivo. También aclara si debes construir o comprar. Si una herramienta encaja limpiamente en un bloque y tiene interfaces bien definidas, generalmente es mejor comprar que construir.

Fase 4: Diseñar para la Integración

Entender los límites entre componentes te ayuda a diseñar mejores interfaces. Principio clave: los componentes no deberían necesitar conocer los internos de cada uno.

• Tu Ejecutor no necesita saber cómo Intención almacena datos: solo necesita una API bien definida para consultar el estado deseado.
• Tu Orquestador no debería importarle si estás usando Ansible o Terraform: solo activa la ejecución y monitorea los resultados.
• Tu sistema de Observabilidad no debería necesitar conocer los internos del Recopilador: solo necesita métricas y eventos claros.

Este desacoplamiento es lo que te permite evolucionar cada componente de forma independiente.

Fase 5: Comunicar con las Partes Interesadas

La arquitectura proporciona un lenguaje común para discutir la automatización con diferentes audiencias:

• A la dirección: “Estamos fortaleciendo nuestra postura de Observabilidad para disminuir el MTTR.”
• A tu equipo: “Estandaricemos cómo nuestro Recopilador envía datos a Observabilidad.”
• A otros departamentos: “Nuestra capa de Presentación se integrará con vuestra instancia ITSM.”

El lenguaje arquitectónico claro reduce la confusión y ayuda a asegurar el apoyo.

Fase 6: Evolucionar Incrementalmente

La arquitectura te permite intercambiar componentes a medida que tus necesidades cambian:

• Hoy podrías usar Git como tu Fuente de Verdad, pero mañana podrías adoptar NetBox o Infrahub sin rediseñar completamente tus flujos de trabajo de automatización, siempre que mantengas interfaces claras.
• Podrías comenzar con un script simple como tu Orquestador, reemplazándolo después por AAP o Windmill.
• Puedes migrar de un TSDB a otro en Observabilidad sin interrumpir cómo el Recopilador recupera sus datos.

Este enfoque evolutivo minimiza el riesgo y te permite aprender sobre la marcha.

No caigas en la trampa de la sobre-ingeniería. El objetivo no es la pureza arquitectónica, sino la automatización práctica que resuelve problemas reales. A veces la mejor solución es un script simple que abarca múltiples bloques arquitectónicos. La arquitectura es una guía, no una camisa de fuerza.

La conclusión clave: usa la arquitectura como un modelo mental para organizar tu pensamiento, identificar brechas y tomar decisiones de diseño deliberadas. No como una plantilla rígida que dicta cada detalle de implementación.

3.3.2. Errores Comunes a Evitar#

Seamos realistas: vas a cometer errores. Pero aprender de otros puede ahorrarte mucho dolor. Aquí hay errores comunes:

1. Intentar Implementar Todo a la Vez

   Es tentador pensar: “Si esta arquitectura es buena, debería construir los siete bloques perfectamente.” Eso lleva a proyectos masivos de varios años que quedan obsoletos antes de terminarse.

   Mejor enfoque: Comienza con uno o dos bloques que resuelvan tu problema más urgente. Construye incrementalmente. El éxito temprano genera impulso y apoyo.

2. Creer en “Una Herramienta para Gobernarlos a Todos”

   Algunos proveedores afirman que su plataforma lo hace todo. Aunque eso pueda ser cierto, a menudo significa:

   • Estás atado a su forma de hacer las cosas.
   • No puedes intercambiar componentes más tarde.
   • Estás pagando por características que no necesitas.

   Mejor enfoque: Elige las mejores herramientas para cada bloque, pero asegúrate de que tengan APIs claras y puntos de integración. Acepta que puede que necesites integrar 3-5 herramientas, pero tendrás flexibilidad.

3. Ignorar las Restricciones de Red

   Diseñas un hermoso Ejecutor usando gNMI, pero el 30% de tus dispositivos solo soportan SSH CLI. O quieres telemetría de streaming, pero tus plataformas más antiguas solo soportan SNMP.

   Mejor enfoque: Entiende primero las capacidades de tu infraestructura de red. Estas restricciones dan forma a tu arquitectura. No puedes ignorar la física, y no puedes ignorar lo que tus dispositivos pueden hacer realmente.

4. Asumir que las Interfaces Serán Simples

   Dices: “El Ejecutor simplemente llamará a la API de Intención para el estado deseado.” Pero Intención usa NetBox con extensiones personalizadas, y el Ejecutor espera YAML plano. De repente estás escribiendo capas de traducción.

   Mejor enfoque: Invierte por adelantado en interfaces claras y bien documentadas. Usa estándares donde sea posible (APIs REST, gRPC, definiciones de esquema claras). Las buenas interfaces cuestan menos ahora que las capas de traducción más tarde.

5. Construir Herramientas Personalizadas Cuando Existen Buenas

   Tu equipo decide construir un Recopilador personalizado porque “ninguna herramienta satisface exactamente nuestras necesidades”. Seis meses después, tienes 3.000 líneas de código manteniendo pipelines de telemetría propietarios.

   Mejor enfoque: Evalúa primero las herramientas existentes (Telegraf, Vector, gNMIc). Manejan el 80% de los casos de uso y están probadas en batalla. Personalízalas o construye adaptadores si es necesario, pero no construyas desde cero.

6. Tratar la Observabilidad como una Idea de Último Momento

   Muchos equipos se enfocan en Intención y Ejecutor, luego se dan cuenta demasiado tarde de que no pueden ver lo que está sucediendo realmente en la red. La Observabilidad se añade al final.

   Mejor enfoque: Planifica la Observabilidad desde el primer día. ¿Qué métricas recopilarás? ¿Cómo detectarás la deriva? ¿Qué alertas importan? Responde a estas preguntas antes de construir el Ejecutor.

7. Olvidar a los Usuarios

   Los ingenieros construyen un potente Orquestador, pero la única forma en que los usuarios pueden interactuar con él es a través de comandos CLI. Los usuarios no técnicos se confunden; la adopción es deficiente.

   Mejor enfoque: Piensa en tus usuarios desde el principio. ¿Qué interfaces necesitan? ¿APIs? ¿UI web? ¿Integración con ServiceNow? A veces la capa de Presentación determina si la adopción se produce o no.

Estos errores no son teóricos, son patrones de proyectos de automatización reales. Aprender de ellos ahora hará tu arquitectura más sólida.

3.3.3. Por Dónde Empezar#

La arquitectura define siete bloques. Nadie implementa los siete a la vez. En la práctica, dos patrones de inicio representan la mayoría de los despliegues reales.

Patrón A: Inicio impulsado por configuración (más común)

Equipos que ya gestionan configuraciones manualmente y quieren hacer ese proceso consistente y automatizado. Comienza con Intención y Ejecutor: pon en marcha una Fuente de Verdad y construye los playbooks para desplegar desde ella. Añade Observabilidad una vez que la ejecución sea estable y necesites retroalimentación sobre lo que se desplegó realmente.

flowchart LR
    A[Intención / SoT] --> B[Ejecutor] --> C[Observabilidad] --> D[Orquestador] --> E[Presentación]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

Patrón B: Inicio impulsado por visibilidad

Equipos cuyo principal dolor es no conocer el estado actual de la red. Comienza con Recopilador y Observabilidad: construye primero el pipeline de datos, entiende qué está realmente desplegado, luego añade Intención y Ejecutor una vez que tengas una imagen fiable contra la que desplegar.

flowchart LR
    A[Recopilador] --> B[Observabilidad] --> C[Intención / SoT] --> D[Ejecutor] --> E[Orquestador]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

En ambos patrones, el Orquestador y la Presentación vienen después de que los flujos de datos principales sean estables. Comenzar con el Orquestador antes de tener Intención o Ejecución fiables es prematuro: todavía no hay nada significativo que coordinar. La Presentación se vuelve importante una vez que los equipos internos están usando la automatización y necesitan una interfaz adecuada en lugar de acceso directo a la API o CLI.

Estos son puntos de partida, no planos. Tus restricciones (herramientas existentes, habilidades del equipo, el dolor más urgente) deberían determinar el orden. La clave es elegir un punto de partida deliberadamente en lugar de intentar construir todo en paralelo y no terminar nada.

3.3.4. Propiedad de Bloques Entre Equipos#

Siete bloques crean una pregunta organizacional tanto como arquitectónica: ¿quién es propietario de qué, y cómo múltiples equipos comparten la misma plataforma sin pisarse los pies?

El modelo más común en organizaciones medianas y grandes se divide en dos grupos. Un equipo de plataforma es propietario de la infraestructura de automatización en sí: el esquema y las APIs del SoT, el runtime del Orquestador, el pipeline de Observabilidad, la capa de Presentación y la infraestructura compartida del Recopilador. Estos son los componentes de los que depende el resto de la organización. El trabajo del equipo de plataforma es mantenerlos fiables, versionados y disponibles. Un equipo de operaciones de red (o múltiples equipos de dominio, uno por área de tecnología) es propietario del contenido de automatización: los playbooks, definiciones de flujo de trabajo, datos previstos y lógica de negocio que se ejecutan sobre la plataforma. Consumen la plataforma; no la mantienen.

Esta división tiene implicaciones para cómo los límites de bloque se traducen en límites de equipo. El SoT es un recurso compartido de plataforma, pero diferentes equipos tienen diferentes permisos de escritura: el equipo de direccionamiento IP puede ser propietario de los datos IPAM; el equipo de campus puede ser propietario del inventario de switches; el equipo de seguridad puede ser propietario de los datos de política de firewall. El modelo Term "rbac" not found del SoT debe mapear a estos límites de propiedad. Una escritura en el dominio equivocado es un incidente operacional en espera de ocurrir.

El Orquestador es similar: el equipo de plataforma es propietario del runtime y el marco de ejecución de flujos de trabajo; el equipo de operaciones es propietario de las definiciones de flujo de trabajo. Las definiciones de flujo de trabajo deben vivir en control de versiones bajo la propiedad del equipo de operaciones, siendo recuperadas por el Orquestador en el momento del despliegue en lugar de editarse directamente en la UI del Orquestador. Esto evita que el equipo de plataforma y el equipo de operaciones interfieran con el trabajo del otro.

La Presentación divide aún más la cuestión de la propiedad. Una API interna utilizada por otras herramientas de automatización es una preocupación de plataforma. Un portal de autoservicio para equipos de aplicaciones es una preocupación de producto que puede pertenecer a un equipo de herramientas dedicado o a un grupo de servicios compartidos. Definir estos límites temprano previene la situación donde cada equipo construye su propia interfaz ad-hoc para la misma plataforma subyacente.

La dimensión organizacional de gestionar una plataforma de automatización, incluyendo cómo los equipos se estructuran alrededor de ella, cómo el pensamiento de producto se aplica a las herramientas internas, y cómo los equipos de plataforma gestionan el contrato con sus consumidores internos, se cubre en profundidad en el Capítulo 10 (Ingeniería de Plataforma) y el Capítulo 13 (Cultura y Colaboración). Las elecciones arquitectónicas hechas aquí, especialmente el alcance RBAC del SoT y la propiedad del flujo de trabajo del Orquestador, restringen directamente los modelos organizacionales que esos capítulos describen.

3.4. Resumen#

El pensamiento arquitectónico es esencial para construir automatización de redes que realmente funcione. Así como el modelo OSI nos da un marco por capas para entender las redes, una arquitectura de referencia te ayuda a organizar y diseñar sistemas de automatización que sean mantenibles, escalables y fiables.

Este capítulo introdujo el Marco NAF, que define siete bloques de construcción clave. La arquitectura no es una prescripción rígida, es un marco flexible. Úsalo para evaluar tu estado actual, planificar tu camino de automatización, tomar decisiones informadas sobre herramientas, comunicarte con las partes interesadas, diseñar para la integración y evolucionar incrementalmente. Recuerda: el objetivo es la automatización práctica que resuelve problemas reales, no la pureza arquitectónica.

En la Parte 2 de este libro, profundizaremos en cada uno de estos bloques de construcción, explorando patrones de implementación, mejores prácticas y ejemplos del mundo real que puedes aplicar a tus propios proyectos de automatización.

💬 Found something to improve? Send feedback for this chapter