Anche l’informatica ha, come probabilmente tutte le branche dell’agire umano, i suoi corsi e ricorsi storici. Uno di questi è l’oscillare periodico tra la il paradigma del “thick computing” e quello del “thin computing”. Per i non addetti ai lavori, la distinzione riguarda chi svolge le “operazioni pesanti” (in genere i calcoli e la memorizzazione). Nel paradigma “thick” il “terminale” (cioè l’interfaccia fisica con l’utente) è appunto “spesso”, perciò può anche svolgere operazioni di calcolo e memorizzazione, nel paradigma “thin” invece il “terminale” è limitato all’essenziale ed è il “server” che svolge tutte le operazioni.

Thin: i Mainframe

Viene perciò subito in mente l’era dei Mainframe, i giganti server che avevano poi centinaia di terminali “stupidi” composti solo da monitor e tastiera. Gli utenti digitavano, l’input andava al server che lo processava, e inviava al terminale il risultato da mostrare a schermo.

Thick: i personal computer

L’era dei personal computer cambiò questo paradigma. Quando i pc cominciarono ad essere sempre più veloci e potenti, ci si rese conto che si poteva demandare a loro sempre più carico di lavoro, alleggerendo quello dei server. Quando iniziai a lavorare, era ancora l’epoca dei programmi “pesanti” connessi a server “leggeri”, che in genere si limitavano a gestire solo il database.

Tuttavia ben presto il vento cambiò, grazie anche al crescere della velocità delle reti e di internet, ma soprattutto a causa dei problemi tecnici che stavano uccidendo dall’interno il paradigma “thick”. Il problema maggiore, a mio parere, era la babele di linguaggi, sistemi e protocolli, in genere proprietari, che si era creata nel corso degli anni, e che rendeva l’interoperabilità dei sistemi difficoltosa e a volte impossibile.

Thin: i browser ed i web server

L’avvento del web sembrò la soluzione a tutti i mali, il deus ex machina (è proprio il caso di dirlo!) che avrebbe riportato miracolosamente pace e concordia, e reso più semplice la vita di tutti: utenti e sviluppatori. Si tornava perciò al paradigma “thin”: bastava un “terminale” leggero in cui far girare un semplice browser, una connessione sufficientemente veloce, e a tutto il resto avrebbe pensato il (web) server.

Ci fu la guerra dei browser (che ancora continua), ci furono tentativi di creare sistemi standard per far girare pezzi di programmi sui client (qualsiasi sistema avessero, tramite l’uso di “virtual machine” – si pensi a Java e a .Net), ma per tanti anni il paradigma imperante fu di fatto il “thin”. Il web server si faceva carico di tutte le elaborazioni, e come nell’era dei mainframe, inviava al browser l’output da visualizzare, completo e già masticato (d’altronde, “browser” implica qualcosa che si limita a consentire di scorrere delle informazioni).

E’ in questo ritorno al “thin” che nacquero alcuni dei peggiori mostri dell’informatica moderna. L’idea era infatti che i server potessero e dovessero diventare sempre più potenti e intelligenti: con l’aumentare della velocità delle reti e della quantità di persone connesse, le operazioni fattibili con i computer diventavano sempre di più e sempre più complesse, e a farsene carico erano sempre solo unicamente i (web) server.

Questo portò alla creazione delle architetture “multistrato”, a sistemi sempre più complessi per far comunicare tra loro i server (nonché ovviamente ad una guerra sui linguaggi e i protocolli, tale e quale a quella che c’era stata per i pc, ma combattuta su scale diverse e con armi più pesanti), e ovviamente, strato dopo strato, la vita degli sviluppatori divenne nuovamente un labirinto tentacolare di standard e tecnologie, di strati su strati di codice da scrivere, etc.

