La rete è ormai divisa, spaccata, in bilico. Ne è convinto Paolo Arcagni, Systems Engineer Manager Italy&Malta di F5 Networks, analizzando il fenomeno dei servizi di rete sfrattati dalla rete aziendale e trasferiti sul lato applicativo del network del datacenter
Qualcuno, spiega il manager, potrebbe obbiettare che il motivo è evidente: la rete aziendale si basa in buona parte sull’hardware e questo semplicemente non possiede la flessibilità e l’agilità necessarie per adattarsi all’ambiente moderno e agile che si sta affermando nel mondo DevOps.
Non è del tutto vero. Non si tratta tanto di hardware o software, perché in realtà l’hardware è comunque qualcosa che bisogna possedere indipendentemente da quello che si fa.
A mio avviso, continua Arcagni, si tratta piuttosto di una questione di cultura operativa e di aspetti che si applicano a ciascuna delle due tipologie di rete e che spostano da una parte o dall’altra della bilancia il peso dei servizi.
Quello che sta realmente accadendo è che le applicazioni sono diventate il centro di gravità e attirano verso di sé tutti i servizi a esse assimilabili. Questi servizi, come il bilanciamento del carico, il caching, l’accelerazione e la sicurezza delle Web app, risultano fondamentali per l’applicazione specifica. Non possono essere standardizzati ma, al contrario, sono incentrati sull’app e le loro policy hanno lo scopo di fornire, proteggere e ottimizzare proprio quella singola applicazione particolare.
Se pensiamo a un firewall di rete o Ips/Ids, l’operatività non è poi così specifica a livello applicativo. Se, invece, ci soffermiamo su come impostare una policy di sicurezza che determini quale tipologia o quantità di dati può essere associata a un singolo campo di inserimento, scopriremo che questa specifica a livello applicativo è piuttosto complicata.
Perché l’affinità è importante
Mediamente le aziende gestiscono circa 508 applicazioni. Questa è la base di partenza, perché molte aziende hanno in programma di accrescere in modo consistente il numero delle app. A esse si aggiungono le organizzazioni che stanno adottando un’architettura con micro servizi e che, anche se non stanno necessariamente cambiando il numero delle applicazioni, vedranno crescere il numero dei “sistemi” di cui avranno bisogno per i già citati servizi “application-affine”.
Immaginate un’organizzazione che punta a raddoppiare il numero delle applicazioni che gestisce, passando in breve tempo, ad esempio, da 500 a mille applicazioni. Questa organizzazione dovrà occuparsi del provisioning, configurare e gestire ogni singola policy di queste app. Ipotizzando che ogni applicazione abbia bisogno di due policy, una per la scalabilità e una per la sicurezza, sarà semplice raggiungere in un attimo 2mila policy da gestire.
Ecco il cuore del problema: non è l’hardware nella rete aziendale che non è in grado di gestire il tutto. Lo può fare perché è stato costruito proprio a questo scopo e le sue capacità vanno ben oltre il server generico.
Il problema sono i processi e le risorse necessarie. Non si tratta solo del numero di dispositivi ma delle policy uniche che devono essere distribuite. E, anche qui, la difficoltà cresce perché non ci riferiamo solo al deployment ma anche all’aggiornamento.
I criteri delle policy “application-affine” sono configurati appositamente per una singola applicazione, perciò quando un’applicazione viene aggiornata o è necessaria una correzione, vi è una probabilità maggiore che le policy di servizio applicativo associate debbano anch’esse essere aggiornate. Oggi le organizzazioni vogliono effettuare deployment più frequenti e il rischio è che la rete aziendale venga presto completamente sopraffatta.
Sull’altro piatto della bilancia, nel network delle app, gli sviluppatori e i responsabili delle operation sono sempre più agguerriti nel delivery e deployment delle applicazioni.
Sono pronti a utilizzare le loro nuove competenze nel campo dell’automazione e dell’orchestrazione per accelerare questo processo. Ed è proprio quello che sta accadendo oggi: gli sviluppatori, sempre più spesso, si assumono la responsabilità dei servizi “application-affine” e della loro integrazione nel deployment di architetture e processi. Grazie all’aumento della consapevolezza rispetto ai DevOps e agli stimoli che vengono dal mercato SDN, i servizi di rete sono per lo più abilitati con le API e con modelli che si adattano come un guanto alla mano degli operatori che utilizzano un approccio “Infrastructure-as-a-code” per la gestione e la distribuzione dell’infrastruttura necessaria a supportare le applicazioni.
Questo è il motivo per cui il centro di gravità dell’It aziendale è l’applicazione e perché sempre più “servizi applicativi” spostano l’ago della bilancia verso il network delle applicazioni.
Si tratta, in conclusione, di una strategia di scala, di business e operativa. È un modo per far fronte alla rapida crescita del portfolio applicativo, senza dover mettere in gioco un organico maggiore a livello di rete o applicazione e per consentire all’It di fornire al mercato le applicazioni più velocemente, con maggiore frequenza, senza dover gestire un numero di policy due o tre volte superiore rispetto a oggi.
