8. La Capa de Presentación#

La automatización de VLANs llevaba seis semanas en marcha. El equipo de red estaba orgulloso de ella. Cada mañana llegaban tres o cuatro nuevas solicitudes de servicio de los equipos de aplicaciones, y el Orquestador las gestionaba sin que nadie del equipo de red tocase un teclado. Los despliegues funcionaban. Los switches estaban configurados. La red estaba sana.

La escalada llegó un jueves. El responsable del equipo de aplicaciones preguntaba por qué las solicitudes de VLAN tardaban entre tres y cinco días laborables cuando el portal mostraba “enviada”. El equipo de red revisó su cola: cero solicitudes pendientes, todos los despliegues exitosos. La automatización había procesado cada solicitud en menos de veinte minutos desde su recepción. Pero los tickets de ServiceNow seguían mostrando “En progreso”, porque nadie había escrito la integración que los actualizaría.

La automatización había hecho su trabajo. El resultado era invisible.

Una semana después, el equipo desplegó un portal de autoservicio rápido para que los equipos de aplicaciones pudiesen enviar solicitudes directamente y ver su estado. Al mediodía habían recibido cuarenta y siete solicitudes de VLAN en una sola hora. Todas válidas. Todas con el formato correcto. El problema: el portal no tenía modelo de autorización. Aceptaba envíos de cualquier persona que tuviera la URL. Todas las solicitudes se ejecutaban bajo un único token de API con derechos de administrador globales. No había límite de tasa, ni puerta de aprobación, ni rastro de auditoría sobre quién enviaba qué.

La automatización funcionaba. El modelo de acceso, no.

Estos dos fallos son ambos fallos de Presentación. Uno es la ausencia de un bucle de retroalimentación; el otro es la ausencia de barreras de seguridad. Este capítulo cierra esa brecha.

8.1. Fundamentos#

8.1.1. Contexto#

Todos los bloques constructivos cubiertos hasta ahora miran hacia adentro: hacia otros bloques o hacia ingenieros que entienden la plataforma. La Source of Truth (SoT) contiene la intención de red para los sistemas de automatización. El Ejecutor aplica cambios a los dispositivos. Observability valida los resultados. El Orchestrator los coordina a todos. Cada uno de estos bloques tiene una UI, una API o ambas, diseñadas para las personas que construyeron y operan la plataforma, no para todos los que necesitan interactuar con ella.

La capa de Presentation (Layer) mira hacia afuera. Su trabajo es hacer la plataforma accesible a audiencias que no deberían necesitar entender los internos: el equipo de aplicaciones que solicita un servicio de red, el auditor de seguridad que pregunta qué cambió el trimestre pasado, el pipeline de CI/CD que aprovisiona infraestructura sin un humano en el bucle.

En el Capítulo 3 el bloque de Presentación se situaba en el borde del framework NAF, de cara a humanos y sistemas externos. El Capítulo 6 estableció el límite entre la visualización de observabilidad y la Presentación: los dashboards construidos directamente sobre telemetría de red pertenecen al bloque de Observabilidad por afinidad de diseño; cómo esos dashboards se presentan a personas no técnicas, se controlan por acceso o se integran en portales es una preocupación de Presentación. El Capítulo 7 estableció que los flujos de trabajo asíncronos requieren endpoints de estado y hooks de notificación. La capa de Presentación proporciona ambos.

8.1.2. Objetivos#

La capa de Presentación sirve tres objetivos que se corresponden directamente con tres funcionalidades arquitectónicas.

1. Proporcionar una API estable y autenticada con un modelo de acceso consistente. Cada consumidor, humano o máquina, debería interactuar con la plataforma a través de un contrato versionado y controlado por acceso que no cambie sin previo aviso. Los bloques subyacentes pueden reemplazarse, actualizarse o reestructurarse; el contrato de cara al consumidor debe permanecer estable. La autenticación y la autorización se aplican en este límite, centralizadas en lugar de duplicadas por herramienta.

2. Servir a cada tipo de consumidor a través de la interfaz que se ajusta a su flujo de trabajo. Un ingeniero de red y un manager del equipo de aplicaciones tienen necesidades diferentes, distintos niveles de profundidad técnica y expectativas diferentes sobre cómo la automatización se comunica con ellos. La capa de Presentación proporciona múltiples superficies: portales GUI, Command Line Interface (CLI), integraciones de ChatOps, todas respaldadas por la misma API y el mismo modelo de acceso, con el estado presentado a la audiencia que inició la acción.

3. Conectar la plataforma bidireccionalmente con sistemas externos y entregar los resultados a través de los canales que ya usan los consumidores. El equipo de aplicaciones ya trabaja en ServiceNow. El pipeline de CI/CD ya corre en un sistema de control de versiones. La plataforma debería ir a donde ellos están: recibiendo solicitudes de sus sistemas y enviando resultados de vuelta a esos mismos sistemas, sin requerir una nueva herramienta en su flujo de trabajo.

8.1.3. Pilares#

Tres pilares dan soporte a estos objetivos, uno por funcionalidad:

1. Capa de API: la base: contratos versionados, autenticados, con RBAC aplicado y estables. La autenticación y el multi-tenancy se aplican aquí, no por herramienta. Toda otra superficie se construye sobre ella.
2. Interfaces de cliente: todas las superficies orientadas al consumidor (portales GUI, CLI, móvil, ChatOps) como distintas formas del mismo API subyacente.
3. Integraciones y notificaciones: conexiones con sistemas externos (ITSM, pipelines CI/CD, sistemas de mensajería) y entrega de resultados hacia afuera (webhooks, callbacks, notificaciones push).

8.1.4. Alcance#

La capa de Presentación presenta. No produce.

Dentro del alcance:

• La capa de API: autenticación, autorización, versionado y límite de tasa para todos los consumidores
• Interfaces de cliente construidas sobre esa API: portales GUI, CLI, ChatOps, superficies móviles
• Integraciones externas: flujos de trabajo ITSM, hooks de pipelines CI/CD, entrega de webhooks
• Notificaciones salientes: callbacks de estado, alertas push, eventos en canales de mensajería
• Dashboards operativos cuando se presentan a audiencias no técnicas (control de acceso, segmentación de audiencia e integración en portales; la arquitectura de métricas subyacente pertenece al Capítulo 6)

Fuera del alcance:

• Producción de datos (Observability, Capítulo 6)
• Renderización de configuración y procesamiento de plantillas (Fuente de Verdad, Capítulo 4)
• Ejecución de flujos de trabajo y producción de registros de auditoría (Orchestrator, Capítulo 7)

Una capa de Presentación que empieza a acumular lógica de negocio (decidir qué flujo de trabajo ejecutar, validar entradas contra el modelo de red, gestionar el estado del flujo de trabajo) se ha convertido en otra cosa. Estas responsabilidades pertenecen al Orquestador y a la Fuente de Verdad. Si el portal empieza a codificar políticas de red o lógica de reintentos, el límite arquitectónico ha colapsado y la plataforma será difícil de evolucionar de forma independiente.

