La direttiva GDPR dell’UE rappresenta un importante momento di svolta nella società dell’informazione. In termini molto sintetici, afferma che la proprietà dei dati è un diritto inalienabile del loro produttore mentre prima del GDPR la proprietà dei dati era qualcosa di commerciabile.
Oggi in Europa, per utilizzare dati altrui, è sempre necessario ottenere puntuali autorizzazioni che possono essere revocate in qualsiasi momento. Oltre a ciò, l’IoT richiede sempre più elaborazione locale dei dati guidando il paradigma dell’edge computing.
Progetti come SOLID e IPFS promettono soluzioni radicali ma pratiche per muoversi verso un vero paradigma di distribuzione dei dati, cercando di ripristinare l’obiettivo originale del web: la condivisione della conoscenza.
Questa visione, in cui ogni persona/macchina ha il pieno controllo dei suoi dati, contrasta con la gestione centralizzata del dato utilizzata dalla maggior parte delle applicazioni.
Molti segnali dicono che la richiesta di tornare ad un web davvero decetralizzato sta guadagnando consenso, sia nel mondo politico che sociale; tuttavia oggi, anche quando le applicazioni dichiarano di essere distribuite (ad esempio Wikipedia), in realtà adottano comunque un’architettura centralizzata per la gestione dei dati.
Secondo Tim Berner Lee, “Il futuro è ancora molto più grande del passato”. Per essere pronti, abbiamo bisogno di ripensare le architetture dei dati, consentendo alle applicazioni di utilizzare le informazioni prodotte e gestite da qualcun altro, siano essi persone o macchine, comunque fuori dal nostro controllo.
Il teorema di Eric Brewer (noto anche come teorema CAP), afferma che è impossibile per un data store distribuito fornire simultaneamente più di due delle seguenti tre garanzie:
- Coerenza : ogni lettura riceve la scrittura più recente o un errore
- Disponibilità : ogni richiesta riceve una risposta (non di errore) - senza la garanzia che contenga la scrittura più recente
- Tolleranza delle partizioni : il sistema continua a funzionare nonostante un numero arbitrario di messaggi interrotti (o ritardati) dalla rete tra i nodi
Il teorema CAP viene spesso frainteso, come se si dovesse sempre e comunque scegliere di abbandonare una delle tre garanzie. In effetti, la scelta è in realtà tra coerenza e disponibilità solo quando avviene una partizione di rete o un errore; in tutte le altre occasioni non è necessario effettuare alcun compromesso.
Ma in un modello di dati realmente distribuito, in cui i set di dati non sono sotto diretto controllo, la partizione dei dati e l’errore di rete è SEMPRE un’opzione, quindi il teorema CAP ha piena applicazione.
Il caching dinamico è probabilmente l’unica soluzione pratica per affrontare efficaciemente il problema della distribuzione dei dati, ma non appena si replicano i dati, si crea un compromesso tra coerenza e latenza.
Daniel J. Abadi della Yale University nel 2010 ha scoperto che anche quando il sistema funziona normalmente in assenza di errori di rete, si deve scegliere tra latenza e coerenza. Ciò è anche è noto come teorema PACELC.
Cosa implica tutto questo? Un facile corollario di questi due teoremi è che occorre dimenticare l’illusione che le funzioni restituiscano gli stessi risultati quando forniamo loro gli stessi input. Di fatto, il determinismo su cui si fonda buona parte dell’attuale informatica è messo in discussione, occorre cominciare a pensare in termini di probabilità.
Ciò avviene già con i motori di ricerca (non si ottiene lo stesso risultato per la stessa query), o con i social network (non è possibile vedere lo stesso elenco di messaggi nella propria wall) o nella maggior parte delle applicazioni di edge computing. Non è una “feature”, è dovuto a vincoli tecnici, ma Facebook, Google e molte altre aziende hanno intelligentemente trasformato questo problema in un’opportunità, dando priorità agli annunci a pagamento, ad esempio.
Se il paradigma del edge computing avrà il successo previsto, tutte le applicazioni, anche quelle aziendali, dovranno affrontare problemi simili. Ad esempio, l’archivio dei clienti/fornitori potrebbe (o essere obbligato ad essere) distribuito.
Tecnologie e soluzioni come IPFS, i Linked Data e i graph database offrono soluzioni pratiche per la il chaching e l’interrogazione di set di dati distribuiti, contribuendo a risolvere incoerenze e problemi di prestazioni.
Anche se non possono essere considerati una silver bullet per ogni esigenza, sono strumenti indispensabili per progettare una nuova generazione di applicazioni in grado di sopravvivere a dati sempre più sparpagliati nella rete.
Per un approfondimento sulle tecnologie disponibili per realizzare una architettura dati distribuita si rimanda a questo link: