Secondo Raffaele D’Albenzio, Manager, Systems Engineers, Global Service Provider Accounts EMEA di F5 Networks, all’orizzonte dell’automazione c’è il Service provider on the edge.
Fino a non molto tempo fa esisteva una linea di demarcazione netta all’interno del mondo dei service provider. Da un lato, i team di networking e sicurezza, che hanno guidato il percorso di evoluzione verso un’architettura NFV, con una forte attenzione alla virtualizzazione della rete e alla sicurezza, ma con minore interesse nell’adozione di scenari di automazione.
Dall’altro, gli sviluppatori, che hanno abbracciato con entusiasmo le piattaforme cloud, le metodologie DevOps e l’automazione tramite approccio CI/CD. Per loro lo sviluppo e la delivery rapida delle applicazioni erano, e rimangono tuttora, gli obiettivi principali.
L’edge computing rappresenta il punto di incontro tra queste due visioni, dove è possibile far convivere armoniosamente applicazioni e funzioni di rete. Quale sistema distribuito e abilitato dalla nuova tecnologia 5G, l’edge computing consente ai service provider di offrire nuove soluzioni e servizi, aumentando, allo stesso tempo, il flusso dei ricavi e riducendo i costi di trasporto della rete.
Invece di trasmettere i dati a un cloud o a un data warehouse centralizzata perché vengano analizzati, l’elaborazione può avvenire infatti all’”edge” della rete, riducendone la latenza, ottimizzando la larghezza di banda, offrendo così tempi di risposta decisamente più rapidi e una migliore Quality of Experience.
Esempio 1: Automobili a guida autonoma
Ospitare le applicazioni in una posizione centralizzata come un cloud pubblico, con tutti i dati ad esse associati, può produrre una latenza end-to-end della durata di decine o anche centinaia di millisecondi, un periodo di tempo ormai troppo lungo per diverse applicazioni. Lo stesso risultato si ottiene anche se l’applicazione rimane centralizzata ed è solo la funzione di rete ad essere localizzata all’edge. Quando invece entrambe – sia l’applicazione sia la funzione di rete – si spostano verso l’edge della rete, è possibile ridurre la latenza a pochi millisecondi.
Esempio 2: Delivery dei contenuti Video
Anche l’evoluzione delle soluzioni di rete virtualizzate per la content delivery (vCDN) è un esempio interessante. Fino a poco tempo fa, infatti, un CDN di terze parti era generalmente ospitato in un punto di peering o in un data center centralizzato. Oggi il panorama sta cambiando e alcuni service provider iniziano a costruire i propri CDN basandosi proprio sull’edge computing, ad esempio per i contenuti video locali e i servizi IPTV, risparmiando sui costi di trasporto e di backhauling.
Esistono diversi modelli di business che possono trarre vantaggio da questi nuovi casi d’uso. Lo scenario più semplice vede il service provider consentire l’accesso fisico a un sito di edge computing da parte fonitori di contenuti e di servizi applicativi di terze parti che installano hardware/software proprio gestendo tutto in modalità centralizzata dai loro sistemi. In base a questo modello, definito colocation model, il service provider è responsabile dello spazio, dell’alimentazione e della connettività. Un approccio ancora più interessante per il service provider è offrire (in maniera autonoma o attraverso partner specializzati) opzioni di infrastructure-as-a-service (IaaS) o platform-as-a-service (PaaS), attraverso una piattaforma di edge computing condivisa.
Verso un framework di automazione comune
L’ingrediente segreto per far funzionare il tutto, oggi, è l’automazione. Nel cloud computing, l’automazione è fondamentale per gli sviluppatori, affinché possano rilasciare frequentemente nuove versioni delle proprie applicazioni. Tuttavia, anche quando si parla di architettura NFV, l’automazione rappresenta la chiave per ridurre i costi operativi a carico del service provider.
Il punto cruciale è che, anche se gli obiettivi possono sembrare differenti, gli strumenti e le tecniche utilizzate per implementare scenari di automazione sono gli stessi, e lo saranno sempre di più quando nell’edge dovranno essere distribuite sia funzioni di rete che servizi applicativi, che richiederranno un deployment nell’edge di funzioni di ADC e/o di sicurezza applicativa.
F5 per questo ha sposato un approccio multicloud, basato principalmente su API dichiarative e indipendenti dall’infrastruttura di cloud/virtualizzazione sottostante, incluse quelle che verranno utilizzate in ambienti di edge computing.
Le API definite “imperative”, di cui sono dotati la maggior parte dei vendor, sono quelle che comunicano al sistema cosa fare. I firewall sono un buon esempio, perché impongono la creazione di liste di indirizzi da allineare alle regole del firewall stesso, raggruppate poi in una policy, a sua volta assegnata a un’interfaccia. Ci sono, quindi, requisiti precisi da seguire per le chiamate rest API perché siano consequenziali – evitando che un solo errore vanifichi tutto e lasci il sistema in uno stato intermedio non noto a priori. Riportare tutto questo all’interno di uno strumento di automazione è costoso e richiede molto tempo.
Le API dichiarative, invece, sono differenti. È possibile comunicare al sistema quello che si desidera, ed è esso stesso a comprendere la strada da seguire. Tramite una dichiarazione (in formato JSON o YAML) è possibile ad esempio definire tutti i parametri per gli ADC e altri servizi di sicurezza, e assegnarli al sistema con una singola Rest API. In questo caso, anche di fronte a un errore, il sistema complessivo rimane inalterato. Non c’è bisogno dell’intelligence in un sistema di automazione, perché l’intelligence rimane all’interno dei sistemi che si stanno configurando, il che riduce notevolmente i costi operativi.
Le stesse misure possono essere adottate per realizzare una funzione di rete virtualizzata in un ambiente NFV. Un’API dichiarativa semplifica notevolmente l’integrazione con gli strumenti di orchestrazione NFV end-to-end. Non c’è bisogno di conoscere i singoli passi per configurare un servizio o una funzione di rete. Anche in questo caso, l’intelligence di configurazione del servizio rimane all’interno del sistema stesso da configurare.
Grazie a un allineamento migliore tra il networking e lo sviluppo delle app, oggi è possibile costruire un’infrastruttura di telco cloud distribuita con un framework di automazione comune per le funzioni applicative e di rete, agile e sicuro ad ogni livello dello stack – dal data center principale fino all’edge, con la possibilità di estendersi ulteriormente anche nel cloud pubblico.
In conclusione, ci si aspetta che i framework di automazione, che abilitano lo sviluppo delle applicazioni e i loro servizi, così come le funzioni di rete, si diffonderanno sempre più e saranno presto di comune utilizzo, soprattutto a seguito dell’avvento del 5G. Unificare i silos e raggiungere una maggiore agilità sono infatti necessità sempre più urgenti per i service provider che porteranno sempre più le applicazioni verso l’edge della rete.
