Le applicazioni basate su Fat-Client si riferiscono alla categorie delle applicazioni multistrato dove (nel modello più semplice) la parte client del codice (ovvero tutta quella parte costituita dai programmi con cui l’utente finale interagisce direttamente) risiedono e “girano” nel contesto del Desktop PC mentre la parte server (generalmente i programmi che gestiscono l’interazione con i database relazionali) risiedono e girano sul server di rete.

Al contrario, nel modello basato su Thin-Client, si rifersice alle applicazioni multistrato dove la parte di codice con la quale l’utente integragisce risiede e viene fatta girare all’interno di un browser ma l’esecuzione del codice che l’utente invoca avviene interamente all’interno del server di rete, non nel PC.

Fatte queste precisazioni è bene prendere in esame quattro regole fondamentali :

1. Per applicazioni identiche, la migrazione dal modello Fat-Client al modello Thin-Client non riduce il fabbisogno di risorse di calcolo: queste vengono solo spostate dal PC desktop al Server;
2. Per applicazioni identiche, la migrazione dal modello Fat-Client al modello Thin-Client non riduce il fabbisogno di banda disponibile: al contrario questo viene spostato dalla infrastruttura LAN/WAN alla Intranet/Internet;
3. Per applicazioni identiche, le unità di calcolo necessarie per servire x utenti sono identiche sia per il modello Thin che per quello Fat;
4. Per applicazioni identiche, la migrazione dal modello Fat-Client al modello Thin-Client non riduce il costo dell’applicazione e, anzi, molto spesso lo aumenterà.

Nessuna riduzione nelle risorse di calcolo necessarie.

Una applicazione Fat-Client utilizza le risorse di calcolo e la potenza messa a disposizione dal desktop pc e dalla banda disponibile per la LAN. In un tipico modello Fat-Client, quasi tutto il carico di lavoro viene eseguito dal pc desktop.
Per esempio, in una applicazione Fat-Client che serva 500 utenti, quasi il 90% delle risorse di calcolo sono impegnate dai pc che, in modo asincrono eseguono l’applicazione, mentre solo il rimanente 10% viene impegnato dal server.

Il deployment di una applicazione Fat-Client generalmente comporta l’utilizzazione dei PC già esistenti nella struttura ed un server (database/application) relativamente piccolo. Solo qualora il numero di client dovesse aumentare significativamente, potrebbe essere necessario ampliare il database server.

Quando si migra da un modello Fat ad uno Thin-Client, le necessarie risorse di calcolo non spariscono per magìa: deve essere comunque disponibile la medesima capacità di calcolo. Ma siccome non si sta più utilizzando la potenza di calcolo offerta dal Pc è necessario dotare il server applicativo di quella potenza extra dovuta al numero di unità di processo che sono state spostate dal client al server. In altre parole il nuovo server deve essere in grado di svolgere anche le attività che svolgevano i singoli pc.

In conclusione la modifica del modello non comporta nessuna ottimizzazione delle risorse a parità di applicazione: si tratta solo di modificarne la distribuzione caricando di più i server nel modello Thin-Client.

Nessuna riduzione delle risorse di banda

E’ opinione tanto diffusa quanto errata che la migrazione ad un modello Thin-Client possa portare dei benefici in termini di risparmio su costose strutture di comunicazione. La realtà e molto diversa e per rendersene conto basta provare ad accedere ad un applicazione server web durante un momento di picco oppure parlare con un ISP su quali siano i costi da sostenere per ospitare un servizio applicativo in modo affidabile.

Una efficace soluzione Thin-Client richiede ingenti costi in infrastrutture: a partire dai server, dagli switch, dai router fino a considerare i costi elevatissimi di una Intranet geografica.

La potenza di calcolo complessiva non cambia.

Per applicazioni identiche ci vogliono sempre e comunque x unità di processo per servire un singolo utente sia nel caso di un Fat-Client che nel caso di un Thin-Client. Ma mentre nel primo caso è il PC che svolge la maggior parte del lavoro, nel secondo caso lo stesso lavoro viene ricaricato sul server.

La migrazione da un modello Fat-Client ad un modello Thin-Client sicuramente aumenterà i costi complessivi dell’applicazione.

Se immaginiamo di migrare 500 utenti da un modello Fat ad uno Thin la prima cosa che salta all’occhio è il fatto che, di certo, non si smonta la ram in eccesso dai PC per montarla sui server e non si può rimandare indietro mezza CPU per chiedere un rimborso. Non vi è nessun beneficio immediato in termini di risparmio economico che potrà avvenire se, e solo se, i prossimi pc verranno acquistati con caratteristiche di capacità di calcolo molto ridotte.

