Posts Tagged ‘cloud computing’

Archiviazione digitale: la soluzione è il peer to peer?

Il modello di cloud p2p di Space Monkey

Il modello di cloud p2p di Space Monkey (fonte: http://www.spacemonkey.com/press)

Il cloud computing è stato un modello tecnologico che sin dal suo apparire ha fortemente diviso la comunità degli informatici e dei CIO tra fautori ed oppositori. A fronte degli evidenti (?) vantaggi di natura economica e di disponibilità H24 dei propri dati / documenti, si è sempre sottolineato come si perdesse il controllo diretto sugli stessi; forti dubbi inoltre venivano (vengono) sollevati in ordine alla tutela della privacy anche se, puntualizzavano i favorevoli, ciò appariva come un qualcosa di accettabile in ragione della sicurezza complessiva garantita dalle strutture (quegli enormi data center che Google, Facebook, Amazon, Apple, etc. vanno costruendo per mezzo mondo) che li ospitavano.
L’uragano Sandy ha però fatto in parte crollare queste certezze; ciò, unitamente a motivazioni di ordine economico (molti servizi non sono poi così convenienti come vorrebbero far credere…) ed ideologico (la ricerca di soluzioni di archiviazione green meno energivore rispetto ai data center, il ritorno ad un computing decentrato) ha indotto a sviluppare soluzioni alternative, soprattutto di personal digital archiving (dal momento che chi ha capacità e disponibilità economiche si costruisce la sua bella private cloud!), che salvassero i vantaggi minimizzando gli svantaggi.
Le linee ad oggi seguite sono state essenzialmente due: la prima è stata quelle di realizzare una cloud domestica (altresì detta personal cloud) con tanto di mini server, gruppi di continuità in grado di salvaguardare dagli sbalzi di corrente e garantire un minimo di autonomia in caso di interruzione nell’erogazione di energia elettrica, etc.; la seconda strada è stata quella di realizzare una rete interconnessa di sistemi di storage di piccole dimensioni. E’ di quest’ultima che mi occupo in questo post.
Spieghiamo innanzitutto in che cosa consiste una “nuvola” P2P? In estrema sintesi si tratta di un sistema che permette la condivisione di risorse di storage connesse alla rete; in pratica ciascun appartenente al network mette a disposizione una porzione del proprio spazio di archiviazione ottenendone a sua volta in cambio dell’altro da parte degli altri aderenti alla rete: un apposito software provvede ad effettuare in automatico una copia (spacchettata e criptata) dei nostri dati / documenti inviandola a kilometri di distanza e garantendone in tal modo la sopravvivenza in caso di rotture del dispositivo di storage, di calamità naturali, etc.
Un esempio concreto è Space Monkey: per 10 dollari al mese questa azienda fornisce ai suoi utenti un dispositivo ad hoc da 3 terabyte di memoria (uno disponibile, i rimanenti due destinati ad ospitare file altrui) che promette di essere più veloce nelle operazioni di upload/download nonché energeticamente più efficiente; la “sopravvivenza” dei propri dati è garantita, come anzidetto, dal fatto che essi vengono replicati in molteplici dispositivi di storage ma anche dall’ulteriore copia che viene fatta nel data center gestito, quale ulteriore precauzione, da Space Monkey stessa. Un sistema siffatto, questa è l’idea, dovrebbe risentire assai meno di eventuali outage (qualunque ne sia la causa) e garantire pertanto l’accesso ai propri dati o perlomeno ad una buona parte di essi.
Personalmente ritengo che questa soluzione, almeno dal punto di vista archivistico, non risolva granché i problemi di personal archiving dal momento che la questione della sicurezza e della eventuale sottrazione di dati / documenti resta sul tappeto. Come non pensare, giusto per fare un banale esempio, che un eventuale malintenzionato si abboni al servizio e tenti, dall’interno, di violarne le difese? In questo senso un tradizionale data center concepito a mo’ di fortino mi sembra molto più rassicurante! Considerando poi che un sistema siffatto non ha pretese di garantire autenticità, affidabilità, integrità, etc. né tantomeno la conservazione nel medio – lungo periodo si deduce che esso non soddisfa i requisiti per fungere da valido sistema di archiviazione digitale (al massimo può essere uno dei tanti modi per diversificare il rischio, così come suggerito dagli esperti del National Digital Information Infrastructure and Preservation Program).
Paradossalmente però un modello distribuito strutturato sulla falsa riga di Space Monkey potrebbe rivelarsi felicemente applicabile ad archivi “istituzionali” massimamente in paesi territorialmente poco estesi come l’Italia: posto che, in attesa dell’entrata in vigore del “Regolamento generale sulla protezione dei dati” (redatto a livello europeo), il trasferimento degli stessi all’estero presenta non poche controindicazioni, bisogna prendere atto che per il momento le soluzioni non possono che essere nazionali; a sua volta ciò deve portare a riconoscere che, ai fini del disaster recovery, è impresa improba (in special modo una volta eliminate le numerose zone a rischio sismico, idrogeologico, etc.) riuscire ad impiantare nello Stivale due data center che si trovino ad una distanza di sicurezza soddisfacente l’uno dall’altro!
Giusto per fare un esempio concreto PARER, il principale Polo italiano per la conservazione digitale, ha due data center rispettivamente nelle province di Bologna e Milano più un sito di back-up offline in quella di Roma. Specie nel primo caso le distanze non mi sembrano sufficientemente rassicuranti (tra Bologna e Milano ci sono appena 200 km mentre tra Bologna e Roma 300 e tra Milano e Roma 480; qui uno strumento per farvi i vostri calcoli!): d’accordo, eventi come il citato Sandy sono improbabili in Italia, ma considerando la tropicalizzazione cui a detta di molti esperti va incontro il bacino del Mediterraneo ed alla luce dei frequenti eventi estremi dei quali siamo testimoni, un po’ di preoccupazione ce l’avrei!
In altri termini sarebbe il caso di valutare se un sistema distribuito che preveda la realizzazione di un unico data center in una zona scelta con tutti i crismi del caso affiancato da una cospicua quantità di “punti di storage” (una per provincia?) nei quali replicare più e più volte i dati sia più confacente al caso italiano. Caso italiano, ricordo, caratterizzato tradizionalmente da un policentrismo spinto e da più centri di produzione e sedimentazione documentaria. Motivo ulteriore per verificare la fattibilità della soluzione.

istella, il motore di ricerca che scandaglia gli archivi nascosti

istella

istella (screenshot)

Settimana dedicata al lancio di nuovi motori di ricerca questa: ha iniziato due giorni fa istella mentre ieri è stata la volta di Quag.
Diciamo subito che dopo la delusione di Volunia ero molto scettico circa la reale capacità di innovare delle start up nostrane (tanto più considerando che alle spalle di Quag c’è quel Mariano Pireddu già finanziatore di Volunia), invece l’impatto è stato immediatamente, anche dal punto di vista grafico, più che positivo.
In particolare interessantissima è l’idea di motore di ricerca che sta alle spalle di istella, creatura di Renato Soru (fondatore di Tiscali): un SE che privilegia il web italiano, con un algoritmo che punta sulla qualità (piuttosto che sulla popolarità) dei risultati e soprattutto che indicizza (su invito) documenti e risorse solitamente precluse ai “normali” spider in quanto nascoste in quell’hidden web (personalmente io preferisco il termine deep web) che pur ne costituisce la parte preponderante.
Com’è stato raggiunto questo risultato? “Semplicemente” stipulando appositi accordi con prestigiose istituzioni (hanno aderito, tra gli altri, l’Istituto Enciclopedia Treccani, l’Archivio LaPresse, l’Archivio RAI, il MIBAC – SAN e l’Archivio Touring Club) le quali hanno fatto in modo che non solo le pagine ma anche le risorse più nascoste fossero raggiungibili, indicizzabili ed accessibili.
Gli ideatori di istella non si sono però fermati agli archivi istituzionali, ma hanno previsto che tutti i navigatori (purché registrati) possano uploadare quelle che il videotutorial definisce digital library (ma che in realtà altro non sono che porzioni più o meno complete degli archivi digitali degli utenti ovvero file di testo, audio, immagini, video), rendendole indicizzabili (= reperibili), liberamente consultabili ed eventualmente scaricabili.
Non mancano ovviamente alcuni problemi, com’è naturale che sia essendo istella ancora in fase di rodaggio: i risultati della ricerca a volte non sono pienamente pertinenti, così come l’accesso alle risorse “nascoste” non è così immediato (non mi ritengo un navigatore sprovveduto ma nel corso dei miei test non sono riuscito, nonostante il tempo e le diverse ricerche, ad accedere ai documenti che il SAN dovrebbe – ma forse non l’ha ancora fatto – aver condiviso; al contrario non ho avuto alcun problema ad accedere agli archivi digitali di altri utenti che come il sottoscritto hanno risposto all’appello lanciato dagli ideatori di istella a “condividere”).
Un progetto, per concludere, decisamente interessante dal momento che sottintende, da parte di tutti (pubbliche amministrazioni, possessori di archivi istituzionali, singoli cittadini), uno scatto culturale con l’apertura ad un modello nel quale tutti contribuiscono all’accrescimento ed alla circolazione del Sapere mettendolo a disposizione di tutti. Anzi, l’auspicio è che questa openess, incentrata sui documenti “finiti”, si saldi con quell’altro fecondo movimento che sta rapidamente prendendo piede, ovvero quello che guarda ai “grezzi” open data.

Società dell’immagine ed archivi fotografici digitali di persona

Who says archives are boring? (di Remco van Gastel, su Flickr)

Who says archives are boring?


INTRO

Nel corso degli ultimi decenni stuoli di studiosi hanno tentato di descrivere la società in cui viviamo etichettandola con aggettivi o formule ad effetto facilmente memorizzabili; se la maggior parte di queste definizioni si sono rivelate poco felici e sono ben presto finite nel dimenticatoio, è incontrovertibile che due di esse hanno resistito all’usura del tempo e si sono anzi progressivamente arricchite di ulteriori connotazioni. Mi riferisco in particolare all’idea di società dell’immagine e a quella, ad essa sempre più correlata, di società della comunicazione: infatti se nella prima l’apparire conta più dell’essere, è evidente che quest’apparire “reificato” in migliaia di foto, video, etc. non è fine a sé stesso ma trova un senso quando “comunicato” agli altri. In altri termini le odierne tecnologie di comunicazione ci mettono a disposizione strumenti (facilmente utilizzabili e che danno un “output” dal costo praticamente nullo per l’utente finale) che servono non tanto a tenere memoria di uno specifico fatto od evento (la vera ragione per cui macchine fotografiche, cineprese, etc. sono state in origine pensate e costruite) ma soprattutto a veicolare a terzi la nostra immagine, vera o costruita che sia.
Oltre ad assecondare il nostro naturale narcisismo vi è un ulteriore, decisivo aspetto che occorre evidenziare: nel momento in cui comunichiamo ad altri la nostra immagine, trasmettiamo anche il nostro stile di vita, i nostri gusti, le nostre preferenze di consumo (come vestiamo, cosa mangiamo, dove andiamo in vacanza, etc.): in altre parole nel momento stesso in cui facciamo vedere chi siamo = come appariamo facciamo anche vedere come spendiamo.
Non deve pertanto sorprendere il fatto che le principali società hi-tech d’oltreoceano, fiutando il business, possiedano o perlomeno controllino servizi di archiviazione e condivisione di foto e video (cito qui i vari Facebook / Instagram, Yahoo! / Flickr, Google / Picasa, Twitter ed entro certi termini HP / Snapfish, Photobucket, Dropbox, etc.), servizi attraverso i quali essi si contendono in una dura battaglia le immagini dei navigatori / clienti, le cui foto, parimenti agli altri dati digitali, finiscono nell’impalpabile (benché realissima) nuvola.

UN INTERESSANTE CASE HISTORY

L’ineluttabilità ed ampiezza di questo processo è confermato dal susseguirsi di operazioni di M&A (mergers & acquisitions) che talvolta finiscono in prima pagina (il caso più noto ha visto protagonista Facebook, la quale ha acquistato Instagram con un’operazione dal controvalore complessivo di quasi un miliardo di dollari) e tal’altre passano decisamente in sordina; è proprio un’operazione di questo secondo tipo, vale a dire la prospettata acquisizione (almeno dando credito a rumor d’oltreoceano, n.d.r.) di ThisLife, start-up per l’archiviazione e la condivisione di foto, da parte di Shutterfly, azienda che a sua volta fornisce servizi di stampa foto e creazione album, calendari, etc. a fornirmi un case history funzionale ad approfondire ulteriormente l’argomento rispetto a quanto già fatto nell’ultimo post pubblicato.
Le caratteristiche che rendono ThisLife così appetibile sono le seguenti:
1) in primo luogo con questo servizio è possibile importare, in automatico o in manuale, tutte le foto scattate e sparpagliate sui vari servizi (essenzialmente di photo sharing) ai quali siamo registrati / abbonati: Flickr, Picasa, Instagram, SmugMug e naturalmente gli immancabili Facebook e Twitter. Oltre che il “riversamento” dai vari servizi online è ovviamente consentito effettuare pure l’upload dal proprio PC: in questo modo è possibile creare sulla nuvola dei veri e propri album fotografici (ThisLife, come suggerisce il nome e la grafica del sito, punta decisamente su quelli di famiglia ma all’atto pratico possiamo caricarci di tutto)
2) una volta caricate, le foto vengono disposte lungo una timeline che si scorre orizzontalmente e che, di fatto, tende a ricostruire, scatto dopo scatto, avvenimento dopo avvenimento, un’intera vita; a rendere ancor più “circostanziata” la foto nello spazio e nel tempo è la possibilità di taggare luoghi ed eventuali persone immortalate (per gli utenti Pro è disponibile persino il riconoscimento facciale automatico)
3) condivisione (in tal modo rispondendo al succitato desiderio di “apparire” di gran parte delle persone) “controllata” delle proprie foto; infatti, diversamente da altri servizi analoghi, tanto la privacy policy quanto i Terms of Service appaiono da subito più equilibrati: in particolare non viene messa in discussione la titolarità sulle foto da parte del proprietario (ovvero colui che le carica, il quale nel momento in cui effettua l’upload dichiara esplicitamente di possederne anche i diritti) così come si dimostra un particolare riguardo per le foto ritraenti minori
4) corollario a questa impostazione è la chiara attenzione posta al tema della sicurezza; pur non assumendosi alcuna responsabilità in caso di perdita delle foto caricate (sic!) si promette di adottare (per quanto ragionevolmente possibile) le migliori soluzioni tecnologiche disponibili così come di far proprie le disposizioni di legge in materia. Non è dunque un caso se agli occhi dei creatori, i coniugi Matt ed Andrea Johnson, ThisLife rappresenta pure un valido modo per creare sulla nuvola una copia di sicurezza delle proprie foto preferite (a riguardo è da segnalare che proprio per considerazioni di “ridondanza” si può decidere di caricare più versioni della stessa foto, tanto un apposito algoritmo darà la preferenza, nella visualizzazione, a quella con la migliore risoluzione grafica).

