Workflow Orchestrator: il direttore d'orchestra della rete GARR

Workflow Orchestrator: come uno strumento open source automatizza il ciclo di vita dei servizi della rete ottica GARR-T. Ne parla Matteo Colantonio.

Come uno strumento open source sta rivoluzionando il ciclo di vita dei servizi della rete ottica

Il Workflow Orchestrator (WFO) è uno strumento open source adottato da GARR per automatizzare e coordinare i processi che stanno dietro alla gestione dei servizi di rete, in particolare nella rete ottica di nuova generazione ad altissima capacità GARR-T. Si tratta di uno scenario tecnologico vasto ed eterogeneo, dove convivono apparati di molteplici piattaforme e sistemi operativi, in cui non basta più inviare semplici comandi testuali ai dispositivi. Più che limitarsi a eseguire singoli comandi, WFO organizza un intero flusso di lavoro: mette in sequenza le operazioni necessarie, dialoga con sistemi diversi e accompagna il servizio lungo tutto il suo ciclo di vita, dalla creazione alla modifica, fino alla verifica e alla dismissione.

Oltre l'automazione: l'era dell'orchestrazione

Ma che cos'è esattamente un orchestratore e qual è la differenza con l’automazione? Nel mondo delle reti, "automazione" è spesso usato come termine ombrello per descrivere qualsiasi cosa non sia digitata su una tastiera. Storicamente, l'automazione di rete è iniziata con script molto specifici per un singolo task, per poi evolvere verso framework di configuration management molto diffusi come Ansible.

A differenza di strumenti come Ansible, ottimi per eseguire la stessa procedura su molti apparati ma intrinsecamente stateless (ossia senza memoria), WFO gestisce il concetto di ciclo di vita di un servizio con memoria persistente di ogni azione.

Workflow Orchestrator (WFO) si comporta come un direttore d’orchestra: non suona i singoli strumenti, ma li coordina finemente affinché la sinfonia finale sia coerente, affidabile e riproducibile. Il direttore segue uno spartito (sequenza logica), gestisce imprevisti e sa esattamente a che punto dell'opera ci si trova. Questo strumento nasce per workflow, ovvero checklist automatiche per operazioni complesse sulla rete ottica, strutturando e coordinando azioni su apparati eterogenei con un approccio modulare, astratto e orientato ai servizi anziché alle righe di configurazione.

La sfida dell'ottica: la fisica incontra il software

Mentre nella rete a pacchetto un router elabora entità logiche (pacchetti IP) che possono essere gestiti, inviati o messi in coda, la rete ottica gestisce fotoni e per questo tratta con la fisica del mondo reale, ossia: dispersione cromatica, rapporti segnale-rumore, livelli di potenza ottica, spettro elettromagnetico.

I sistemi di gestione proprietari dei fornitori spesso tentano di astrarre questa complessità, ma finiscono per creare dei "silos" chiusi. Per utilizzare l’apparato di un determinato costruttore, va usato il controller dello stesso costruttore e così via. È evidente che un servizio end-to-end che attraversi tecnologie diverse diventa un incubo di integrazione. GARR ha scelto un approccio device-direct: WFO comunica direttamente con gli apparati tramite protocolli nativi, bypassando i controller proprietari.

Cosa c'è dietro a WFO: modelli astratti, modulari e minimali

Per capire questa rivoluzione silenziosa ma dirompente, abbiamo esplorato il dietro le quinte dell'automazione in GARR insieme a Matteo Colantonio, ingegnere del team della rete ottica GARR, che sta guidando la messa in atto di questa architettura all'avanguardia.

Quali sono i vantaggi dell’uso di WFO rispetto ad Ansible nella gestione dei servizi della rete GARR?

Ansible è utile, in GARR lo usiamo in PACMAN, ma per la rete ottica è inadeguato: mancano moduli compatibili con i dispositivi ottici e la gestione di logiche complesse diventa difficile. Il problema emerge con il ciclo di vita di un servizio complesso, come un circuito da 400 Gbps che attraversa mezza Italia: bisogna interrogare il database di inventario, allocare lo spettro sulla fibra, configurare transponder e ROADM, verificare la potenza ottica e, se qualcosa va storto, ripartire dal punto esatto di interruzione. WFO, infatti, è stateful, ossia con memoria: esso salva tutta la storia di ogni azione con un registro delle attività completo e strutturato, e può eseguire sia playbook Ansible sia codice Python.

In che modo WFO si integra con PACMAN per accompagnare il passaggio dalla rete ottica alla rete a pacchetto?

GARR ha un'infrastruttura IP/MPLS (la rete a pacchetto) incredibilmente sofisticata, e ha sviluppato strumenti interni eccellenti per gestirla. PACMAN è il sistema basato su Ansible e sviluppato in casa GARR per gestire le configurazioni degli apparati, permettendo ai nostri colleghi del NOC di configurare i servizi Layer 2 e Layer 3.

Il Workflow Orchestrator è stato progettato con un approccio API-first. WFO non pretende di essere l'unico software padrone dell'universo; anzi nasce proprio come orchestratore delle varie componenti dell'ecosistema. L'integrazione con strumenti come PACMAN avviene tramite API standardizzate. WFO può agire da "orchestratore di orchestratori" (service orchestrator) per i servizi multi-layer. Al momento è solo un’ipotesi ma si potrebbe immaginare uno scenario in cui, quando il NOC richiederà un servizio complesso, WFO potrà avviare il workflow: prima eseguendo direttamente i task sul dominio ottico, e successivamente, facendo una chiamata API a PACMAN passando i parametri necessari. PACMAN riceverebbe la richiesta, configurerebbe poi i router della rete a pacchetto, e restituirebbe a WFO gli aggiornamenti sull'esecuzione.