8.2. Funcionalidades#

Los tres objetivos y pilares se realizan a través de tres funcionalidades principales, cada una correspondiendo directamente a un objetivo y un pilar:

1. Capa de API: el contrato y el modelo de acceso para todos los consumidores
2. Interfaces de cliente: las superficies construidas sobre ese contrato
3. Integraciones y notificaciones: las conexiones con sistemas externos y la entrega hacia afuera

graph LR

    subgraph Goals["Objetivos"]
        direction TB
        A1[API autenticada estable y modelo de acceso consistente]
        A2[Superficie adecuada para cada tipo de consumidor]
        A3[Integración bidireccional con sistemas externos]
    end

    subgraph Pillars["Pilares"]
        direction TB
        B1[Capa API: versionada, autenticada, estable]
        B2[Interfaces de cliente: GUI, CLI, chatops, móvil]
        B3[Integraciones y notificaciones: ITSM, CI/CD, webhooks]
    end

    subgraph Functionalities["Funcionalidades"]
        direction TB
        C1[Capa API]
        C2[Interfaces de Cliente]
        C3[Integraciones y Notificaciones]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    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;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

8.2.1. Capa de API#

El Capítulo 4 cubrió en profundidad la propia API de la SoT: cómo los sistemas de automatización consultan los datos de intención, los patrones de consumo (REST, GraphQL, webhooks) y el modelo de lectura/escritura para la configuración de red. La API que se trata aquí es diferente en propósito: es el contrato de cara al exterior para los consumidores de la plataforma de automatización como un todo. Mientras que la API de la SoT responde “¿cómo debería ser la red?”, la API de la capa de Presentación responde “¿qué está haciendo la plataforma de automatización y cómo interactúo con ella?”. Ambas pueden ser APIs REST; sirven a audiencias diferentes con modelos de acceso distintos.

La API de la capa de Presentación es la base. Cada superficie de consumidor (portal, CLI, formulario ITSM, bot de ChatOps, agente de IA) es un llamador de esta capa. La autenticación, el RBAC, el versionado y el límite de tasa se aplican aquí. Hay que diseñarla bien o todo lo que haya encima heredará sus problemas.

La API de Presentación no debería reflejar las interfaces internas de los bloques. Exponer un endpoint /v1/sot/vlans/ que haga proxy directamente a la API de la SoT, o un endpoint /v1/orchestrator/jobs/ que envuelva IDs de jobs del Orquestador, ata a los consumidores a los detalles de implementación interna. Cuando se reemplaza un bloque por otro, cada pipeline de CI/CD que almacenó esos IDs debe actualizarse. La API de Presentación debería exponer conceptos a nivel de plataforma: un endpoint /v1/requests/ que representa una solicitud de servicio independientemente de qué Orquestador la procesó, un endpoint /v1/services/vlan/ que devuelve el estado actual de una VLAN agregado desde la SoT y la Observabilidad sin revelar qué bloque proporcionó cada pieza de datos. Los consumidores obtienen un contrato estable; la implementación interna puede evolucionar libremente detrás de él.

8.2.1.1. Qué expone la API#

La API expone dos categorías de endpoints:

• Endpoints de lectura: estado e historial de flujos de trabajo, registros de auditoría, estado de dispositivos y servicios agregado desde los bloques de SoT y Observabilidad. Son las consultas que el equipo de aplicaciones usa para comprobar el estado de una solicitud, que el auditor usa para revisar un registro de cambio, y que el sistema de monitorización usa para verificar la salud de la plataforma.

• Endpoints de escritura: disparar un flujo de trabajo, enviar una solicitud de servicio, aprobar o rechazar una puerta pendiente, cancelar un job en ejecución. Los endpoints de escritura requieren una autorización más estricta. Los distintos roles deben tener acceso a distintas operaciones de escritura: un miembro del equipo de aplicaciones puede enviar una solicitud pero no puede disparar flujos de trabajo arbitrarios; un ingeniero de red puede aprobar una puerta pendiente pero no puede modificar las definiciones de flujos de trabajo.

La distinción lectura/escritura también moldea la estabilidad del contrato. Los endpoints de lectura deben permanecer estables indefinidamente: un dashboard que lleva un año en funcionamiento no debería romperse porque cambió un esquema upstream. Los endpoints de escritura deben versionarse explícitamente, con avisos de deprecación antes de los cambios disruptivos.

8.2.1.2. Versionado y estabilidad#

Las APIs orientadas al consumidor deben versionarse. La API de la capa de Presentación es el contrato; los internos de los bloques son la implementación. La refactorización interna del Orquestador, la SoT o los bloques de Observabilidad no debe romper a los llamadores externos.

El enfoque estándar: versionar por prefijo de URL (/v1/, /v2/) o por cabecera Accept, mantener la versión anterior durante una ventana de deprecación definida y comunicar los cambios disruptivos mediante un changelog. Un pipeline de CI/CD que lleva ocho meses llamando a /v1/workflows/trigger no debería descubrir un lunes que el endpoint se movió sin previo aviso.

8.2.1.3. Autenticación y autorización#

La autenticación responde: ¿quién eres? La autorización responde: ¿qué tienes permitido hacer?

Muchos equipos implementan la autenticación antes que la autorización, y luego descubren que “autenticado” y “autorizado” son problemas diferentes cuando alguien envía cuarenta y siete solicitudes bajo un token válido que no debería haber tenido.

Patrones de autenticación para plataformas de automatización de redes:

• Integración SSO / LDAP: el estándar empresarial. Los ingenieros y los equipos de aplicaciones se autentican con su identidad corporativa. No hay credenciales separadas que gestionar, y la baja es automática cuando alguien se va.
• OAuth 2.0 / OIDC: para sistemas externos y usuarios del portal web. Produce tokens de corta duración en lugar de credenciales de larga duración.
• Tokens de API con alcance: para el acceso programático de pipelines CI/CD y scripts de automatización. Cada token tiene un alcance limitado a un conjunto específico de permisos con una caducidad definida. Un token de administrador compartido usado por todos los consumidores no es autenticación: es una contraseña compartida que no puede revocarse sin romper todos los llamadores simultáneamente.

Autorización mediante RBAC. Los roles deben mapear a responsabilidades operativas, no a capacidades de las herramientas. Un modelo inicial para la automatización de redes:

• read-only: ver cualquier dato, no disparar ninguna acción
• operator: disparar flujos de trabajo pre-aprobados, aprobar puertas, enviar solicitudes de servicio
• engineer: gestión completa de flujos de trabajo, acceso de escritura a la SoT, ver todos los registros de auditoría
• admin: configuración de la plataforma, gestión de usuarios, rotación de credenciales