I RISVOLTI ARCHIVISTICI

Se queste sono le principali caratteristiche “di funzionamento” di ThisLife, dal punto di vista archivistico questo servizio, che pure non è immune da gran parte dei difetti che notoriamente affliggono i servizi in cloud computing (assenza di controllo sui server che ospitano i dati => sulla loro localizzazione, sul tipo di soluzioni tecnologiche adottate e sulle procedure operative messe in atto; assenza di adeguato ristoro in caso di perdita dei dati; assenza di garanzie sulla continuità del servizio e via di questo passo), presenta delle innegabili novità:
1) nel momento in cui esso consente di recuperare (in automatico o meno) le foto sparpagliate tra i vari servizi presenti sulla nuvola esso finisce per ridare unitarietà ai nostri archivi fotografici (in opposizione alla frammentazione prima vigente); in altri termini ThisLife agisce come un “metacloud” specifico per le nostre foto (mentre ZeroPC, per chi si ricorda il mio post di qualche tempo fa, è più generalista)
2) la presenza di una timeline assicura (tendenzialmente) la presenza di un ordine cronologico alle foto caricate; alla sensazione di ordine contribuisce anche il contatore in basso a sinistra che aumenta di volta in volta che un “momento di vita” viene aggiunto (parlare di numero di protocollo è ovviamente una forzatura ma rende bene l’idea!)
3) la vocazione “familiare” del servizio è comprovata dal fatto che è possibile creare account condivisi (tra marito e moglie, fidanzato e fidanzata, etc.) in modo da far apparire assieme i rispettivi archivi fotografici; anche in questo caso il pensiero corre veloce, pur con i debiti distinguo, al caso degli archivi di famiglia ed alle loro tipiche peripezie (confluiti in archivi di altre famiglie od enti vuoi per matrimonio, vuoi per estinzione di un ramo della “casata”, vuoi per donazione, vuoi per qualsiasi altro accidente della Storia!)
4) il riconoscimento automatico dei volti (con “apposizione” del relativo tag) rappresenta un salto qualitativo nella modalità di creazione dei dati a corredo delle nostre foto che presenta rischi ed opportunità: a) tra i primi, come al solito, quelli inerenti alla tutela della privacy (in definitiva se una macchina è in grado di riconoscere il nostro volto significa che essa è in possesso dei relativi dati biometrici, con tutto ciò che ne consegue!) b) tra i secondi invece si potrebbero segnalare i possibili usi per finalità storiche: non solo gli storici del futuro (ammesso naturalmente che i dati siano leggibili…) potrebbero associare con maggior facilità nomi e cognomi ai volti presenti in una foto, ma anche quelli dei nostri giorni trarrebbero giovamento, nel momento in cui si procede alla digitalizzazione del patrimonio fotografico analogico e vi si inseriscono in automatico i dati identificativi delle persone fotografate, dalla possibilità di lavorare con foto di più facile “lettura”.

CONCLUSIONI

In questo post abbiamo visto come molteplici sono i motivi che ci spingono a “catturare immagini”: la volontà di tenere memoria di un fatto, il desiderio di apparire, la semplice disponibilità di device in grado di farlo ad un costo praticamente nullo… Abbiamo anche visto come le nostre immagini digitali prendono sempre più la via delle nuvole: gli archivi in the cloud infatti eccellono per flessibilità (permettono infatti al contempo di conservare e di condividere le proprie foto), accessibilità (teoricamente h24) e costi ragionevoli (fino alla completa gratuità); gli indubbi vantaggi non possono però far passare in secondo piano gli altrettanto evidenti svantaggi derivanti essenzialmente dal “mancato controllo” (privacy, proprietà, etc.).
Tenendo bene a mente questi poli opposti il case history presentato è dunque importante in quanto dimostra: 1) che alcuni servizi si stanno muovendo nella giusta direzione grazie all’applicazione, fosse anche involontaria, di principi riconducibili alla buona prassi archivistica b) l’importanza di avviare un dialogo (o perlomeno uno scambio) tra iniziative private e pubbliche: le prime ad esempio primeggiano per l’usabilità e piacevolezza della grafica ma peccano sotto il lato archivistico, le seconde al contrario sono dal punto di vista tecnico e della compliance legislativa ineccepibili ma perdono di vista il singolo cittadino, al quale spesso risultano troppo tecniche o ancor peggio non sono nemmeno destinate.
E’ quest’ultimo aspetto, e concludo, quello sul quale occorre velocemente agire: spesso gli archivi digitali di persona (fotografici e non) finiscono in posti “sbagliati” per il semplice motivo che mancano valide alternative. Se vogliamo garantire anche a questi archivi un futuro (nell’attesa che un domani venga valutata la loro rilevanza), dobbiamo fornire, attraverso un fecondo scambio di esperienze e, perché no, una vera e propria collaborazione “operativa” tra pubblico e privato, a tutti i cittadini (e non solo a poche fortunate istituzioni ed enti!) soluzioni di archiviazione adeguate.

