3. Pensament Arquitectònic#

Aquest capítol introdueix els fonaments d’aquest llibre. Explica per què necessites adoptar aquesta mentalitat, introdueix un marc de referència proposat pel Network Automation Forum (NAF), i mostra com aprofitar-lo en els teus projectes.

La Part 2 aprofundeix en aquests temes. En aquest capítol, simplement els presentarem per donar una visió d’alt nivell abans d’entrar en els detalls. Això importa perquè un cop descriguem cada bloc de construcció, tenir la imatge global t’ajuda a connectar els punts.

Però soc un ferm creient en entendre el PER QUÈ abans del QUÈ, així que primer entenguem les raons per aprofitar una arquitectura.

3.1. Per què importa una arquitectura de referència#

“Només els educats són lliures.” d’Epíctet

Una solució d’automatització de xarxes és una combinació de múltiples peces, cadascuna jugant un paper. En xarxes, estem acostumats a solucions simples o monolítiques que intenten comportar-se com caixes tot-en-un per resoldre tots els problemes. Això pot ser cert fins a cert punt, però res pot resoldre per si sol tots els desafiaments i casos d’ús tan diversos. Per tant, si el teu cas d’ús no és un dels més populars, pot ser que necessitis personalitzar o estendre.

Sense una arquitectura de referència clara, els equips sovint s’enfronten a un conjunt predictible de problemes:

• Esforç Duplicat: Múltiples equips construeixen eines similars (fonts de dades, scripts duplicats, sistemes de monitoratge redundants) de forma independent, malbaratant recursos i creant interfícies inconsistents.
• Bretxes d’Integració: Les eines no es comuniquen entre si de forma neta, cosa que obliga a costosos treballs d’integració personalitzats.
• Responsabilitats Poc Clares: No és clar quina eina hauria de gestionar l’observabilitat, l’orquestració o la gestió de l’estat, cosa que porta a confusió.
• Difícil d’Estendre: Afegir noves capacitats o eines requereix repensar tot el sistema.
• Sitges de Coneixement: Diferents equips usen diferents models mentals, cosa que dificulta incorporar noves persones o mantenir solucions.

Una arquitectura de referència resol aquests problemes proporcionant un únic model mental clar sobre com han d’organitzar-se els sistemes d’automatització. Defineix:

• Què ha de fer cada component -> les seves responsabilitats
• Com interactuen els components -> les seves interfícies i fluxos de dades
• On pots prendre decisions -> quines eines usar
• On necessites consistència -> com es comuniquen els components entre si

Una arquitectura de referència no és nova per als enginyers de xarxa. Tots hem crescut amb el nostre estimat model OSI. Usar el model OSI proporciona un enfocament per capes, pas a pas, per diagnosticar i comprendre els problemes de xarxa perquè cada capa té diferents responsabilitats i preocupacions. Els professionals de xarxes entenen intuïtivament que aquesta separació de responsabilitats fa que els sistemes complexos siguin manejables.

En l’automatització de xarxes, necessitem alguna cosa similar que pugui guiar com desenvolupar i interconnectar solucions que funcionin juntes. Ajuda els equips a prendre decisions consistents, reutilitzar components en projectes i evolucionar les seves capacitats d’automatització sense reinventar la roda cada vegada.

3.2. Una Arquitectura d’Automatització de Xarxes#

En conseqüència, necessitem una arquitectura. Però nota la ‘A’ en el títol de la secció: no hi ha només una arquitectura, n’hi ha moltes. Una arquitectura és simplement un marc de referència: una manera d’estructurar el pensament i guiar decisions consistents. He contribuït a tres iniciatives:

• Arquitectura de referència de Network to Code, un esforç col·lectiu liderat per l’equip d’Arquitectura de NTC (del qual vaig formar part durant quatre anys), dissenyat per suportar automatització de xarxes eficient i comprensible en una àmplia gamma de casos d’ús.
• Network Automation and Programmability 2nd Edition d’O’Reilly, un esforç per connectar els punts de tot el contingut del llibre amb els meus coautors: Matt Oswalt, Scott S. Lowe i Jason Edelman.
• Marc NAF va ser un projecte comunitari sota el paraigua del NAF liderat juntament amb Wim Henderickx, Dinesh Dutt, Claudia de Luna, Ryan Shaw i Damien Garros amb l’objectiu d’ajudar tant als nouvinguts com als professionals experimentats a construir solucions d’automatització de manera estructurada i repetible.

A través d’aquestes iteracions, em vaig centrar en mantenir la consistència i aprendre de cada evolució. Els tres enfocaments són útils. Tanmateix, proposo usar el NAF Framework com la millor pràctica actual: és impulsat per la comunitat, agnòstic al proveïdor i àmpliament aplicable. Consolida anys d’aprenentatge col·lectiu i és mantingut activament per una comunitat compromesa i en creixement.

Els tres són complementaris en lloc de competidors. Una breu comparació ajuda a aclarir quan és més rellevant cadascun:

El Marc NAF defineix els contractes entre blocs i deixa obertes les opcions d’implementació. L’arquitectura NTC omple aquestes opcions amb recomanacions específiques d’eines. Si el teu equip usa eines NTC, les dues s’apliquen simultàniament sense conflicte.

El NAF Framework proposa la següent arquitectura:

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

    space:7

    
    block:Observability:2
        columns 2
        ObservedState[("Estat Observat")]:1
        ObservedLogic["Lògica Observada"]:1
    end

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

	space
    
    block:Intent:2
        columns 2
        IntendedState[("Estat Previst")]:1
        IntendedLogic["Lògica Prevista"]:1
    end
    
    space:7

	space

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

Aquesta arquitectura conté els blocs següents, usant les definicions del document:

• Intent (Architectural Block): Defineix la lògica per gestionar i la capa de persistència per emmagatzemar el Desired State de la xarxa, incloent tant la configuració com les expectatives operacionals.
• Executor: Abasta les tasques reals aplicades a la xarxa per impulsar canvis (actualitzant la configuració) segons guia l’estat previst.
• Collector: En contrast amb l’Executor, aquest component se centra en recuperar (llegir) l’Actual State de la xarxa.
• Observability: Persisteix l’Actual State de la xarxa i defineix la lògica per processar-lo.
• Orchestrator: Defineix com es coordinen i executen les tasques d’automatització en resposta a esdeveniments.
• Presentation (Layer): Proporciona les interfícies a través de les quals els usuaris interactuen amb el sistema, incloent dashboards, interfícies gràfiques d’usuari (ITSM) i eines Command Line Interface (CLI).

Aquesta arquitectura no és arbitrària; és la conseqüència natural d’aplicar principis d’enginyeria de programari a les operacions de xarxa.

El marc NAF té com a objectiu ajudar els arquitectes d’automatització de xarxes a organitzar les seves solucions referenciant les funcionalitats de cada mòdul, i definint MUSTs, SHOULDs i MAYs (usant l’estil RFC). Llavors, pots decidir com implementar-los per resoldre els teus propis casos d’ús.

Tenir múltiples components no significa que hagis de triar una eina per component. En molts casos, podries usar una eina que implementa diferents funcionalitats, però això ve amb compromisos que has d’entendre (i reconèixer).

Ara, repassarem els diferents blocs per introduir-los.

3.2.1. Intenció o Font de Veritat#

La Intenció són totes les dades que defineixen tota la informació necessària per portar la teva xarxa de res a completament operativa, abastant tots els diferents estats del cicle de vida, des del pre-aprovisionament fins al bootstrap, fins a completament operativa, i la retirada final de tot tipus de serveis de xarxa.

L’arquitectura l’anomena Intenció, però la relaciono amb un altre terme popular: Font de Veritat (SoT). El terme SoT de vegades s’entén malament, i vull començar aclarint què és el SoT o la Intenció (els usaré indistintament al llarg del llibre).

Com pots imaginar, això podria representar dades molt diverses incloent dispositius, adreçament IP, infraestructura de centre de dades (bastidors, cables), protocols d’encaminament, serveis virtualitzats, secrets, límits operacionals, plantilles de configuració, i abstraccions de serveis o polítiques. Un aspecte clau és que aquestes dades han d’estar estructurades per ser enteses per màquines. Llavors, han de suportar operacions de crear, llegir, actualitzar i eliminar i ser accessibles a través d’una Application Programming Interface (API) estandarditzada i ben documentada com Representational State Transfer (REST) o GraphQL.

Per analogia amb la gestió manual de xarxes, això coincideix principalment amb el paper de l’arquitecte de xarxa que defineix el disseny, l’esquema de xarxa, o el planificador de xarxa que defineix la llista de materials per a un nou desplegament de xarxa.

Idealment, aquest component hauria de proporcionar una vista consistent i unificada de l’estat desitjat, fins i tot quan les dades estan distribuïdes en múltiples fonts de dades. Aquestes fonts de dades, que anomeno Sistemes de Registre (SoR), són els propietaris reals de les dades. Així que, això és una de les primeres coses a aclarir: és extremadament rar tenir només una font de dades, però les dades han de ser consistents quan es consoliden. La gestió de dades és un tema complex que requereix característiques de governança de dades, incloent alguna forma de metadades com marques de temps, origen de les dades, propietat de les dades i períodes vàlids, per facilitar la comprensió i gestió d’aquestes dades.

A més, connectat amb les característiques que permeten l’automatització de xarxes de confiança, aquest bloc hauria d’oferir accés transaccional i versionat a les dades que permet processos d’automatització de xarxes predictibles i fiables.

Si estàs intentant entendre quines eines reals podrien encaixar en aquesta categoria, aquí hi ha alguns exemples: fitxers CSV/YAML/JavaScript Object Notation (JSON), Git, NetBox, Nautobot, Infrahub, Infoblox, o qualsevol base de dades de propòsit general.

Consulta el Capítol 4 per a una immersió profunda en la construcció i gestió de la teva Font de Veritat.

3.2.2. Executor#

