8. La Capa de Presentació#

L’automatització de VLANs feia sis setmanes que s’executava. L’equip de xarxa n’estava orgullós. Cada matí, tres o quatre sol·licituds de servei noves arribaven dels equips d’aplicacions, i l’Orquestrador les gestionava sense que ningú de l’equip de xarxa toqués un teclat. Els desplegaments funcionaven. Els switches estaven configurats. La xarxa era sana.

L’escalada va arribar un dijous. El responsable de l’equip d’aplicacions preguntava per qué les sol·licituds de VLAN tardaven de tres a cinc dies hàbils quan el portal deia “enviada”. L’equip de xarxa va revisar la seva cua: zero sol·licituds pendents, tots els desplegaments reeixits. L’automatització havia processat cada sol·licitud en vint minuts des de la recepció. Però els tiquets de ServiceNow seguien mostrant “En Progrés”, perquè ningú havia escrit la integració que els actualitzaria.

L’automatització havia fet la seva feina. El resultat era invisible.

Una setmana més tard, l’equip va desplegar un portal d’autoservei ràpid perquè els equips d’aplicacions poguessin enviar sol·licituds directament i veure el seu estat. Al migdia havien rebut quaranta-set sol·licituds de VLAN en una sola hora. Totes vàlides. Totes formatades correctament. El problema: el portal no tenia cap model d’autorització. Acceptava enviaments de qualsevol persona que tingués l’URL. Totes les sol·licituds s’executaven sota un únic token d’API amb drets d’administrador de tota la plataforma. No hi havia limitació de taxes, cap porta d’aprovació, cap rastre d’auditoria de qui havia enviat qué.

L’automatització funcionava. El model d’accés no.

Aquestes dues fallades són ambdues fallades de Presentació. Una és l’absència d’un bucle de retroalimentació; l’altra és l’absència de proteccions. Aquest capítol tanca aquesta bretxa.

8.1. Fonaments#

8.1.1. Context#

Cada bloc constructiu cobert fins ara mira cap endins: cap a altres blocs o cap a enginyers que entenen la plataforma. La Source of Truth (SoT) conté la intenció de xarxa per als sistemes d’automatització. L’Executor aplica canvis als dispositius. L’Observability valida els resultats. L’Orchestrator els coordina tots. Cadascun d’aquests blocs té una interfície d’usuari, una API o ambdues, dissenyades per a les persones que han construït i operen la plataforma, no per a tothom que ha d’interactuar-hi.

La capa de Presentation (Layer) mira cap enfora. La seva feina és fer la plataforma accessible a audiències que no haurien de necessitar entendre els interns: l’equip d’aplicacions que sol·licita un servei de xarxa, l’auditor de seguretat que pregunta qué ha canviat l’últim trimestre, la pipeline de CI/CD que aprovisiona infraestructura sense cap humà en el bucle.

Al Capítol 3 el bloc de Presentació estava a la vora del marc NAF, mirant cap a humans i sistemes externs. El Capítol 6 va establir el límit entre la visualització d’observabilitat i la Presentació: els panells construïts directament sobre la telemetria de xarxa pertanyen al bloc d’Observabilitat per afinitat de disseny; com es presenten aquells panells als no-enginyers, s’accedeixen amb control d’accés o s’inclouen en portals és una preocupació de Presentació. El Capítol 7 va establir que els fluxos de treball asíncrons requereixen endpoints d’estat i hooks de notificació. La capa de Presentació proporciona tots dos.

8.1.2. Objectius#

La capa de Presentació serveix tres objectius que s’associen directament a tres funcionalitats arquitectòniques.

1. Proporcionar una API estable i autenticada amb un model d’accés consistent. Cada consumidor, humà o màquina, hauria d’interactuar amb la plataforma a través d’un contracte versionat i amb control d’accés que no canvia sense avís. Els blocs subjacents es poden substituir, actualitzar o reestructurar; el contracte orientat al consumidor ha de romandre estable. L’autenticació i l’autorització s’apliquen en aquest límit, centralitzats en lloc de duplicats per eina.

2. Servir cada tipus de consumidor a través de la interfície que s’adapta al seu flux de treball. Un enginyer de xarxa i un gestor d’equip d’aplicacions tenen necessitats diferents, nivells de profunditat tècnica diferents i expectatives diferents sobre com l’automatització es comunica amb ells. La capa de Presentació proporciona múltiples superfícies: portals GUI, Command Line Interface (CLI), integracions de chatops, totes recolzades en la mateixa API i el mateix model d’accés, amb l’estat presentat a l’audiència que ha iniciat l’acció.

3. Connectar la plataforma bidirectionalment als sistemes externs i lliurar resultats de tornada a través dels canals que els consumidors ja fan servir. L’equip d’aplicacions ja treballa a ServiceNow. La pipeline de CI/CD ja s’executa en un sistema de control de versions. La plataforma hauria de trobar-los on ja estan: rebent sol·licituds dels seus sistemes i enviant resultats de tornada a aquells mateixos sistemes, sense requerir una nova eina en el seu flux de treball.

8.1.3. Pilars#

Tres pilars suporten aquests objectius, un per funcionalitat:

1. Capa API: la base: contractes versionats, autenticats, amb RBAC aplicat i estables. L’autenticació i la multitenència s’apliquen aquí, no per eina. Tota altra superfície es construeix al damunt.
2. Interfícies de client: totes les superfícies orientades al consumidor (portals GUI, CLI, mòbil, chatops) com a formats diferents de la mateixa API subjacent.
3. Integracions i notificacions: connexions a sistemes externs (ITSM, pipelines de CI/CD, sistemes de missatgeria) i lliurament de resultats sortints (webhooks, callbacks, notificacions push).

8.1.4. Abast#

La capa de Presentació presenta. No produeix.

Dins de l’abast:

• La capa API: autenticació, autorització, versionat i limitació de taxes per a tots els consumidors
• Interfícies de client construïdes sobre aquesta API: portals GUI, CLI, chatops, superfícies mòbils
• Integracions externes: fluxos de treball ITSM, hooks de pipeline CI/CD, lliurament de webhooks
• Notificacions sortints: callbacks d’estat, alertes push, events de canals de missatgeria
• Panells operatius quan es presenten a audiències no-enginyers (control d’accés, àmbit d’audiència i inclusió en portals; l’arquitectura mètrica subjacent pertany al Capítol 6)

Fora de l’abast:

• Producció de dades (Observability, Capítol 6)
• Renderització de configuració i processament de plantilles (Font de Veritat, Capítol 4)
• Execució de fluxos de treball i producció de registres d’auditoria (Orchestrator, Capítol 7)

