Non ci sarà 5G senza DevOps. Alle Telco servono modelli di gestione distribuita delle risorse, architetture agili e flessibili, il rispetto di nuovi standard di qualità. Uno studio di Ericsson.
Il 5G ha bisogno di DevOps. Lo affermano sei ricercatori di Ericsson – Catalin Meirosu, Wolfgang John, Miljenko Opsenica, Tomas Mecklin, Fatih Degirmenci e Torsten Dinsing – in un recente articolo apparso su “Ericsson Technology Review”. Nello studio si sottolinea in particolare il fatto che, nel contesto delle reti di quinta generazione, sarà indispensabile impiegare in misura massiccia tecnologie di virtualizzazione e strumenti per l’automazione dei processi. Solo in questo modo, infatti, si potranno definire dinamicamente i servizi supportati dall’infrastruttura e il modo in cui essi saranno gestiti. Virtualizazione e automazione, appunto: proprio i due driver di DevOps.
Network Functions Virtualization
Per il team dei ricercatori di Ericsson è dunque necessario adottare un modello di tipo NFV (network functions virtualization), ossia un’architettura che virtualizzi le funzioni dei nodi di rete – router, gateway, firewall, load balancer – separandole dai contenitori fisici. La virtualizzazione di tali risorse permette la loro distribuzione sul cloud e una gestione dinamica. Aumentano in tal modo le possibilità di controllare livelli di utilizzo dei workload, consumo di energia e copertura.
L’NFV è qualcosa di cui si parla dal 2012, quando il termine DevOps non era ancora di moda. Il paradigma è connesso a un altro modello concettuale, che chiamiamo SDN (software-defined networking) e al quale gli autori dell’articolo alludono senza però svilupparlo più di tanto. L’SDN postula l’astrazione dei componenti di rete e del software. In questo modo è possibile disaccoppiare il livello di controllo dallo stato dei dati: l’uno viene gestito centralmente, l’altro in modo distribuito.
Applicare i concetti dell’SDN per implementare una rete di tipo NFV ha una serie di conseguenze sul modo di gestire il ciclo di sviluppo delle singole funzioni. Un ciclo in cui tutte le fasi sono sempre più interconnesse, nell’ottica della cosiddetta continuous delivery. Ed è questo il cuore dell’idea di DevOps. Grazie alla gestione snella del processo, secondo il modello del paradigma agile, e all’automazione di numerose operazioni, in particolare nelle fasi di test e rilascio, si riesce a rafforzare il controllo su tutto il ciclo. Il risultato è la possibilità di aumentare la frequenza dei rilasci, anche “a caldo”, e quindi ottenere un miglioramento del time-to-market.
Continuous Everything
Più che di continuous delivery, peraltro, sarebbe corretto parlare di continuous everything. Tutti i team sono coinvolti: sviluppo, integrazione, operations. E la parola chiave è automazione. Attraverso una serie di metodi e strumenti e possibile configurare dinamicamente i parametri dei servizi e dunque automatizzarne il dimensionamento e lo scaling. L’automazione interviene anche nei processi di monitoring, troubleshooting e analytics.
Parlare di DevOps significa dunque anche parlare di management and orchestration (MANO). Si tratta di uno strato concettuale inedito rispetto alle architetture tradizionali. Per implementarlo, è necessario integrare i sistemi esistenti via API. In questo senso il mondo degli OSS/BSS deve evolvere, in modo da interoperare nell’ambito di un’architettura NFV appunto attraverso lo strato MANO.
Ed è proprio su questo strato che Spindox sta lavorando, con l’obiettivo da un lato di definire un metodo robusto e applicabile nei vari contesti operativi, dall’altro di selezionare gli strumenti di orchestrazione più appropriati. Uno degli tool per l’automazione su cui stiamo facendo esperienza è Ansible, motore di continuous integration e configuration management molto potente. Collaboriamo poi attivamente con Apcera, scelta da Spindox come piattaforma di riferimento per il container management. In alternativa ad Apcera usiamo Rancher, soluzione open-source con la quale stiamo containerizzando una serie di applicazioni rilasciate in origine, e DC/OS. Un ulteriore orchestratore open-source è Kubernetes, nato dall’esperienza pluriennale di containerizzazione in ambiente Linux condotta da Google e che comincia ad essere sperimentato per il deploy di applicazioni nel mondo TLC.
