7. Orquestación#

El equipo de red había hecho todo bien. Tenían una Fuente de Verdad sólida, playbooks bien probados para cada operación y un runbook claro para ejecutarlos. Sobre el papel, desplegar un nuevo servicio de VLAN estaba completamente automatizado. En la práctica, llevaba medio día y requería a una ingeniera en concreto.

Esa ingeniera conocía la secuencia. Primero, validar que los datos del SoT estuvieran completos. Luego ejecutar el playbook de pre-verificación. Luego revisar la salida, buscar dispositivos fallidos y decidir si continuar. Luego lanzar el playbook de despliegue. Luego esperar. Luego ejecutar el playbook de validación. Luego actualizar manualmente el ticket de ServiceNow. Si algún dispositivo fallaba a mitad del proceso, revertirlo antes de que los demás se vieran afectados. Lo tenía todo en un runbook, paso a paso, en un documento compartido que nadie más había interiorizado del todo.

Cuando se fue de vacaciones, los despliegues se detuvieron. Cuando un ingeniero júnior intentó seguir la secuencia y se equivocó en el orden, la red quedó en un estado parcial durante seis horas. La automatización existía. La coordinación seguía siendo manual.

Ese es el problema que resuelve este capítulo. La orquestación es el bloque de construcción que convierte una colección de herramientas de automatización en un sistema que se comporta como uno solo. Coordina los demás bloques, decide cuándo ejecutarlos, gestiona los fallos con elegancia, registra cada decisión y hace todo esto sin que un ingeniero esté en medio gestionando el flujo a mano.

7.1. Fundamentos#

7.1.1. Contexto#

Cada bloque de construcción que hemos cubierto hasta ahora hace una cosa bien. La Fuente de Verdad almacena la intención. El Ejecutor la aplica. El Colector recupera el estado. La Observabilidad le da sentido a ese estado. Cada uno es un especialista, y los especialistas necesitan un conector: algo que decida cuándo debe actuar cada uno, qué hacer con el resultado y cómo recuperarse cuando algo sale mal.

Ese conector es el Orchestrator.

En el Capítulo 3 lo situamos en el centro del marco NAF como el bloque que coordina a todos los demás. El Capítulo 5 mostró cómo el Ejecutor aplica los cambios de configuración; el Capítulo 6 mostró cómo la Observabilidad valida los resultados. Este capítulo muestra cómo el Orquestador secuencia ambos y gestiona todo lo que puede salir mal entre ellos.

Sin orquestación, no estás ejecutando automatización. Estás ejecutando scripts que alguien tiene que invocar en el orden correcto, en el momento correcto y que tiene que interpretar de la manera correcta. Eso es automatización solo de nombre.

7.1.2. Objetivos#

El Orquestador necesita cumplir cinco objetivos:

1. Coordinar flujos de trabajo multi-bloque de extremo a extremo. Un despliegue no es una acción única; es una secuencia: validar la intención en el SoT, ejecutar pre-verificaciones, aplicar la configuración, validar el resultado y notificar a los interesados. El Orquestador mantiene unida la secuencia completa.

2. Reaccionar a eventos automáticamente, con o sin intervención humana. Una aprobación de ServiceNow, una alerta de Observabilidad, un análisis programado de cumplimiento: todos deben poder iniciar un flujo de trabajo sin que una persona lo arranque manualmente.

3. Ejecución resiliente y escalable. Un flujo de trabajo que toca 800 switches en paralelo debe completarse de forma fiable. Debe sobrevivir a un reinicio. Debe gestionar fallos parciales sin perder el trabajo realizado por los dispositivos que tuvieron éxito.

4. Proporcionar visibilidad inalterable. Los operadores necesitan ver qué está ejecutándose ahora mismo. Los auditores necesitan ver qué se ejecutó el mes pasado, quién lo desencadenó, qué versión del flujo de trabajo se ejecutó y qué produjo cada paso. Ambas necesidades deben satisfacerse desde el mismo sistema.

5. Gestionar las definiciones de flujos de trabajo como software en producción. Un flujo de trabajo que despliega en 800 switches no puede modificarse de forma descuidada. La lógica en sí necesita persistirse, versionarse, probarse y promoverse a producción con la misma disciplina que se aplica a cualquier código que se ejecute en producción.

7.1.3. Pilares#

Cinco pilares sostienen estos objetivos:

1. Motor de flujos de trabajo: definir, ejecutar y rastrear procesos de múltiples pasos
2. Capa de activación: manual, programada, dirigida por eventos, webhook
3. Ejecución resiliente: el flujo de trabajo sobrevive a reinicios; soporta reintentos, reversión y operaciones concurrentes en cientos de dispositivos sin cuellos de botella por dispositivo
4. Auditoría y observabilidad: cada paso registrado, cada decisión trazable
5. Gestión de pipelines: persistir, versionar y promover definiciones de flujos de trabajo de forma segura en producción

7.1.4. Alcance#

El Orquestador coordina. No actúa.

En el alcance:

• Coordinar otros bloques de construcción
• Definir la lógica del flujo de trabajo y las dependencias entre pasos
• Gestionar la activación desde múltiples fuentes
• Rastrear el estado de ejecución y producir registros de auditoría
• Gestionar decisiones de reversión cuando los pasos fallan

Fuera del alcance:

• Ejecutar cambios en los dispositivos (eso corresponde al Executor)
• Almacenar el estado operacional de la red (eso corresponde a Observability)
• Mantener la intención de la red (eso corresponde a la Fuente de Verdad)

Un error frecuente es construir un Orquestador que duplica las responsabilidades de ejecución o almacenamiento de sus bloques vecinos. La interfaz entre bloques debe mantenerse limpia.

Un Orquestador que también almacena credenciales, gestiona el inventario de dispositivos o ejecuta su propio motor de configuración se ha convertido en otra cosa. Si tu herramienta de orquestación empieza a absorber responsabilidades de otros bloques, tienes un problema de acoplamiento arquitectónico que será costoso desenredar más adelante.

7.2. Funcionalidades#

Los cinco objetivos y pilares se materializan a través de cinco funcionalidades principales. Cada una se corresponde directamente con un objetivo y su pilar de soporte:

1. Motor de flujos de trabajo: cómo se estructuran los flujos de trabajo y cómo se coordinan los pasos
2. Activación: cómo y cuándo arrancan los flujos de trabajo y qué experimenta quien los invoca
3. Resiliencia y escala: cómo los flujos de trabajo se completan de forma fiable bajo fallos y con gran volumen
4. Estado y trazabilidad: rastrear el estado de ejecución y producir registros de auditoría inalterables
5. Gestión de pipelines: persistir y gestionar definiciones de flujos de trabajo de forma segura en producción

graph LR

    subgraph Goals["Objetivos"]
        direction TB
        A1[Coordinar flujos de trabajo multibloques de extremo a extremo]
        A2[Reaccionar a eventos automáticamente]
        A3[Ejecución resiliente y escalable]
        A4[Visibilidad a prueba de manipulación y auditoría]
        A5[Cambios seguros en pipelines de producción]
    end

    subgraph Pillars["Pilares"]
        direction TB
        B1[Motor de flujos de trabajo: definir, ejecutar, rastrear]
        B2[Capa de activación: manual, programada, dirigida por eventos]
        B3[Ejecución resiliente: durable, reintentos, rollback a escala]
        B4[Auditoría y observabilidad: cada paso registrado]
        B5[Gestión de pipeline: persistir, versionar, promover con seguridad]
    end

    subgraph Functionalities["Funcionalidades"]
        direction TB
        C1[Motor de Flujos de Trabajo]
        C2[Activación]
        C3[Resiliencia y Escala]
        C4[Estado y Trazabilidad]
        C5[Gestión de Pipeline]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;

7.2.1. Motor de flujos de trabajo#

El motor de flujos de trabajo es el núcleo del Orquestador. Define procesos de múltiples pasos, los ejecuta, rastrea su estado y gestiona las relaciones entre los pasos.

Antes de entrar en los patrones, conviene nombrar los cuatro enfoques fundamentales de coordinación, porque esta elección condiciona todo lo demás.

7.2.1.1. Enfoques de coordinación#

• Monolito (programa imperativo): Un único script de Python llama a cada paso en secuencia, espera el resultado de cada uno y decide qué hacer a continuación. Sencillo de escribir, y muchos equipos empiezan aquí. El problema es la durabilidad: si el script falla en el paso 5 de 10, se reinicia desde el principio. No hay estado persistente entre ejecuciones. Tampoco se pueden paralelizar pasos sin escribir lógica de hilos. Funciona para operaciones pequeñas y rápidas; falla bajo carga e infraestructura poco fiable. En la práctica, esto es lo que el bloque Ejecutor ya proporciona: un script invocado por un operador. Llamarlo orquestación es generoso.

• Workflow (basado en DAG): Aquí es donde empieza genuinamente la orquestación. Los pasos se definen como un grafo acíclico dirigido, donde cada nodo es una tarea y las aristas expresan dependencias. El motor rastrea el estado por nodo: si reinicias tras un fallo, solo se vuelven a ejecutar los pasos fallidos o incompletos. El paralelismo está integrado: las ramas independientes se ejecutan de forma concurrente. Este es el enfoque dominante para la orquestación en producción y el más contrastado para la automatización de redes. Las herramientas de esta categoría incluyen Prefect, Temporal y las plantillas de workflow de AWX.

• Coreografía (dirigida por eventos, sin coordinador central): No hay Orquestador. Cada componente reacciona a los eventos publicados por otros: el Ejecutor publica “despliegue completado”, el sistema de Observabilidad lo consume y ejecuta la validación, el sistema de notificación consume el resultado de la validación. El acoplamiento entre componentes es laxo, lo que facilita añadir nuevos consumidores. El inconveniente: no hay un único lugar para entender el estado completo del flujo de trabajo. Depurar fallos entre servicios requiere correlacionar eventos de múltiples sistemas. Este enfoque funciona para patrones reactivos simples, pero escala mal en complejidad.

• Agéntico (bucle sensación-lógica-acción): Un Large Language Model (LLM) o sistema de IA actúa como capa lógica. El agente observa el estado actual (desde Observabilidad o el SoT), razona sobre qué acción es necesaria e invoca al Ejecutor. En lugar de seguir un grafo de flujo de trabajo predefinido, toma decisiones dinámicamente en tiempo de ejecución. Este es el enfoque que intercambia determinismo por flexibilidad y forma la base arquitectónica de las redes autónomas. La sección 7.2.7 lo cubre en profundidad; el Capítulo 17 lo extiende hacia la autonomía completa.

La mayoría de los equipos comienzan con el enfoque Monolito y evolucionan al Workflow (basado en DAG) a medida que maduran en automatización. La Coreografía rara vez es la elección correcta para las operaciones de red porque los requisitos de auditoría y trazabilidad hacen valioso tener un coordinador central. Los enfoques agénticos son reales pero aún no son el estándar para las operaciones de red en producción.

7.2.1.2. Patrones de flujos de trabajo#

Dentro del enfoque basado en DAG, cuatro patrones cubren la mayoría de los flujos de trabajo de automatización de redes del mundo real:

• Secuencial: Los pasos se ejecutan uno tras otro; cada uno depende de que el anterior se complete con éxito. Apropiado cuando se requiere un orden estricto: validar la intención, luego hacer la pre-verificación, luego ejecutar, luego verificar.

• Paralelo (expansión/contracción): Múltiples pasos independientes se ejecutan de forma concurrente. Un paso de expansión lanza muchas tareas en paralelo (una por dispositivo o una por edificio); un paso de contracción espera a que todas se completen antes de continuar. Esencial para operaciones en cientos de dispositivos: sin expansión, una operación de 10 segundos por dispositivo en 800 dispositivos tarda más de dos horas en modo secuencial.

• Bifurcación condicional: El camino tomado depende del estado en tiempo de ejecución. ¿Pasó la pre-verificación? Bifurcar hacia la ejecución. ¿Falló? Bifurcar hacia el aborto y la notificación. La definición del flujo de trabajo incluye nodos de decisión que evalúan resultados y eligen el siguiente paso.

• Patrón Saga: Para flujos de trabajo de larga duración, el Patrón Saga añade transacciones compensatorias a cada paso. Si el paso N falla, el flujo de trabajo ejecuta acciones compensatorias para los pasos N-1 hasta 1 en orden inverso, devolviendo el sistema a un estado conocido. Así es como funciona la reversión a nivel de orquestación: no volviendo a ejecutar todo el flujo de trabajo, sino ejecutando la inversa de cada paso que tuvo éxito.