L’executor s’encarrega d’implementar (escriure) l’estat desitjat provinent de la Intenció en l’estat real de la xarxa, interactuant amb la xarxa a través de diferents interfícies com SSH, NETCONF, gNMI/gNOI i APIs REST.

Continuant amb l’analogia a la gestió manual de xarxes, l’executor seria l’enginyer de xarxa que prepara la configuració de xarxa final i es connecta al dispositiu de xarxa a través de CLI per introduir les ordres de configuració.

Tanmateix, això no és tan simple com copiar i enganxar dades d’un lloc (la intenció) a un altre (la xarxa). Hi ha moltes operacions a tenir en compte, des de canvis de xarxa fins a reiniciar o actualitzar sistemes. A més, tot i que la majoria de les vegades les dades de referència provenen del bloc d’Intenció, en alguns casos, les dades observades provinents d’Observabilitat poden influir en aquest component, per la qual cosa tots dos han de combinar-se.

Per exemple, l’Executor podria validar l’accessibilitat del dispositiu abans d’intentar canvis, adaptar la lògica de failover segons l’estat actual de la xarxa, o ometre l’execució si Observabilitat mostra que un servei de dependència crítica està caigut. Aquesta retroalimentació d’Observabilitat assegura que les decisions d’automatització estiguin informades per les condicions reals de la xarxa, no només per la Intenció.

Similar a la Intenció, aquest component hauria de proporcionar característiques com dry-run, canvis transaccionals i idempotència (a través d’enfocaments declaratius o imperatius) que ajuden a construir sistemes d’automatització en els quals els enginyers de xarxa puguin confiar. Aquest és usualment el component del qual els enginyers de xarxa es preocupen més (inicialment) perquè és el que realment “canvia” la xarxa.

Les eines que majoritàriament encaixen en aquesta categoria són Ansible, Terraform/OpenTofu, o qualsevol tipus de scripts que aprofiten biblioteques com Netmiko, Scrapli o Napalm, o fins i tot un Kubernetes CRD (Custom Resource).

Ves al Capítol 5 per explorar marcs d’execució, patrons d’idempotència i estratègies d’implementació.

3.2.3. Recol·lector#

Anàleg a l’Executor, el Recol·lector s’encarrega de recuperar les dades operatives reals de la xarxa a través de diferents interfícies i protocols (les mateixes interfícies que l’Executor, més altres com SNMP, Syslogs o altres telemetries basades en flux).

La destinació de totes aquestes dades és el bloc d’Observabilitat, on les dades s’usen per impulsar les decisions d’automatització.

Un tema important aquí, no considerat habitualment, és la necessitat de dades normalitzades per ser comparables. Per tant, obtenir noms de mètriques consistents per a tots els proveïdors (system_version definint la versió del SO independentment de la plataforma) i metadades consistents per permetre el processament avançat de dades és crucial.

Exemples d’eines que encaixen en aquesta categoria són Telegraf, Vector, gNMIc, PMACCT, goFlow, Akvorado, o qualsevol tipus de script que aprofiti biblioteques per obtenir dades de la xarxa.

Per afinitat, cobriré el Recol·lector juntament amb el següent bloc de construcció, Observabilitat, al Capítol 6. El Recol·lector i l’Observabilitat són arquitectònicament distincts però operativament inseparables: cada decisió de disseny sobre com recollir dades és impulsada pel que la capa d’Observabilitat necessita processar. Cobrir-los junts preserva aquesta dependència.

3.2.4. Observabilitat#

Estretament relacionada amb el Recol·lector (en molts casos vistos junts), l’Observabilitat rep les dades recollides, suporta la seva persistència i ofereix accés programàtic per suportar anàlisis avançades, informes i fluxos de treball de resolució de problemes, idealment usant llenguatges de consulta capaços (com PromQL).

Les dades d’aquest bloc han d’exposar discrepàncies rellevants entre el Desired State i l’Actual State de la xarxa, generant esdeveniments (o alertes) que podrien desencadenar sistemes de mitigació.

Continuant amb l’analogia de la gestió manual de xarxes, això encaixa amb el paper del centre d’operacions de xarxa, que verifica l’estat real de la xarxa i reacciona en conseqüència.

A més, les dades observades es poden enriquir amb informació contextual de l’estat previst, incloent altres fonts de tercers (per exemple, informació d’EoL, CVEs, notificacions de manteniment, etc.), millorant l’anàlisi i habilitant una correlació de dades més precisa.

En el monitoratge de xarxa tradicional, totes les funcionalitats d’Observabilitat (i recol·lecció) s’han integrat en una gran caixa (eines com Nagios, LibreNMS, Spectrum, etc.).

Actualment, sistemes més diversos que s’integren estan guanyant popularitat, sent Prometheus i InfluxDB Time Series Database (TSDB) populars o Elasticsearch, i altres sistemes relacionats que gestionen les alertes (Alertmanager) i visualitzen (Grafana, Kibana). Això ha portat a algunes piles populars: ELK, TIG o TPG.

Aprèn més sobre arquitectura de monitoratge, estratègies d’alertes i millors pràctiques d’observabilitat al Capítol 6.

