A seguito della presentazione di IP Fabric, in occasione del Networking Field Day 23, numerosi thread su Twitter hanno cominciato a sondare le possibilità offerte dall’Intent-Based Networking (IBN): è solo una trovata di marketing che i produttori utilizzano per vendere, oppure ha un significato più profondo? Che impatto ha sul team di rete? L’automazione ruberà loro il lavoro?
Il problema che l’IBN cerca di risolvere
Non è sbagliato dire che ogni azienda moderna dipende dal suo IT, che la rete fa da supporto a tutti i sistemi su cui si fa affidamento. Il business ha bisogno che l’IT sia sempre disponibile a facilitare i processi aziendali con un overhead operativo minimo. Ma è ovvio, a chiunque lavori nell’IT, come questo rappresenti uno sforzo gravoso per via di molti fattori, come ad esempio:
- Complessità. Sentiamo spesso parlare di come l’ultima tecnologia o prodotto possano semplificare IT e reti. Ma dobbiamo accettare il fatto che la complessità è spesso imprescindibile! In genere gestiamo e manteniamo più reti e le interazioni tra di esse. Queste includono le LAN di uno o più uffici o campus, data center, WAN e Public Cloud.
- Debito tecnico. In un recente post sul blog, Terry Slattery ha descritto il debito tecnico come “l’accumulo di dispositivi che invecchiano, sistemi operativi obsoleti, configurazioni inutili o parziali e variazioni nell’implementazione”. Occorre dire altro? Ogni ambiente di rete ha almeno un elemento come questo. Pensate al progetto di migrazione “quasi completo” o alle fusioni che non hanno mai razionalizzato completamente sistemi e applicazioni…
- Qualità dell’implementazione. Le pressioni a livello di tempi e progetto che si scaricano sul team di implementazione portano a ridurre i tempi di consegna. Il risultato più frequente è una documentazione incompleta, lacune nel monitoraggio e nella copertura del supporto durante il passaggio di consegne.
- Processi operativi manuali che richiedono raccolte di dati di rete prima di poter agire: dal controllo delle modifiche basato su ITIL, alla risoluzione dei ticket, alla convalida dei contratti di supporto.
- Compliance normativa. Un’aggiunta recente all’overhead operativo di molte organizzazioni. Audit regolari fatti alla buona, seguiti da un programma che rimedi i problemi, stanno diventando una costante nella maggior parte delle operazioni IT all’interno delle aziende.
Network Automation
Automatizzare le consuete attività di rete aiuta a ridurre l’overhead operativo della gestione e trattare un dominio di rete come una macro-entità, dove le micro attività necessarie alla manutenzione sono in carico a processi automatizzati, porta innegabili benefici. Si possono usare controller o script, modelli, provisioning zero-touch e meccanismi di cambiamento automatico.
Tuttavia, è fondamentale avere una comprensione completa delle reti che costruiamo, per garantire che la piattaforma di automazione stia distribuendo la configurazione con il risultato sperato. La configurazione di un dominio di rete avviene ancora su base box-by-box, mentre il sistema di automazione esegue e testa le modifiche, poi recupera i dati sulle operazioni sulla base di regole predefinite.
Intent-Based Networking
L’IBN porta l’approccio di automazione a un livello superiore. Dato il business intent per la rete, lo si traduce per prima cosa in un insieme di capacità tecniche, poi lo si rende in configurazione attraverso diversi domini di rete, si verifica che lo stato della rete rifletta correttamente l’intent e si fornisce un meccanismo di feedback per correggere la configurazione, nel caso in cui la rete si discosti dall’intent.
Quello che stiamo realmente facendo, però, è far evolvere leggermente i ruoli dell’architetto di rete, del progettista e dell’ingegnere.
Il business intent può includere idee astratte come “assicurarsi che le applicazioni critiche siano sempre disponibili”. L’approccio tradizionale coinvolgerebbe un architetto di rete nel tradurre tale intento in criteri di progettazione: “usare sempre l’alta disponibilità, nessun SPOF, far convergere il protocollo di routing entro “x” secondi, definire la QoS in tutta la rete” e così via. Un progettista di rete prenderà poi questi principi e, guardando ogni dominio di rete, vedrà come realizzare specifiche distinte base, topologie e progetti di Layer 1, 2 e 3 usando apposite piattaforme. L’ingegnere di rete infine eseguirebbe il tutto e trasformerebbe i progetti in configurazione effettiva per poi gestire e mantenere la rete.
Come funziona l’IBN?
L’IBN automatizza gran parte del processo, prendendo il business intent e offrendo un ambiente di rete che si auto-regola e auto-aggiusta.
Imperniata su una “Source of Truth” (SoT): un’immagine della rete come si vuole che appaia, sviluppata a partire dal business intent utilizzando la logica definita dagli architetti e dai progettisti di rete. Utilizzata come punto di riferimento centrale per tutti i dati di configurazione previsti, spesso facendo riferimento ad altri “Systems of Record” come fonti definitive, se necessario.
L’aggiornamento dell’intent nella SoT innesca flussi di lavoro di orchestrazione per elaborare le configurazioni nei diversi domini di rete. Queste configurazioni possono includere modelli di Best Practice organizzative o di settore, dati relativi ai criteri di sicurezza o dettagli specifici del dominio di rete per supportare l’intent. E di solito i flussi di lavoro di orchestrazione danno il via alle attività di automazione nei controller o come script, per interagire con diversi set di dispositivi di rete, anche se provenienti da diversi fornitori. Successivamente, possono anche aggiornare i motori di policy a cui i dispositivi fanno riferimento, senza dover mantenere copie locali della configurazione o della policy stessa.
I flussi di lavoro di assurance sono costruiti in primo luogo per raccogliere informazioni sullo stato dei dispositivi di rete e dei controller. Successivamente, analizzano i dati per garantire che stiano soddisfacendo l’intent.
E se l’intent non è soddisfatto, l’elemento di assurance innesca un ciclo di feedback nella piattaforma di orchestrazione per aggiornare la configurazione attraverso il livello di automazione.
Stupendo, dove devo firmare?
Ovviamente esistono alcuni aspetti su cui agire con cautela.
1. Senza la piena visibilità dell’intera rete, non è possibile implementare alcuna forma di IBN. Le informazioni sulla configurazione delle reti, quali tecnologie sono in uso e come i diversi domini di rete interagiscono, in particolare, diventano elementi vitali per assicurarsi che i flussi di lavoro di orchestrazione possano essere costruiti con l’effetto desiderato;
2. È fondamentale costruire e mantenere aggiornata una Single Source of Truth efficace e definitiva in grado di contenere (o delegare) le risposte sullo stato previsto. Una volta stabilita, diventa l’unico punto di riferimento per tutti gli intent.
3. L’architettura, la progettazione di rete e i ruoli degli ingegneri sono ancora fondamentali. Senza i seguenti elementi, l’intera impresa fallirà:
- abilità di tradurre il business intent in capacità tecniche;
- intuizione progettuale: per fornire una certa funzionalità, saranno necessarie alcune specifiche topologie e configurazioni;
- competenza ingegneristica per portare una profonda conoscenza della configurazione e l’esperienza nella progettazione e nella risoluzione dei problemi nel caso in cui il software fallisca.
E così vediamo che l’architetto di rete, il progettista e l’ingegnere sono ancora fondamentali, poiché dimostrano la loro conoscenza ed esperienza in modi diversi.
Dove si inserisce IP Fabric?
Come accennato in un post precedente, IP Fabric non è ben posizionato come SSoT per l’intent, semplicemente perché il focus di questo prodotto è fare da riferimento informativo per lo stato attuale della rete.
IP Fabric può essere il cuore del vostro ecosistema di rete basato sugli intent. Dal momento che fornisce un inventario completo, la configurazione e la visibilità dello stato dell’intera rete, si posiziona bene come sistema di registrazione per tali elementi. Può essere utilizzato per popolare inizialmente la Source of Truth, poi come fonte regolare di dati di true-up per garantire che la SoT rappresenti davvero la rete attiva.
Poiché IP Fabric sta già raccogliendo tutti i dati della rete, si trova in una posizione ideale per gestire gli elementi di assurance del sistema IBN. Andremo a definire regole che convalidano elementi di configurazione e stato, controllati ad ogni snapshot. Le regole non sono create solo attraverso l’UI ma anche attraverso l’API. Questo significa che possono poi essere spinte verso la piattaforma da un agente che funge da Source of Truth. I webhooks possono in seguito essere inviati da IP Fabric per calcolare le regole di verifica dell’intent, per fornire un meccanismo di feedback alla piattaforma di orchestrazione nel caso in cui l’intent non sia soddisfatto.
La vera bellezza di usare IP Fabric, con il suo database di rete completo e l’API aperta, è che può servire come riferimento per chiunque abbia bisogno di quei dati. Lo stesso sistema che opera come parte della piattaforma IBN può essere utilizzato per tenere aggiornate le piattaforme di monitoraggio, fornire dati ai ticket ITSM al momento della creazione, successivamente essere interrogato tramite comandi slash in Slack.
E così, l’ingegnere di rete ha già tutti i dati dettagliati di configurazione e di stato di cui ha bisogno per mantenere, risolvere i problemi e distribuire le reti. Il progettista di rete ha una comprensione dell’inventory e delle relazioni topologiche a tutti i livelli. E l’architetto di rete può ottenere molto rapidamente un quadro dello stato attuale dell’interoperabilità dei domini di rete per contribuire a pianificare la trasformazione.
Se avete trovato utile questo articolo, continuate a seguire il nostro profilo LinkedIn o il Blog, dove pubblicheremo altri contenuti. Se desiderate vedere con i vostri occhi come IP Fabric può aiutarvi a gestire la vostra rete più efficacemente, contattateci visitando il nostro sito www.ipfabric.io.