Gli archivi sulla nuvola alla prova dell’uragano Sandy

A quanto pare è destino che gli uragani fungano da banco di prova per gli archivi digitali: nel 1995 l’uragano Marilyn colpì violentemente le Isole Vergini provocando vittime e danni ad edifici tanto pubblici quanto privati: sulla scorta di quell’evento il National Media Lab redasse delle linee guida (una sintesi in italiano la trovate all’interno del volume “Memorie digitali: rischi ed emergenze”, pubblicato dall’ICCU nel 2005) su come minimizzare i danni in simili casi.
Alcuni dei consigli forniti allora mantengono appieno la loro validità (in particolare quelli su dove collocare fisicamente i sistemi di archiviazione ed i sistemi ed i supporti informatici contenenti dati, ovvero in piani che non siano il primo e l’ultimo ed in locali non affacciantesi sull’esterno) ma molti altri appaiono anacronistici ed evidenziano quanta strada abbia fatto la tecnologia in questi tre lustri e, di riflesso, quanto la nostra vita dipenda in modo sempre più stringente da quest’ultima.
Un esempio su tutti: 15 anni fa il NML suggeriva di scollegare dalla rete elettrica tutte le apparecchiature elettroniche e di impacchettarle in apposite buste di plastica mentre oggi la lotta con l’uragano Sandy si è giocata tutta, al contrario, proprio sul riuscire ad evitare di finire offline! Del resto all’epoca l’ipotesi di “vivere senza Internet” ed i vari dispositivi tecnologici ad essa collegati per alcuni giorni non sollevava particolari problemi, a differenza di oggi dove la cosa sarebbe vissuta come una tragedia!
Non è dunque un caso se siti e blog nordamericani hanno fatto a gara a raccontare, praticamente minuto per minuto, quali e quanti data center (con relativi servizi) “andavano giù”; molti commentatori infatti hanno sottolineato come fosse, quella presente, una prova del nove della sostenibilità del modello del cloud computing (con annesso servizio di archiviazione) il quale ha come imprescindibile corollario l’essere always on.
Come spesso accade non c’è unanimità sul fatto che la prova sia stata superata o meno: come mostra l’analisi di Renesys (sintetizzata nel video qui sopra) in termini percentuali appena il 10% dei network dell’area di New York sono rimasti colpiti anche se, aggiunge poco sotto la stessa società, considerando la densità di reti è come se l’intera Austria si fosse bloccata, il che non è esattamente una cosa da niente!
Vittime di Sandy, del resto, sono stati anche servizi di primo piano come Gawker (che annovera tra i suoi siti pure il tecnologicissimo Gizmodo!) ed il celeberrimo Huffington Post, tutti “ospitati” nei server della newyorkese Datagram Inc. che, nel momento in cui scrivo, ha da poco terminato di svuotare i propri locali dall’acqua ed opera dunque ancora in regime di piena emergenza.
L’acqua infatti, oggi come per gli archivi cartacei dei secoli passati, si è rivelata ancora una volta essere la minaccia principale: evidentemente molti data center erano fisicamente collocati in locali non idonei (vuoi vedere che macchinari dal valore complessivo di centinaia di migliaia di dollari sono finiti negli scantinati?!) o comunque senza tener conto di possibili criticità idrauliche (l’agglomerato urbano di New York in definitiva sorge su più isole ed è attraversato da grossi fiumi come l’Hudson e l’East River).
Sono stati proprio gli allagamenti diffusi, una volta che la Conedison (la società energetica che serve New York; n.d.r.) ha interrotto l’erogazione di corrente, ad impedire ad un gran numero di generatori ausiliari di entrare in azione! Ma va tenuto presente che anche nei casi in cui i generatori sono correttamente entrati in funzione si è palesata la limitatezza dell’autonomia vuoi perché le scorte non erano sufficienti (le 48 – 72 ore di norma previste sono risultate troppo poche per un’emergenza di questa portata) vuoi perché gli stessi serbatoi erano finiti in ammollo. Questo ha costretto molti tecnici ad un’affannosa ricerca per la città di pompe di benzina per sopperire alla carenza del prezioso carburante! Su “The Verge” Adrianne Jeffries ha spiegato con dovizia di particolari un’emergenza tipo, con i tecnici sistemisti che, una volta riempite le taniche, hanno dovuto travasare a mano il loro contenuto nei serbatoi dei generatori operando in ambienti invasi da un misto di acqua, carburante e rifiuti.
Un’altra criticità chiaramente emersa, e che deve far profondamente riflettere, riguarda poi la collocazione geografica dei centri secondari di back-up e ripristino: è evidente che se i succitati servizi sono andati giù ciò è dipeso dal fatto che non solo i siti primari ma anche quelli secondari hanno fatto cilecca. Difatti è emerso che molti di questi siti secondari si trovano nel vicino New Jersey (vicino in senso relativo; è più o meno come se un’azienda di Milano avesse il suo sito secondario nei pressi di Bologna…), investito anch’esso dalla furia di Sandy.
Ovviamente non tutto è filato storto, anzi, prendendo per buona e rigirando la statistica citata all’inizio si può a buon diritto affermare che nel 90% dei casi le procedure ed i sistemi d’emergenza hanno funzionato a dovere (qui alcuni esempi). Pertanto mi sembra si possa tranquillamente affermare che complessivamente il “modello cloud computing” abbia retto all’urto e che anzi esso, se sarà capace di metabolizzare le lessons learned ovvero:
1) porre serbatoi, generatori e sale macchine in zone al riparo dagli allagamenti,
2) costruire i centri secondari di ripristino a debita distanza dal primario, sacrificando magari qualche frazione di secondo in fatto di tempi di latenza,
potrà, almeno dal punto di vista tecnologico, divenire davvero un modello altamente affidabile tale da assicurare un elevato grado di sopravvivenza ai nostri archivi digitali sulla nuvola.
Certo, resta il problema di fondo della dipendenza assoluta dall’energia elettrica, ma questo è un limite generale della nostra società e personalmente non vedo soluzioni soddisfacenti all’orizzonte (la diversificazione, magari puntando sulle rinnovabili, al momento non è che un palliativo) e pertanto lo lascerei fuori dal dibattito fin qui fatto.
Va infine sottolineata l’eccezionalità, relativamente alle aree geografiche interessate, del fenomeno meteorologico in oggetto ed anzi c’è da domandarsi (ma qui mi rendo perfettamente conto che entriamo nel campo della pura speculazione): quanti archivi, digitali ed analogici, sarebbero sopravvissuti se un’emergenza simile si fosse verificata in Italia?

Con Glacier anche gli archivi storici vanno sulla nuvola

Inside the library

Inside the library di muegyver, su Flickr


LA NOTIZIA

Non sarà passato inosservato ai più l’annuncio, dato da Amazon qualche settimana fa, del lancio di Glacier, servizio di archiviazione sulla nuvola appositamente pensato per quei dati / documenti digitali oramai “vecchi” e poco utilizzati ma dei quali per svariati motivi (prescrizione legislativa, ragioni di opportunità e convenienza, etc.) è prevista la conservazione nel lungo periodo.
Come spiegato in un post di Werner Vogels, CTO di Amazon, il servizio si rivolge ad un pubblico eterogeneo: si spazia dalle grandi aziende alle PMI, passando naturalmente per le giovani e dinamiche start up, senza ovviamente dimenticare gli enti di ricerca, i governi, le aziende sanitarie, le media company, le biblioteche, etc.
A tutti costoro Amazon propone di sottoscrivere un contratto sicuramente aggressivo ed “accattivante”: appena 0,01 dollari per Gigabyte al mese (0,011 qualora come data center di riferimento si scelga quello irlandese) purché non si “movimenti” più del 5% di quanto caricato o non lo si cancelli entro 90 giorni dall’upload; in tale evenienza Amazon applica una tariffa che parte da 0,011 GB nel primo caso e fissa di 0,033 nel secondo (per ulteriori dettagli sul piano tariffario rimando a questa pagina). L’intento è chiaro, ovvero disincentivare gli utenti a fare un uso “improprio” di Glacier che, per l’appunto, è dedicato all’archiviazione (caratterizzata da un relativamente minor numero di operazioni di recupero) e non allo storage di breve respiro; a fungere da ulteriore deterrente a comportamenti “da furbetti”, oltre alla tariffazione, è il tempo stesso impiegato per l’operazione di estrazione dei dati / documenti richiesti, mediamente quantificato in 5 ore!

LE REAZIONI