Cada rol hereda todos los permisos del rol inferior. Un ingeniero puede hacer todo lo que puede hacer un operador, más escribir en la SoT y gestionar flujos de trabajo.

flowchart TD
    RO[read-only]
    OP[operator]
    ENG[engineer]
    ADM[admin]

    RO -->|añade: disparar flujos de trabajo + aprobar puertas| OP
    OP -->|añade: acceso escritura SoT + gestión de flujos| ENG
    ENG -->|añade: configuración plataforma + gestión usuarios| ADM

    style RO fill:#e8f5e9,stroke:#4caf50
    style OP fill:#c8e6c9,stroke:#388e3c
    style ENG fill:#a5d6a7,stroke:#2e7d32
    style ADM fill:#66bb6a,stroke:#1b5e20

El RBAC se aplica en el límite de la API. Los bloques subyacentes solo ven llamadas de API autenticadas desde la capa de Presentación; no gestionan la identidad del consumidor de forma independiente. El multi-tenancy se implementa mediante el alcance de los datos: cada consulta se filtra por el alcance organizativo del llamador. El equipo de aplicaciones del Edificio B no debería ver las solicitudes del equipo de retail del Edificio A. Esto debe diseñarse desde el principio. Retrofit del multi-tenancy en un modelo de datos plano es un doloroso proyecto de reestructuración.

El rastro de auditoría debería capturar las solicitudes denegadas junto con las aprobadas. Quién intentó hacer qué y fue denegado es tan importante para el cumplimiento como lo que fue permitido. La capa de Presentación produce este registro junto con el rastro de auditoría de flujos de trabajo del Capítulo 7. El Capítulo 12 extiende este modelo con rotación de secretos, política como código y flujos de automatización orientados al cumplimiento.

8.2.1.4. Límite de tasa#

Los consumidores automatizados sin límites de tasa agotarán la cola del Orquestador. El incidente de las cuarenta y siete solicitudes no requirió un actor malicioso: solo un equipo motivado, una URL y sin throttle.

Límite de tasa en el límite de la API: límites por token (solicitudes por minuto por consumidor), límites de ráfaga (solicitudes en vuelo simultáneas) y límites específicos por operación (un flujo de trabajo de actualización de firmware nunca debería ejecutar más de una instancia por dispositivo al mismo tiempo). Las respuestas de límite de tasa deben devolver HTTP 429 con una cabecera Retry-After, no un llenado silencioso de cola que aparece como un timeout horas después.

8.2.1.5. REST, GraphQL y la interfaz MCP#

REST es la opción por defecto. Es más simple de versionar, razonar y cachear que GraphQL. Los equipos de automatización de redes raramente necesitan la flexibilidad de consulta orientada al consumidor de GraphQL y pagan un coste operativo significativo por la complejidad adicional. La excepción: si la plataforma sirve a un gran número de tipos de consumidores distintos con patrones de consulta significativamente diferentes, GraphQL puede reducir el over-fetching y la necesidad de múltiples endpoints especializados. Es una elección justificada; raramente es la primera opción correcta.

La interfaz Model Context Protocol (MCP) es la superficie de IA de la capa de Presentación. Igual que los operadores humanos acceden a la plataforma vía CLI y los equipos de aplicaciones vía portal, los agentes basados en Large Language Model (LLM) acceden a ella vía un servidor MCP. El agente llama a herramientas (consultar el estado del flujo de trabajo, disparar una remediación, leer el log de auditoría) en la secuencia que requiera su razonamiento, sujeto al mismo modelo RBAC que cualquier otro llamador. Esto conecta directamente con el patrón de orquestación agéntica introducido en el Capítulo 7 (sección 7.2.7): el servidor MCP de la capa de Presentación es la interfaz que hace operables esos patrones en toda la plataforma sin integraciones codificadas de forma rígida entre el agente y cada bloque individual.

REST y MCP difieren en quién controla la interacción. En una integración REST, el consumidor sabe de antemano qué endpoints llamar y en qué orden: un pipeline CI/CD llama a POST /v1/requests/vlan, luego sondea GET /v1/requests/{id} hasta completarse. La secuencia está fijada en el código. Con MCP, un agente basado en Large Language Model (LLM) decide en tiempo de ejecución qué herramientas invocar y en qué secuencia, basándose en el resultado de cada llamada anterior. El consumidor no es un pipeline con un grafo de llamadas predeterminado; es un sistema de razonamiento que lee cada resultado antes de decidir qué hacer a continuación. El servidor MCP define las herramientas disponibles y sus esquemas; el agente decide cómo usarlas. Esto hace que MCP sea apropiado para consultas operativas abiertas (“investiga el problema de conectividad entre building-b y el núcleo”) que requerirían que un desarrollador anticipase cada posible secuencia de llamadas si se implementase como REST. También hace que la autorización sea más sensible: un agente con acceso amplio a herramientas puede combinar operaciones de formas para las que el modelo de acceso no fue diseñado explícitamente. El modelo RBAC debe aplicarse a nivel de herramienta, no solo a nivel de servidor.

8.2.2. Interfaces de Cliente#

Las interfaces de cliente son las superficies construidas sobre la API. Son distintas formas del mismo subyacente de la plataforma, cada una apropiada para un tipo de consumidor diferente. El modelo RBAC se aplica de forma uniforme independientemente de qué superficie se use.

8.2.2.1. GUI y portal de autoservicio#

El portal web es la interfaz principal para los no ingenieros. Su principio de diseño es la revelación progresiva: mostrar la cantidad correcta de información a la audiencia correcta sin exponer la complejidad subyacente.

El equipo de aplicaciones ve una vista de tres pasos: enviada, en progreso, completa, con un detalle de estado que dice “pre-comprobaciones ejecutándose en 24 switches” en lenguaje sencillo, no IDs de jobs de AWX. El ingeniero de red ve los resultados de la pre-comprobación por dispositivo, la puerta de aprobación con una acción de aprobar o rechazar, y la traza completa del flujo de trabajo si se necesita. El admin lo ve todo, incluyendo configuración y consultas de auditoría.

Las interfaces de lectura y escritura tienen distintos requisitos de diseño. Un dashboard de estado de solo lectura puede ser relativamente permisivo: cualquier ingeniero de la plataforma puede ver el estado actual de sus solicitudes. La ruta de escritura (enviar una solicitud, aprobar una puerta, cancelar un job en ejecución) necesita validación de entradas, un paso de confirmación y una declaración clara de qué ocurrirá antes de que se comprometa la acción.

Se han visto equipos construir portales donde el botón de envío en un formulario de nueva solicitud de servicio llama directamente a la API del Orquestador, sin capa de validación entre el formulario y el flujo de trabajo. Cuando un usuario envía una subred que entra en conflicto con una asignación existente, el error vuelve como un stack trace sin formato del Orquestador. La capa de Presentación debería validar las entradas contra el modelo de la SoT antes de que la solicitud llegue al Orquestador, y devolver un error claro y accionable cuando falle la validación.