3.2.5. Orquestrador#

Fins ara, has vist molts components diferents, i hi ha la necessitat de coordinar-los: integrant els processos dels diferents blocs de construcció i creant sofisticats fluxos de treball d’automatització d’extrem a extrem. Per això, l’orquestrador ha de suportar múltiples formes d’interactuar, des de l’activació manual fins a fluxos de treball completament impulsats per esdeveniments, tant de forma síncrona com asíncrona.

Els fluxos de treball que implementa l’orquestrador haurien de proporcionar formes de definir múltiples passos, i també han de suportar funcions de reversió i dry-run, basant-se en els altres components (per exemple, usant instantànies versionades del bloc d’intenció).

En les operacions manuals, això sol estar definit de forma vaga en una llista de verificació d’un procés que s’ha de seguir.

Aquest component proporciona als usuaris una visualització completa del que està passant en tota l’automatització de xarxa, mostrant com s’uneixen els diferents processos, a través d’un registre clar i traçabilitat.

Exemples són AAP o AWX (Ansible Automation Platform), Windmill o Prefect.

On encaixen la IA i els agents en l’arquitectura: La presa de decisions assistida per IA se situa principalment a la intersecció dels blocs d’Orquestrador i Observabilitat. Un agent d’IA segueix un bucle de sentit-lògica-acció: observa l’estat de la xarxa a través del bloc d’Observabilitat, aplica raonament per decidir quina acció es necessita, i activa l’Executor a través de l’Orquestrador. Això és diferent del paper tradicional de l’Orquestrador (seguir un flux de treball predefinit) però usa la mateixa infraestructura. El Capítol 7 (Orquestració, secció 7.2.7) cobreix l’enfocament agèntic com un patró de coordinació; els Capítols 15-17 l’exploren com la base per a xarxes autònomes. Per ara, pensa en l’automatització agèntica com un enfocament de coordinació que reemplaça les definicions de flux de treball estàtiques amb presa de decisions dinàmica impulsada per models.

Submergeix-te al Capítol 7 per aprendre sobre disseny de fluxos de treball, automatització impulsada per esdeveniments i plataformes d’orquestració.

3.2.6. Presentació#

De vegades oblidem com és d’important exposar la interfície adequada als usuaris de l’automatització de xarxes. Aquesta és usualment una àrea difusa perquè totes les eines que ja hem presentat tenen algun tipus d’interfície: CLI, API o basada en web. En alguns casos, pot ser que decideixis que n’hi ha prou. En altres casos, pot ser que creïs la teva pròpia interfície d’usuari per obtenir el millor de tots els mons i simplificar l’experiència d’usuari. Depèn.

Tradicionalment, això ha estat limitat per als usuaris externs a trucades telefòniques o correu electrònic, i per als equips de xarxa, CLI.

D’una manera o altra, aquesta capa ha de permetre autenticació i autorització flexibles (és el punt d’entrada del teu sistema), i després ajustar-se a les necessitats reals. De vegades, això podria ser una plataforma específica de xarxa, o en altres casos podria integrar-se amb sistemes de tota l’empresa (ServiceNow, Slack, etc.).

Podria cobrir operacions d’escriptura o lectura, depenent del rol, però sempre considera les necessitats dels teus diferents tipus d’usuaris per obtenir els millors resultats.

Explora l’experiència d’usuari, el disseny d’interfícies i els patrons d’integració al Capítol 8.

3.2.7. La Xarxa#

Per últim, però no menys important, hem d’entendre les capacitats de la xarxa per suportar l’automatització, i la xarxa ja no són només dispositius i cables connectats. A la dècada del 2020, la virtualització i les solucions de xarxa basades en el núvol fan que l’accessibilitat d’extrem a extrem (la xarxa) sigui un entorn híbrid i divers.

La xarxa en si mateixa és tant una restricció com un facilitador per a tota la teva arquitectura d’automatització. A diferència dels sis blocs anteriors sobre els quals tens control, la infraestructura de xarxa (els teus dispositius, plataformes, serveis i connectivitat) pot tenir limitacions que afecten el que és possible.

Les capacitats de xarxa cauen en diverses categories:

• Interfícies i Protocols: Quines interfícies de gestió suporta la teva xarxa? SSH CLI? NETCONF? gNMI? APIs REST? SNMP? Algunes plataformes suporten moltes, algunes poques. Aquestes opcions restringeixen directament el que el Recol·lector i l’Executor poden fer.
• Models de Dades: Fins i tot si un dispositiu suporta gNMI, els models YANG que exposa poden ser incomplets. Per exemple, el teu dispositiu pot afirmar suport gNMI però no exposar la configuració específica que necessites gestionar. Entendre aquestes bretxes és crític durant la planificació.
• Maduresa Operacional: Les plataformes més noves poden tenir APIs modernes però comportaments no documentats. Les plataformes més antigues poden ser estables però mancar completament d’APIs. Necessites avaluar la maduresa real, no només les característiques promocionades.