Alla base di questo “ispessimento” dei server c’era il concetto di “application server”, ed i figli mostruosi che ha creato, come ad esempio EJB o Liferay. Mi soffermo su questa “era” perché ad oggi, nonostante l’informatica abbia già compiuto un altro giro completo (tornando prima al “thick” ed ora di nuovo al “thin” – leggi oltre), nella pubblica amministrazione e nelle aziende carrozzone si continua a richiedere e a proporre soluzioni basate su quelle tecnologie di quindici anni fa, e forse sarebbe ora di passare oltre.

Anche l’era dei “portali dinosauro”  venne superata a causa dei suoi limiti intrinseci, mentre tutt’intorno c’era un pullulare di piccoli “web mammiferi” con soluzioni molto più leggere e veloci. Tra i maggiori limiti dei “portali dinosauro” c’era sicuramente l’enorme quantità di dati ridondanti che venivano scambiati tra browser e server e l’eccessiva complessità e stratificazione del codice. Il primo problema era dovuto al fatto che le “pagine” del portale venivano totalmente rigenerate ad ogni interazione dell’utente, obbligando quindi il server a ricreare e re-inviare l’intera struttura della pagina, andando spesso a fare le stesse interrogazioni e gli stessi calcoli decine di volte. Il secondo problema è lampante se si tenta di leggere un qualsiasi stacktrace di un application server: si rimane invischiati in qualche centinaio di nidificazioni di chiamate, la maggior parte delle quali a invoker che chiamano locator che cercano proxy per chiamare services che a loro volta chiamano invoker e giù a cascata per una decina di strati totalmente ridondanti.

Thick: il web 2.0

Giungi al punto che anche per fare le più banali operazioni occorrevano server degni della NASA, si cominciò a tornare al paradigma “thick”, anche grazie al fatto che nel frattempo i browser erano diventati sempre più intelligenti (e i pc ancora più potenti) e permettevano perciò di svolgere sempre più operazioni sul client invece che sul server. Ci fu perciò un fiorire di tecnologie (ad es. il celeberrimo AJAX, jQuery, Dojo, etc.) che sfruttavano l’ormai standardizzato JavaScript per svolgere sul client le operazioni più banali, permettendo ad esempio di rinfrescare solo i pezzi di pagina che cambiavano con l’interazione dell’utente, e di limitare così lo scambio di dati col server al minimo indispensabile (peraltro, scambiando dati “semplici” senza gli orpelli di formattazione, e demandando al browser e a JavaScript la creazione dell’interfaccia utente, il formato usato per lo scambio dei dati diventava molto più stringato, risparmiando ulteriore banda di rete e tempo).

Nacque così il famoso “web 2.0”, con siti dalla dinamicità sempre più alta ed una nuova spinta a rendere sempre più complessi i compiti demandati al client (ovvero, nel caso specifico, il browser web). Questa fase è tuttora in corso, e molte tecnologie, benché affondino le radici nella notte dei tempi (si pensi alle metodologie REST, che sfruttano le basi del protocollo HTTP) stanno giungendo a maturazione oggi (ad es. Node.js o Backbone.js).

Thin: il cloud computing

Ma ogni oscillazione, giunta agli estremi, comincia a scontrarsi con i limiti propri e delle tecnologie che usa, ed inizia quindi la spinta opposta. E’ quello che sta accadendo proprio in questi anni: è esperienza comune l'”inchiodarsi” del browser in qualche sito eccessivamente “dinamico” che richiede troppe risorse al client, ma soprattutto la diffusione dei dispositivi mobili, con limitate risorse hardware, ha imposto un nuovo cambio di rotta ed un ritorno al paradigma “thin”, con il nome, stavolta, di “cloud computing”.

Poiché ormai usiamo almeno 4-5 dispositivi elettronici a testa, e vogliamo avere gli stessi dati su tutti, la soluzione che ci propongono è di far “vivere” i nostri dati sulla rete, per poi accedervi con qualsiasi dispositivo, anche con risorse limitate. Lo smartphone, il tablet, e gli altri dispositivi, sono l’incarnazione moderna del “terminale” del Mainframe.