El riesgo de adopción es mayor en la interfaz. Un portal técnicamente correcto que nadie usa porque no encaja en cómo trabaja ya el equipo aporta menos valor que una integración más simple en la herramienta que todo el mundo abre cada mañana. El equipo de aplicaciones que ya vive en ServiceNow enviará solicitudes más consistentemente a través de un formulario de ServiceNow que a través de un nuevo portal que tienen que aprender y en el que deben iniciar sesión por separado. El equipo de ingeniería que ya usa Slack para la coordinación de incidentes actuará sobre las notificaciones de puertas de aprobación más rápido a través de un mensaje de Slack que a través de un enlace del navegador que requiere autenticación adicional. La familiaridad reduce la fricción en la adopción y reduce las tasas de error en el uso diario. Cuando existe la elección entre construir una nueva superficie y encontrarse con los usuarios en la herramienta que ya conocen, la integración es casi siempre el primer paso correcto.

8.2.2.2. CLI#

La CLI para la plataforma de automatización no es la CLI del dispositivo, que es el dominio del Capítulo 9. Esta es una interfaz de línea de comandos para la propia plataforma: una herramienta que los ingenieros usan para disparar, inspeccionar y gestionar la automatización sin abrir un navegador.

Los ingenieros prefieren la CLI por la misma razón que prefieren los scripts de shell sobre las GUIs para el trabajo repetitivo: composabilidad, velocidad y programabilidad. Un comando de CLI puede aliarse, canalizarse con otros comandos, iterarse sobre una lista de dispositivos, incorporarse a un runbook o comprometerse en un repositorio junto con la infraestructura que gestiona. Un clic en el portal no puede. Durante un incidente a las 2 de la madrugada, un comando escrito de memoria en cinco segundos es más rápido que un portal que tarda veinte segundos en navegar y autenticar. Para los pipelines CI/CD, una CLI produce códigos de salida estructurados (0 para éxito, distinto de cero para fallo) que se corresponden directamente con las condiciones de pass/fail del paso del pipeline sin necesidad de análisis. Los ingenieros también confían más en las herramientas CLI para operaciones de alto riesgo: los parámetros son visibles en el historial del shell, auditables y reproducibles.

La CLI se gana su lugar incluso cuando existe un portal. Durante un incidente a las 2 de la madrugada, abrir un navegador, iniciar sesión, navegar a un flujo de trabajo y hacer clic en un formulario es más lento que ejecutar un único comando. Para los pipelines CI/CD, una CLI es preferible a las llamadas de API directas: gestiona la autenticación a partir de variables de entorno, produce códigos de salida estructurados y proporciona salida legible cuando algo falla.

Principios de diseño para una CLI de plataforma de automatización:

• Estructura de comandos sustantivo-verbo consistente (workflow run, workflow status, request list) que se corresponde de forma predecible con las operaciones de la API
• Salida legible por máquinas mediante un flag --json para que los scripts de pipeline puedan analizar el resultado
• Configuración consciente del entorno: el endpoint de la API y el token se leen de un fichero de configuración o de variables de entorno, no codificados de forma rígida en los scripts
• El mismo RBAC que se aplica a la API se aplica a la CLI: un token con permisos de nivel operador no puede disparar operaciones de nivel admin independientemente de qué superficie se use

8.2.2.3. Mensajería instantánea y móvil#

Slack, Teams y plataformas similares sirven un doble papel en la automatización de redes: son tanto un canal de notificación (la capa de Presentación empuja eventos hacia ellas) como una superficie de interacción (los ingenieros envían comandos a través de ellas). Entender este doble papel importa para la arquitectura: el mismo espacio de trabajo que recibe notificaciones de alertas debería soportar flujos de aprobación, reduciendo el cambio de contexto para los ingenieros que ya monitorean esos canales.

Como superficie de interacción, las plataformas de mensajería funcionan a través de bots que traducen comandos conversacionales en llamadas de API. El bot es fino: analiza el mensaje, lo mapea a una llamada de la API de la capa de Presentación bajo la identidad del remitente y formatea la respuesta para el canal. Tres patrones funcionan bien en la práctica:

• Flujos de aprobación: un mensaje de Slack con botones “Aprobar” y “Rechazar” permite que un ingeniero de red actúe sobre una puerta pendiente sin salir de Slack. El clic del botón llama al endpoint de aprobación de la API con la identidad del ingeniero, resuelta a través de la integración SSO de la plataforma con el OAuth de Slack.
• Consultas de estado: @netbot status app-payments devuelve el estado actual del flujo de trabajo en un mensaje formateado en el canal.
• Acciones rápidas: @netbot compliance-check building-b dispara un flujo de trabajo de verificación ligero y publica el resultado en línea.

Las interfaces móviles sirven a una audiencia específica que los portales y la CLI no alcanzan: técnicos de centros de datos que trabajan físicamente en el campo. Un técnico que reemplaza una tarjeta de línea en un rack no tiene un portátil abierto. Sus manos pueden estar ocupadas, su posición incómoda. Una app móvil que les permite escanear el código de barras de un dispositivo, ver su estado actual de automatización (gestionado por automatización, último despliegue hace 14 días, sin cambios pendientes), confirmar un reemplazo físico y disparar el flujo de trabajo de remediación apropiado conecta el trabajo físico con la plataforma de automatización sin volver a una estación de trabajo. El modelo RBAC se aplica: el token del técnico tiene el alcance a las operaciones que permite su rol. La interfaz tiene el alcance a los datos relevantes para el campo: identidad del dispositivo, estado actual, tareas pendientes y acciones de disparo simples, no la vista completa de la plataforma.

El mismo modelo RBAC se aplica. El bot autentica a los ingenieros a través de SSO y reenvía solicitudes con un token con el alcance del rol del ingeniero. Un ingeniero con acceso de solo lectura no puede disparar un flujo de trabajo a través de Slack más de lo que puede hacerlo a través del portal.

Como destino de notificaciones, los canales de mensajería reciben actualizaciones impulsadas por eventos desde la capa de Presentación: completaciones de despliegues, alertas de fallos, solicitudes de puertas de aprobación y errores críticos de flujos de trabajo. El enrutamiento de notificaciones es una política de configuración: qué eventos van a qué canales para qué audiencias. Los ingenieros reciben detalles de fallos en un canal de operaciones dedicado. Los equipos de aplicaciones reciben el estado de completación a través del ticket ITSM. Los ingenieros de guardia reciben fallos críticos vía PagerDuty.

Las interfaces móviles siguen el mismo patrón. La restricción es el espacio de pantalla y el modelo de interacción, no la arquitectura. Una interfaz de aprobación móvil que permite a un ingeniero aprobar una puerta pendiente desde su teléfono llama a la misma API que el portal. El modelo RBAC no cambia.

8.2.2.4. Cuándo construir frente a aceptar las UIs integradas#

Casi todos los bloques ya tienen una UI. AWX tiene un portal de flujos de trabajo. Nautobot tiene una interfaz web. Grafana tiene dashboards. Estas UIs integradas son suficientes para las audiencias de ingeniería que entienden la plataforma. La decisión de construir una capa de Presentación dedicada no debería ser la opción por defecto.

Una secuencia de decisiones práctica:

1. ¿Son todos los consumidores ingenieros que ya usan las UIs de los bloques? Usar las UIs integradas. No construir un portal personalizado.
2. ¿Necesitan los no ingenieros solicitar o rastrear la automatización? Se necesita ya sea un portal o una integración ITSM.
3. ¿Es el ITSM ya donde se gestionan todas las solicitudes de servicio? Adoptar el ITSM como capa de Presentación o integrarlo como consumidor principal. Si el motor de flujos de trabajo, el modelo de aprobación y el sistema de notificaciones del ITSM son suficientes para los patrones de solicitud, dejar que el ITSM sea la capa de Presentación directamente: las llamadas de automatización se originan dentro de los flujos de trabajo del ITSM, no desde una capa separada por encima. Si se necesita un contrato de API más capaz, vistas de estado entre bloques o RBAC que el ITSM no pueda aplicar limpiamente, una capa dedicada fina entre el ITSM y los bloques proporciona esas propiedades mientras el ITSM permanece como la superficie orientada al usuario.
4. ¿Se necesita RBAC que abarque múltiples bloques de forma uniforme? Se necesita una capa de API con autenticación centralizada, independientemente de qué superficies de cliente se construyan encima.
5. ¿Se puede comprometer a mantener un portal personalizado a largo plazo? Si hay dudas, empezar con la integración ITSM. Construir un portal solo cuando el ITSM resulte insuficiente para los patrones de acceso que se necesitan.
6. ¿Necesitan los consumidores introducir o ver detalles que los formularios ITSM no pueden representar? Los campos de entrada complejos (fragmentos YAML, parámetros de topología, vistas previas de asignación de subredes), la validación en línea contra el modelo de la SoT o las vistas de estado enriquecidas con navegación por dispositivo típicamente superan lo que los constructores de formularios ITSM soportan limpiamente. Si los consumidores regularmente necesitan ese nivel de especificidad, un portal personalizado merece su coste operativo.

El portal personalizado merece construirse cuando los no ingenieros necesitan acceso que el ITSM no puede expresar limpiamente, o cuando se necesita una única vista de estado entre bloques que ninguna de las UIs integradas proporciona. El error más común es construirlo antes de validar que la necesidad es real.

8.2.2.5. Documentación e informes#

Dos salidas de solo lectura relacionadas de la capa de Presentación sirven a audiencias que consumen el conocimiento de automatización de forma asíncrona: consumidores de documentación (equipos que necesitan entender el estado actual de los servicios de red) y consumidores de informes (managers y auditores que necesitan resúmenes periódicos y evidencia de cumplimiento).

El patrón docs-as-code se aplica aquí: documentación generada a partir de datos vivos de la plataforma usando lenguajes de plantillas (Jinja2, Markdown), versionada junto con el código base de automatización y regenerada con cada cambio. Los diagramas Mermaid integrados en los documentos generados pueden reflejar la topología real de la SoT en lugar de dibujos mantenidos manualmente. Del mismo modo, la lógica de normalización que el bloque de Observabilidad aplica a las métricas en bruto (cubierta en el Capítulo 6) puede reutilizarse aquí: una plantilla de informe consulta los mismos datos de series temporales normalizadas para producir resúmenes tabulares para auditores, sin duplicar el trabajo de normalización.

• Documentación autogenerada: convierte los datos vivos de la plataforma en artefactos legibles y compartibles sin mantenimiento manual. Para cada servicio de red desplegado, un documento generado puede combinar la definición del servicio de la SoT, el estado operativo actual de la Observabilidad y el historial de cambios del rastro de auditoría del Orquestador. Dado que los datos de origen están siempre actualizados, la documentación se mantiene actual automáticamente. Las definiciones de flujos de trabajo en el Orquestador son otra fuente: un generador de documentación puede producir un runbook legible por humanos a partir de una definición de flujo de trabajo, garantizando que lo que describe el runbook coincide con lo que realmente hace la automatización.

• Informes: sirve a audiencias de gestión y cumplimiento que necesitan resúmenes periódicos en lugar de vistas en tiempo real. Los resúmenes de cambios semanales (cuántos flujos de trabajo se ejecutaron, tasa de éxito, duración media, dispositivos afectados) alimentan las revisiones operativas. Las exportaciones de cumplimiento (todos los registros de cambios de un período, estructurados para la presentación de auditoría) se ensamblan del rastro de auditoría del Orquestador y el registro de autorización de la capa de Presentación. Los informes de SLA y capacidad (tendencias de tiempo de aprovisionamiento, tasas de error por clase de dispositivo, backlog de solicitudes pendientes) alimentan las discusiones de planificación de capacidad y mejora del servicio.

Los dashboards operativos abarcan ambos capítulos por intención de diseño. El Capítulo 6 cubre la arquitectura de datos: qué se recopila, cómo se normaliza y los dashboards construidos directamente sobre telemetría para audiencias de ingeniería. La implicación de la capa de Presentación comienza cuando esos mismos dashboards se presentan a audiencias no técnicas: integrándolos en un portal de autoservicio, delimitando el acceso para que los equipos de aplicaciones solo vean sus servicios, o estructurando vistas adaptadas para uso en campo. Las métricas subyacentes permanecen en el bloque de Observabilidad; el modelo de acceso y el contexto de la superficie son preocupaciones de Presentación.

La distinción frente a los dashboards operativos (Capítulo 6) es el consumidor y el encuadre temporal: los dashboards muestran el estado actual para ingenieros que toman decisiones en tiempo real; la documentación y los informes son instantáneas consumidas de forma asíncrona por no ingenieros. Los datos subyacentes pueden ser los mismos. La superficie y la cadencia son distintas.

8.2.3. Integraciones y Notificaciones#

La capa de Presentación se conecta a sistemas externos en ambas direcciones: recibiendo eventos que disparan la automatización y entregando resultados de vuelta a los sistemas que iniciaron las solicitudes. Aquí es donde el flujo de trabajo del consumidor y el flujo de trabajo de la plataforma convergen.

