A cura di Paolo Arcagni, Systems Engineer Manager Italy&Malta di F5 Networks
La rete è ormai divisa, spaccata, in bilico. Insomma, siete autorizzati a usare il termine che preferite per descrivere il fenomeno dei servizi di rete sfrattati dalla loro tranquilla casetta in periferia, che corrisponde alla rete aziendale, e trasferiti in quartieri urbani frenetici e rumorosi, sul lato applicativo del network del data center. Al di là del termine scelto, vale la pena soffermarsi su quello che sta accadendo e analizzarne le cause.
Qualcuno 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 oggi nel mondo dev e ops.
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 (risorse come RAM, calcolo e accesso alla rete non si materializzano dal nulla!). A mio avviso 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 ad esse assimilabili (application-affine). Questi servizi – come il bilanciamento del carico, il caching, l’accelerazione e la sicurezza delle web app – sono tutti 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. Le web app sono eseguite sulla porta 80, in modo da potersi aprire e ottenere l’accesso attraverso il firewall, utilizzano lo stesso protocollo (HTTP) e sono eseguite sulla stessa porta.
Se invece ci soffermiamo su come impostare una policy di sicurezza che determini quale tipologia di dati (stringa, numero intero, alfanumerico?) o quantità di dati (15 caratteri, 12 o 100?) possa essere associata a un singolo campo di inserimento (come il nome utente, la mail o altro) associato, a sua volta, a un unico URI (/login.x), scopriremo che questa specifica a livello applicativo è piuttosto complicata.
Perché l’affinità è importante
Mediamente le aziende gestiscono circa 508 applicazioni. Secondo una ricerca F5 il 31% delle organizzazioni ne possiede in realtà 500 o più. 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 servizi “application-affine” di cui abbiamo parlato prima.
Immaginate un’organizzazione che punta a raddoppiare il numero delle applicazioni che gestisce, passando in breve tempo, ad esempio, da 500 a 1.000 applicazioni. Questa organizzazione dovrà gestire il provisioning, configurare e gestire ogni singola policy di queste app. Ipotizzando che ogni applicazione abbia bisogno di solo due policy, una per la scalabilità e una per la sicurezza, sarà semplice raggiungere in un attimo 2.000 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 (application-affine) 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!
Dall’altra parte della bilancia, nel network delle app, gli sviluppatori e i responsabili delle operation sono sempre più agguerriti nella 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 del 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 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 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.