flowchart TD
    subgraph Sequential["Secuencial"]
        S1[Paso A] --> S2[Paso B] --> S3[Paso C]
    end

    subgraph FanOut["Fan-out y Fan-in"]
        F0[Inicio] --> F1[Dispositivo 1]
        F0 --> F2[Dispositivo 2]
        F0 --> F3[Dispositivo N]
        F1 --> FJ[Fan-in]
        F2 --> FJ
        F3 --> FJ
    end

    subgraph Saga["Saga - rollback en caso de fallo"]
        P1[Paso 1] --> P2[Paso 2] --> P3[Paso 3]
        P3 -- fallo --> R3[Rollback 3]
        R3 --> R2[Rollback 2]
        R2 --> R1[Rollback 1]
    end

El Patrón Saga es también la base estructural para los despliegues progresivos: aplicar cambios de red en oleadas en lugar de todos a la vez. La oleada 1 cubre una pequeña población de prueba; si tiene éxito, el flujo de trabajo se expande a la oleada 2, luego a la oleada N. Si alguna oleada falla, la compensación revierte solo esa oleada. Es el equivalente de red de un despliegue canary: la misma disciplina de promoción controlada que los equipos de software aplican a los lanzamientos de código, aplicada a los cambios de red.

7.2.1.3. Gestión de dependencias#

Los pasos de un flujo de trabajo raramente existen de forma aislada. El motor necesita expresar y hacer cumplir tres tipos de dependencias:

• Dependencias de datos: La tarea B no puede empezar hasta que la tarea A se complete y produzca un resultado que B consume. El motor pasa las salidas entre pasos como datos estructurados. En la práctica, esto significa que el paso de pre-verificación pasa la lista de dispositivos alcanzables al paso de ejecución, en lugar de volver a consultarla desde cero.

• Dependencias de múltiples entradas (contracción): Un paso espera a que múltiples ramas paralelas finalicen antes de continuar. El motor mantiene el estado de cada rama y activa el paso de unión solo cuando se cumple la política de finalización configurada: todas completadas, o N de M, o el primero en tener éxito.

• Dependencias externas: A veces un paso no puede continuar hasta que ocurra algo fuera del sistema. Se abre una ventana de cambios. Un humano aprueba. Un dispositivo se vuelve alcanzable tras un reinicio. El motor debe soportar estados de espera con timeouts configurables y rutas de escalado definidas para cuando la espera nunca se resuelve.

7.2.2. Activación#

Un flujo de trabajo tiene que comenzar de alguna manera. La activación responde a dos preguntas: qué hace que un flujo de trabajo comience y qué experimenta quien lo invoca después.

Cómo difiere la activación del Capítulo 5: En el Capítulo 5, la activación se refería a cómo un operador o sistema invoca directamente el motor de ejecución: una llamada a la API de AWX, un lanzamiento de plantilla desde una Command Line Interface (CLI). Eso es la activación a nivel de ejecución. Aquí, la activación describe qué hace que el Orquestador inicie un flujo de trabajo, que a su vez puede invocar al Ejecutor como uno de varios pasos. El Orquestador recibe la activación y decide qué flujo de trabajo completo ejecutar. El Ejecutor simplemente ejecuta lo que el Orquestador le indica.

7.2.2.1. Modos de activación#

Cuatro modos cubren todo el espectro, desde humano hasta completamente automatizado:

• Llamada a la API: El orquestador expone un endpoint HTTP. Un operador lo llama manualmente, un botón de interfaz lo llama, o un sistema externo (ServiceNow, Nautobot, un pipeline de CI/CD) lo llama cuando ocurre un evento. Estos son el mismo mecanismo: lo que difiere es quién inicia la llamada y si lleva datos de evento estructurados. Apropiado para cualquier cambio que necesite comenzar ahora, ya sea que quien lo inicie sea un humano o un sistema.

• Programado: Un calendario tipo cron inicia un flujo de trabajo a una hora configurada. Análisis de cumplimiento nocturnos, auditorías semanales de firmware, informes de capacidad mensuales. La mayoría de los orquestadores lo soportan de forma nativa; algunos equipos usan un programador externo y llaman a la API del orquestador.

• Cola de mensajes: El Orquestador consume mensajes de una cola (Kafka, NATS, RabbitMQ) e inicia un flujo de trabajo por mensaje. Esto desacopla al productor de eventos del orquestador: el productor publica y continúa; el orquestador procesa a su propio ritmo. Apropiado para flujos de eventos de alto volumen donde las garantías de entrega-como-máximo-una-vez de las llamadas directas a la API son insuficientes.

La elección entre push (llamada a la API) y pull (cola de mensajes, programado) depende del volumen y la tolerancia al acoplamiento. Las llamadas a la API son más simples pero requieren que el remitente conozca el endpoint del orquestador. Las colas de mensajes escalan mejor para flujos de alto volumen pero añaden infraestructura que operar.

7.2.2.2. Contrato de respuesta#

Una vez que un flujo de trabajo comienza, quien lo invocó necesita saber qué esperar:

• Síncrono: Quien invoca espera hasta que el flujo de trabajo se completa y recibe el resultado directamente. Apropiado para operaciones cortas (menos de 30 segundos) donde quien invoca necesita el resultado para continuar. La mayoría de los casos de uso interactivos empiezan aquí y descubren que lo han superado cuando intentan ejecutar un despliegue de 10 minutos y el cliente de la API agota el tiempo de espera.

• Asíncrono: Quien invoca recibe inmediatamente un ID de ejecución del flujo de trabajo y consulta el estado, o registra una URL de callback para recibir el resultado cuando se complete. Requerido para cualquier flujo de trabajo que toque más que un puñado de dispositivos. Esto tiene una implicación directa en cómo el sistema muestra el estado: la capa de Presentación (Capítulo 8) debe exponer endpoints de estado y notificaciones push, porque los usuarios activaron flujos de trabajo desde algún lugar y necesitan una forma de rastrearlos sin mantener una conexión HTTP abierta.

• Híbrido: El flujo de trabajo comienza de forma asíncrona, pero quien invoca puede opcionalmente bloquearse en un endpoint de espera síncrona si es necesario. Un patrón de conveniencia que evita forzar a quien invoca a elegir de antemano.