La distinción frente a la capa de API es la direccionalidad y la iniciación. La capa de API gestiona las solicitudes entrantes: un consumidor llama a la plataforma y espera una respuesta. Las integraciones y notificaciones son sobre la plataforma que se dirige a sistemas que no iniciaron la interacción actual: empujar una actualización de estado a un ticket de ServiceNow, entregar un callback de webhook a un pipeline CI/CD que espera de forma asíncrona, publicar un evento en un canal de Slack que monitoriza un servicio específico. La capa de API responde llamadas. Esta sección envía eventos. Ambas usan el mismo modelo de autenticación y límites RBAC; la diferencia es la dirección de la iniciación. A pequeña escala, un único componente gestiona ambos patrones limpiamente. A mayor escala, la entrega de eventos salientes (con su lógica de reintentos, colas de mensajes fallidos y gestión de suscripciones) típicamente se convierte en un componente distinto con sus propias preocupaciones operativas, por eso este modelo separa los dos como funcionalidades distintas.

8.2.3.1. Integración ITSM#

Las plataformas ITSM ocupan dos posiciones distintas en una arquitectura de automatización de redes, y la distinción importa para el diseño. En la primera posición, la plataforma ITSM es la capa de Presentación: sus formularios definen la interfaz de usuario, su motor de flujos de trabajo gestiona las aprobaciones y notificaciones, y la API de automatización se llama desde dentro de los flujos de trabajo del ITSM. En este modelo no hay integración externa porque el ITSM no es externo a la capa de Presentación: es la capa de Presentación. En la segunda posición, existe una capa de Presentación dedicada y la plataforma ITSM es uno de los consumidores con los que se sincroniza: las solicitudes llegan vía webhooks de ITSM y las actualizaciones de estado fluyen de vuelta a los tickets del ITSM. También es común un tercer rol: el ITSM como fuente de datos de la SoT. Cuando el CMDB contiene registros de activos o servicios autorizados, la SoT puede consultarlo como fuente de datos federada (cubierto en el Capítulo 4), pero el ITSM en este rol no juega ningún papel en la interfaz de automatización orientada al usuario.

El resto de esta sección describe el patrón de integración (segunda posición). El patrón ITSM-como-capa-de-Presentación (primera posición) es la elección correcta cuando el motor de flujos de trabajo, el modelo de aprobación y el sistema de notificaciones de la plataforma ITSM son suficientes para los patrones de solicitud y se quiere evitar introducir una capa separada entre los usuarios y los bloques.

La integración ITSM es lo que se construye cuando los consumidores no deberían necesitar saber que existe la plataforma de automatización. El equipo de aplicaciones ya trabaja en ServiceNow. La interfaz más usable es la que ya están usando.

Un formulario de ServiceNow para “Nueva solicitud de servicio de red” captura exactamente los campos que el modelo de la SoT necesita y los envía en el formato estructurado que espera la capa de API. El formulario es la capa de Presentación; el consumidor nunca ve la llamada de API. Al enviar, la capa de Presentación valida el payload, autentica el token de cuenta de servicio que usa la integración ITSM y reenvía la solicitud al Orquestador.

Después de que se dispara la solicitud, el ticket debería reflejar el estado del flujo de trabajo en tiempo casi real: “Validación de SoT completa”, luego “Pre-comprobaciones ejecutándose: 24 switches”, luego “Puerta de aprobación: pendiente de firma del ingeniero”, luego “Completo: 24/24 switches configurados”. Esta sincronización bidireccional es más compleja que un webhook de un solo disparo. Requiere que la capa de Presentación se suscriba a los eventos de estado del Orquestador y los traduzca en actualizaciones de tickets usando una suscripción de eventos persistente o un reconciliador de sondeo.

En muchas organizaciones, el ticket ITSM es el registro de gestión de cambios. La capa de Presentación debe asegurarse de que el ticket contiene suficiente información para satisfacer los requisitos de gestión de cambios aunque el rastro de auditoría autoritativo viva en el Orquestador. Los dos registros sirven a audiencias distintas: el ticket ITSM sirve al solicitante y a su manager; el registro de auditoría del Orquestador sirve al ingeniero de red y al auditor de cumplimiento.

La integración ITSM tiene límites. Es apropiada para flujos de trabajo de solicitud estructurados y basados en formularios con estados definidos. No es adecuada para consultas operativas en tiempo real, inspección compleja de trazas de flujos de trabajo u operaciones de usuario avanzado donde los ingenieros necesitan iterar rápidamente. Hay que diseñar la plataforma sabiendo que el ITSM cubre la mayoría de las solicitudes de no ingenieros y una CLI o portal cubre el resto.

8.2.3.2. Integración con pipelines CI/CD#

Un pipeline de despliegue que aprovisiona recursos de red llama a la API de la capa de Presentación en un paso definido, pasa entradas estructuradas y se bloquea hasta que se devuelve un resultado de éxito o fallo. El pipeline corre bajo una cuenta de servicio con un token con alcance: permisos suficientes para disparar el flujo de trabajo de red y leer su estado, nada más.

Aquí es también donde la CLI se gana su lugar en contextos automatizados. Un paso de pipeline que ejecuta netauto workflow run vlan-deploy --params params.json --wait es más fácil de depurar, más fácil de versionar y más fácil de reemplazar que una llamada HTTP directa construyendo el payload de la API en línea. El código de salida estructurado de la CLI se corresponde directamente con la condición de pass o fail del paso del pipeline.

8.2.3.3. Notificaciones push y entrega de webhooks#

Cuando un flujo de trabajo se completa, alcanza una puerta de aprobación o falla, la capa de Presentación notifica a la audiencia correcta a través del canal correcto. El enrutamiento de notificaciones es una decisión de política, no un mapeo codificado de forma rígida. Los ingenieros reciben detalles de fallos en un canal de Slack dedicado. Los equipos de aplicaciones reciben el estado de completación vía actualización de ticket. Los ingenieros de guardia reciben fallos críticos vía PagerDuty. Las reglas de enrutamiento son configuración, no código.

La entrega de webhooks es la contrapartida saliente de los webhooks entrantes. Un llamador que registró una URL de callback al disparar un flujo de trabajo recibe el resultado vía HTTP POST cuando el flujo de trabajo se completa. Las garantías de entrega, la política de reintentos en caso de fallo y el esquema del payload forman parte del contrato de la API. Un callback que falla silenciosamente (sin reintento, sin log, sin alerta) es peor que ningún callback, porque el llamador asume que el resultado fue entregado.

8.2.4. Panorama de Soluciones#

Las herramientas listadas aquí son ejemplos con propósitos explicativos, no recomendaciones. Hay que evaluarlas frente a las capacidades del equipo, las herramientas existentes y las restricciones operativas.

El capítulo de Presentación tiene una relación diferente con el panorama de soluciones que cualquier otro capítulo de la Parte 2. Casi no existen herramientas que existan exclusivamente como Presentación. Todos los bloques ya tienen una UI. La pregunta arquitectónica no es “¿qué herramienta de Presentación debería usar?”. Es: ¿cuándo acepto las UIs integradas de cada bloque, y cuándo construyo una capa de Presentación dedicada por encima de ellas?

Dos modelos coexisten en plataformas de automatización maduras.