Dal momento che la stessa Amazon, in linea con tutte le “novità” che gravitano attorno al cloud computing, ha impostato la sua proposta puntando sull’elemento cost-effectiveness, non deve sorprendere che il dibattito sui siti e blog specializzati si sia sviluppato con l’obiettivo preciso di confutare o meno la convenienza del nuovo servizio omettendo quasi del tutto di chiedersi se esso, al di là della dimensione economica, risponda realmente alle esigenze di archiviazione: è banale sottolinearlo ma gli eventuali risparmi ottenibili da soli non giustificano il passaggio ad un diverso sistema di archiviazione, soprattutto qualora quest’ultimo non sia archivisticamente valido almeno quanto quello che si abbandona! Ciò nondimeno, anche alla luce delle perduranti ristrettezze economiche, credo sia utile sintetizzare le posizioni dei due schieramenti, rimandando ai paragrafi successivi per una trattazione più dettagliata delle caratteristiche squisitamente archivistiche di Glacier e delle problematiche sollevate.
I detrattori del nuovo servizio di Amazon si sono sforzati, conti alla mano, di dimostrare come esso non sia competitivo rispetto alle librerie di nastri che vorrebbe pensionare dal momento che costa circa 10 volte tanto (soprattutto in presenza di archivi di notevoli dimensioni; siamo sull’ordine delle decine di Petabyte, n.d.r.). Se da Amazon si sono affrettati a rispondere che per vedere i risparmi bisogna (giustamente a mio avviso, dal momento che stiamo parlando di archiviazione nel lungo periodo) fare proiezioni di spesa che vadano oltre i 5 anni, altri analisti hanno rilevato come i sostenitori delle tape library abbiano omesso di mettere in conto alcune voci di spesa non esattamente irrilevanti, come quelle derivanti dalla necessità di allestire un sito secondario di ripristino oppure ancora una buona quota di quelle di manutenzione e di gestione (e come ben sintetizza Enrico Signoretti, quel che conta è il TCO e non il TCA, vale a dire il costo totale di possesso e non quello di acquisto!); morale della favola, aggiungendo queste ulteriori voci di spesa le soluzioni finiscono per l’equivalersi ma con il vantaggio innegabile, per coloro che si affidano a Glacier, di venir “affrancati” da ogni incombenza diretta sulla materia e soprattutto con la certezza di non venire mai a trovarsi nella poco invidiabile situazione di essere dotati di infrastrutture vuoi sottodimensionate vuoi sovradimensionate (origine nel primo caso di sprechi e di inefficienze, nel secondo di onerosi upgrade); con Glacier, così come con tutti gli altri servizi ispirati al modello del cloud computing, si paga infatti solo in base all’effettivo consumo (pay-as-you-go) con la possibilità di scalare verso l’alto o verso il basso a seconda delle esigenze.

OSSERVAZIONI DI NATURA TECNICA

Come accennato poc’anzi uno dei tratti salienti di Glacier è l’abbandono del nastro magnetico come supporto principe (e low cost!) per l’archiviazione di massa di lunga durata; sollecitata a dare delucidazioni sulle soluzioni tecnologiche adottate, Amazon ha confermato attraverso un portavoce che “essentially you can see [Glacier] as a replacement for tape” che gira su “inexpensive commodity hardware components” (verosimilmente, chiosa l’autore dell’articolo, si tratta di un “very large storage arrays consisting of a multitude of high-capacity low-cost discs”).
Si tratta di una informazione di non poco conto dal momento che si abbandonano i nastri, con la loro lenta memoria ad accesso sequenziale (in sostanza per accedere ad un determinato dato occorre percorrere tutto il nastro a partire dall’ultimo punto cui si era acceduti), in luogo delle più performanti memorie ad accesso diretto: peccato che ciò sia vanificato dai lunghi tempi di latenza (circa 5 ore) entro i quali Amazon garantisce il recupero. Insomma, un servizio low cost ma anche very slow!
Per il resto viene ovviamente posto l’accento sulla ridondanza delle copie: ogni dato viene archiviato in più strutture ed in più dispositivi all’interno della singola struttura, al punto che si garantisce, come anzidetto, la durabilità annuale del 99.999999999% con periodiche, rigorose operazioni di verifica dell’integrità dei dati medesimi.

OSSERVAZIONI DI NATURA ARCHIVISTICA

Dal punto di vista archivistico con Glacier viene fino ad un certo punto ricostituita sulla nuvola l’unitarietà fisica e logica dell’archivio: giusto per restare in casa Amazon se su Amazon Web Services (AWS) va la parte corrente su Glacier va quella storica con la prospettiva, come ricordato da Vogels nel post citato, che in un prossimo futuro le due parti possano dialogare pienamente con il trasferimento dall’una una all’altra.
Ma oltre a questa premessa di cappello ci sono altre considerazioni archivistiche da fare; vediamo in modo un po’ più articolato:
1) poche righe sopra scrivevo che viene a ricrearsi l’unità dell’archivio “fino ad un certo punto”: questa precisazione perché non esiste ad oggi una soluzione intermedia per la fase di deposito né è dato sapersi se mai esisterà! Oramai infatti il cambiamento di status tra le varie fasi, al di là di alcuni aspetti giuridici (ad esempio il passaggio di responsabilità dai responsabili dei vari uffici a quello della conservazione), si risolve dal punto di vista “fisico” nell’allocazione dei dati / documenti in device sempre più omogenei e che differiscono, come ben esemplificano i prodotti di Amazon, “solo” per diverse scelte architetturali e per il livello di prestazioni
2) le cinque ore di tempo di latenza entro il quale Amazon assicura il recupero dei dati e la possibilità di effettuarne il download sono oggettivamente troppi: per anni si è scritto che l’avvento del digitale avrebbe garantito una fruizione universale ed istantanea degli archivi storici, favorendone nel contempo la valorizzazione, ed ora ci si dovrebbe accontentare di un tempo di recupero mediamente assai superiore rispetto a quello occorrente in un Archivio di Stato per vedersi consegnata la busta (cartacea) richiesta?!
Mi si potrà obiettare che non necessariamente i dati / documenti devono essere accessibili al pubblico ed inoltre che, in linea con l’Hyerarchical Storage Management (HSM), è sempre possibile allocare quei dati / documenti “di valore” negli storage device più prestanti, ma ciò vuol dire non tener conto di quanto ultimamente si va dicendo in fatto di big data =>
3) riguardo a quest’argomento assai in voga io stesso in un post di qualche mese fa ho evidenziato come, alla luce degli usi e riusi inaspettati che si fanno (e si faranno sempre più) degli open (linked) data, il relativo life-cycle stia mutando: meno picchi ma al contrario un uso più costante e prolungato nel tempo e soprattutto con numeri di istanze mediamente più elevati. In buona sostanza, considerando che Amazon stessa indica tra i vari scenari applicativi quello degli open data (i quali praticamente per definizione non si sa se, come, quando e da chi verranno utilizzati), non è sensato far aspettare un eventuale ricercatore per ore ed ore! Questo aspetto ci introduce al punto seguente =>
4) il mutato ed imprevedibile data life-cycle dei giorni nostri, al contrario di quello “scontato” che l’ha preceduto (caratterizzato da alto uso durante la fase attiva e poi istanze man mano decrescenti nella fase passiva), rende ovviamente più difficile l’individuazione, che giocoforza deve essere effettuata a priori, di quali dati caricare e conseguentemente delle soluzioni di archiviazione più idonee. Del resto questo problema rimanda a quello più amplio della discrezionalità (in assenza di strumenti avvicinabili al massimario di selezione e scarto), circa cosa caricare e ai conseguenti rischi di rottura del vincolo archivistico
5) critici pure alcuni aspetti denunciati da Andrea Rota (che ha avuto modo di provare Glacier) sul suo blog personale: a prescindere dal fatto che le “operazioni di upload e download possono essere effettuate solo tramite la programmazione delle API di Amazon” (quindi in modo non immediato), Rota sottolinea che “come già avviene per altri servizi di storage di Amazon, i file caricati perdono il loro nome originale, che viene sostituito con una lunga stringa alfanumerica”, motivo per cui “se si vuole tracciare l’associazione fra nome e stringa identificativa, ad esempio per ricercare i file per nome, è necessario mantenere un indice esterno a Glacier oppure usare i metadati associati agli archivi”. Pare dunque di capire che, in assenza di adeguate cautele, vi sia l’elevato pericolo di perdita dei legami esistenti tra i vari dati / documenti.

OSSERVAZIONI DI NATURA LEGALE

Non meno importanti gli aspetti di natura legale sulla valutazione complessiva del servizio: valgono infatti in toto le considerazioni fatte a suo tempo per i servizi di storage sulla nuvola. Non a caso l’uso di Glacier è soggetto al medesimo contratto che regolamenta Amazon Web Services (si veda a riguardo AWS Customer Agreement) ed in particolare, tra le tante, vige la seguente condizione (punto 11; i grassetti sono miei, n.d.r.):

WE AND OUR AFFILIATES OR LICENSORS WILL NOT BE LIABLE TO YOU FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES […], EVEN IF A PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. FURTHER, NEITHER WE NOR ANY OF OUR AFFILIATES OR LICENSORS WILL BE RESPONSIBLE FOR ANY COMPENSATION, REIMBURSEMENT, OR DAMAGES ARISING IN CONNECTION WITH: (A) YOUR INABILITY TO USE THE SERVICES, INCLUDING […] (II) OUR DISCONTINUATION OF ANY OR ALL OF THE SERVICE OFFERINGS, OR, (III) WITHOUT LIMITING ANY OBLIGATIONS UNDER THE SLAS, ANY UNANTICIPATED OR UNSCHEDULED DOWNTIME OF ALL OR A PORTION OF THE SERVICES FOR ANY REASON, INCLUDING AS A RESULT OF POWER OUTAGES, SYSTEM FAILURES OR OTHER INTERRUPTIONS; […] (D) ANY UNAUTHORIZED ACCESS TO, ALTERATION OF, OR THE DELETION, DESTRUCTION, DAMAGE, LOSS OR FAILURE TO STORE ANY OF YOUR CONTENT OR OTHER DATA. IN ANY CASE, OUR AND OUR AFFILIATES’ AND LICENSORS’ AGGREGATE LIABILITY UNDER THIS AGREEMENT WILL BE LIMITED TO THE AMOUNT YOU ACTUALLY PAY US UNDER THIS AGREEMENT FOR THE SERVICE THAT GAVE RISE TO THE CLAIM DURING THE 12 MONTHS PRECEDING THE CLAIM