8.2. Funcionalitats#

Els tres objectius i pilars es realitzen a través de tres funcionalitats bàsiques, cadascuna associada directament a un objectiu i un pilar:

1. Capa API: el contracte i el model d’accés per a tots els consumidors
2. Interfícies de Client: les superfícies construïdes al damunt d’aquell contracte
3. Integracions i Notificacions: les connexions als sistemes externs i el lliurament sortint

graph LR

    subgraph Goals["Objectius"]
        direction TB
        A1[API autenticada estable i model d'accés consistent]
        A2[Interfície adequada per a cada tipus de consumidor]
        A3[Integració bidireccional amb sistemes externs]
    end

    subgraph Pillars["Pilars"]
        direction TB
        B1[Capa API: versionada, autenticada, estable]
        B2[Interfícies de client: GUI, CLI, chatops, mòbil]
        B3[Integracions i notificacions: ITSM, CI/CD, webhooks]
    end

    subgraph Functionalities["Funcionalitats"]
        direction TB
        C1[Capa API]
        C2[Interfícies de Client]
        C3[Integracions i Notificacions]
    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 API#

El Capítol 4 va cobrir en profunditat la pròpia API del SoT: com els sistemes d’automatització consulten les dades d’intenció, els patrons de consum (REST, GraphQL, webhooks) i el model de lectura/escriptura per a la configuració de xarxa. L’API que es discuteix aquí és diferent en propòsit: és el contracte orientat cap enfora per als consumidors de la plataforma d’automatització com un tot. On l’API del SoT respon “com hauria de semblar la xarxa?”, l’API de la capa de Presentació respon “qué fa la plataforma d’automatització, i com interactueu amb ella?” Totes dues poden ser APIs REST; serveixen audiències diferents amb models d’accés diferents.

L’API de la capa de Presentació és la base. Tota superfície de consumidor (portal, CLI, formulari ITSM, bot de chatops, agent d’IA) és un client d’aquesta capa. L’autenticació, el RBAC, el versionat i la limitació de taxes s’apliquen aquí. Dissenyeu-la bé o tot el que hi ha al damunt heretarà els seus problemes.

L’API de Presentació no hauria de reflectir les interfícies internes dels blocs. Exposar un endpoint /v1/sot/vlans/ que fa de proxy directament a l’API del SoT, o un endpoint /v1/orchestrator/jobs/ que embolcalla els IDs de job de l’Orquestrador, lliga els consumidors als detalls d’implementació interns. Quan substituïu un bloc per un altre, cada pipeline de CI/CD que ha emmagatzemat aquells IDs s’ha d’actualitzar. L’API de Presentació hauria d’exposar conceptes a nivell de plataforma: un endpoint /v1/requests/ que representa una sol·licitud de servei independentment de quin Orquestrador l’ha processat, un endpoint /v1/services/vlan/ que retorna l’estat actual d’una VLAN agregat del SoT i l’Observabilitat sense revelar quin bloc ha proporcionat cada peça de dades. Els consumidors obtenen un contracte estable; la implementació interna pot evolucionar lliurement darrere d’ell.

8.2.1.1. El que exposa l’API#

L’API exposa dues categories d’endpoints:

• Endpoints de lectura: estat i historial de fluxos de treball, registres d’auditoria, estat de dispositius i serveis agregat dels blocs SoT i Observabilitat. Aquestes són les consultes que l’equip d’aplicacions usa per comprovar l’estat de la sol·licitud, l’auditor usa per revisar un registre de canvis i el sistema de monitoratge usa per verificar la salut de la plataforma.

• Endpoints d’escriptura: activar un flux de treball, enviar una sol·licitud de servei, aprovar o rebutjar una porta pendent, cancel·lar un job en execució. Els endpoints d’escriptura requereixen una autorització més forta. Els rols diferents haurien de tenir accés a operacions d’escriptura diferents: un membre de l’equip d’aplicacions pot enviar una sol·licitud però no pot activar fluxos de treball arbitraris; un enginyer de xarxa pot aprovar una porta pendent però no pot modificar les definicions de fluxos de treball.

La distinció lectura/escriptura també conforma l’estabilitat del contracte. Els endpoints de lectura han de romandre estables indefinidament: un panell que s’executa durant un any no hauria de trencar-se perquè un esquema aigües amunt ha canviat. Els endpoints d’escriptura s’han de versionar explícitament, amb avisos de deprecació abans dels canvis trencadors.

8.2.1.2. Versionat i estabilitat#

Les APIs orientades al consumidor han d’estar versionades. L’API de la capa de Presentació és el contracte; els interns dels blocs són la implementació. La refactorització interna de l’Orquestrador, el SoT o els blocs d’Observabilitat no ha de trencar els clients externs.

L’enfocament estàndard: versionar per prefix d’URL (/v1/, /v2/) o per capçalera Accept, mantenir la versió anterior durant una finestra de deprecació definida i comunicar els canvis trencadors a través d’un registre de canvis. Una pipeline de CI/CD que ha estat cridant /v1/workflows/trigger durant vuit mesos no hauria de descobrir un dilluns que l’endpoint s’ha mogut sense avís.

8.2.1.3. Autenticació i autorització#

L’autenticació respon: qui sou? L’autorització respon: qué teniu permís de fer?

Molts equips implementen l’autenticació abans de l’autorització, i llavors descobreixen que “autenticat” i “autoritzat” són problemes diferents quan algú envia quaranta-set sol·licituds sota un token vàlid que no hauria de tenir.

Patrons d’autenticació per a plataformes d’automatització de xarxes:

• Integració SSO / LDAP: l’estàndard empresarial. Els enginyers i els equips d’aplicacions s’autentiquen amb la seva identitat corporativa. No hi ha credencials separades per gestionar, i la desprovisió és automàtica quan algú se’n va.
• OAuth 2.0 / OIDC: per a sistemes externs i usuaris de portals web. Produeix tokens de curta durada en lloc de credencials de llarga durada.
• Tokens API amb àmbit: per a l’accés programàtic per part de pipelines de CI/CD i scripts d’automatització. Cada token té un àmbit a un conjunt específic de permisos amb una expiració definida. Un token d’administrador compartit usat per tots els consumidors no és autenticació: és una contrasenya compartida que no es pot revocar sense trencar tots els clients simultàniament.

Autorització a través de RBAC. Els rols haurien d’associar-se a les responsabilitats operatives, no a les capacitats de les eines. Un model de partida per a l’automatització de xarxes:

• read-only: veure qualsevol dada, no activar cap acció
• operator: activar fluxos de treball preaprovats, aprovar portes, enviar sol·licituds de servei
• engineer: gestió completa de fluxos de treball, accés d’escriptura al SoT, veure tots els registres d’auditoria
• admin: configuració de la plataforma, gestió d’usuaris, rotació de credencials

Cada rol hereta tots els permisos del rol inferior. Un enginyer pot fer tot el que pot un operador, a més d’escriure al SoT i gestionar els fluxos de treball.

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

    RO -->|afegeix: activar fluxos de treball + aprovar portes| OP
    OP -->|afegeix: accés escriptura SoT + gestió de fluxos| ENG
    ENG -->|afegeix: configuració plataforma + gestió usuaris| 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 s’aplica al límit de l’API. Els blocs subjacents veuen únicament crides API autenticades de la capa de Presentació; no gestionen la identitat del consumidor de manera independent. La multitenència s’implementa a través de l’àmbit de les dades: cada consulta es filtra per l’àmbit organitzatiu del qui fa la crida. L’equip d’aplicacions de l’Edifici B no hauria de veure les sol·licituds de l’equip de vendes al minorista de l’Edifici A. Això s’ha de dissenyar des del principi. Implementar la multitenència retroactivament en un model de dades pla és un projecte de reestructuració dolorós.

8.2.1.4. Limitació de taxes#

Els consumidors automatitzats sense limitació de taxes exhauriran la cua de l’Orquestrador. L’incident de les quaranta-set sol·licituds no requeria un actor maliciós: només un equip motivat, una URL i cap accelerador.

Limitació de taxes al límit de l’API: límits per token (sol·licituds per minut per consumidor), límits de ràfega (sol·licituds en vol simultànies) i límits específics d’operació (un flux de treball d’actualització de firmware mai hauria d’executar més d’una instància per dispositiu alhora). Les respostes de limitació de taxes haurien de retornar HTTP 429 amb una capçalera Retry-After, no un emplenament silenciós de la cua que apareix com un timeout hores més tard.

8.2.1.5. REST, GraphQL i la interfície MCP#

REST és el predeterminat. És més simple de versionar, raonar i emmagatzemar en memòria cau que GraphQL. Els equips d’automatització de xarxes rarament necessiten la flexibilitat de consulta impulsada pel consumidor de GraphQL i paguen un cost operatiu significatiu per la complexitat addicional. L’excepció: si la plataforma serveix un gran nombre de tipus de consumidors diferents amb patrons de consulta significativament diferents, GraphQL pot reduir l’excés de recollida i la necessitat de múltiples endpoints especialitzats. És una elecció justificada; rarament és la primera elecció correcta.

La interfície Model Context Protocol (MCP) és la superfície d’IA de la capa de Presentació. Igual que els operadors humans accedeixen a la plataforma via CLI i els equips d’aplicacions via portal, els agents basats en Large Language Model (LLM) hi accedeixen via un servidor MCP. L’agent crida eines (consultar l’estat del flux de treball, activar una remediació, llegir el registre d’auditoria) en qualsevol seqüència que requereixi el seu raonament, subjecte al mateix model RBAC que qualsevol altre client. Això es connecta directament al patró d’orquestració agèntica introduït al Capítol 7 (secció 7.2.7): el servidor MCP de la capa de Presentació és la interfície que fa operables aquells patrons a tota la plataforma sense integracions codificades entre l’agent i cada bloc individual.

REST i MCP difereixen en qui condueix la interacció. En una integració REST, el consumidor sap d’avançada quins endpoints cridar i en quin ordre: una pipeline de CI/CD crida POST /v1/requests/vlan, llavors consulta GET /v1/requests/{id} fins a la compleció. La seqüència és fixa en el codi. Amb MCP, un agent basat en Large Language Model (LLM) decideix en temps d’execució quines eines invocar i en quin ordre, basant-se en el resultat de cada crida precedent. El consumidor no és una pipeline amb un graf de crides predeterminat; és un sistema de raonament que llegeix cada resultat abans de decidir qué fer a continuació. El servidor MCP defineix les eines disponibles i els seus esquemes; l’agent decideix com usar-les. Això fa que MCP sigui adequat per a consultes operatives obertes (“investiga el problema de connectivitat entre l’edifici B i el core”) que requeririen que un desenvolupador anticipés cada possible seqüència de crides si s’implementés com a REST. També fa que l’autorització sigui més sensible: un agent amb accés ampli a les eines pot combinar operacions de maneres per a les quals el model d’accés no ha estat dissenyat explícitament. El model RBAC s’ha d’aplicar al nivell d’eina, no només al nivell del servidor.

8.2.2. Interfícies de Client#

Les interfícies de client són les superfícies construïdes al damunt de l’API. Són formats diferents de la mateixa plataforma subjacent, cadascun adequat per a un tipus de consumidor diferent. El model RBAC s’aplica uniformement independentment de la superfície usada.

8.2.2.1. Portal GUI i d’autoservei#

El portal web és la interfície principal per als no-enginyers. El seu principi de disseny és la divulgació progressiva: mostrar la quantitat correcta d’informació a l’audiència correcta sense exposar la complexitat subjacent.

L’equip d’aplicacions veu una vista de tres passos: enviada, en progrés, completada, amb un detall d’estat que diu “pre-comprovacions executant-se en 24 switches” en llenguatge planer, no IDs de job d’AWX. L’enginyer de xarxa veu els resultats de la pre-comprovació per dispositiu, la porta d’aprovació amb una acció d’aprovar o rebutjar i el rastre complet del flux de treball si és necessari. L’administrador veu-ho tot, incloent la configuració i les consultes d’auditoria.

Les interfícies de lectura i escriptura tenen requisits de disseny diferents. Un panell d’estat de només lectura pot ser relativament permissiu: qualsevol enginyer de la plataforma pot veure l’estat actual de les seves sol·licituds. El camí d’escriptura (enviar una sol·licitud, aprovar una porta, cancel·lar un job en execució) necessita validació d’entrada, un pas de confirmació i una declaració clara del que passarà abans de confirmar l’acció.

He vist equips construir portals on el botó d’enviar en un formulari de nova sol·licitud de servei crida directament l’API de l’Orquestrador, sense cap capa de validació entre el formulari i el flux de treball. Quan un usuari envia una subxarxa que entra en conflicte amb una assignació existent, l’error torna com una traça d’error no formatada de l’Orquestrador. La capa de Presentació hauria de validar les entrades contra el model del SoT abans que la sol·licitud arribi a l’Orquestrador, i retornar un error clar i accionable quan la validació falla.

El risc d’adopció és màxim a la interfície. Un portal tècnicament correcte que ningú usa perquè no s’adapta a com ja treballa l’equip aporta menys valor que una integració més simple a l’eina que tothom obre cada matí. L’equip d’aplicacions que ja viu a ServiceNow enviarà sol·licituds de manera més consistent a través d’un formulari de ServiceNow que a través d’un portal nou que han d’aprendre i en el qual han d’iniciar sessió per separat. L’equip d’enginyeria que ja usa Slack per a la coordinació d’incidents actuarà sobre les notificacions de la porta d’aprovació més ràpidament a través d’un missatge de Slack que a través d’un enllaç del navegador que requereix autenticació addicional. La familiaritat redueix la fricció en l’adopció i redueix les taxes d’error en l’ús diari. Quan hi ha una opció entre construir una nova superfície i trobar els usuaris a l’eina que ja coneixen, la integració gairebé sempre és el primer pas correcte.

8.2.2.2. CLI#

La CLI per a la plataforma d’automatització no és la CLI del dispositiu, que és el domini del Capítol 9. Aquesta és una interfície de línia de comandes per a la pròpia plataforma: una eina que els enginyers usen per activar, inspeccionar i gestionar l’automatització sense obrir un navegador.

Els enginyers prefereixen la CLI per la mateixa raó que prefereixen els scripts de shell als GUI per a la feina repetitiva: composabilitat, velocitat i scriptabilitat. Una comanda de CLI es pot afegir àlies, redirigir-se a altres comandes, iterar sobre una llista de dispositius, incorporar-se a un runbook o confirmar-se a un repositori al costat de la infraestructura que gestiona. Un clic al portal no pot. Durant un incident a les 2 de la matinada, una comanda escrita de memòria en cinc segons és més ràpida que un portal que triga vint segons a navegar i autenticar-se. Per a les pipelines de CI/CD, una CLI produeix codis de sortida estructurats (0 per a l’èxit, no zero per a la fallada) que s’associen directament a les condicions de pas/fallada de la pipeline sense cap anàlisi. Els enginyers també confien més en les eines CLI per a les operacions d’alt risc: els paràmetres són visibles a l’historial del shell, auditables i reproduïbles.

La CLI guanya el seu lloc fins i tot quan existeix un portal. Durant un incident a les 2 de la matinada, obrir un navegador, iniciar sessió, navegar a un flux de treball i fer clic a través d’un formulari és més lent que executar una única comanda. Per a les pipelines de CI/CD, una CLI és preferible a les crides API en brut: gestiona l’autenticació des de les variables d’entorn, produeix codis de sortida estructurats i dona una sortida llegible per a humans quan alguna cosa falla.

Principis de disseny per a una CLI de plataforma d’automatització:

• Estructura de comandes substantiu-verb consistent (workflow run, workflow status, request list) que s’associa de manera predictible a les operacions de l’API
• Sortida llegible per màquina via un indicador --json perquè els scripts de pipeline puguin analitzar el resultat
• Configuració conscient de l’entorn: l’endpoint de l’API i el token es llegeixen d’un fitxer de configuració o de variables d’entorn, no codificats en dur en els scripts
• El mateix RBAC que s’aplica a l’API s’aplica a la CLI: un token amb permisos de nivell operador no pot activar operacions de nivell administrador independentment de quina superfície s’usa

8.2.2.3. Missatgeria instantània i mòbil#

Slack, Teams i plataformes similars serveixen un doble paper en l’automatització de xarxes: tant com a canal de notificació (la capa de Presentació hi envia events) com a superfície d’interacció (els enginyers hi envien comandes). Entendre aquest doble paper importa per a l’arquitectura: el mateix espai de treball que rep notificacions d’alertes hauria de suportar fluxos d’aprovació, reduint el canvi de context per als enginyers que ja monitoritzen aquells canals.

Com a superfície d’interacció, les plataformes de missatgeria funcionen a través de bots que tradueixen les comandes conversacionals en crides API. El bot és lleuger: analitza el missatge, l’associa a una crida de l’API de la capa de Presentació sota la identitat del remitent i formata la resposta per al canal. Tres patrons funcionen bé a la pràctica:

• Fluxos d’aprovació: un missatge de Slack amb botons “Aprovar” i “Rebutjar” permet a un enginyer de xarxa actuar sobre una porta pendent sense sortir de Slack. El clic del botó crida l’endpoint d’aprovació de l’API amb la identitat de l’enginyer, resolta a través de la integració SSO de la plataforma amb l’OAuth de Slack.
• Consultes d’estat: @netbot status app-payments retorna l’estat actual del flux de treball en un missatge formatat al canal.
• Accions ràpides: @netbot compliance-check building-b activa un flux de treball de verificació lleuger i publica el resultat de manera integrada.

Les interfícies mòbils serveixen una audiència específica que els portals i la CLI no arriben: tècnics de centres de dades que treballen físicament al camp. Un tècnic que substitueix una tarja de línia en un rack no té un portàtil obert. Les seves mans poden estar ocupades, la seva posició incòmoda. Una aplicació mòbil que els permeti escanejar un codi de barres del dispositiu, veure el seu estat actual d’automatització (gestionat per l’automatització, últim desplegament fa 14 dies, sense canvis pendents), confirmar un reemplaçament físic i activar el flux de treball de remediació adequat connecta la feina física a la plataforma d’automatització sense tornar a una estació de treball. El model RBAC s’aplica: el token del tècnic té un àmbit a les operacions que el seu rol permet. La interfície té un àmbit a les dades rellevants per al camp: identitat del dispositiu, estat actual, tasques pendents i accions d’activació simples, no la vista completa de la plataforma.

El mateix model RBAC s’aplica. El bot autentica els enginyers a través de SSO i reenvia les sol·licituds amb un token amb àmbit al rol d’aquell enginyer. Un enginyer amb accés de només lectura no pot activar un flux de treball a través de Slack més del que pot a través del portal.

Com a objectiu de notificació, els canals de missatgeria reben actualitzacions impulsades per events de la capa de Presentació: finalitzacions de desplegament, alertes de fallada, sol·licituds de porta d’aprovació i errors crítics de flux de treball. L’enrutament de notificacions és una política de configuració: quins events van a quins canals per a quines audiències. Els enginyers reben els detalls de les fallades en un canal d’operacions dedicat. Els equips d’aplicacions reben l’estat de la compleció a través del tiquet ITSM. Els enginyers de guàrdia reben les fallades crítiques via PagerDuty.

Les interfícies mòbils segueixen el mateix patró. La restricció és l’espai de pantalla i el model d’interacció, no l’arquitectura. Una interfície d’aprovació mòbil que permet a un enginyer aprovar una porta pendent des del seu telèfon crida la mateixa API que el portal. El model RBAC no canvia.

8.2.2.4. Quan construir vs. acceptar les interfícies integrades#

Gairebé cada bloc ja té una interfície d’usuari. AWX té un portal de flux de treball. Nautobot té una interfície web. Grafana té panells. Aquestes interfícies integrades són suficients per a les audiències d’enginyeria que entenen la plataforma. La decisió de construir una capa de Presentació dedicada no hauria de ser el predeterminat.

Una seqüència de decisió pràctica:

1. Tots els consumidors són enginyers que ja usen les interfícies integrades dels blocs? Useu les interfícies integrades. No construïu un portal personalitzat.
2. Els no-enginyers necessiten sol·licitar o fer el seguiment de l’automatització? Necessiteu un portal o una integració ITSM.
3. L’ITSM ja és on es gestionen totes les sol·licituds de servei? O bé adopteu l’ITSM com a capa de Presentació, o bé integreu-vos-hi com a consumidor principal. Si el motor de flux de treball, el model d’aprovació i el sistema de notificació de l’ITSM són suficients per als vostres patrons de sol·licituds, deixeu que l’ITSM sigui directament la capa de Presentació: les crides d’automatització s’originen dins dels fluxos de treball de l’ITSM, no d’una capa separada al damunt. Si necessiteu un contracte d’API més capaç, vistes d’estat entre blocs o RBAC que l’ITSM no pot aplicar de manera neta, una capa dedicada i lleugera entre l’ITSM i els blocs us dona aquelles propietats mentre l’ITSM continua sent la superfície orientada a l’usuari.
4. Necessiteu RBAC que abasti múltiples blocs de manera uniforme? Necessiteu una capa API amb autenticació centralitzada, independentment de quines superfícies de client construïu al damunt.
5. Podeu comprometre’s a mantenir un portal personalitzat a llarg termini? Si no n’esteu segurs, comenceu amb la integració ITSM. Construïu un portal només quan l’ITSM resulta insuficient per als patrons d’accés que necessiteu.
6. Els consumidors necessiten introduir o veure detalls que els formularis ITSM no poden representar? Els camps d’entrada complexos (fragments YAML, paràmetres de topologia, previsualitzacions d’assignació de subxarxa), la validació en línia contra el model del SoT o les vistes d’estat riques amb drill-down per dispositiu normalment superen el que els constructors de formularis ITSM poden suportar de manera neta. Si els consumidors necessiten regularment aquell nivell d’especificitat, un portal personalitzat justifica el seu cost operatiu.

El portal personalitzat val la pena construir-lo quan els no-enginyers necessiten accés que l’ITSM no pot expressar de manera neta, o quan necessiteu una vista d’estat entre blocs única que cap de les interfícies integrades proporciona. L’error més comú és construir-lo abans de validar que la necessitat és real.

8.2.2.5. Documentació i informes#

Dues sortides de només lectura relacionades de la capa de Presentació serveixen a audiències que consumeixen el coneixement d’automatització de manera asíncrona: consumidors de documentació (equips que necessiten entendre l’estat actual dels serveis de xarxa) i consumidors d’informes (gestors i auditors que necessiten resums periòdics i evidències de compliment).

El patró de documentació com a codi s’aplica aquí: documentació generada a partir de dades de la plataforma en viu usant llenguatges de plantilles (Jinja2, Markdown), versionada al costat de la base de codi d’automatització i regenerada a cada canvi. Els diagrames Mermaid integrats en documents generats poden reflectir la topologia real del SoT en lloc de dibuixos mantinguts manualment. De manera similar, la lògica de normalització que el bloc d’Observabilitat aplica a les mètriques en brut (coberta al Capítol 6) es pot reutilitzar aquí: una plantilla d’informe consulta les mateixes dades de sèries temporals normalitzades per produir resums tabulars per als auditors, sense duplicar el treball de normalització.

• Documentació autogenerada converteix les dades de la plataforma en viu en artefactes llegibles i compartibles sense manteniment manual. Per a cada servei de xarxa desplegat, un document generat pot combinar la definició del servei del SoT, l’estat operatiu actual de l’Observabilitat i l’historial de canvis del rastre d’auditoria de l’Orquestrador. Com que les dades font sempre són actuals, la documentació es manté actualitzada automàticament. Les definicions de fluxos de treball a l’Orquestrador són una altra font: un generador de documentació pot produir un runbook llegible per a humans a partir d’una definició de flux de treball, assegurant que el que descriu el runbook coincideixi amb el que realment fa l’automatització.

• Els informes serveixen a les audiències de gestió i compliment que necessiten resums periòdics en lloc de vistes en temps real. Els resums de canvis setmanals (quants fluxos de treball s’han executat, taxa d’èxit, durada mitjana, dispositius tocats) alimenten les revisions operatives. Les exportacions de compliment (tots els registres de canvis d’un període, estructurats per a la presentació d’auditoria) s’assemblen del rastre d’auditoria de l’Orquestrador i del registre d’autorització de la capa de Presentació. Els informes de SLA i capacitat (tendències de temps-de-provisió, taxes d’error per classe de dispositiu, cartera de sol·licituds pendents) alimenten la planificació de capacitat i les discussions de millora del servei.

Els panells operatius abracen ambdós capítols per intenció de disseny. El Capítol 6 cobreix l’arquitectura de dades: qué es recull, com es normalitza i els panells construïts directament sobre la telemetria per a les audiències d’enginyeria. La implicació de la capa de Presentació comença quan aquells mateixos panells es presenten a audiències no d’enginyeria: integrant-los en un portal d’autoservei, limitant l’accés perquè els equips d’aplicacions vegin només els seus serveis o estructurant vistes adaptades per a mòbil per a l’ús al camp. Les mètriques subjacents romanen al bloc d’Observabilitat; el model d’accés i el context de la superfície són preocupacions de Presentació.

La distinció dels panells operatius (Capítol 6) és el consumidor i el marc temporal: els panells mostren l’estat actual per als enginyers que prenen decisions en temps real; la documentació i els informes són instantànies consumides de manera asíncrona pels no-enginyers. Les dades subjacents poden ser les mateixes. La superfície i la cadència són diferents.

8.2.3. Integracions i Notificacions#

La capa de Presentació es connecta als sistemes externs en ambdues direccions: rebent events que activen l’automatització i lliurant resultats de tornada als sistemes que han iniciat les sol·licituds. Aquí és on el flux de treball del consumidor i el flux de treball de la plataforma convergeixen.

La distinció de la capa API és la direccionalitat i la iniciació. La capa API gestiona les sol·licituds entrants: un consumidor crida la plataforma i espera una resposta. Les integracions i les notificacions tracten de la plataforma que s’adreça als sistemes que no han iniciat la interacció actual: enviar una actualització d’estat a un tiquet de ServiceNow, lliurar un callback de webhook a una pipeline de CI/CD que espera de manera asíncrona, publicar un event a un canal de Slack que monitoritza un servei específic. La capa API respon crides. Aquesta secció envia events. Tots dos usen el mateix model d’autenticació i límits RBAC; la diferència és la direcció de la iniciació. A petita escala, un únic component gestiona els dos patrons de manera neta. A una escala més gran, el lliurament d’events sortints (amb la seva lògica de reintent, cues de missatges morts i gestió de subscripcions) es converteix normalment en un component diferent amb les seves pròpies preocupacions operatives, que és per qué aquest model separa els dos com a funcionalitats diferenciades.

8.2.3.1. Integració ITSM#

Les plataformes ITSM ocupen dues posicions diferenciades en una arquitectura d’automatització de xarxes, i la distinció importa per al disseny. A la primera posició, la plataforma ITSM és la capa de Presentació: els seus formularis defineixen la interfície d’usuari, el seu motor de flux de treball gestiona les aprovacions i notificacions, i l’API d’automatització es crida des de dins dels fluxos de treball de l’ITSM. En aquest model no hi ha integració externa perquè l’ITSM no és extern a la capa de Presentació: és la capa de Presentació. A la segona posició, existeix una capa de Presentació dedicada i la plataforma ITSM és un dels consumidors amb els quals se sincronitza: les sol·licituds arriben via webhooks ITSM i les actualitzacions d’estat flueixen de tornada als tiquets ITSM. Un tercer rol també és comú: l’ITSM com a font de dades SoT. Quan el CMDB conté registres d’actius o serveis autoritzats, el SoT pot consultar-lo com a font de dades federada (coberta al Capítol 4), però l’ITSM en aquest rol no té cap paper a la interfície d’automatització orientada a l’usuari.

La resta d’aquesta secció descriu el patró d’integració (segona posició). El patró ITSM-com-a-capa-de-Presentació (primera posició) és l’elecció correcta quan el motor de flux de treball, el model d’aprovació i el sistema de notificació de la plataforma ITSM són suficients per als vostres patrons de sol·licituds i voleu evitar introduir una capa separada entre els usuaris i els blocs.

La integració ITSM és el que construïu quan els consumidors no haurien de necessitar saber que la plataforma d’automatització existeix. L’equip d’aplicacions ja treballa a ServiceNow. La interfície més usable és la que ja estan usant.

Un formulari de ServiceNow per a “Nova Sol·licitud de Servei de Xarxa” captura exactament els camps que el model del SoT necessita i els envia en el format estructurat que espera la capa API. El formulari és la capa de Presentació; el consumidor mai veu la crida API. En l’enviament, la capa de Presentació valida el payload contra el model de dades del SoT, autentica el token del compte de servei que usa la integració ITSM i reenvia la sol·licitud estructurada a l’Orquestrador.

Després que la sol·licitud s’activi, el tiquet hauria de reflectir l’estat del flux de treball en temps quasi real: “Validació del SoT completada”, llavors “Pre-comprovacions en execució: 24 switches”, llavors “Porta d’aprovació: pendent de confirmació de l’enginyer”, llavors “Completat: 24/24 switches configurats”. Aquesta sincronització bidireccional és més complexa que un webhook d’un sol ús. Requereix que la capa de Presentació se subscrigui als events d’estat de l’Orquestrador i els tradueixi en actualitzacions de tiquets usant una subscripció d’events persistent o un reconciliador de polling.

La integració ITSM té límits. És adequada per a fluxos de treball de sol·licituds estructurades i impulsades per formularis amb estats definits. No és adequada per a consultes operatives en temps real, inspecció de rastres de fluxos de treball complexos o operacions d’usuari avançat on els enginyers necessiten iterar ràpidament. Dissenyeu la plataforma sabent que l’ITSM cobreix la majoria de les sol·licituds de no-enginyers i una CLI o portal cobreix la resta.

8.2.3.2. Integració de pipelines CI/CD#

Una pipeline de desplegament que aprovisiona recursos de xarxa crida l’API de la capa de Presentació en un pas definit, passa les entrades estructurades i es bloqueja fins que es retorna un resultat d’èxit o fallada. La pipeline s’executa sota un compte de servei amb un token amb àmbit: permisos suficients per activar el flux de treball de xarxa i llegir el seu estat, res més.

Aquí és també on la CLI guanya el seu lloc en contextos automatitzats. Un pas de pipeline que executa netauto workflow run vlan-deploy --params params.json --wait és més fàcil de depurar, versionar i substituir que una crida HTTP en brut que construeix el payload de l’API de manera integrada. El codi de sortida estructurat de la CLI s’associa directament a la condició de pas o fallada del pas de la pipeline.

8.2.3.3. Notificacions push i lliurament de webhooks#

Quan un flux de treball es completa, arriba a una porta d’aprovació o falla, la capa de Presentació notifica l’audiència adequada a través del canal correcte. L’enrutament de notificacions és una decisió de política, no una associació codificada en dur. Els enginyers reben els detalls de les fallades en un canal de Slack dedicat. Els equips d’aplicacions reben l’estat de la compleció via actualització del tiquet. Els enginyers de guàrdia reben les fallades crítiques via PagerDuty. Les regles d’enrutament són configuració, no codi.

El lliurament de webhooks és la contrapart sortint dels webhooks entrants. Un client que ha registrat una URL de callback quan activava un flux de treball rep el resultat via HTTP POST quan el flux de treball es completa. Les garanties de lliurament, la política de reintent en cas de fallada i l’esquema del payload formen part del contracte de l’API. Un callback que falla silenciosament (sense reintent, sense registre, sense alerta) és pitjor que cap callback, perquè el client assumeix que el resultat ha estat lliurat.

8.2.4. Panorama de Solucions#

El capítol de Presentació té una relació diferent amb el panorama de solucions que qualsevol altre capítol de la Part 2. Gairebé no hi ha eines que existeixin exclusivament com a Presentació. Cada bloc ja té una interfície d’usuari. La pregunta arquitectònica no és “quina eina de Presentació hauria d’usar?” És: quan accepto les interfícies integrades de cada bloc, i quan construeixo una capa de Presentació dedicada al damunt?

Dos models coexisteixen en les plataformes d’automatització madures.

• Model integrat: useu la interfície integrada de cada bloc per a la seva audiència. Els enginyers usen el portal de l’orquestrador per a la gestió de fluxos de treball, la interfície web del SoT per a l’inventari, els panells d’observabilitat per a la salut de la xarxa. Funciona quan tots els consumidors són enginyers que entenen les eines i quan no es necessiten vistes entre blocs. La sobrecàrrega operativa és baixa: no cal executar sistemes addicionals.

• Model de Presentació dedicada: construïu o adopteu una capa al damunt dels blocs que proporcioni una experiència unificada. Necessari quan els no-enginyers necessiten accés, quan necessiteu l’estat entre blocs en una vista única o quan els requisits de RBAC no s’associen de manera neta als permisos integrats de les eines individuals.

Entendre qué hi ha dins de les interfícies integrades importa per a les decisions de personalització. NetBox està construït sobre Django (Python); la seva interfície web i l’API REST són vistes Django i endpoints de Django REST Framework. Nautobot comparteix el mateix llinatge. Infrahub usa FastAPI. El “component de Presentació” d’aquestes eines SoT és un marc web madur: personalitzable a través de connectors, vistes personalitzades i extensions de serialitzador. Això és alhora la seva fortalesa (ben documentat, de qualitat de producció) i la seva restricció (esteu personalitzant dins d’un marc dissenyat principalment per al cas d’ús del SoT, no per al cas d’ús del portal d’autoservei).

La fila ITSM a la taula anterior representa l’ITSM com a capa de Presentació, no com a integració externa. Quan una organització s’ha estandarditzat en ServiceNow o Jira Service Management com a punt d’entrada per a totes les sol·licituds de servei, l’ITSM és la capa de Presentació. L’API d’automatització és el que l’ITSM crida internament com a part dels seus propis fluxos de treball; cap passarel·la separada s’intercala entre l’usuari i l’ITSM. La passarel·la s’intercala entre l’ITSM i els blocs aigües avall.

Un principi arquitectònic que talla a través de tots els enfocaments: la capa de Presentació hauria de ser lleugera. És una superfície, no un sistema. La lògica de negoci pertany a l’Orquestrador i al SoT. La capa de Presentació tradueix, autentica i enruta. En el moment que comença a prendre decisions d’automatització, el límit ha col·lapsat.

8.3. Exemple d’Implementació#

8.3.1. Dues Superfícies, Tres Audiències, Una Plataforma#

Hem seguit la xarxa del campus a través de tota la Part 2. La sol·licitud de servei de VLAN per a app-payments es va modelar al SoT al Capítol 4, es va desplegar per l’Executor al Capítol 5, es va validar per l’Observabilitat al Capítol 6 i es va coordinar d’extrem a extrem per l’Orquestrador al Capítol 7. El que mai es va abordar és com tres audiències diferents interactuen amb aquell flux de treball.

En aquest campus, la capa de Presentació es compon de tres components. ServiceNow és la interfície principal per a l’organització en general: els equips d’aplicacions envien sol·licituds i fan el seguiment de l’estat completament dins de ServiceNow, que enruta a través de l’API de la capa de Presentació com a part de la seva pròpia automatització de flux de treball. Un portal personalitzat amb una vista d’auditoria serveix a les audiències d’enginyeria i compliment: els enginyers de xarxa revisen els resultats de la pre-comprovació i actuen sobre les portes d’aprovació allà, i els auditors de seguretat consulten els registres de canvis compostos a través de la seva interfície d’auditoria de només lectura. Ambdues superfícies comparteixen la mateixa capa API, que es troba dins de la pròpia capa de Presentació i aplica l’autenticació, el RBAC i el versionat abans que qualsevol sol·licitud arribi als blocs subjacents.

Les tres audiències

• L’equip d’aplicacions envia sol·licituds a través d’un formulari de ServiceNow. Volen saber quan el servei està llest i qué ha passat si ha fallat. Mai haurien de necessitar obrir AWX o Nautobot. ServiceNow és la seva capa de Presentació; l’API de la plataforma és alguna cosa que mai veuen.

• L’enginyer de xarxa va rebre una notificació de porta d’aprovació durant el flux de treball (Capítol 7, pas 3). Necessita veure els resultats de la pre-comprovació per als 24 switches objectiu, aprovar o rebutjar i poder inspeccionar el resultat. La seva interfície és el portal personalitzat: més detallat que el formulari de ServiceNow, però encara limitat a l’àmbit del seu equip.

• L’auditor de seguretat arriba tres mesos més tard amb una pregunta: qui va sol·licitar aquesta VLAN, qui la va aprovar, quina versió del flux de treball de desplegament es va executar i quin era l’estat abans i després dels switches afectats? La seva interfície és la vista d’auditoria del portal: de només lectura, sense la capacitat d’activar res.

Les dues superfícies de Presentació

La capa API és la base compartida dins de la capa de Presentació. Tant ServiceNow com el portal personalitzat enruten cada sol·licitud a través d’ella abans que res arribi als blocs subjacents. Aplica tres tokens basats en rols: el token d’operador de l’equip d’aplicacions (llegir les seves pròpies sol·licituds, enviar noves sol·licituds), el token d’enginyer de l’enginyer de xarxa (llegir totes les sol·licituds del seu àmbit, aprovar o rebutjar portes) i el token de només lectura de l’auditor (consultar els registres d’auditoria de tota la plataforma, sense accés d’escriptura). Cap superfície no el passa per alt.

flowchart TD
    subgraph Consumers["Consumidors"]
        AT[Equip d'Aplicacions]
        NE[Enginyer de Xarxa]
        SA[Auditor de Seguretat]
    end

    subgraph PL["Capa de Presentació"]
        SN[ServiceNow]
        PORTAL[Portal Personalitzat]
        API[Capa API: Autenticació · RBAC · Versionat]
    end

    subgraph Blocks["Blocs de Plataforma"]
        ORC[Orquestrador]
        SOT[Font de Veritat]
        OBS[Observabilitat]
    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

Pas 1: ServiceNow com a superfície de l’equip d’aplicacions

L’equip d’aplicacions omple un formulari de ServiceNow: nom del servei (app-payments), mida de la subxarxa (/24), edifici (building-b), equip sol·licitant i justificació de negoci. En l’enviament, ServiceNow crida la capa API de la plataforma directament com a part de la seva pròpia automatització de flux de treball. La capa API valida el payload contra el model de dades del SoT, autentica el token del compte de servei que usa ServiceNow i reenvia la sol·licitud estructurada a l’Orquestrador.

Si la validació falla (per exemple, l’edifici sol·licitat no coincideix amb cap lloc al SoT, o la mida de la subxarxa entra en conflicte amb una assignació existent), la capa API retorna immediatament un error estructurat, abans que s’iniciï cap flux de treball de l’Orquestrador. ServiceNow actualitza el tiquet amb una raó de fallada clara: “building-c no trobat al registre de llocs” o “la subxarxa /24 entra en conflicte amb l’assignació existent 10.22.14.0/24 a building-b”. L’equip d’aplicacions veu el rebuig al seu tiquet i pot corregir la sol·licitud sense implicar un enginyer de xarxa. No es crea cap estat parcial de flux de treball i no cal cap rollback Saga, perquè el flux de treball mai ha començat.

A mesura que el flux de treball avança, la capa de Presentació se subscriu als events d’estat de l’Orquestrador i els tradueix en actualitzacions de tiquets de ServiceNow: “Validació del SoT completada”, “Pre-comprovacions en execució: 24 switches”, “Porta d’aprovació: pendent de confirmació de l’enginyer”, “Completat: 24/24 switches configurats”. L’equip d’aplicacions veu el seu tiquet actualitzar-se sense saber que l’Orquestrador, el SoT o AWX existeixen.

Pas 2: La superfície de la porta d’aprovació

Quan el flux de treball arriba a la porta d’aprovació, l’Orquestrador es pausa i emet un event. La capa de Presentació el rep, identifica l’enginyer de xarxa responsable de l’Edifici B i envia una sol·licitud d’aprovació al seu canal de Slack amb un enllaç directe a la pàgina de revisió de la porta. La pàgina de revisió mostra els resultats de la pre-comprovació per switch: quins han passat, quins han fallat, quins han estat saltats i per qué. L’enginyer aprova o rebutja des del portal. L’acció es registra: qui ha aprovat, des de quina interfície, a quina hora, sota quin token.

Pas 3: La vista d’auditoria

Tres mesos més tard, l’auditor de seguretat consulta l’API de la capa de Presentació: “mostra’m el registre complet de canvis per a la VLAN app-payments, Edifici B”. L’endpoint d’auditoria de només lectura agrega tres fonts:

• El registre d’execució de l’Orquestrador (Capítol 7, secció 7.2.4): quina versió del flux de treball s’ha executat, cada entrada i sortida del pas, qualsevol acció de compensació Saga
• El registre de canvis del SoT (Capítol 4): l’estat abans i després de la definició de VLAN
• El propi registre d’autorització de la capa de Presentació: qui ha enviat la sol·licitud, quin token ha usat, qui ha aprovat la porta i quan

La resposta és un document estructurat que l’auditor pot adjuntar al registre de gestió de canvis. Cap dels tres blocs subjacents estava dissenyat per produir aquest registre compost de manera independent. La capa de Presentació l’ha assemblet des de les seves API individuals sota el token de només lectura de l’auditor.

El que demostra

El mateix flux de treball de deu passos del Capítol 7 ha servit tres audiències diferents a través de dues superfícies de Presentació sense que cap d’aquelles audiències hagi necessitat entendre la plataforma subjacent. ServiceNow ha servit l’organització en general: l’equip d’aplicacions ha fet el seguiment de la seva sol·licitud a través d’una eina que ja usa cada dia, sense saber que AWX, Nautobot o l’Orquestrador existien darrere d’ella. El portal personalitzat ha servit a les audiències d’enginyeria i compliment: l’enginyer de xarxa ha revisat una interfície d’aprovació neta limitada a les sol·licituds del seu equip, i l’auditor ha consultat un registre de canvis compost assemblet de tres blocs a través d’una única vista de només lectura. Una capa API, aplicant el mateix model d’accés per a ambdues superfícies, ha fet la plataforma accessible sense fer-la visible.

8.4. Resum#

La capa de Presentation (Layer) és l’últim bloc constructiu de la Part 2, i és el que és més probable que es tracti com a reflexió posterior. Els blocs per sota d’ella fan el treball substantiu: mantenir la intenció, aplicar canvis, validar resultats, coordinar fluxos de treball. La capa de Presentació no en produeix cap. Però sense ella, la plataforma només és accessible per a les persones que l’han construït, i tota altra audiència depèn d’un intermediari humà.

La capa API és la base. L’autenticació i l’autorització aplicades al límit de l’API (no per eina) és el que separa l’automatització accessible de l’automatització perillosa. El versionat i els contractes estables és el que separa una plataforma d’un prototip que trenca els seus clients en cada actualització. La interfície Model Context Protocol (MCP) estén el mateix model d’accés als agents basats en Large Language Model (LLM), fent la plataforma disponible per als patrons d’orquestració agèntica introduïts al Capítol 7 i desenvolupats més endavant al Capítol 17.

Les interfícies de client són formats diferents de la mateixa API subjacent. Un portal GUI amb divulgació progressiva serveix als no-enginyers que necessiten sol·licitar i fer el seguiment de l’automatització sense entendre la plataforma. Una CLI serveix als operadors que necessiten velocitat, scriptabilitat i integració amb CI/CD. Les superfícies de ChatOps i mòbil serveixen per als fluxos d’aprovació i les consultes d’incidents. La decisió sobre quines superfícies construir hauria de seguir una seqüència deliberada: comenceu amb les interfícies integrades dels blocs per a les audiències d’enginyeria, integreu-vos amb l’ITSM quan els no-enginyers necessitin sol·licitar automatització, construïu un portal personalitzat només quan l’ITSM resulti insuficient.

Les integracions i les notificacions tanquen el bucle que el contracte de resposta asíncrona del Capítol 7 ha obert. L’Orquestrador produeix un resultat del flux de treball; la capa de Presentació el lliura a l’audiència que ha activat l’acció a través del canal que ja usa. La sincronització ITSM bidireccional, els callbacks de webhook i les notificacions push no són funcionalitats de conveniència. Són el que fa que l’automatització sigui visible per a les persones que en depenen.

L’escenari del campus ha mostrat això a la pràctica: un flux de treball, tres audiències, dues superfícies de Presentació. ServiceNow ha servit l’organització en general com a la seva pròpia superfície de Presentació, cridant l’API de la plataforma directament i presentant l’estat a través d’actualitzacions de tiquets familiars. El portal personalitzat ha servit a les audiències d’enginyeria i compliment: l’enginyer de xarxa ha revisat una interfície d’aprovació neta limitada a les sol·licituds del seu equip, i l’auditor ha consultat un registre de canvis compost assemblet de l’Orquestrador, el SoT i el propi registre d’autorització de la capa de Presentació. La mateixa capa API ha aplicat el model d’accés per a totes dues. La plataforma ja no era invisible.

Amb la capa de Presentació al seu lloc, la Part 2 ha cobert tots els set blocs constructius del marc NAF. El proper capítol es dirigeix al bloc sobre el qual tota aquesta automatització actua en última instància: la pròpia Xarxa, coberta al Capítol 9.

💬 Found something to improve? Send feedback for this chapter