Siamo solo agli inizi del ritorno al paradigma “thin”, e ancora non sono evidenti i nuovi limiti con cui ci si scontrerà. Uno di questi è, a mio parere (e i fatti di questi giorni lo dimostrano), il dover affidare i propri dati a degli operatori “terzi”, che non sempre sono degni di fiducia. C’è anche da considerare l’affidabilità dei server, in termini di continuità operativa e resistenza agli attacchi, senza considerare anche l’affidabilità in generale della rete, senza la quale non accediamo ai server. Se i nostri dati sono “altrove” (e questo “altrove”, rispetto ai Mainframe, oggi è estremamente virtuale – è per questo che si parla di “cloud”), ci facciamo ben poco con la nostra “stupida” app, nel momento in cui il server non risponde o non abbiamo la connessione di rete. E possiamo anche star certi che la “privacy” diventa un concetto senza significato.

Nuovamente Thick? Il mesh computing

Se la storia ci insegna qualcosa, è che alla fine di una oscillazione, si torna a quella opposta. C’è da aspettarsi perciò che la risposta ai problemi del “cloud” risiederà in una qualche tecnologia “thick”. Cosa d’altronde ovvia: se con un client “thin” non ho controllo sui miei dati, devo necessariamente ospitarli su qualcosa di più “spesso”.

Cosa sarà, è presto per dirlo, ma a mio parere un buon candidato è il “mesh computing”. Da una breve ricerca, ho dedotto che è un mio neologismo (eppure l’idea non è tanto originale…), che ho coniato per estensione da “mesh networking”. Il concetto è anche molto simile al “grid computing” ed al “peer-to-peer”: di fatto è una crasi dei due (non starò a spiegare in cosa si differenzia, diverrebbe un articolo accademico).

L’idea è che ciascun dispositivo dovrebbe poter funzionare contemporaneamente come client e come server, similmente a ciò che avviene nelle reti “peer-to-peer” tipo Kad o BitTorrent. In questo modo i nostri dati risiederebbero su ciascun dispositivo (non necessariamente tutti su ogni dispositivo, basterebbe un medio livello di ridondanza), e verrebbero sincronizzati in automatico, quando possibile, tra i vari dispositivi. Ciò consentirebbe di avere una notevole resistenza alle catastrofi (i dati sarebbero in diversi posti), una maggiore sicurezza (è l’utente il proprietario di tutti i dispositivi che contengono i propri dati), ed una elevata velocità e disponibilità (il dato che mi occorre è con grande probabilità anche sul dispositivo che ho in mano).

In aggiunta al “peer-to-peer”, che prevede solo lo scambio di dati, il “mesh computing” includerebbe anche la capacità del “grid computing” di distribuire i calcoli su diversi dispositivi (come ad esempio avviene nel progetto SETI@home). In questo modo, il nostro smartphone, che per quanto smart ha un hardware limitato, potrebbe chiedere al fratello maggiore notebook di fare le conversioni dei video o altre operazioni “pesanti”, o addirittura distribuirle tra i vari computer che ho in casa. A differenza del “grid computing”, che prevede in genere una parallelizzazione senza ridondanza, il “mesh computing” (soprattutto in casi in cui i dispositivi sono tra loro distanti e/o con connessioni poco affidabili – in ufficio, a casa, ad Honolulu) prenderebbe in prestito dal “mesh networking” il concetto di ridondanza, sia applicato ai collegamenti tra i dispositivi, sia alla distribuzione dei calcoli.

Ma ovviamente, questa è solo una mia ipotesi. Magari a causa delle spinte politiche ed economiche, l’evoluzione dell’informatica sarà in direzioni totalmente diverse. D’altronde: a chi interessa difendere la nostra privacy?

Quale sarà, poi, il ritorno al paradigma “Thin”?  Beh, decisamente troppo presto per dirlo. Chi vivrà, vedrà.