Per suportar efectivament l’automatització, la teva infraestructura de xarxa hauria d’idealment proporcionar:

• Entorns de Desenvolupament i Proves: Com el desenvolupament de programari, l’automatització requereix llocs segurs per provar. Això podria significar: xarxes de laboratori (sovint cares i limitades), entorns de xarxa virtuals (Containerlab, GNS3), o simuladors proporcionats pel proveïdor (Cisco DevNet, Arista EOS-lite).
• Interfícies Consistents: Si el 90% dels teus dispositius suporten NETCONF però el 10% només suporten SSH, necessitaràs estandarditzar o construir múltiples Executors. Cada inconsistència augmenta la complexitat.
• Telemetria Adequada: Si no pots obtenir les dades que necessites dels teus dispositius, l’Observabilitat es torna sense sentit. Assegura’t que els teus dispositius puguin transmetre telemetria (telemetria de streaming, SNMP, syslog) amb la granularitat i informació que necessites.

La xarxa és la part més difícil de l’arquitectura de canviar. No pots intercanviar fàcilment els teus routers. Així que entén les seves restriccions aviat, i dissenya la teva automatització dins d’elles. Per això el bloc de Xarxa mereix una atenció acurada durant la planificació de l’arquitectura.

Entén les capacitats de xarxa, les APIs de dispositius i els entorns de proves al Capítol 9.

A continuació, per resumir aquesta secció, repassem un cas d’ús molt simple i com l’arquitectura es mapeja en ell.

3.2.8. Un Exemple Pràctic#

Abans de submergir-nos en cada bloc, passem per un escenari concret que mostra com funciona l’arquitectura en conjunt.

Problema: Un equip d’aplicacions ha enviat una sol·licitud per a un nou segment d’aplicació: una nova VLAN, subxarxa IP, política d’encaminament i zona de control d’accés en una xarxa de campus heterogènia que executa aproximadament 800 switches d’accés i distribució de Cisco, Arista i HPE. L’equip d’operacions necessita complir-ho d’extrem a extrem sense treball manual de CLI en centenars de dispositius.

Com pot resoldre-ho l’arquitectura:

1. Intenció (Font de Veritat): Un enginyer de xarxa introdueix la nova definició de servei a Nautobot: ID de VLAN, subxarxa, política d’encaminament, plantilles de configuració per proveïdor, i a quins grups de switches s’aplica. Això s’emmagatzema com el Desired State, l’únic lloc de veritat per a 800 dispositius.
2. Orchestrator: AWX rep un webhook de Nautobot sobre el canvi i activa el flux de treball d’execució, coordinant els passos en l’ordre correcte i gestionant les fallades per dispositiu.
3. Executor: Un playbook d’Ansible llegeix de l’Application Programming Interface (API) de Nautobot, renderitza la configuració específica del dispositiu per proveïdor (Cisco, Arista i HPE requereixen cadascun una sintaxi diferent), i envia els canvis a través de NETCONF. Cada execució és idempotent: executar-la de nou en switches ja configurats no produeix cap canvi.
4. Collector: Després del desplegament, un recol·lector gNMIc es connecta a cada switch i recupera la pertinença real de VLAN, l’estat de la interfície i les entrades d’encaminament.
5. Observability: Les dades recollides flueixen cap a un Time Series Database (TSDB) Prometheus. Una consulta compara el Desired State (d’Intenció) contra l’Actual State (del Collector). Els switches on falta la VLAN s’exposen com a mètriques i activen alertes.
6. Orchestrator: Quan s’activa una alerta (“VLAN 210 no present a access-switch-b3-07”), un flux de treball AWX torna a executar automàticament l’Executor en aquell switch, torna a recollir dades i valida la correcció.
7. Presentation (Layer): Un dashboard mostra els 800 switches agrupats per edifici i proveïdor, destacant quins són conformes (✅) i quins han derivat (❌). L’equip d’aplicacions pot rastrejar el desplegament sense accés a CLI. Les operacions de TI poden activar remediacions manuals sense escriure codi.
8. La Xarxa: L’èxit d’aquest flux depèn del que els dispositius realment suporten. A Cisco i Arista, NETCONF funciona neta. Diversos switches HPE només suporten SSH CLI, per la qual cosa un camí d’Executor separat els gestiona, menys elegant però necessari. Cap arquitectura elimina les restriccions del proveïdor; simplement les fa explícites.

La Visió Clau: Cap eina única va fer això. Nautobot (Intenció), Ansible (Executor), gNMIc (Recol·lector), Prometheus (Observabilitat), AWX (Orquestrador) i un dashboard de Grafana (Presentació) van treballar junts. L’arquitectura va proporcionar el model mental per com integrar-los.

Això és el que permet el pensament arquitectònic: automatització sistemàtica i composable.