Condizioni, si intende, che definire sbilanciate è un eufemismo e che peraltro stridono con le numerose rassicurazioni date in ordine all’affidabilità tecnica (si veda il 99.999999999% di durabilità media annuale): non ha senso da un lato promettere mari e monti e dall’altra declinare praticamente ogni responsabilità impegnandosi a risarcimenti spesso irrisori!

CONCLUSIONI

Tirando le somme, Glacier è sicuramente interessante in quanto costituisce il primo esempio di servizio sulla nuvola pensato per la conservazione permanente di dati e documenti digitali, questi ultimi in prospettiva “raccordati” pure con la parte corrente; è questa probabilmente l’unica nota positiva assieme al pricing aggressivo (che indubbiamente costituisce un ottimo biglietto da visita) giacché è bastata la veloce analisi alla quale ho sottoposto il nuovo servizio made in Seattle per evidenziare come esso patisca le consuete “tare”: discrezionalità su cosa caricare con conseguente rischio di rottura del vincolo, assenza di metadati (la cui presenza dipende dalla buona volontà di chi carica i dati), termini legali insoddisfacenti, cui si aggiungono un tempo di latenza imbarazzante e la vexata quaestio se sia o no un vantaggio affidare a terzi la gestione dei propri archivi digitali (o più correttamente delle infrastrutture sulle quali questi risiedono). Come saprete ritengo che almeno le istituzioni pubbliche dovrebbero farsi carico di queste incombenze ma a vedere il trend sono in minoranza…

Tra metacloud e personal cloud passa il destino degli archivi di persona digitali?

Zero PC Cloud - Storage Analyzer

Zero PC Cloud – Storage Analyzer

Di metacloud me ne sono già occupato in questo blog ed in particolare con l’occasione avevo descritto il funzionamento di Zero PC; ritorno oggi sull’argomento non solo perché di recente quest’azienda ha rilasciato la nuova versione del suo servizio web-based (rammento che non ho alcun tornaconto a spingere per questo o quel servizio) ma soprattutto perché le linee di sviluppo seguite sembrano paradossalmente confermare le altrettanto recenti previsioni di Gartner circa l’inarrestabile ascesa dello storage sulla nuvola in special modo da parte di privati.
Quali sono dunque, per iniziare, le novità introdotte da Zero PC? Oltre ad una grafica più pulita ed intuitiva, la nuova release si caratterizza innanzitutto per l’accresciuto numero di servizi terzi che si possono gestire: in particolare ci sono, eccezion fatta per iCloud, tutti i principali provider di cloud storage come Box, Dropbox, Drive, Skydrive, etc. al punto che solo ad essere membri free di questi servizi si raggiunge il ragguardevole valore di 40 GB di spazio disponibile (per vedere in dettaglio quanto ce ne rimane di residuo sui vari servizi c’è l’utilissimo Storage Analyzer all’interno del Cloud Dashboard). Ma Zero PC non è mero un gestore di spazi di “archiviazione” e di backup, anzi la nuova versione dimostra appieno la volontà di andare oltre a questo ruolo: a fianco dell’Universal Inbox (che gestisce tutta la messaggistica, quindi non solo email ma anche tweet), hanno fatto la loro comparsa il browser di navigazione interno, il player in HTML 5 e soprattutto la suite di produttività online ThinkFree che permette di creare documenti in formato .doc, fogli di calcolo Excel e presentazioni in Power Point.
Ne risulta, per l’utente, la sensazione di trovarsi in un unico spazio di lavoro e di archiviazione, connotato da condivisione spinta ed elevata versatilità.
E qui il ragionamento si salda con le previsioni di Gartner (spesso tutt’altro che infallibili ma che nello specifico caso ritengo verosimili) alle quali avevo fatto cenno all’inizio: secondo questa importante società di analisi e di ricerca nel 2016 gli utenti / consumatori caricheranno nella nuvola circa il 36% dei propri contenuti digitali (essenzialmente foto e video; a far da volano al fenomeno è infatti la diffusione di device, come i tablet e gli smartphone, con foto/videocamera integrata) mentre la percentuale di contenuti archiviati on premise scenderà dall’attuale 93 al 64%. Anche quando effettuata in locale non si tratterà più comunque di un’archiviazione “statica”: soluzioni di personal cloud capaci di integrarsi in primo luogo con la propria rete domestica ed in seconda battuta con quelle di altri utenti diventeranno la norma.
Questo mix di storage remoto e locale sarà inevitabile anche in vista della crescita esponenziale dei dati posseduti: sempre secondo Gartner ciascun nucleo familiare passerà dagli attuali 464 GB ai 3,3 TB del 2016. L’uso massiccio e quotidiano che verrà fatto delle diverse tipologie di storage condurrà alla loro trasformazione in commodity: per l’utente finale, in poche parole, un servizio varrà l’altro il che non è esattamente il massimo del desiderabile per le aziende che vi basano il proprio business (di qui l’invito di Gartner, rivolto a queste ultime, a ripensare strategicamente il proprio approccio)!
In effetti già ora con i servizi di metacloud, di cui Zero PC è esempio lampante, tutto tende a confondersi nella mai così nebulosa cloud, al punto che non fa apparentemente differenza che un file risieda su Dropbox anziché su Skydrive (tanto Zero PC mi ritrova tutto e posso spostare lo stesso file da una parte all’altra con la massima facilità!): in realtà le condizioni contrattuali, le soluzioni tecnologiche adottate, la qualità del servizio, etc. che sono alle spalle dei diversi servizi possono differire anche sensibilmente! Ma di ciò l’utente medio non è consapevole oppure non vi attribuisce la dovuta importanza.
In altre parole temo che nel prossimo futuro tutto (da una parte i servizi di metacloud che ti invitano a caricare sulla nuvola tanto ci pensano loro a gestire il tutto, dall’altra l’archiviazione in locale che si fa commodity) concorrerà ad aumentare la “disinvoltura” con la quale gli individui “gestiranno” i propri archivi digitali di persona, con le immaginabili conseguenze in termini di potenziale perdita dei dati, di (mancata) tutela della privacy, di (non) oculata gestione della propria identità digitale, etc. Insomma, prospettive non esattamente incoraggianti!
Concludo però facendo notare come il tipo di tecnologia è sì importante ma non decisivo: dati e documenti sono andati definitivamente persi per noncuranza o semplice ignoranza (ed in alcuni casi per deliberata volontà!) in ogni epoca e a prescindere dalla tipologia di supporti adottati. Come ricordato in altri post il problema che ora si pone in ambiente digitale è che serve una chiara e duratura volontà di mantenere “vivi”, conservandoli nel tempo, i vari oggetti digitali che andiamo creando in maniera esponenziale nel corso della nostra esistenza. Questa volontà, a sua volta, non può prescindere dalla presenza, nel soggetto produttore (il singolo individuo, nel caso specifico) di una particolare sensibilità per queste tematiche e soprattutto la consapevolezza che dei fatti, degli avvenimenti, delle cose teniamo memoria non solo perché è un obbligo di legge o perché ne abbiamo materialisticamente l’interesse ma soprattutto perché la memoria è un valore. Temo purtroppo che i nostri tempi non siano i migliori per un simile scatto culturale.

La natura infrastrutturale degli archivi contemporanei

IMG_20110415_151845 di GrigorPDX, su Flickr

Left: air filters - they look like plain old disposable filters you'd have in your furnace. Right top: louvers leading to outside air Right bottom: louvers leading to the "hot" side of the data center racks.
(Foto di GrigorPDX, su Flickr)


INTRODUZIONE.

In un celebre quanto datato articolo Robert-Henry Bautier, insigne archivista e medievista francese, proponeva una interessante periodizzazione circa la storia degli archivi; in particolare egli individuava quattro fasi, la terza delle quali veniva definita come “celle des archives arsenal de l’authorithé” e che sarebbe stata caratterizzata dalla concentrazione dei fondi all’interno di edifici realizzati ad hoc che erano in tutto e per tutto castelli, vale a dire muniti di fossati, mura e torrioni difensivi in pietra (da manuale i casi del castello di Simancas in Spagna oppure quello di Castel Sant’Angelo nello Stato Pontificio). Dietro a simili realizzazioni stava una concezione che attribuiva ai documenti un’importanza decisiva per il regolare andamento della macchina amministrativa, l’attestazione dei diritti e delle prerogative regie così come per l’attuazione della politica estera (per riprendere Bautier gli archivisti, e gli archivi, “se font auxiliaires de la politique e de la diplomatie“) motivo per cui la dimensione del corretto ordinamento delle carte procedeva di pari passo con quella della loro “sicura custodia”. Insomma, il ricorso a questa terminologia “militaresca” da parte di Bautier non era dettato da semplici motivazioni retoriche ma dalla constatazione di una realtà oggettiva: così come l’arsenale è una struttura deputata alla costruzione, alla riparazione, all’immagazzinamento ed alla fornitura di armi e munizioni, similmente l’archivio era il luogo in cui trovavano riparo quei documenti che sarebbero stati usati alla stregua di armi nel corso delle bella diplomatica del XVII secolo.

I DATA CENTER, ARSENALI DEL XXI SECOLO.

Con le debite differenze, sulle quali torno poco sotto, mi sembra che gli odierni “arsenali archivistici” siano rappresentati dagli enormi data center che si vanno costruendo in giro per il mondo; il paragone appare calzante in quanto 1) in essi si vanno concentrando le “memorie digitali” relative a milioni e milioni di persone, enti ed aziende 2) nella loro realizzazione vengono adottate precauzioni ed accorgimenti del tutto affini a quelle delle basi militari. Basta dare una scorsa alle misure di sicurezza messe in campo da Amazon per capire come l’accostamento con la realtà militare sia tutt’altro che campato per aria:

Amazon has many years of experience in designing, constructing, and operating large-scale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities, and critical facilities have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

Amazon only provides data center access and information to employees who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical and electronic access to data centers by Amazon employees is logged and audited routinely.

Fin qui le affinità; venendo alle differenze, ve ne sono due di macroscopiche: 1) gli archivi residenti nei data center, per quanto militarizzati, almeno in linea di principio non sono concepiti per essere al servizio di un qualche potere vessatorio ma bensì sono la base per offrire “servizi” e/o custodire dati, documenti, etc. di cittadini liberi, di aziende operanti nel libero mercato e di istituzioni democratiche 2) diversamente dai secoli passati, lo Stato sembra latitare ed i principali data center sono di proprietà di colossi ben noti al grande pubblico come Amazon, Apple, Google, Facebook ma anche di provider / fornitori come Carpathia, Cogent, OVH, Rackspace, Digital Realty; operatori che ovviamente poi sono ben lieti di offrire i propri “servizi” ai vari enti pubblici! Ad esempio sia Amazon che Carpathia hanno sviluppato apposite soluzioni per il Governo Federale degli Stati Uniti, il quale attinge largamente in modalità cloud computing a questo tipo di servizi (cliccate qui per una lista parziale); in Europa invece, essendo la legislazione comunitaria relativa al trasferimento transfrontaliero dei dati decisamente più restrittiva, si è molto più cauti nell’affidarsi a privati.
Ciò nonostante, ragionando in prospettiva, è verosimile ipotizzare che nell’Unione Europea o si allenteranno le citate restrizioni al trasferimento dei dati (a riguardo si sta delineando una spaccatura tra stati nordici, non disponibili ad un simile passo, e stati mediterranei, più possibilisti), dando dunque la possibilità di avvalersi dei servizi offerti da privati, oppure si procederà alla realizzazione di data center europei in territorio europeo. Personalmente ritengo la seconda opzione come la più lungimirante per i seguenti motivi: 1) il possedere dei data center è, dal punto di vista archivistico, premessa necessaria (ma non sufficiente) per attuare le indispensabili procedure tese a garantire la continuità operativa ed il disaster recovery (il che consente in primis di salvaguardare la parte “corrente”, vale a dire quei dati e documenti contenuti nei server ed indispensabili per il proseguimento dell’attività “istituzionale” del produttore, ed in ultima analisi di garantire la conservazione nel lungo periodo; ovviamente anche un privato può attuare questi piani ma quando si tratta della cosa pubblica e, soprattutto, sono in ballo aspetti così delicati, sono dell’avviso che la P.A. debba occuparsene direttamente) 2) assicura indipendenza ed in un ultima analisi “libertà”. Il rovescio della medaglia, evidente, è che ci si deve fare carico di tutti i costi: realizzativi, di gestione e di manutenzione.

DATA CENTER: MODELLI REALIZZATIVI, ASPETTI TECNICI…

La maggior parte dei moderni data center non è costituita da pochi supercomputer o pochissimi mainframe, bensì dall’unione all’interno di un medesimo spazio fisico di migliaia di elaboratori di fascia medio – bassa. E’ questo, tra i tanti, l’approccio di Google che significativamente lo definisce wharehouse computing e così lo descrive:

The hardware for such a platform consists of thousands of individual computing nodes with their corresponding networking and storage subsystems, power distribution and conditioning equipment and extensive cooling systems. The enclosure for these systems is in fact a building structure and often indistinguishable from a large warehouse

Tale definizione individua quelli che sono gli elementi principali di un data center ovvero “n” elaboratori, custoditi in una sorta di armadietto definito in gergo rack, a loro volta siti all’interno di un edificio e collegati tra di loro. Da ciò deriva che in un DC ricoprono un ruolo cruciale i seguenti sistemi:
1) UPS (Uninterruptible Power Supply; Gruppo di Continuità), il quale assolve a tre compiti fondamentali, ovvero a) garantire l’erogazione continua di energia elettrica alla struttura e, qualora dovesse verificarsi un’interruzione nella fornitura da parte della public utility, b) far intervenire la batteria fintantoché non interviene il generatore di emergenza, il tutto c) senza che si verifichino dannosi sbalzi di tensione
2) PDU (Power Distribution Units), ovvero il sistema di distribuzione dell’energia elettrica, distribuzione che avviene attraverso quadri e/o interruttori elettrici in genere “annegati” nel pavimento del data center
3) sistema di condizionamento; il metodo più diffuso vede la presenza di CRAC (Computer Room Air Conditioning), vale a dire di “stanze” dalle quali spira aria fredda che, scorrendo sotto il pavimento (tra il pavimento vero e proprio e quello che effettivamente si calpesta e sul quale sono collocati rack, CRAC, etc. può esserci sino ad un metro e mezzo di spazio vuoto; n.d.r.), esce attraverso delle specie di grate giusto in corrispondenza dei rack da raffreddare; l’aria calda uscita dai rack fluisce verso l’alto all’interno di un ulteriore spazio vuoto posto nel soffitto e di qui indirizzata verso il CRAC per riprendere il circolo. Nei DC più evoluti la gestione dei flussi d’aria è così raffinata che ad ogni singolo server perviene la necessaria aria di raffreddamento alla temperatura ottimale (una via alternativa è il cosiddetto in-rack cooling nel quale ogni “armadietto” è praticamente “cablato” da serpentine che fungono da scambiatori di calore; questa soluzione ovviamente ottimizza il raffreddamento ma è assai costosa dal momento che l’impianto di raffreddamento viene ad estendersi su tutta la superficie del centro dati oltre che relativamente più pericolosa giacché, in caso di rottura delle serpentine, il liquido di raffreddamento potrebbe finire sulla parte elettrica… evenienza assolutamente da scongiurare!).

Cabinet Airflow

Cabinet Airflow di talk2stu, su Flickr

Va ricordato, per finire, che per aumentare il livello di sicurezza spesso e volentieri i citati elementi sono ridondanti; così se in un data center Tier I vi è un’unico canale di raffreddamento e di distribuzione dell’energia in un Tier IV (il più elevato della scala) ve ne sono due di attivi oltre che ulteriori percorsi di emergenza. Non va ovviamente neppure dimenticato che fondamentale risulta essere la localizzazione geografica del data center: non dovrebbe trovarsi, ad esempio, in zone sismiche, in prossimità di corsi d’acqua ed in generale in aree soggette ad allagamenti o frane (“a rischio idro-geologico”) così come andrebbero evitate zone troppo fredde od al contrario troppo calde! Inoltre, sarebbe auspicabile che nella realizzazione dei DC europei si metabolizzasse l’approccio “green” di Gartner e, pertanto, si facesse ricorso a fonti di energia rinnovabile.

… E L’OBIETTIVO INDEROGABILE DELLA CONTINUITA’ OPERATIVA.

