[section_title title=Il networking nell’era dei container – Parte 2]
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 COMPATIBILITA’ 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 E’ 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à.