Se il modello Fat comporta l’installazione del codice dell’applicazione su ogni macchina si potrebbero ridurre i costi di manutenzione del software client adottando un modello Thin-Client, ma se, come dovrebbe essere, il codice viene distribuito mediante idonei application server, allora i risparmi offerti da un modello Thin sarebbero veramente minimi.
In realtà, in ogni caso, i risparmi sarebbero minimi comunque dato che la maggior parte delle risorse di manutenzione viene impiegata per il buon funzionamento della rete, delle applicazioni desktop come Microsoft Office, Outlook, Autocad ecc. e quindi fondamentalmente il numero di risorse uomo allocate per queste attività non cambia.

Perchè il costo di un’applicazione Thin client è di molto superiore ad una equivalente ma basata su Fat client ?

Dalla lettura delle prime quattro regole esposte all’inizio appare evidente come i principali problemi siano :

• Replicare la potenza di calcolo di un pc per ogni utente on-line
• Il costo incrementale di ogni utente aggiuntivo

Quando si aggiungono utenti ad una applicazione Fat, il 90% del carico di lavoro viene assolto dal Pc mentre l’aumento di carico di lavoro del server è marginale. Al contrario, in un modello Thin-Client, per ogni utente aggiunto da servire, il server dovrà fornire la maggior parte delle risorse di calcolo necessarie per la nuova sessione e, in assenza, tutti gli altri sperimenteranno un degrado generalizzato delle performance.

In una applicazione Fat la potenza di calcolo è decentralizzata al contrario di quanto avviene nel modello Thin che, per naturale conseguenza, a parità di hardware, raggiungerà molto prima il limite critico di utenti servibili.

Quindi perchè è sempre più alto il numero delle applicazioni Thin Client ?

Molte aziende adottano questo modello seguendo alcune linee guida

1. Riduzione dell’impegno totale di risorse disponibili per la WAN : purtroppo, come abbiamo visto questo non è assolutamente vero.
2. Riduzione dei costi di manutenzione dei singoli PC : vero in minima parte. Se si considera che i pc vanno comunque tenuti in buono stato anche solo per il loro sistema operativo e le applicazioni tipicamente desktop come Office allora il costo marginale dovuto alla manutenzione di una singola applicazione è praticamente azzerato.
3. Maggior controllo sull’applicazione: il gestore di una applicazione Thin ha sicuramente dei vantaggi nell’adozione di questo modello in termini di rapidità e facilità nel deployment di nuove release. Per converso si deve anche sobbarcare l’onere di gestire una struttura server più complessa.
4. Migliorare i tempi di risposta dell’applicazione : le risorse di banda e di calcolo non cambiano nei due modelli. Il problema non viene risolto adottando un modello piuttosto che un altro: semplicemente si spostano da un estremo all’altro.
5. Utilizzare le più recenti tecnologie hardware e software: è in dubbio che gli sviluppatori cercheranno di utilizzare al meglio sempre le migliori tecnologie disponibili che li aiuteranno in un più rapido sviluppo. Ed è indubbio che sia molto più realistico aggiornare i server di rete piuttosto che l’intero parco PC Client.
6. Risparmiare : è molto improbabile, direi impossibile, che si possa risparmiare denaro implementando la migrazione di una applicazione da modello Fat a Thin.

Tutto quanto sopra poi non sfugge ad una regola che impera sovrana nel mondo IT : il trend della moda. Fino a solo un paio d’anni fa lo sviluppo di applicazioni di Thin-Client era considerato il non plus ultra della modernità per raggiungere in modo uguale utenze disomogenee per quanto riguarda gli apparati e i sistemi operativi (un’applicazione Web funzionerà verosimilmente allo stesso modo sia con Windows che con Linux). Tuttavia l’evoluzione ha negato se stessa: l’avvento in massa degli smart-phone e dei piccoli PDA, a bordo dei quali il browser è molto poco efficiente, ha messo in gioco un terzo modello, il Tick-Client, che sfrutta al meglio le risorse di calcolo offerte dall’hardware presso cui è ospitato e rimanda al modello web solo per quanto riguarda l’effettiva trasmissione dei dati.

Non va sottovalutato anche un fatto essenziale : quasi tutte le applicazioni Thin-Client si basano sul paradigma web/http che, come noto, è un protocollo di comunicazione privo di congnizione di stato. Ne consegue che le applicazioni Thin, per quanto concerne il loro lato server, sono molto più onerose delle omologhe applicazioni basate su Fat-Client in quanto ad ogni richiesta di sessione devono ricostruire lo stato originario. Non ultima la sempre maggiormente estremizzata ricerca di far assomigliare le interfacce Thin a delle vere e proprie interfacce Fat iniettando nel codice HTML sempre più pesanti informazioni grafiche, codice di scripting ecc. che ha come effetto indesiderato quello di aumentare notevolmente la richiesta di banda.

Insomma … pensare che una nuova applicazione possa avere come unica soluzione quella di essere sviluppata necessariamente come Thin-Client può essere un grave errore.