Il networking nell'era dei container

Arcagni (F5 Networks): la rete è e continuerà a essere uno sforzo architetturale. Non si tratta solo di come ottenere risorse di rete dove è necessario e nel modo più veloce ed efficiente. Ma anche del posizionamento di queste e di come ciò si ripercuota su tutto lo stack: i servizi di rete, i servizi applicativi, le prestazioni delle app e, in ultima analisi, il successo dell'azienda

La virtualizzazione negli ultimi anni e oggi la tecnologia container hanno aumentato la densità delle applicazioni sull'hardware rendendo sempre più complessa la sfida di gestire il traffico est-ovest, invece del traffico nord-sud. Per chi non ha dimestichezza con i pattern del traffico sul data center, il traffico est-ovest è quello da server a server, da app a app, da servizio a servizio o semplicemente all'interno del data center. I pattern del traffico nord-sud sono influenzati dal numero crescente di utenti, applicazioni e oggetti. Più aumenta la richiesta di connessioni utente-app, maggiore sarà il traffico nord-sud. Il traffico est-ovest, invece, è influenzato dalle architetture applicative e dalla tecnologia infrastrutturale.
Combinare tecnologie come la virtualizzazione e i container con le architetture emergenti, come i micro-servizi, comporta un aumento esponenziale del numero di app o servizi che devono poter comunicare tra di loro in tutto il data center.
In sostanza, più l'architettura applicativa e la sua infrastruttura sono distribuite, maggiore sarà il traffico est-ovest.

Ogni cambiamento significativo nelle architetture applicative e nella tecnologia negli ultimi venti anni ha comportato una conseguenza di uguale portata nella rete, questo perché la rete è responsabile della gestione del traffico, indipendentemente dalla sua direzione. Sia che si tratti di virtuale o di fisico, il networking è coinvolto per fare in modo che il traffico vada nella direzione corretta.
La domanda è: oggi che assistiamo all'aumento del traffico est-ovest a causa della segmentazione delle applicazioni con i micro-servizi, come dovrebbe rispondere la rete? Più precisamente, come devono comportarsi i servizi di rete per poter garantire le funzioni critiche (disponibilità, sicurezza e ottimizzazione) necessarie a fornire le applicazioni agli utenti o, come accade sempre di più, ad altre applicazioni?

Prima risposta: lo spostamento verso la app

La prima risposta a questa domanda è semplice, i servizi legati all'applicazione devono avvicinarsi all'app stessa, non possono restare fuori, ai margini del pattern nord-sud. Non fare questo spostamento significa utilizzare in modo inefficiente le risorse di rete, con un impatto sui modelli di routing che causerebbe una latenza nella comunicazione dell'applicazione.

A questo punto cominceremmo a sentire parlare di pattern di traffico che descrivono un percorso attraverso la rete che richiede l'abbandono della macchina, l'attraversamento della rete verso nord, per poi tornare sulla macchina stessa. Questa latenza si traduce in costi aziendali reali dal punto di vista della riduzione della produttività ("credetemi, il mio computer oggi è lentissimo!") e in un abbandono maggiore da parte dei consumatori degli acquisti online e dell'utilizzo delle web app. Se vogliamo evitare tutto questo, quando il traffico va nella direzione est-ovest, anche i servizi dovrebbero seguire lo stesso percorso dei dati.

Seconda risposta: la compatibilità operativa

La seconda risposta è che servizi come il bilanciamento del carico e la sicurezza delle web app devono poter essere distribuiti in formati compatibili dal punto di vista operativo. In altre parole, non possiamo abbandonare l'hardware di rete di fronte all'emergere di una qualsiasi applicazione (o micro-servizio), quindi le piattaforme su cui vengono forniti questi servizi devono essere virtualizzate o in container, in modo da essere, dal punto di vista operativo, compatibili con le architetture e le tecnologie emergenti.

Devono essere anche schematiche, fornendo API e modelli che consentano un approccio DevOps al provisioning e alla gestione. I servizi, sia che riguardino l'applicazione sia la rete, devono essere orchestrabili. Il Software-Defined Networking, se integrato con gli strumenti e i framework che dominano gli ambienti delle infrastrutture e delle applicazioni operative, è in grado di rispondere anche a questa esigenza.

Terza risposta: l'architettura è la chiave

La terza risposta è che l'architettura è più importante che mai. Solo perché si può implementare un servizio di rete sullo stesso host della sua applicazione non significa necessariamente che il deployment debba avvenire proprio lì. Sarà stabilito in base al tipo di servizio e alla sua interazione con gli altri servizi (e istanze dei servizi); in questo contesto il posizionamento diventa una questione seria da considerare.
Un bilanciamento del carico mal architettato può causare pattern di traffico spaventosi che comportano latenze inutili direttamente traducibili in perdite economiche. In questo scenario, ad esempio, qualsiasi guasto (hardware, software, di rete o di storage) sull'host su cui i servizi sono distribuiti comporta tempi di inattività, perché i servizi responsabili di garantire le applicazioni sono anch'essi non disponibili.

In un'architettura applicativa altamente segmentata (i micro-servizi) tutto questo potrebbe essere disastroso se le dipendenze tra queste applicazioni sono elevate. È necessario valutare attentamente quale sia l'architettura richiesta per garantire che le best practice rispetto alle prestazioni e alla disponibilità non vengano ignorate.

Il networking è una questione di architettura

In sintesi, la rete è e continuerà a essere uno sforzo architetturale. Non si tratta solo di come ottenere risorse di rete dove è necessario e nel modo più veloce ed efficiente. Si tratta anche del posizionamento di queste risorse e di come questo si ripercuota su tutto lo stack: i servizi di rete, i servizi applicativi, le prestazioni delle app e, in ultima analisi, il successo dell'azienda.
Il networking nell'era dei container, della virtualizzazione e del cloud riguarda l'architettura tanto quanto l'operatività.

Paolo Arcagni, Systems Engineer Manager Italia e Malta di F5 Networks