• Modelo integrado: usar la UI integrada de cada bloque para su audiencia. Los ingenieros usan el portal del orquestador para la gestión de flujos de trabajo, la UI web de la SoT para el inventario, los dashboards de observabilidad para la salud de la red. Esto funciona cuando todos los consumidores son ingenieros que entienden las herramientas y cuando no se necesitan vistas entre bloques. La carga operativa es baja: no hay sistemas adicionales que operar.

• Modelo de Presentación dedicada: construir o adoptar una capa por encima de los bloques que proporcione una experiencia unificada. Necesario cuando los no ingenieros necesitan acceso, cuando se necesita estado entre bloques en una única vista, o cuando los requisitos de RBAC no se corresponden limpiamente con los permisos integrados de las herramientas individuales.

Entender qué hay dentro de las UIs integradas importa para las decisiones de personalización. NetBox está construido sobre Django (Python); su interfaz web y su API REST son vistas de Django y endpoints de Django REST Framework. Nautobot comparte el mismo linaje. Infrahub usa FastAPI. El “componente de Presentación” de estas herramientas SoT es un framework web maduro: personalizable mediante plugins, vistas personalizadas y extensiones de serializador. Esa es tanto su fortaleza (bien documentado, de calidad producción) como su restricción (se está personalizando dentro de un framework diseñado principalmente para el caso de uso de SoT, no para el caso de uso del portal de autoservicio).

La fila ITSM en la tabla anterior representa el ITSM como la capa de Presentación, no como una integración externa. Cuando una organización ha estandarizado en ServiceNow o Jira Service Management como punto de entrada para todas las solicitudes de servicio, el ITSM es la capa de Presentación. La API de automatización es lo que el ITSM llama internamente como parte de sus propios flujos de trabajo; no hay ninguna gateway separada entre el usuario y el ITSM. La gateway se sitúa entre el ITSM y los bloques downstream.

Un principio arquitectónico que atraviesa todos los enfoques: la capa de Presentación debe ser fina. Es una superficie, no un sistema. La lógica de negocio pertenece al Orquestador y a la SoT. La capa de Presentación traduce, autentica y enruta. En el momento en que empieza a tomar decisiones de automatización, el límite ha colapsado.

8.3. Ejemplo de Implementación#

8.3.1. Dos Superficies, Tres Audiencias, Una Plataforma#

Se ha seguido la red de campus a lo largo de toda la Parte 2. La solicitud de servicio de VLAN para app-payments se modeló en la SoT en el Capítulo 4, fue desplegada por el Ejecutor en el Capítulo 5, validada por la Observabilidad en el Capítulo 6 y coordinada de extremo a extremo por el Orquestador en el Capítulo 7. Lo que nunca se abordó es cómo tres audiencias distintas interactúan con ese flujo de trabajo.

En este campus, la capa de Presentación está compuesta por tres componentes. ServiceNow es la interfaz principal para la organización en general: los equipos de aplicaciones envían solicitudes y rastrean el estado completamente dentro de ServiceNow, que enruta a través de la API de la capa de Presentación como parte de su propia automatización de flujos de trabajo. Un portal personalizado con una vista de auditoría sirve a las audiencias de ingeniería y cumplimiento: los ingenieros de red revisan los resultados de las pre-comprobaciones y actúan sobre las puertas de aprobación allí, y los auditores de seguridad consultan registros de cambios compuestos a través de su interfaz de auditoría de solo lectura. Ambas superficies comparten la misma capa de API, que se encuentra dentro de la propia capa de Presentación y aplica autenticación, RBAC y versionado antes de que cualquier solicitud llegue a los bloques subyacentes.

Las tres audiencias

• El equipo de aplicaciones envía solicitudes a través de un formulario de ServiceNow. Quieren saber cuándo el servicio está listo y qué ocurrió si falló. Nunca deberían necesitar abrir AWX o Nautobot. ServiceNow es su capa de Presentación; la API de la plataforma es algo que nunca ven.

• El ingeniero de red recibió una notificación de puerta de aprobación durante el flujo de trabajo (Capítulo 7, paso 3). Necesita ver los resultados de la pre-comprobación para los 24 switches objetivo, aprobar o rechazar, y poder inspeccionar el resultado. Su interfaz es el portal personalizado: más detallado que el formulario de ServiceNow, pero aún delimitado al alcance de su equipo.

• El auditor de seguridad llega tres meses después con una pregunta: ¿quién solicitó esta VLAN, quién la aprobó, qué versión del flujo de trabajo de despliegue se ejecutó y cuál fue el estado anterior y posterior de los switches afectados? Su interfaz es la vista de auditoría del portal: de solo lectura, sin capacidad de disparar nada.

Las dos superficies de Presentación

La capa de API es la base compartida dentro de la capa de Presentación. Tanto ServiceNow como el portal personalizado enrutan cada solicitud a través de ella antes de que nada llegue a los bloques subyacentes. Aplica tres tokens basados en roles: el token de operador del equipo de aplicaciones (leer las propias solicitudes, enviar nuevas solicitudes), el token de ingeniero del ingeniero de red (leer todas las solicitudes en su alcance, aprobar o rechazar puertas) y el token de solo lectura del auditor (consultar registros de auditoría en toda la plataforma, sin acceso de escritura). Ninguna superficie lo evita.

flowchart TD
    subgraph Consumers["Consumidores"]
        AT[Equipo de Aplicaciones]
        NE[Ingeniero de Red]
        SA[Auditor de Seguridad]
    end

    subgraph PL["Capa de Presentación"]
        SN[ServiceNow]
        PORTAL[Portal Personalizado]
        API[Capa API: Autenticación · RBAC · Versionado]
    end

    subgraph Blocks["Bloques de Plataforma"]
        ORC[Orquestador]
        SOT[Fuente de Verdad]
        OBS[Observabilidad]
    end

    AT --> SN
    NE & SA --> PORTAL
    SN & PORTAL --> API
    API --> ORC & SOT & OBS

    classDef presentation fill:#f0e6ff,stroke:#9b59b6,color:#4a235a
    classDef api fill:#e8e8e8,stroke:#555,color:#111,font-weight:bold
    classDef block fill:#f5f5f5,stroke:#999,color:#333

    class SN,PORTAL presentation
    class API api
    class ORC,SOT,OBS block

Paso 1: ServiceNow como superficie del equipo de aplicaciones

El equipo de aplicaciones rellena un formulario de ServiceNow: nombre del servicio (app-payments), tamaño de subred (/24), edificio (building-b), equipo solicitante y justificación de negocio. Al enviarlo, ServiceNow llama a la capa de API de la plataforma directamente como parte de su propia automatización de flujos de trabajo. La capa de API valida el payload contra el modelo de datos de la SoT, autentica el token de cuenta de servicio que usa ServiceNow y reenvía la solicitud estructurada al Orquestador.