Idempotencia en flujos de trabajo dirigidos por eventos: Cuando la Observabilidad lanza una alerta o se activa un evento de cambio en el SoT, múltiples sistemas pueden reaccionar simultáneamente. La misma alerta puede activarse dos veces; una cola de mensajes puede entregar el mismo mensaje más de una vez. Cada flujo de trabajo dirigido por eventos debe ser idempotente: ejecutarlo dos veces contra la misma entrada debe producir el mismo resultado que ejecutarlo una vez. A nivel de orquestación, esto generalmente requiere una clave de deduplicación: un identificador único que el orquestador verifica antes de iniciar una nueva ejecución. Si ya existe una ejecución con esa clave y sigue en marcha, rechazar o encolar el duplicado. Suena sencillo y es sorprendentemente fácil hacerlo mal en la práctica.

El Patrón de Bucle Cerrado: La Observabilidad detecta una condición de deriva (la configuración de un dispositivo ha divergido de la intención). Lanza una alerta al Orquestador a través de los mecanismos de activación anteriores. El Orquestador inicia un flujo de trabajo de remediación: consulta el SoT para conocer el estado esperado, invoca al Ejecutor para corregir el dispositivo y luego vuelve a ejecutar una verificación de Observabilidad para confirmar la corrección. Si la verificación pasa, el bucle se cierra. Si falla, el Orquestador escala. Este patrón es la base de la automatización autocurativa y se cubre en profundidad en el Capítulo 15. El bucle solo funciona si el Orquestador, la Observabilidad y el Ejecutor están suficientemente desacoplados para que cada uno pueda jugar su papel de forma independiente.

7.2.3. Resiliencia y Escala#

Esto es lo que separa un orquestador con el que se prototipa de uno en el que se confía a las 3 de la mañana en producción. Un flujo de trabajo que funciona de forma fiable en condiciones ideales no dice nada sobre si sobrevivirá a un reinicio del coordinador a mitad de ejecución, gestionará 40 de 800 dispositivos que fallan las pre-verificaciones, o degradará con elegancia cuando una dependencia nunca se resuelve. La próxima vez que tu orquestador sea puesto a prueba, no será en una demo.

La resiliencia a nivel de ejecución, cubierta en el Capítulo 5, aborda la idempotencia y los reintentos a nivel de dispositivo individual: si un playbook falla contra un dispositivo, volver a intentarlo. Lo que el Capítulo 5 no aborda es la durabilidad a nivel de flujo de trabajo: qué sucede cuando el propio Orquestador se reinicia a mitad de ejecución, cuando 40 de 800 dispositivos fallan las pre-verificaciones o cuando una dependencia nunca se resuelve y el flujo de trabajo se bloquea. Escalar el propio orquestador, incluyendo alta disponibilidad, trabajadores horizontales y carga de base de datos bajo ejecuciones concurrentes, es una preocupación de infraestructura abordada en el Capítulo 11.

7.2.3.1. Estado duradero#

Un motor de flujos de trabajo que almacena el estado de ejecución en memoria pierde todo al reiniciarse. Esto es aceptable para scripts e inaceptable para la orquestación en producción. Estado duradero significa que el progreso del flujo de trabajo sobrevive al fallo del orquestador: qué pasos se completaron, qué produjeron, cuáles están pendientes. Cuando el orquestador vuelve a estar en línea, reanuda desde donde lo dejó.

Temporal está construido completamente en torno a esta garantía: reproduce la función del flujo de trabajo desde su historial de eventos al reiniciarse, haciendo que el estado en vuelo sea resistente a fallos. AWX almacena el estado de los trabajos en su base de datos. Los scripts no almacenan nada.

7.2.3.2. Estrategias de reintento#

No todos los fallos son iguales. Un dispositivo que estuvo brevemente inalcanzable durante un reinicio de firmware debería reintentarse. Un dispositivo que devolvió un error permanente de autorización no debería: reintentar no ayudará y puede activar políticas de bloqueo.

La configuración de reintentos debería distinguir:

• Fallos transitorios: interrupciones de red, tiempos de espera de API, contención temporal de recursos. Reintentar con retroceso exponencial.
• Fallos permanentes: credenciales incorrectas, dispositivo en modo de mantenimiento, configuración que no se aplica a este tipo de dispositivo. Abortar y escalar.

La definición del flujo de trabajo debería especificar la política de reintento por paso. Un paso de pre-verificación y un paso de despliegue de configuración tienen semánticas de fallo diferentes y no deberían compartir la misma configuración de reintento.

7.2.3.3. Reversión y compensación#

Cuando un flujo de trabajo de despliegue falla a mitad del proceso, tienes tres opciones: dejar el estado parcial, corregirlo manualmente o revertirlo automáticamente. En la mayoría de las operaciones de red, el estado parcial es peligroso: los dispositivos que recibieron la nueva configuración se comportarán de forma diferente a los que no la recibieron.

El Patrón Saga aborda esto definiendo una transacción compensatoria para cada paso. Si el flujo de trabajo tiene éxito hasta el paso N y luego falla, ejecuta acciones compensatorias para los pasos N-1 hasta 1 en orden inverso. En un despliegue de VLAN: si el despliegue de configuración tiene éxito en 30 dispositivos y falla en el 31, la saga revierte los 30 despliegues exitosos antes de informar del fallo.

El Patrón Saga requiere que las transacciones compensatorias se definan de antemano, en el momento del diseño del flujo de trabajo. Esto es trabajo adicional por adelantado. La alternativa es descubrir a las 2 de la mañana que tu red está en un estado que ningún runbook describe.

7.2.3.4. Control de concurrencia#

La expansión hacia 800 dispositivos simultáneamente sobrecargará la mayoría de las capas de ejecución. El control de concurrencia a nivel de orquestación significa:

• Procesamiento por lotes: ejecutar N dispositivos en paralelo, esperar a que el lote se complete, luego ejecutar el siguiente N. Esto controla el radio de explosión: si una configuración incorrecta revela un problema, no has tocado los 800 dispositivos aún.
• Limitación de tasa: la capa de ejecución tiene límites; el orquestador debe respetarlos. No dejar que la cola de AWX se llene con 800 trabajos simultáneos.
• Umbrales de éxito parcial: definir qué significa el éxito a escala. 798 de 800 dispositivos configurados correctamente puede ser suficiente para continuar; 600 de 800 debería detener el flujo de trabajo y escalar.