Al llarg de la Part 2 (Capítols 4-9) tornem a aquesta mateixa xarxa de campus per explorar cada bloc de construcció en profunditat: el SoT emmagatzema la definició del servei VLAN (Capítol 4), l’Executor el desplega (Capítol 5), l’Observabilitat el monitoritza (Capítol 6), l’Orquestrador coordina el cicle de vida complet (Capítol 7), la capa de Presentació l’exposa a diferents audiències (Capítol 8), i el capítol de La Xarxa tanca amb una porta de pre-producció basada en simulació (Capítol 9). On els exemples fan referència a una eina de Font de Veritat, Nautobot i NetBox s’usen indistintament; els patrons arquitectònics són els mateixos independentment del que triïs.

3.3. Com Usar una Arquitectura#

Ara que entens els diferents blocs de construcció de l’arquitectura d’automatització de xarxes NAF, potser t’estàs preguntant: “Com començo realment amb això en els meus projectes?”

3.3.1. Enfocament Seqüencial per a l’Adopció#

L’arquitectura de referència no és una prescripció. És un marc per pensar i organitzar les teves solucions d’automatització. Aquí hi ha un enfocament pràctic i seqüencial per aplicar-la:

flowchart LR
    A[Entendre l'Estat Actual]:::phase1 --> B[Planificar el Camí d'Automatització]:::phase2
    B --> C[Prendre Millors Decisions d'Eines i Disseny]:::phase3
    C --> D[Dissenyar per a la Integració]:::phase4
    D --> E[Comunicar amb les Parts Interessades]:::phase5
    E --> F[Evolucionar Incrementalment]:::phase6

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

Fase 1: Entendre el Teu Estat Actual

Comença mapeant les teves eines i processos existents als blocs arquitectònics. Aquest exercici d’avaluació t’ajuda a identificar bretxes, solapaments i àrees potencials de millora:

• Les teves dades estan disperses en múltiples sistemes?
• Estàs recollint l’estat de la xarxa efectivament, o estàs volant a cegues?
• Com executes actualment els canvis? Manualment? Scripts ad-hoc? Marcs organitzats?

Si descobreixes excel·lents capacitats d’execució però poca observabilitat, has identificat un problema d’alt impacte a resoldre a continuació.

Fase 2: Planificar el Teu Camí d’Automatització

Usa l’arquitectura per guiar el teu full de ruta d’automatització. No necessites implementar tots els blocs alhora. Comença amb els components que aborden els teus punts de dolor més crítics:

• Si estàs lluitant amb la deriva de configuració, centra’t en Intenció/Font de Veritat i Execució.
• Si no pots detectar problemes ràpidament, prioritza el Recol·lector i l’Observabilitat.
• Si la teva automatització és fragmentada i poc fiable, inverteix en Orquestració.
• Si els usuaris estan confosos sobre com sol·licitar canvis, millora la Presentació.

Prioritza per impacte en el negoci, no per completitud arquitectònica.

Fase 3: Prendre Millors Decisions d’Eines i Disseny

En avaluar noves eines o construir solucions personalitzades, pregunta’t:

• A quin bloc arquitectònic serveix això?
• S’integra bé amb els meus altres components?
• Quins fluxos de dades necessito entre blocs?

Això prevé la proliferació d’eines i garanteix que el teu ecosistema d’automatització segueixi sent cohesiu. També aclareix si hauries de construir o comprar. Si una eina encaixa neta en un bloc i té interfícies ben definides, generalment és millor comprar que construir.

Fase 4: Dissenyar per a la Integració

Entendre els límits entre components t’ajuda a dissenyar millors interfícies. Principi clau: els components no haurien de necessitar conèixer els interns de cadascun.

• El teu Executor no necessita saber com Intenció emmagatzema dades: només necessita una API ben definida per consultar l’estat desitjat.
• Al teu Orquestrador no li hauria d’importar si estàs usant Ansible o Terraform: simplement activa l’execució i monitoritza els resultats.
• El teu sistema d’Observabilitat no hauria de necessitar conèixer els interns del Recol·lector: només necessita mètriques i esdeveniments clars.

Aquest desacoblament és el que et permet evolucionar cada component de forma independent.

Fase 5: Comunicar amb les Parts Interessades

L’arquitectura proporciona un llenguatge comú per discutir l’automatització amb diferents audiències:

• A la direcció: “Estem enfortint la nostra postura d’Observabilitat per disminuir el MTTR.”
• Al teu equip: “Estandarditzem com el nostre Recol·lector envia dades a Observabilitat.”
• A altres departaments: “La nostra capa de Presentació s’integrarà amb la vostra instància ITSM.”

El llenguatge arquitectònic clar redueix la confusió i ajuda a assegurar el suport.

Fase 6: Evolucionar Incrementalment

L’arquitectura et permet intercanviar components a mesura que les teves necessitats canvien:

• Avui podries usar Git com la teva Font de Veritat, però demà podries adoptar NetBox o Infrahub sense redissenyar completament els teus fluxos de treball d’automatització, sempre que mantinguis interfícies clares.
• Podries començar amb un script simple com el teu Orquestrador, substituint-lo després per AAP o Windmill.
• Pots migrar d’un TSDB a un altre a Observabilitat sense interrompre com el Recol·lector recupera les seves dades.

Aquest enfocament evolutiu minimitza el risc i et permet aprendre sobre la marxa.

No caiguis en la trampa de la sobre-enginyeria. L’objectiu no és la puresa arquitectònica, sinó l’automatització pràctica que resol problemes reals. De vegades la millor solució és un script simple que abasta múltiples blocs arquitectònics. L’arquitectura és una guia, no una camisa de força.

La conclusió clau: usa l’arquitectura com un model mental per organitzar el teu pensament, identificar bretxes i prendre decisions de disseny deliberades. No com una plantilla rígida que dicta cada detall d’implementació.

3.3.2. Errors Comuns a Evitar#

Siguem realistes: cometraràs errors. Però aprendre d’altres pot estalviar-te molt de dolor. Aquí hi ha errors comuns:

1. Intentar Implementar Tot Alhora

   És temptador pensar: “Si aquesta arquitectura és bona, hauria de construir els set blocs perfectament.” Això porta a projectes massius de diversos anys que queden obsolets abans de completar-se.

   Millor enfocament: Comença amb un o dos blocs que resolguin el teu problema més urgent. Construeix incrementalment. L’èxit primerenc genera impuls i suport.

2. Creure en “Una Eina per Governar-les Totes”

   Alguns proveïdors afirmen que la seva plataforma ho fa tot. Tot i que això pugui ser cert, sovint significa:

   • Estàs lligat a la seva manera de fer les coses.
   • No pots intercanviar components més tard.
   • Estàs pagant per característiques que no necessites.

   Millor enfocament: Tria les millors eines per a cada bloc, però assegura’t que tinguin APIs clares i punts d’integració. Accepta que potser necessites integrar 3-5 eines, però tindràs flexibilitat.

3. Ignorar les Restriccions de Xarxa

   Dissenyes un bell Executor usant gNMI, però el 30% dels teus dispositius només suporten SSH CLI. O vols telemetria de streaming, però les teves plataformes més antigues només suporten SNMP.

   Millor enfocament: Entén primer les capacitats de la teva infraestructura de xarxa. Aquestes restriccions donen forma a la teva arquitectura. No pots ignorar la física, i no pots ignorar el que els teus dispositius poden fer realment.

4. Assumir que les Interfícies Seran Simples

   Dius: “L’Executor simplement cridarà l’API d’Intenció per a l’estat desitjat.” Però Intenció usa NetBox amb extensions personalitzades, i l’Executor espera YAML pla. De sobte estàs escrivint capes de traducció.

   Millor enfocament: Inverteix per endavant en interfícies clares i ben documentades. Usa estàndards on sigui possible (APIs REST, gRPC, definicions d’esquema clares). Les bones interfícies costen menys ara que les capes de traducció més tard.

5. Construir Eines Personalitzades Quan n’Existeixen de Bones

   El teu equip decideix construir un Recol·lector personalitzat perquè “cap eina satisfà exactament les nostres necessitats”. Sis mesos després, tens 3.000 línies de codi mantenint pipelines de telemetria propietaris.

   Millor enfocament: Avalua primer les eines existents (Telegraf, Vector, gNMIc). Gestionen el 80% dels casos d’ús i estan provades en batalla. Personalitza-les o construeix adaptadors si és necessari, però no construeixis des de zero.

6. Tractar l’Observabilitat com una Idea de Darrera Hora

   Molts equips se centren en Intenció i Executor, llavors s’adonen massa tard que no poden veure el que està passant realment a la xarxa. L’Observabilitat s’afegeix al final.

   Millor enfocament: Planifica l’Observabilitat des del primer dia. Quines mètriques recolliràs? Com detectaràs la deriva? Quines alertes importen? Respon aquestes preguntes abans de construir l’Executor.

7. Oblidar els Usuaris

   Els enginyers construeixen un potent Orquestrador, però l’única manera en que els usuaris poden interactuar amb ell és a través d’ordres CLI. Els usuaris no tècnics es confonen; l’adopció és deficient.

   Millor enfocament: Pensa en els teus usuaris des del principi. Quines interfícies necessiten? APIs? UI web? Integració amb ServiceNow? De vegades la capa de Presentació determina si l’adopció es produeix o no.

Aquests errors no són teòrics, són patrons de projectes d’automatització reals. Aprendre d’ells ara farà la teva arquitectura més sòlida.

3.3.3. Per On Començar#

L’arquitectura defineix set blocs. Ningú implementa els set alhora. En la pràctica, dos patrons d’inici representen la majoria dels desplegaments reals.

Patró A: Inici impulsat per configuració (més comú)

Equips que ja gestionen configuracions manualment i volen fer aquest procés consistent i automatitzat. Comença amb Intenció i Executor: posa en marxa una Font de Veritat i construeix els playbooks per desplegar des d’ella. Afegeix Observabilitat un cop l’execució sigui estable i necessitis retroalimentació sobre el que s’ha desplegat realment.

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

Patró B: Inici impulsat per visibilitat

Equips el principal dolor dels quals és no conèixer l’estat actual de la xarxa. Comença amb Recol·lector i Observabilitat: construeix primer el pipeline de dades, entén el que s’ha desplegat realment, llavors afegeix Intenció i Executor un cop tinguis una imatge fiable contra la qual desplegar.

flowchart LR
    A[Recol·lector] --> B[Observabilitat] --> C[Intenció / SoT] --> D[Executor] --> E[Orquestrador]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

En tots dos patrons, l’Orquestrador i la Presentació venen després que els fluxos de dades principals siguin estables. Començar amb l’Orquestrador abans de tenir Intenció o Execució fiables és prematur: encara no hi ha res significatiu que coordinar. La Presentació es torna important un cop els equips interns estan usant l’automatització i necessiten una interfície adequada en lloc d’accés directe a l’API o CLI.

Aquests són punts de partida, no plànols. Les teves restriccions (eines existents, habilitats de l’equip, el dolor més urgent) haurien de determinar l’ordre. La clau és triar un punt de partida deliberadament en lloc d’intentar construir tot en paral·lel i no acabar res.

3.3.4. Propietat de Blocs Entre Equips#

Set blocs creen una pregunta organitzacional tant com arquitectònica: qui és propietari de què, i com múltiples equips comparteixen la mateixa plataforma sense trepitjar-se els peus?

El model més comú en organitzacions mitjanes i grans es divideix en dos grups. Un equip de plataforma és propietari de la infraestructura d’automatització en si: l’esquema i les APIs del SoT, el runtime de l’Orquestrador, el pipeline d’Observabilitat, la capa de Presentació i la infraestructura compartida del Recol·lector. Aquests són els components dels quals depèn la resta de l’organització. La feina de l’equip de plataforma és mantenir-los fiables, versionats i disponibles. Un equip d’operacions de xarxa (o múltiples equips de domini, un per àrea de tecnologia) és propietari del contingut d’automatització: els playbooks, definicions de flux de treball, dades previstes i lògica de negoci que s’executen sobre la plataforma. Consumeixen la plataforma; no la mantenen.

Aquesta divisió té implicacions per com els límits de bloc es tradueixen en límits d’equip. El SoT és un recurs compartit de plataforma, però diferents equips tenen diferents permisos d’escriptura: l’equip d’adreçament IP pot ser propietari de les dades IPAM; l’equip de campus pot ser propietari de l’inventari de switches; l’equip de seguretat pot ser propietari de les dades de política de tallafoc. El model Term "rbac" not found del SoT ha de mapear-se a aquests límits de propietat. Una escriptura en el domini equivocat és un incident operacional esperant ocórrer.

L’Orquestrador és similar: l’equip de plataforma és propietari del runtime i el marc d’execució de fluxos de treball; l’equip d’operacions és propietari de les definicions de flux de treball. Les definicions de flux de treball han de viure en control de versions sota la propietat de l’equip d’operacions, sent recuperades per l’Orquestrador en el moment del desplegament en lloc d’editar-se directament a la UI de l’Orquestrador. Això evita que l’equip de plataforma i l’equip d’operacions interfereixin amb la feina de l’altre.

La Presentació divideix encara més la qüestió de la propietat. Una API interna utilitzada per altres eines d’automatització és una preocupació de plataforma. Un portal d’autoservei per a equips d’aplicacions és una preocupació de producte que pot pertànyer a un equip d’eines dedicat o a un grup de serveis compartits. Definir aquests límits aviat prevé la situació on cada equip construeix la seva pròpia interfície ad-hoc per a la mateixa plataforma subjacent.

La dimensió organitzacional de gestionar una plataforma d’automatització, incloent com els equips s’estructuren al seu voltant, com el pensament de producte s’aplica a les eines internes, i com els equips de plataforma gestionen el contracte amb els seus consumidors interns, es cobreix en profunditat al Capítol 10 (Enginyeria de Plataforma) i al Capítol 13 (Cultura i Col·laboració). Les eleccions arquitectòniques fetes aquí, especialment l’abast RBAC del SoT i la propietat del flux de treball de l’Orquestrador, restringeixen directament els models organitzacionals que aquells capítols descriuen.

3.4. Resum#

El pensament arquitectònic és essencial per construir automatització de xarxes que realment funcioni. Igual que el model OSI ens dóna un marc per capes per entendre les xarxes, una arquitectura de referència t’ajuda a organitzar i dissenyar sistemes d’automatització que siguin mantenibles, escalables i fiables.

Aquest capítol va introduir el Marc NAF, que defineix set blocs de construcció clau. L’arquitectura no és una prescripció rígida, és un marc flexible. Usa-la per avaluar el teu estat actual, planificar el teu camí d’automatització, prendre decisions informades sobre eines, comunicar-te amb les parts interessades, dissenyar per a la integració i evolucionar incrementalment. Recorda: l’objectiu és l’automatització pràctica que resol problemes reals, no la puresa arquitectònica.

A la Part 2 d’aquest llibre, aprofundirem en cadascun d’aquests blocs de construcció, explorant patrons d’implementació, millors pràctiques i exemples del món real que pots aplicar als teus propis projectes d’automatització.

💬 Found something to improve? Send feedback for this chapter