L'evoluzione di WFO in GARR
WFO nasce in seno a SURF ed ESnet ed è oggi un progetto open source collaborativo a cui partecipano diverse NREN europee. GARR ha sviluppato una propria variante pubblica su GitHub, personalizzata per i servizi ottici multi-vendor di GARR-T. Luciano Lenzini ed Enzo Valente tra i protagonisti del panel "Le radici del futuro"in occasione della Conferenza GARR 2026 a Pisa

Si tratta di uno scenario di prospettiva su cui stiamo lavorando ma l’obiettivo che abbiamo in mente è abbattere i silos operativi tra rete ottica e a pacchetto. Già durante l'ultima campagna di upgrade dei transponder della rete ottica, il WFO controllava lo stato delle porte sui router e non solo sui transponder stessi per stabilire se poteva proseguire con il riavvio di altre schede del transponder.

Uno dei concetti più affascinanti è l'astrazione dall’hardware. La rete ottica GARR è parzialmente disaggregata. Come avete gestito questa eterogeneità?

Questo è stato forse il nostro maggiore successo architetturale. L'obiettivo dell'automazione non è solo fare le cose più in fretta, ma creare modelli che sopravvivano al cambiamento dell'hardware con un approccio lungimirante.

Abbiamo applicato il principio del polimorfismo: in WFO si modellano entità astratte ("Fibra Ottica", "Porta", "Servizio Ethernet") disaccoppiate dalle peculiarità dei singoli vendor. Se domani GARR acquistasse apparati di un vendor diverso, i workflow di alto livello non cambierebbero. Ci avvaliamo dei modelli YANG per la modellazione dei dati e comunichiamo direttamente con le API degli apparati, ottenendo così il 100% del controllo sulla rete.

Esistono piani per sfruttare i LLM nella generazione di workflow dinamici a partire da descrizioni in linguaggio naturale, con l’obiettivo di ridurre il codice manuale e semplificare ulteriormente l’automazione?

L'AI applicata al networking è entusiasmante ma richiede prudenza: un errore di configurazione può interrompere flussi vitali per ore. Non darei a un'AI agentica la possibilità di modificare la rete. I LLM però stanno già cambiando lo sviluppo software: non siamo lontani dal poter fornire a un LLM la base di codice dell'orchestratore e il manuale di un apparato per ottenere il workflow di upgrade. La responsabilità di verificare il codice prima del rilascio in produzione resta però sempre all'essere umano.

In futuro le informazioni salvate nel WFO potrebbero essere usate per demandare la diagnosi dei problemi di rete a sistemi come Antares. Si tratta di un sistema multi-agente basato su LLM sviluppato dal collega Francesco Lombardo che, tramite “ragionamento autonomo” e accesso in sola lettura all'infrastruttura, aiuta nella risoluzione dei guasti partendo da richieste in linguaggio naturale. Anche qui, in realtà, l’unico vero “agente” dotato di volere è chi progetta e opera il sistema, ai LLM vengono demandati solo alcuni compiti sicuri.

Dopo averlo portato sul campo, quali sono le tue impressioni su WFO e quali aspetti consideri oggi più promettenti per il futuro dei servizi di rete in GARR?

È un approccio abilitante. La gestione dell’intero ciclo di vita di un nodo o di un servizio è molto più veloce e sicura rispetto alle procedure manuali. Inoltre si eliminano completamente le configurazioni spurie e inaspettate che possano creare problemi. In prospettiva, gli utenti potranno richiedere modifiche al proprio servizio da un portale web: è la trasformazione della rete in un'infrastruttura cloud-like.

Cosa consigli a chi vuole iniziare, e quali sono stati i maggiori ostacoli superati?

Un momento della presentazione di Matteo Colantonio al AutoCon (Automated Networking Conference) a luglio 2025 dal titolo "From Clicks to Code: Optical Network Automation Journey at GARR"

Il maggiore ostacolo per noi è stato sicuramente non aver saputo prima del framework del WFO. Precedentemente abbiamo provato altre soluzioni ma si sono rivelate tutte insoddisfacenti, da Ansible puro ai sistemi di gestione dei costruttori.

Per cui il consiglio più importante che posso dare è di adottare o sviluppare un sistema strutturato e flessibile come il WFO che sia abilitante e che scali in complessità senza diventare un peso. Chi è interessato, può guardare le registrazioni della conferenza dedicata all’automazione di rete AutoCon, e si accorgerà che gli elementi ricorrenti fondamentali in questo tipo di sistemi sono un database che mantenga lo stato desiderato e la storia dei servizi e componenti software che interagiscano direttamente con gli apparati e i sistemi informativi.

Un altro ostacolo è sicuramente la resistenza al cambiamento. È un approccio alla gestione delle reti molto più vicino all'ingegneria del software che all'ingegneria delle telecomunicazioni, ma che allo stesso tempo necessita di persone esperte nella gestione e nel funzionamento degli apparati e dei servizi di rete. Il consiglio è di non iniziare da zero, ma adottare framework consolidati e lasciarsi ispirare dal lavoro di chi questi sistemi li ha in produzione. Il nostro lavoro sull’orchestratore ottico è pubblico e accessibile a tutti su GitHub.