Si la validación falla (por ejemplo, el edificio solicitado no coincide con ninguna sede en la SoT, o el tamaño de la subred entra en conflicto con una asignación existente), la capa de API devuelve un error estructurado de inmediato, antes de que se inicie ningún flujo de trabajo del Orquestador. ServiceNow actualiza el ticket con una razón de fallo clara: “building-c no encontrado en el registro de sedes” o “la subred /24 entra en conflicto con la asignación existente 10.22.14.0/24 en building-b”. El equipo de aplicaciones ve el rechazo en su ticket y puede corregir la solicitud sin involucrar a un ingeniero de red. No se crea ningún estado parcial del flujo de trabajo y no se necesita ningún rollback de Saga, porque el flujo de trabajo nunca empezó.

A medida que el flujo de trabajo avanza, la capa de Presentación se suscribe a los eventos de estado del Orquestador y los traduce en actualizaciones de tickets de ServiceNow: “Validación de SoT completa”, “Pre-comprobaciones ejecutándose: 24 switches”, “Puerta de aprobación: pendiente de firma del ingeniero”, “Completo: 24/24 switches configurados”. El equipo de aplicaciones observa cómo se actualiza su ticket sin saber que el Orquestador, la SoT o AWX existen.

Paso 2: La superficie de la puerta de aprobación

Cuando el flujo de trabajo alcanza la puerta de aprobación, el Orquestador hace una pausa y emite un evento. La capa de Presentación lo recibe, identifica al ingeniero de red responsable del Edificio B y envía una solicitud de aprobación a su canal de Slack con un enlace directo a la página de revisión de la puerta. La página de revisión muestra los resultados de la pre-comprobación por switch: cuáles pasaron, cuáles fallaron, cuáles se omitieron y por qué. El ingeniero aprueba o rechaza desde el portal. La acción queda registrada: quién aprobó, desde qué interfaz, a qué hora, bajo qué token.

Paso 3: La vista de auditoría

Tres meses después, el auditor de seguridad consulta la API de la capa de Presentación: “muéstrame el registro completo de cambios para la VLAN app-payments, Edificio B”. El endpoint de auditoría de solo lectura agrega tres fuentes:

• El registro de ejecución del Orquestador (Capítulo 7, sección 7.2.4): qué versión del flujo de trabajo se ejecutó, cada entrada y salida de cada paso, cualquier acción de compensación de Saga
• El registro de cambios de la SoT (Capítulo 4): estado anterior y posterior de la definición de VLAN
• El propio registro de autorización de la capa de Presentación: quién envió la solicitud, qué token usó, quién aprobó la puerta y cuándo

La respuesta es un documento estructurado que el auditor puede adjuntar al registro de gestión de cambios. Ninguno de los tres bloques subyacentes fue diseñado para producir este registro compuesto de forma independiente. La capa de Presentación lo ensambló a partir de sus APIs individuales bajo el token de solo lectura del auditor.

Qué demuestra esto

El mismo flujo de trabajo de diez pasos del Capítulo 7 sirvió a tres audiencias diferentes a través de dos superficies de Presentación sin que ninguna de esas audiencias necesitase entender la plataforma subyacente. ServiceNow sirvió a la organización en general: el equipo de aplicaciones rastreó su solicitud a través de una herramienta que ya usa cada día, sin ninguna conciencia de AWX, Nautobot o el Orquestador detrás. El portal personalizado sirvió a las audiencias de ingeniería y cumplimiento: el ingeniero de red revisó una interfaz de aprobación limpia delimitada al alcance de las solicitudes de su equipo, y el auditor consultó un registro de cambios compuesto ensamblado de tres bloques a través de una única vista de solo lectura. Una capa de API, aplicando el mismo modelo de acceso para ambas superficies, hizo la plataforma accesible sin hacerla visible.

8.4. Resumen#

La capa de Presentation (Layer) es el último bloque constructivo de la Parte 2, y es el que con más probabilidad se trata como algo secundario. Los bloques por debajo de ella hacen el trabajo sustantivo: mantener la intención, aplicar cambios, validar resultados, coordinar flujos de trabajo. La capa de Presentación no produce nada de eso. Pero sin ella, la plataforma solo es accesible para las personas que la construyeron, y toda otra audiencia sigue dependiendo de un intermediario humano.

La capa de API es la base. La autenticación y la autorización aplicadas en el límite de la API (no por herramienta) es lo que separa la automatización accesible de la automatización peligrosa. El versionado y los contratos estables son lo que separa una plataforma de un prototipo que rompe a sus llamadores en cada actualización. La interfaz Model Context Protocol (MCP) extiende el mismo modelo de acceso a los agentes basados en Large Language Model (LLM), haciendo la plataforma disponible para los patrones de orquestación agéntica introducidos en el Capítulo 7 y desarrollados más adelante en el Capítulo 17.

Las interfaces de cliente son distintas formas del mismo API subyacente. Un portal GUI con revelación progresiva sirve a los no ingenieros que necesitan solicitar y rastrear la automatización sin entender la plataforma. Una CLI sirve a los operadores que necesitan velocidad, programabilidad e integración con CI/CD. Las superficies de ChatOps y móvil sirven a flujos de aprobación y consultas de incidentes. La decisión sobre qué superficies construir debería seguir una secuencia deliberada: empezar con las UIs integradas de los bloques para audiencias de ingeniería, integrar con el ITSM cuando los no ingenieros necesiten solicitar automatización, construir un portal personalizado solo cuando el ITSM resulte insuficiente.

Las integraciones y notificaciones cierran el bucle que el contrato de respuesta asíncrona del Capítulo 7 abrió. El Orquestador produce un resultado del flujo de trabajo; la capa de Presentación lo entrega a la audiencia que disparó la acción a través del canal que ya usa. La sincronización bidireccional del ITSM, los callbacks de webhooks y las notificaciones push no son características de conveniencia. Son lo que hace la automatización visible para las personas que dependen de ella.

El escenario de campus mostró esto en la práctica: un flujo de trabajo, tres audiencias, dos superficies de Presentación. ServiceNow sirvió a la organización en general como su propia superficie de Presentación, llamando directamente a la API de la plataforma y presentando el estado a través de actualizaciones de tickets conocidas. El portal personalizado sirvió a las audiencias de ingeniería y cumplimiento: el ingeniero de red revisó una interfaz de aprobación limpia delimitada al alcance de las solicitudes de su equipo, y el auditor consultó un registro de cambios compuesto ensamblado del Orquestador, la SoT y el propio registro de autorización de la capa de Presentación. La misma capa de API aplicó el modelo de acceso para ambas. La plataforma ya no era invisible.

Con la capa de Presentación en su lugar, la Parte 2 ha cubierto los siete bloques constructivos del framework NAF. El siguiente capítulo se centra en el único bloque sobre el que actúa en última instancia toda esta automatización: La propia Red, cubierta en el Capítulo 9.

💬 Found something to improve? Send feedback for this chapter