7.2.3.5. Timeout y disyuntor#

Los flujos de trabajo que esperan indefinidamente son un problema de fiabilidad. Cada paso que puede bloquearse necesita un timeout configurado. Cuando el timeout expira, el flujo de trabajo necesita una acción definida: escalar, omitir o abortar.

El patrón Circuit Breaker extiende esto a los fallos repetidos: si un paso falla más de N veces en una ventana de tiempo, dejar de intentarlo y lanzar una alerta. Esto evita que un único dispositivo inalcanzable mantenga un flujo de trabajo abierto durante horas.

7.2.3.6. Resiliencia en los límites entre bloques#

Los cinco patrones anteriores abordan fallos dentro de la propia ejecución del Orquestador: estado duradero, reintentos, reversión, concurrencia, timeouts. Pero los flujos de trabajo también fallan en los límites entre bloques, y esos fallos requieren un manejo diferente.

Cuando el Orquestador llama a la API del SoT y recibe un timeout, la respuesta apropiada es diferente a cuando el Ejecutor devuelve un fallo de dispositivo. Un timeout del SoT significa que el Orquestador no puede verificar que la intención que está a punto de desplegar sea actual. Proceder con datos en caché arriesga aplicar una configuración obsoleta. La respuesta correcta suele ser abortar y reintentar en lugar de proceder con incertidumbre. Un evento de la capa de Presentación que nunca llega (el webhook de aprobación de ServiceNow) puede significar que la solicitud fue rechazada, que la integración está rota o que el mensaje se perdió. Estos requieren diferentes rutas de recuperación: una aprobación faltante no es un fallo transitorio que deba reintentarse indefinidamente.

Los fallos en los límites entre bloques deben clasificarse explícitamente en la definición del flujo de trabajo:

• Dependencia no disponible (SoT, Observabilidad): el flujo de trabajo no puede continuar de forma segura. Fallar de forma limpia, emitir un evento de diagnóstico y no reintentar con datos obsoletos.
• Dependencia degradada (lectura parcial del SoT, Observabilidad con retraso): el flujo de trabajo puede continuar con reconocimiento explícito de que opera con confianza reducida. Registrar el estado degradado; no continuar silenciosamente.
• Bloque descendente fallido (el Ejecutor devolvió un error, el Colector no devolvió datos): aplicar los patrones de reintento y reversión anteriores, pero clasificar con precisión la fuente del fallo para que la alerta y el registro de auditoría nombren el bloque correcto.

Un flujo de trabajo que trate todos los fallos como errores de dispositivo reintentables reintentará una integración rota del SoT hasta agotar su presupuesto de reintentos y alertará a un ingeniero de guardia con el diagnóstico equivocado. Clasificar los fallos en los límites entre bloques es la diferencia entre un flujo de trabajo que falla rápido y uno que falla de forma confusa.

7.2.4. Estado y Trazabilidad#

Cuando algo sale mal a las 3 de la mañana, dos preguntas necesitan respuesta inmediata: cuál es el estado actual del flujo de trabajo y quién lo desencadenó.

Cuando el equipo de auditoría hace preguntas tres meses después, el mismo registro debe responder: qué se ejecutó, qué versión de la definición del flujo de trabajo se ejecutó, qué recibió cada paso como entrada, qué produjo como salida y cuál fue el resultado final.

Son preguntas diferentes con urgencia diferente, pero provienen de la misma fuente: el estado de ejecución del flujo de trabajo y su registro de auditoría.

La trazabilidad es una preocupación transversal en toda la plataforma de automatización: la Fuente de Verdad registra cada cambio en la intención; la Observabilidad registra cada cambio en el estado de la red. Pero ninguno de esos registros dice quién inició un flujo de trabajo, qué pasos se ejecutaron en secuencia y qué causó el resultado. Solo el registro de auditoría del Orquestador cierra esa brecha. Porque el Orquestador coordina todos los demás bloques, su traza es la vista autorizada de todo lo que ocurrió en todo el sistema de automatización para un evento dado.

7.2.4.1. El estado no es el estado de la red#

Esta distinción es fácil de perder. En el Capítulo 6, “estado” significaba el estado operacional de la red: contadores de interfaces, sesiones BGP, CPU de los dispositivos. En el Capítulo 5, “estado” significaba la intención de configuración deseada almacenada en el SoT. Aquí, estado significa el estado de ejecución del propio flujo de trabajo: qué pasos se han ejecutado, cuáles están en ejecución, cuáles fallaron y qué produjeron.

Los dos están relacionados (un paso del flujo de trabajo produce cambios en el estado de la red que la Observabilidad luego valida), pero se almacenan de forma diferente, se consultan de forma diferente y tienen propósitos diferentes. No hay que confundirlos.

7.2.4.2. La máquina de estados del flujo de trabajo#

Cada ejecución de un flujo de trabajo avanza a través de una máquina de estados definida:

• Pendiente: recibido pero aún no iniciado
• En ejecución: ejecutando pasos activamente
• Exitoso: todos los pasos requeridos se completaron con éxito
• Fallido: un paso falló y el flujo de trabajo no pudo continuar
• Cancelado: detenido por un humano o una señal externa

Cada paso dentro del flujo de trabajo lleva su propio estado. Una ejecución de expansión parcialmente exitosa debe mostrar exactamente qué dispositivos tuvieron éxito, cuáles fallaron y cuáles se omitieron. “El flujo de trabajo falló” no es útil sin el desglose por dispositivo.

7.2.4.3. Requisitos del registro de auditoría#

Cada registro de ejecución de flujo de trabajo debe contener, como mínimo:

• Quién o qué activó la ejecución: identidad humana, nombre del sistema, ID del evento activador
• Cuándo comenzó y cuándo se completó
• Qué versión de la definición del flujo de trabajo se ejecutó
• La entrada completa que recibió el flujo de trabajo
• La salida de cada paso
• El resultado final

Este registro debe ser inalterable: no puede editarse después del hecho. En entornos regulados, el registro de auditoría del Orquestador es el registro de gestión de cambios. Si este registro puede alterarse, el sistema de gestión de cambios no es de confianza.