Castelli e fortezze, spesso progettati dai migliori architetti militari, erano in grado di resistere a lunghissimi attacchi ed assedi senza che si verificasse un sensibile degradamento della loro capacità bellica; similmente tutte le soluzioni tecnologiche descritte nella precedente sezione sono finalizzate a garantire la continuità operativa (business continuity), ossia il normale funzionamento dei servizi ICT utilizzati per lo svolgimento delle attività istituzionali, anche in presenza di disguidi tecnici, di “attacchi” o di altri eventi imprevisti. A fronte di avvenimenti che provocano l’indisponibilità prolungata del data center in cui normalmente si opera / al quale ci si appoggia (sito primario), viene attivato il piano di disaster recovery, il quale prevede l’attuazione di un mix di soluzioni tecnologiche ed organizzative tese a garantire la pronta ripresa dell’attività istituzionale in siti alternativi (detti secondari) rispetto a quelli primari/di produzione per il tempo necessario a rendere nuovamente operativo il sito primario.
Si tratta, manco a dirlo, di argomenti da tempo dibattuti in ambito internazionale ma che in Italia, dal punto di vista legislativo, solo di recente hanno finalmente trovato piena recezione; ad esempio le “Linee guida per il Disaster Recovery delle Pubbliche Amministrazioni”, redatte ai sensi dell’art. 50-bis, co. 3 del CAD (D. Lgs. 82/2005), hanno visto la luce solo nell’autunno 2011 ed imponevano che ogni ente presentasse entro il 25 aprile 2012 un Piano di Continuità Operativa (PCO) ed uno di Disaster recovery (PDR), individuando contestualmente una figura responsabile (RCO). Al di là del fatto che le varie amministrazioni abbiano ottemperato o meno nei tempi prescritti ai suddetti obblighi di legge, mi preme qui rilevare come l’input sia stato essenzialmente “archivistico”: nelle citate Linee Guida si trova infatti testualmente scritto che “il processo di dematerializzazione promosso dal CAD […] ha trasformato da ordinatoria a perentoria l’azione di eliminazione della carta, comporta[ndo] un incremento della criticità dei sistemi informatici che non possono più contare su un backup basato sulla documentazione cartacea”.
Da quanto innanzi detto derivano a cascata alcuni cambiamenti di una certa portata:
1) la continuità operativa ed in subordine il disaster recovery sono possibili a patto di individuare preliminarmente, accanto al sito primario, un sito secondario al quale trasferire come operazione di routine i dati / documenti prodotti dal primario; in caso di “problemi” il sito secondario diviene temporaneamente operativo fintantoché il primario non ritorna disponibile e pertanto deve disporre delle necessarie risorse hardware e software =>
2) nelle procedure di BC / DR diventa un fattore cruciale il trasferimento tra i due siti; le Linee Guida prevedono sei livelli (Tier 1 – 6) nei primi due dei quali il trasferimento consiste nel trasporto fisico (ad esempio a mezzo di apposito furgone) dal sito primario a quello secondario dei dischi ottici contenenti la copia di backup. E’ inutile sottolineare, però, come nell’epoca di Internet, grazie anche all’innalzamento delle velocità di upload / download ed ai migliori tempi di latenza, la Rete sia la soluzione più in voga e come il paradigma del cloud computing sia la soluzione sulla quale oggi si punta di più
3) dando per assodato che il trasferimento dei dati avvenga attraverso la Rete, va osservato che le operazioni di copia (Data Mirroring) finiscono per riguardare anche gli applicativi; le Linee Guida infatti lo definiscono “un processo con cui dati ritenuti critici vengono copiati secondo precise regole e politiche di backup al fine di garantire l’integrità, la custodia e la fruibilità degli archivi, dei dati e delle applicazioni e la possibilità di renderli utilizzabili, ove fosse necessario, procedendo al ripristino degli archivi, dei dati e delle applicazioni presso un sito alternativo a quello primario”. In particolare uno degli obiettivi principali è ottenere l’allineamento dei dati (ovvero il “coordinamento dei dati presenti in più archivi finalizzato alla verifica della corrispondenza delle informazioni in essi contenute”; per inciso l’allineamento, a seconda del Tier prescelto, può essere asincrono o sincrono) ed eventualmente il retroallineamento (ovvero “caricare” i dati prodotti nel sito secondario durante una fase di emergenza in quello primario in vista della ripresa dell’operatività di quest’ultimo) =>
4) dal punto di vista archivistico l’attuazione del Piano di Continuità Operativa significa il trasferimento costante di dati / documenti dal sito primario a quello secondario con questi ultimi che, nel caso di Tier 6, sono de facto speculari, motivo per cui (fatto salvo il caso di mancato allineamento), mi sembra si possa parlare della presenza di originali in duplice copia (per quanto poco senso possa avere la distinzione originale – copia in ambiente digitale). Inoltre è interessante osservare come, proprio perché parte integrante delle policy messe in atto, l’instabilità e l’ubiquità di dati e documenti sia, soprattutto nella fase corrente, più la regola che l’eccezione.
5) il legislatore ha chiaro come le operazioni di backup da un sito all’altro non equivalgono alla conservazione di lungo periodo per finalità storico – documentali; a proposito nelle Linee Guida ci si limita a ricordare come occorra raccordarsi al Manuale di conservazione e come il “salvataggio” debba avvenire su supporti adeguati. Sulla scorta di tali suggerimenti mi vien da ipotizzare due possibili soluzioni: a) all’interno della medesima coppia di data center vanno predisposti dei rack attrezzati con storage server di elevata qualità (diversamente dai rimanenti che, abbiamo visto, possono essere di livello medio – basso) nei quali destinare quei dati e documenti per i quali è prevista la conservazione permanente (la cosa è fattibile in quanto la “destinazione finale” è nota sin dal momento della creazione) b) che accanto alla coppia di data center deputati alla fase operativa / corrente ne venga costruita una ad hoc per quella di conservazione.
A prescindere da quale delle due opzioni prediligere (motivazioni di contenimento dei costi / ottenimento di economie di scala mi fanno propendere per la prima soluzione), va rimarcato come venga confermato che la migliore strategia conservativa sia quella di assicurare (potendolo provare attraverso audit, file di log, etc.), che la vita dei dati / documenti è sempre avvenuta all’interno di un sistema sicuro ed inviolato (e qui ritorniamo alle specifiche costruttive che devono possedere i data center) e che le procedure di copia sono avvenute senza errori.
6) Superfluo, da ultimo, sottolineare come gli aspetti tecnici non debbano mettere in secondo piano quelli organizzativi (come sempre deve venir coinvolta l’intera organizzazione!); mi preme solamente evidenziare come vada assolutamente individuata una catena di comando strutturata gerarchicamente secondo un modello che guarda caso rimanda nuovamente all’ambiente militare.

CONCLUSIONI.

Considerando la formazione prettamente umanistica della maggior parte degli archivisti (sottoscritto naturalmente incluso), comprendo come gli argomenti trattati in questo post appaiano oggettivamente ostici; eppure con tali tematiche occorre confrontarsi in quanto, è la mia convinzione, l’archivio del prossimo futuro coinciderà de facto con i moderni data center. Si tratta di un cambiamento di prospettiva di notevole portata per almeno i seguenti motivi: a) in primo luogo perché si torna a parlare di archivio nel suo complesso e non per questa o quella delle ripartizioni logiche – corrente, deposito, storico – nelle quali la teoria e la legislazione tradizionalmente l’hanno suddiviso b) in secondo luogo perché l’archivio diviene infrastruttura strategica e centrale per il “regolare svolgimento” della vita (digitale) di cittadini, aziende ed enti pubblici c) ultimo perché, della costruzione di tali data center / archivi “arsenali”, devono tornare a farsene carico gli Stati, meglio ancora se in chiave europea, l’unica che può garantire il necessario apporto finanziario nonché quell’ampiezza di spazi geografici tali da rendere la localizzazione dei DC veramente adeguata al raggiungimento dei dichiarati obiettivi di business continuity e di disaster recovery.

A chi volesse approfondire questo importante argomento consiglio di leggere la versione su Storify di questo post, ricca di documenti utili.

Futuro dell’editoria, ruolo delle biblioteche, cloud… e la necessità di una visione integrata

Convegno Stelline 2012 - Valdo Pasqui

Convegno Stelline 2012 - Valdo Pasqui

Scrivo questo post reduce da un autentico tour de force al Convegno delle Stelline / Bibliostar, con tutte le interessantissime relazioni ed i dibattiti da queste scaturiti che mi frullano per la testa… eppure non riesco a togliermi l’idea che in quanto ascoltato ci sia qualcosa che non torna.
Mi spiego: fatta salva la sessione iniziale, ho seguito incontri paralleli e seminari di stretta attinenza con gli argomenti che più mi interessano e che poi puntualmente ritornano in questo blog (vale a dire ebook ed ereader, punti di contatto tra biblioteche ed archivi, cloud computing e via discorrendo), ma ho avuto la netta impressione che gli interventi dei vari relatori, senz’ombra di dubbio tra i massimi esperti nei rispettivi campi, mancassero della necessaria visione d’insieme (sarà forse un caso, ma la relazione che più mi ha colpito è stata quella introduttiva di Maurizio Ferraris che NON è un bibliotecario, insegnando egli filosofia teoretica a Torino). Una serie di esempi renderanno perfettamente l’idea: parlando dell’accoppiata ebookereader si ricordava come il loro uso in ambito didattico non sia la panacea per tutti i mali, essendo (in certi contesti) meno efficaci per l’apprendimento rispetto ai tradizionali testi scolastici di carta; parlando di biblioteca non c’è una visione comune su cosa essa dovrà fare (a proposito quasi opposte le posizioni di Riccardo Ridi e Davis Lankes, con il primo ancorato a compiti più “tradizionali” come quello, tra i tanti, della conservazione ed il secondo tutto proteso verso l’erogazione dei più disparati servizi); parlando di cloud computing ascoltando l’esperto di diritto vien semplicemente da lasciar perdere tutto tali e tanti sono gli ostacoli ed i rischi! Intendiamoci, è comprensibile che essi, proprio perché profondi conoscitori dei vari ambiti, sentano quasi il dovere di evidenziare pregi e difetti, ma potrete capire come l’ascoltatore, dopo essersi sentito dire per due giorni che quelle novità che si ritiene rappresenteranno il futuro non si sa se facciano più bene o più male, non possa sentirsi perlomeno spiazzato.
Tanto più, e qui ritorno al punto iniziale, che mancava nell’analisi una visione complessiva delle trasformazioni; capisco che stiamo parlando di seminari di approfondimento e magari si da per acquisito il contesto di riferimento ma se non si tiene presente il quadro generale il rischio di giungere a conclusioni erronee e drastiche è sempre dietro l’angolo.
Anche perché a mio avviso (e chi ha letto i miei vecchi post ben lo sa) non è possibile scindere la diffusione dei vari device da quella dei contenuti (ebook, ejournal, risorse in genere disseminate su repository in Rete e via discorrendo) e dall’infrastruttura (il cloud) che rendono possibile tutto ciò e che sono nel contempo causa e conseguenza delle trasformazioni in atto a tutti i livelli (di utilizzatore finale, di biblioteca intermediatrice, di editori produttori e/o distributori) nelle modalità di creazione, fruizione e conservazione.
Chiarisco meglio la mia posizione: se rinunciamo agli ebook nella didattica (senza entrare nel merito, ma solo per riprendere l’esempio citato) rinunciamo ad un fattore propulsivo nella diffusione dei dispositivi di lettura; se facciamo a meno del modello del cloud computing e soprattutto all’infrastruttura che lo supporta non solo le potenzialità tecnologiche dei medesimi dispositivi escono ridimensionate ma anche ciò che noi in quanto utenti possiamo fare (usare, creare, salvare e modificare contenuti, condividere, diffondere, etc.); viceversa, senza un’infrastruttura adeguata i nuovi device diventano meno appetibili e a cascata gli ebook hanno meno appeal
Appare evidente che è un sistema altamente interconnesso e che pertanto le biblioteche non possono rinunciare a nessuno degli aspetti elencati a patto di venir velocemente estromesse da queste realtà avanzate; corollario di tutto ciò è, per concludere, che le biblioteche (ma è più sensato parlare del settore dei beni culturali tout court, ma questo è un altro discorso…) inizino a dotarsi di quell’infrastruttura che ne costituisce il presupposto e che attorno a queste creino il proprio ecosistema di relazioni, applicazioni, risorse. Il futuro delle biblioteche è questo e può essere roseo.

