E’ ormai assodato che in periferia si producono più dati di quelli che la rete possa trasportare. Cisco (indice VNI Cisco 2019) ad esempio, così come altri analisti, certificano come la digital transformation, stia mettendo a dura prova il modello core-edge, centro-periferia per quanto concerne la distribuzione di intelligenza applicativa e di immagazzinamento dati.
Dopo anni di centralizzazione dell’intelligenza in moderni data center, è ormai prassi comune distribuire funzionalità all’edge per scremare la mole di dati da portare verso il centro. Un esempio sono i motori applicativi di IoT che tendono a sintetizzare sull’edge, portando dati di sintesi verso il centro.
Gartner identifica l’edge computing come l’insieme delle risorse, in un ambiente distribuito, che eseguono computazione memorizzazione in prossimità dell’edge della rete o, se si vuole, in prossimità di dove le informazioni vengono prodotte.
Per fare questo è necessario dotare l’edge di strumenti decisionali basati su policy, che possibilmente prendano decisioni in modo evolutivo. In concreto, significa dotare l’edge di intelligenza guidata da sistemi alimentati da algoritmi di Machine Learning.
Questa è la vera frontiera per la gestione dei dati: essere in grado di applicare comportamenti all’edge che auto-apprendano dall’andamento del business. In questo contesto si inserisce con forza il ruolo del Cloud.
È ovvio che esiste un piano logico e uno fisico-strutturale nelle architetture Core-Edge. Mentre sul piano logico, il ruolo dell’edge e del core è chiaro, sul piano fisico-strutturale rimangono aperti vari fronti.
- Utilizzare il cloud per il core, per l’edge o per entrambi?
- Come implementare una logica ibrida, inserendo nel disegno le proprie facilities (data center o edge computing node)?
A questi tre attori fisici che collaborano si aggiunge un quarto elemento imprescindibile: la rete, e nello specifico rete WAN.
Ricordiamoci che la rete WAN lavora almeno due ordini di grandezza maggiori rispetto alla LAN in termini di prestazioni (o meglio in termini di latenze). In LAN siamo abituati a muoverci con latenze misurabili in millisecondi, sulla WAN siamo sulle centinaia di millisecondi.
Questo significa che produrre i dati è importante ma ancora di più è spostarli ove sia necessario implementare funzioni di controllo e di business.
Il trasporto tra core ed edge è spesso implementato utilizzando la rete pubblica per il 70% e per il 30% reti dedicate che portano l’edge della rete pubblica nel core dei data center.
All’interno di questo trend, sempre il Cisco VNI ci dice che il 70% del traffico sarà veicolato attraverso CDN, ossia reti create per la gestione dei contenuti.
In questo contesto, la rete entra sempre più nel contesto del dato.
Questo scenario è assolutamente pertinente se consideriamo non tanto i dati strutturati, di cui ormai sappiamo tutto, come trattarli, proteggerli e anche comprimerli (sia in modo semantico che in modo binario a basso livello), ma soprattutto la potente mole dei dati non strutturati (ossia file, thread, immagini, post, facebook post, dati provenienti da sonde IoT, o librerie importate per simulazioni Machine Learning e cosi via).
A questa prima analisi, è necessario aggiungere che il costo della rete non risiede solo nel costo della linea (mbit/s o gbit/s) che si affitta, ma risiede (anche) soprattutto nelle istruzioni di movimentazione di questi dati, soprattutto e sostanzialmente se il core (o l’edge) di cui si parla risiede in un cloud provider.
Le soluzioni che solitamente vengono implementate mettono in campo ottimizzatori del traffico di rete a meccanismi ad hoc per determinati protocolli o casi applicativi.
Per questi motivi, sulla rete WAN e quindi in contesto core-edge diventa fondamentale imparare a fare due cose:
- Utilizzare i metadati (che rappresentano il dato e permettono di verificare le informazioni con un minimo spostamento degli stessi);
- Creare un piano di implementazione flessibile che permetta di spostare l’esecuzione dei carichi applicativi al core o all’edge, nel cloud o nel proprio data center in modo rapido ed aderente ai cambiamenti delle logiche di business.
La logica Core-Edge, quindi, non può sfuggire alla gestione dei metadati che rappresentano sempre di più le informazioni disponibili.
Spesso l’accesso al metadato è condizione sufficiente per verificare contenuti e congruenze.
Ottimizzare la gestione dei metadati, implementare meccanismi di Life-Cycle management di metadati è condizione necessaria per utilizzare al massimo la distribuzione dei dati senza cadere in modelli di trasferimento di pesantissime moli di dati da una parte all’altra.
La sfida Core/Edge si vince, sicuramente ottimizzando il traffico dati, ma ancor di più nel momento in cui si implementa una logica di gestione distribuita dei metadati che rappresentano l’accesso alle informazioni.
Solo controllando i metadati è possibile:
- Controllarne la diffusione
- Accedere ai dati in modo ubiquo
- Controllarne la storicizzazione
- Tenere sotto controllo l’accesso in modo indipendente dalla eventuale storicizzazione
Ad esso è necessario aggiungere la possibilità di memorizzare in dati in modo coerente alle applicazioni invece che coerente al piano di implementazione (Cloud o On prem, questa o quella tecnologia). Questo secondo aspetto aiuta le aziende a ragionare con una logica di replica dei dati a livello infrastrutturale invece che a livello applicativo.
Riteniamo che questo sia vincente in quanto permette di suddividere i carichi e soprattutto di evitare di vivere lo spostamento dei dati come una migrazione continua.
Il modello Core-edge funziona se siamo in grado di creare una “pipe” virtuosa di dati che alimentano logiche decisionali e sistemi che imparano a pre-filtrare i dati che aiutano tali logiche.
Considerare la movimentazione dei dati come lo spostamento di Petabyte è riduttivo e sostanzialmente non aderente alle reali esigenze che sono quelle della rapidità di accesso (prima ancora che di recupero), della certezza della localizzazione e della possibilità di accedere agli stessi indipendentemente dalla localizzazione.