La mayoría de las herramientas de orquestación escriben registros de auditoría en una base de datos que también gestionan. Si eso es suficiente depende de tus requisitos de cumplimiento. Algunas organizaciones exportan los registros de auditoría de orquestación a un sistema externo de solo adición (un SIEM, un almacén de registros de solo escritura) para evitar manipulaciones por parte de cualquier persona con acceso a la base de datos, incluida cualquier persona que pueda ejecutar consultas contra la propia base de datos del orquestador.

7.2.5. Gestión de Pipelines#

Un flujo de trabajo que configura 800 switches de producción es, arquitectónicamente, software en producción. El desafío central no es solo el versionado: es cómo almacenar, validar y promover las definiciones de flujos de trabajo para que la lógica en sí sea tan fiable como la infraestructura que gestiona.

La definición del flujo de trabajo codifica decisiones: qué pre-verificaciones ejecutar, qué hacer cuando un dispositivo es inalcanzable, qué constituye el éxito. Cambiarla descuidadamente cambia lo que ocurre con cada dispositivo que ese flujo de trabajo toca la próxima vez que se ejecuta.

He visto equipos romper silenciosamente flujos de trabajo de producción editando la definición del flujo de trabajo directamente en la interfaz de la herramienta de orquestación. Nadie lo notó hasta que la siguiente ejecución tocó un tipo de dispositivo que el paso modificado no gestionaba correctamente. La edición en la interfaz no tenía revisión, ni prueba, ni ruta de reversión.

7.2.5.1. Estrategias#

• Definiciones respaldadas por Git: Almacenar las definiciones de flujos de trabajo en control de versiones. La herramienta de orquestación extrae de Git en el despliegue, no de ediciones locales en la interfaz. Esto proporciona un historial, un proceso de revisión y la capacidad de revertir a cualquier versión anterior.

• Versiones de pipeline azul/verde: Mantener dos versiones de un flujo de trabajo en producción: la versión estable actual que gestiona todos los flujos de trabajo activos y una nueva versión que recibe nuevas ejecuciones tras un período de validación. El tráfico cambia solo cuando la nueva versión demuestra ser estable.

• Despliegue canary: Una nueva versión del flujo de trabajo gestiona primero un número reducido de ejecuciones. Un flujo de trabajo de actualización de firmware podría aplicar la nueva versión a 10 dispositivos antes de promoverla a toda la flota. Los problemas salen a la luz con 10 dispositivos, no con 800.

7.2.5.2. Probar cambios en la orquestación#

Las definiciones de flujos de trabajo pueden probarse antes de producción:

• Modo de ejecución en seco: ejecutar el flujo de trabajo contra entradas reales pero omitir los pasos que modifican la red. Verificar que la lógica produce la secuencia esperada de acciones.
• Entorno de staging: un subconjunto de dispositivos dedicado a probar cambios en flujos de trabajo antes de que se ejecuten contra producción.
• Ejecución en sombra: ejecutar la nueva versión en paralelo con la versión actual, pero ignorar sus resultados. Comparar salidas para detectar divergencias antes de cambiar.

Dos reversiones diferentes: Revertir una ejecución de flujo de trabajo significa deshacer los cambios de red realizados por una ejecución específica (gestionado por el Patrón Saga en la sección 7.2.3). Revertir una definición de flujo de trabajo significa volver la lógica del flujo de trabajo a una versión anterior: cambiar la referencia de Git, redesplegar la definición y la siguiente ejecución usa la versión anterior. Son operaciones ortogonales. Confundirlas es cómo los equipos acaban revirtiendo lo incorrecto.

7.2.6. Panorama de Soluciones#

Nota: las herramientas listadas aquí son ejemplos con fines explicativos, no recomendaciones. Cada una tiene una arquitectura y un perfil de compromisos diferente. Evalúalas según las capacidades de tu equipo, las herramientas existentes y las restricciones operativas.

El mercado de herramientas de orquestación cubre una amplia gama de modelos, desde plataformas específicas para redes hasta motores de flujos de trabajo de propósito general. La pregunta rara vez es “cuál es la mejor” y casi siempre es “cuál encaja con cómo operamos”.

Una pregunta arquitectónica atraviesa todas estas opciones: ¿tu herramienta de orquestación también actúa como motor de ejecución, o están separados? AWX/AAP colapsa ambos en uno. Prefect, Temporal y Windmill son orquestadores que llaman a herramientas de ejecución separadas (Ansible, scripts personalizados, APIs). El modelo colapsado es más sencillo de operar; el modelo separado proporciona más flexibilidad para intercambiar motores de ejecución de forma independiente. El Capítulo 3 introdujo este compromiso bajo el principio de acoplamiento mínimo.

La fila de AWX/AAP en la tabla anterior merece una nota aclaratoria para los equipos que lo consideran como plataforma principal. Las plantillas de workflow de AWX son el Orquestador; las plantillas de trabajo individuales de Ansible son el Ejecutor. El límite arquitectónico entre los dos existe aunque se ejecuten dentro de la misma plataforma. Un equipo que pone toda la lógica en las plantillas de trabajo (el Ejecutor) y usa plantillas de workflow solo para encadenarlas ha construido efectivamente un Orquestador a partir de primitivos de ejecución, lo que limita la visibilidad, la configuración de reintentos y las opciones de reversión. Por el contrario, un equipo que pone lógica de negocio en las plantillas de workflow (bifurcación condicional basada en datos externos, selección dinámica de inventario) está usando AWX como un orquestador genuino. La distinción importa porque el registro de auditoría de AWX, las puertas de aprobación y los hooks de notificación son características a nivel de workflow. Si toda tu lógica vive en las plantillas de trabajo, no puedes usar esas características sin reestructurar. Esto no es una limitación de AWX; es una consecuencia de no distinguir Orquestación de Ejecución en el diseño.

Estas herramientas se solapan significativamente: Python se ejecuta tanto en Prefect como en Windmill; tanto Prefect como Temporal pueden llamar a Ansible. Un punto de partida aproximado: si tu equipo es principalmente de Ansible y quiere mínimos componentes nuevos, las plantillas de workflow de AWX son la opción natural; si quieres pipelines testables y con código en primer lugar con disciplina de ingeniería de software, Prefect y Windmill funcionan con diferentes modelos operativos; si la durabilidad bajo fallo parcial es la restricción principal, el modelo de reproducción de Temporal está construido específicamente para ello. Trata esto como un punto de partida para la evaluación, no como una respuesta definitiva.

7.2.7. El Orquestador Agéntico#

El enfoque de coordinación agéntica listado en 7.2.1 introduce un modelo de ejecución diferente: en lugar de seguir un DAG predefinido, un Large Language Model (LLM) recibe un objetivo y determina la secuencia de acciones en tiempo de ejecución. El agente observa el estado actual desde los bloques de Observabilidad y SoT, razona sobre qué acción cierra la brecha, invoca al Ejecutor y vuelve a observar para verificar el resultado. Si el resultado no es el esperado, razona de nuevo. La lógica de decisión no está codificada en una definición de flujo de trabajo; vive en el razonamiento del modelo.

Lo que habilita esto a través de toda la plataforma de automatización es el Model Context Protocol (MCP) (Model Context Protocol). Cada bloque de construcción expone un servidor MCP: un conjunto definido de herramientas que el agente puede llamar como parte de su bucle de razonamiento. El servidor del SoT expone consultas de dispositivos y búsquedas de intención; el servidor de Observabilidad expone consultas de estado y verificaciones de cumplimiento; el servidor del Ejecutor expone la activación de trabajos y el sondeo de estado. El agente llama a estas herramientas en cualquier secuencia que la situación requiera, sin que el autor del flujo de trabajo haya precodificado cada combinación posible.

La implicación arquitectónica es que los bloques no necesitan saber nada sobre los demás ni sobre el agente. La interfaz MCP es el contrato. El mismo SoT que responde llamadas REST de un flujo de trabajo basado en DAG hoy responderá llamadas de herramientas MCP de un agente de IA sin modificación. Los límites limpios entre bloques rinden sus frutos aquí de una manera que el acoplamiento estrecho nunca podría.

Los flujos de trabajo basados en DAG y la orquestación agéntica no son mutuamente excluyentes. En la práctica, los flujos de trabajo basados en DAG son la elección correcta para operaciones rutinarias y bien definidas: despliegues de VLAN, análisis de cumplimiento, actualizaciones de firmware. Estas tienen alta frecuencia, necesitan registros de auditoría predecibles y no deberían depender del razonamiento de un LLM. La capa agéntica gestiona lo novedoso: remediación impulsada por incidentes, investigación de anomalías, situaciones donde la secuencia correcta de acciones no puede determinarse hasta que se entiende el estado actual. Los dos enfoques pueden coexistir en la misma plataforma, con el DAG enrutando hacia un flujo de trabajo agéntico cuando una situación no coincide con ningún patrón conocido.

Esta sección introduce el patrón. El tratamiento arquitectónico completo, incluyendo cómo la orquestación agéntica escala hacia la operación autónoma continua en toda la red, está en el Capítulo 17.

7.3. Ejemplo de Implementación#

7.3.1. Orquestando el Ciclo de Vida del Servicio VLAN en el Campus#

Hemos seguido la misma red de campus a lo largo de la Parte 2. En el Capítulo 4, almacenamos la solicitud de servicio VLAN en Nautobot: el ID de VLAN, la subred, los switches de destino y las plantillas de configuración por proveedor. En el Capítulo 5, usamos Ansible a través de AWX para enviar esa configuración a los switches del campus. En el Capítulo 6, validamos el despliegue y comenzamos a monitorizar el servicio.

Lo que nunca abordamos es quién coordina todo eso. Cada capítulo tenía una suposición implícita: un ingeniero ejecutó cada paso manualmente. Aquí lo hacemos explícito y reemplazamos al ingeniero con un flujo de trabajo.

El escenario

El equipo de aplicaciones ha enviado una solicitud para un nuevo segmento de aplicación: VLAN app-payments, subred 10.22.14.0/24, desplegada en todos los switches de acceso en building-b en las instalaciones de Cisco y Arista. La solicitud fue enviada a través de ServiceNow y acaba de recibir la aprobación final.

Esa aprobación activa un webhook. El Orquestador lo recibe e inicia el flujo de trabajo de despliegue del servicio VLAN.

El flujo de trabajo

Implementamos esto como una plantilla de workflow de AWX, coherente con la capa de ejecución ya en uso. AWX soporta plantillas de workflow que encadenan plantillas de trabajo con bifurcación condicional y puertas de aprobación, lo cual es suficiente para este escenario.

flowchart TD
    A[Webhook ServiceNow\nSolicitud VLAN aprobada] --> B[Paso 1: Validar SoT\nConsultar Nautobot para registros de dispositivo\ny completitud de la definición de VLAN]
    B --> C{¿Datos del SoT completos?}
    C -- No --> Z1[Abortar: notificar al ingeniero\ny actualizar ticket ServiceNow]
    C -- Sí --> D[Paso 2: Fan-out pre-verificaciones\nAccesibilidad y estado VLAN\nen todos los switches objetivo]
    D --> E{¿Pre-verificaciones superadas?}
    E -- Fallos --> Z2[Abortar: reportar fallos\npor dispositivo a ServiceNow]
    E -- Superadas --> F[Paso 3: Puerta de aprobación\nValidación humana opcional\nantes de la ejecución en producción]
    F --> G[Paso 4: Ejecutar despliegue\nPlaybook Ansible via AWX]
    G --> H[Paso 5: Validación fan-out\nComprobación de Observabilidad por switch]
    H --> I{¿Todos los dispositivos validados?}
    I -- Éxito completo --> J[Paso 6: Notificar\nActualizar ticket ServiceNow\npublicar en Slack]
    I -- Fallo parcial --> K[Paso 6a: Compensación Saga\nRollback solo del ámbito fallido]
    K --> J

Paso 1: Validación del SoT

El Orquestador consulta Nautobot para confirmar que los registros de dispositivos y la definición de VLAN están completos antes de que nada toque la red. Este paso de guardia es responsabilidad del Orquestador, no del Ejecutor: el Ejecutor debería recibir entradas válidas, no descubrir datos incorrectos a mitad del despliegue. Si alguna verificación falla, el flujo de trabajo aborta y actualiza el ticket de ServiceNow con la brecha específica. (Cómo se estructura la validación del SoT se cubre en el Capítulo 4.)

Paso 2: Pre-verificaciones en los switches de destino (expansión)