Open data a Milano, ma gli archivi dove sono?

Open Data

Open Data di DevelopmentSeed, su Flickr

L’altro ieri il Comune di Milano ha presentato con una certa enfasi il progetto Open Data, con il quale si rendono disponibili (lo evidenzio perché pubblici lo sono già) e soprattutto liberamente usabili quei dati raccolti dal Comune stesso, il tutto con la speranza che i cittadini creino app capaci di migliorare la vita della città dando ad esempio informazioni in tempo reale sul traffico, sui parcheggi liberi, sui tombini intasati, sulle buche presenti sul manto stradale, etc.
Naturalmente l’iniziativa va accolta con il massimo favore, anche se voglio fare un po’ il guastafeste sottolineando un paio di note dolenti / aspetti critici, i primi due dei quali sono di natura “archivistica”, i rimanenti due di ordine più generale: 1) nell’iniziativa milanese sono, in questa fase iniziale, coinvolti la direzione informatica ed il settore statistica con i rispettivi dati; anche se è già stato anticipato che progressivamente verranno resi disponibili tutti i dati di tutte le aree organizzative, mi aspettavo quanto meno un cenno di riguardo per gli archivi (correnti in primis, ma anche quelli di deposito potrebbero fornire serie storiche più che utili!) dal momento che dai documenti in essi contenuti si possono estrapolare dati a volontà! In altri termini rappresentano delle autentiche miniere! 2) i dati sono “pubblici” nel senso pieno del termine, ovvero in quanto provenienti (anche) dai cittadini e non esclusivamente da enti od organizzazioni pubbliche / a rilevanza pubblica; questo punto merita due ulteriori riflessioni: a) se da un lato quei dati provenienti dai cittadini contribuiscono a far funzionare il sistema nel suo complesso, dall’altro va riconosciuto che la loro veridicità (non parlo nemmeno di autenticità, affidabilità, etc.) non può essere paragonabile a quella dei dati provenienti, per stare in tema, dagli archivi b) tutti questi dati confluiscono in una struttura informatica che si rifà al paradigma del cloud computing e vengono aggregati a seconda delle esigenze (avvicinandosi pertanto al modello di vista documentale) 3) prendendo il modello statunitense, che è sicuramente avanti di un paio d’anni rispetto a noi, come punto di riferimento, è evidente come gli open data necessitino, come presupposto, di una tensione civica che non si crea dal nulla! Insomma, non basta “liberare i dati”, ma occorre che muti l’atteggiamento dei cittadini, cosa che non avviene da un giorno all’altro! Che si tratti di una conditio sine qua non ne ho avuto la prova guardando la diretta streaming dell’SXSW in corso ad Austin, nel corso del quale Jennifer Pahlka, fondatrice dell’organizzazione Code for America, ha espressamente sostenuto la tesi che government is what we do together, richiedendo in questo senso una attiva mobilitazione della cittadinanza la quale finisce quasi per “soppiantare” i governi locali 4) ora, ovviamente mi auguro che un simile slancio attraversi l’italica penisola ma anche se ciò avvenisse potrebbe non bastare: la Pubblica Amministrazione italiana, purtroppo, è notoriamente caratterizzata da burocratizzazione, eccesso di formalità e di formalismi, impersonalità (nonostante la 241/1990), opacità e scarsa trasparenza (anche qui alla faccia della 241). Tutte caratteristiche, ahimè, che stridono (tornando oltre Atlantico), con l’obiettivo dichiarato di Code for America, ovvero a) collaborare gomito a gomito con gli amministratori cittadini b) realizzando soluzioni web based capaci di migliorare la città. La collaborazione di cui al punto a) è ottenibile, secondo Code for America, a patto che vengano rimossi gli ostacoli burocratici e ci sia voglia di trasparenza; così facendo si arriverebbe ad un cambio del paradigma stesso con cui si governa la città, sintetizzato dall’efficace slogan “government as a platform“.
Sfide, si intuisce, difficili anche per gli Stati Uniti e che se venissero realizzate in Italia anche solo per la metà rappresenterebbero niente meno che una rivoluzione copernicana per come viene intesa la gestione della cosa pubblica e per il nuovo rapporto che si verrebbe ad instaurare tra amministratori ed amministrati; rapporto, per concludere, assai delicato e che vedrebbe, nel futuro così come nel passato, gli archivi in un ruolo chiave.

Oltre le nuvole

Reset phone. 1st 25 apps I needed or thought about.

Reset phone. 1st 25 apps I needed or thought about. di hillary h, su Flickr

In una realtà tecnologica in continua ed ossessiva evoluzione non abbiamo ancora metabolizzato il concetto di cloud computing che già si inizia a parlare di metacloud; se con il primo intendiamo “un insieme (o combinazione) di servizi, software e infrastruttura It offerto da un service provider accessibile via Internet da un qualsiasi dispositivo” (definizione data da Rinaldo Marcandalli) in che cosa consiste ora questo andare “oltre la nuvola”?
In definitiva non è nulla di trascendentale: di norma con questo neologismo si fa riferimento a quei servizi (uno è Zero PC, lo cito giusto perché vi facciate un’idea) che consentono di gestire in modo semplice ed immediato, attraverso un’interfaccia unica, i contenuti prodotti e caricati su distinte cloud a) principalmente da individui b) che hanno in dotazione molteplici dispositivi. Per fare un esempio concreto se si usa un servizio di metacloud non è più necessario collegarsi a Flickr, Picasa od Instagram per visualizzare le proprie foto così come non serve accedere ai servizi Google per leggere i propri documenti (Google Docs) e mail (GMail); analogamente avviene con Evernote per la propria “bacheca virtuale”, con Dropbox o Box.net per il proprio spazio di storage e con Twitter e Facebook per quanto concerne la gestione delle proprie reti sociali.
Visto sotto questo punto di vista è innegabile che un servizio di metacloud presenta molteplici aspetti positivi: 1) non occorre più ricordarsi su quale servizio / dispositivo si trova tale foto e talaltro documento, in quanto con una semplice ricerca per nome, tag, data, etc. si individua il contenuto desiderato punto e basta 2) dal momento che anche il metacloud è un servizio web based, l’accesso ai propri contenuti digitali è H24 e device independent 3) non occorre più ricordarsi tante credenziali di accesso quante i servizi che si adoperano 4) spesso e volentieri è compreso il servizio di backup automatico dei propri dati e documenti dalle molteplici nuvole (ciascuna corrispondente ai vari servizi cui siamo iscritti) alla “metanuvola” (il citato ZeroPC ad esempio mette a disposizione 1 GB nella versione gratuita).
Quest’ultimo punto ci introduce alla parte più propriamente “archivistica” della questione (ma a ben guardare c’è pure un risvolto “biblioteconomico”, giacché sulla nuvola posso caricare anche la mia biblioteca personale composta di e-book!): come ormai saprete sono fortemente convinto che il cloud computing rappresenti un grosso pericolo per quelli che sono i moderni archivi di persona (diverso il caso di realtà più strutturate come aziende e pubbliche amministrazioni che peraltro sono tenute per legge a gestire e conservare i propri documenti). Infatti tale paradigma tecnologico, unitamente all’esplosione quantitativa degli strumenti di produzione, comporta una frammentazione / dispersione fisica dei propri dati e documenti su molteplici servizi e supporti di memoria al punto che è facile perdere la cognizione di “dove si trovi cosa”. In questo senso la comparsa di servizi di metacloud è la naturale risposta alla perdita di controllo conseguente al passaggio sulla nuvola ed è apparentemente in grado di ridare unità logica (ed eventualmente anche fisica, qualora si proceda al backup sulla metanuvola, poniamo quella di Zero PC) a quelli che altrimenti non sarebbero altro che frammenti sparsi della nostra vita digitale. Purtroppo non son tutte rose e fiori perché un servizio di metacloud soffre di molte di quelle problematiche già evidenziate per il cloud computing, vale a dire a) il rischio di hijacking nella fase critica del trasferimento dati da/per la nuvola / metanuvola, b) policy non adeguatamente esplicitate in fatto di tutela dei dati caricati, di localizzazione dei data center e delle misure di sicurezza ivi adottate, etc.
Partendo dal presupposto che il modello del cloud sia irrinunciabile nell’attuale contesto tecnologico, sociale ed economico, il problema dunque che si pone è il seguente: come mantenerne gli indiscutibili benefici limitando e se possibile azzerandone le controindicazioni (sempre in relazione all’uso da parte di singoli individui; n.d.r.)? Il metacloud è una prima strada che, come abbiamo visto, risolve parzialmente le cose; l’altra a mio avviso non può che essere quella delle personal cloud, alle quali ho già fatto cenno in un precedente post. Quest’ultima soluzione permette un controllo nettamente maggiore (e migliore) dei propri contenuti digitali così come per tutto ciò che concerne la sicurezza fisica anche se ad oggi risulta assai più costosa e sottintende una tutt’altro che scontata sensibilità archivistica in capo al suo “proprietario”, senza che peraltro vengano eliminati gli annosi problemi relativi all’affidabilità, autenticità, etc. dei dati e documenti medesimi.
Insomma, per concludere, neppure le personal cloud sembrano risolvere tutti i problemi, anche se a ben guardare una possibilità ci sarebbe e consisterebbe nel consentire al singolo individuo di effettuare la copia di backup della propria nuvola personale all’interno di porzioni di server appartenenti, che ne so, agli Archivi di Stato, che verrebbero così a svolgere la funzione di trusted repository in favore di tutta la collettività; peccato che tutto ciò presupponga un salto tecnologico, e soprattutto culturale, che allo stato attuale delle cose è pura utopia… Sia come sia l’importante è che l’attenzione sui destini degli archivi di persona nell’era digitale non venga mai meno.