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.
Per Raffaele D’Albenzio, Manager, Systems Engineers, GSP Accounts EMEA F5 Networks, 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.
Assinform: buoni segnali per il Digitale
Lo scenario più semplice vede il service provider consentire l'accesso fisico a un sito di edge computing da parte di fornitori 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, sempre per D’Albenzio, sono invece 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.