El flujo de trabajo se expande en todos los switches de destino en paralelo. Cada rama ejecuta una pre-verificación ligera: alcanzabilidad, estado de la tabla de VLAN, capacidad disponible. El paso de contracción clasifica los resultados y bifurca; el umbral de fallo es configurable. Lo que importa desde el punto de vista de la orquestación es que este es un patrón de expansión/contracción con bifurcación condicional, no un sondeo secuencial. (Los patrones de ejecución de pre-verificaciones están en el Capítulo 5.)

Paso 3: Puerta de aprobación

Una aprobación humana opcional antes del despliegue en producción. Un ingeniero tiene 30 minutos para aprobar o rechazar; un timeout procede automáticamente y se registra. El Orquestador mantiene el flujo de trabajo en estado de espera con una dependencia externa hasta que llegue la aprobación o expire la ventana.

La puerta de aprobación es una decisión de política, no arquitectónica. Los equipos de alta madurez a menudo la eliminan y reemplazan la aprobación humana con umbrales de confianza automatizados derivados de los resultados de la pre-verificación: si la cobertura de la pre-verificación supera el 95% y no se encontraron fallos críticos, proceder automáticamente. Los equipos que aún están construyendo confianza mantienen la puerta. Ambas elecciones son válidas en diferentes puntos del espectro de madurez de automatización discutido en el Capítulo 1.

Paso 4: Ejecución del despliegue

El Orquestador activa la plantilla de trabajo de AWX del Capítulo 5, pasa los parámetros del paso de validación del SoT y espera el resultado. El Ejecutor gestiona el resto. Esta es la separación de responsabilidades en la práctica: el Orquestador decide actuar, el Ejecutor actúa.

Paso 5: Validación de Observabilidad (expansión)

Tras el despliegue, una segunda expansión ejecuta un trabajo de validación por switch de destino: ¿aparece la VLAN en la tabla de VLAN, están las interfaces en el estado esperado? La contracción clasifica los resultados: éxito completo, éxito parcial o fallo. (Qué valida la capa de Observabilidad y cómo se cubre en el Capítulo 6.)

Paso 6: Enrutamiento del resultado

El éxito completo cierra el flujo de trabajo: el ticket de ServiceNow se actualiza y se publica un resumen en Slack. El fallo parcial activa la compensación Saga: el playbook de reversión se ejecuta solo para los dispositivos que fallaron la validación; los dispositivos que tuvieron éxito conservan su configuración. El ticket de ServiceNow registra el resultado por dispositivo.

De vuelta a la ingeniera del inicio

Este flujo de trabajo muestra los siete bloques de construcción del marco NAF del Capítulo 3 trabajando juntos: Nautobot (Fuente de Verdad) proporcionó la intención, AWX (Ejecutor) la aplicó, Prometheus (Observabilidad) validó el resultado, la plantilla de workflow de AWX (Orquestador) coordinó la secuencia completa y un webhook de ServiceNow (Presentación, cubierto en el Capítulo 8) desencadenó todo el flujo desde la solicitud del equipo de aplicaciones.

La ingeniera del inicio sigue aquí. Es ella quien revisa la puerta de aprobación cuando se activa. Es ella quien investiga el fallo parcial que el Patrón Saga marcó pero no pudo resolver completamente. Sigue siendo la experta. Lo que el orquestador le quitó no es la experiencia, sino la carga de mantener la secuencia unida en su cabeza, volver a ejecutarla paso a paso y ser la única persona que podía. Eso es lo que realmente cuesta la coordinación sin automatización.

7.4. Resumen#

Este capítulo estableció que el Orchestrator es el bloque de construcción que transforma un conjunto de herramientas de automatización que funcionan en un sistema que se comporta como uno solo. Sin él, la coordinación sigue siendo manual, los fallos requieren intervención humana y la escala de la red se convierte en un límite a cuánta automatización es realmente posible.

En su núcleo, la orquestación descansa en un motor de flujos de trabajo que define cómo se estructuran y ejecutan los procesos de múltiples pasos. La elección entre monolito, DAG, coreografía y coordinación agéntica es una decisión arquitectónica, no una preferencia de herramientas. El modelo DAG con sus patrones nombrados (secuencial, expansión, condicional, Saga) es el estándar de producción para la automatización de redes. El patrón agéntico, introducido en la sección 7.2.7 con Model Context Protocol (MCP) como capa de interfaz, representa un compromiso diferente y recibe su tratamiento completo en el Capítulo 17.

La activación define cómo el mundo exterior alcanza al orquestador. La distinción entre la activación a nivel de ejecución (Capítulo 5) y la activación a nivel de orquestación importa arquitectónicamente: una impulsa un cambio en un único dispositivo, la otra impulsa un flujo de trabajo coordinado de múltiples sistemas. La automatización dirigida por eventos y el Patrón de Bucle Cerrado heredan las propiedades no negociables de idempotencia y deduplicación precisamente porque los activadores automáticos se disparan sin revisión humana.

La resiliencia y la escala separan la automatización que funciona en demos de la que funciona a las 3 de la mañana. El estado duradero, las estrategias de reintento que distinguen entre fallos transitorios y permanentes, el Patrón Saga para la compensación de fallos parciales y los controles de concurrencia para grandes poblaciones de dispositivos no son características opcionales para añadir más adelante. Definen si el orquestador puede ser de confianza cuando las condiciones no son ideales.

El estado y la trazabilidad proporcionan el registro de qué se ejecutó, quién lo desencadenó y qué produjo cada paso. Este registro es distinto del estado operacional de la red (Capítulo 6) y de la intención de la red (Capítulo 4). Los registros de auditoría inalterables son un requisito de cumplimiento, no algo añadido a posteriori. La gestión de pipelines cierra el bucle: las definiciones de flujos de trabajo son software de producción y deben versionarse, probarse y promoverse con la misma disciplina que cualquier otro código que se ejecute en la plataforma de automatización.

El escenario del servicio VLAN del campus reunió estas cinco funcionalidades: un flujo de trabajo de diez pasos activado por un webhook de ServiceNow, coordinando la validación del SoT, las pre-verificaciones, la ejecución, la validación de Observabilidad y la compensación Saga, sin ningún ingeniero en el bucle de coordinación. La siguiente pregunta natural es quién ve este flujo de trabajo ejecutándose y cómo el equipo de aplicaciones que lo desencadenó rastrea su progreso. Esa es la capa de Presentación, cubierta en el Capítulo 8.

💬 Found something to improve? Send feedback for this chapter