La scalabilità delle soluzioni software
Segnalo un recente post di Giuseppe Guerrasio, persona che stimo da anni per la professionalità con la quale si occupa in Microsoft di SOA e architetture distribuite. Trovo questo post molto interessante per diverse ragioni e mi stimola a fare delle riflessioni:
- Innanzitutto, come sempre sottolineo anche io quando parlo di scalabilità ai clienti, il concetto di scalabilità è proprio quello di prestazioni costanti al crescere degli utenti, richiedendo eventualmente l'aggiunta di hardware ma non la modifica del codice per supportare il crescere degli utenti. Prestazioni costanti non vuole dire necessariamente "veloce", ma vuole dire solo che non cambiano le prestazioni al cresce degli utenti. Per assurdo una soluzione scalabile potrebbe essere lenta e rimanere costantemente lenta, ma non diventare più lenta ... Mi ritrovo quindi assolutamente nella definizione data da Giuseppe.
- Sessione ASP.NET ... sono anni che io e RoB predichiamo :-) che la sessione non aiuta per nulla a rendere scalabili le soluzioni. Da quando è arrivato .NET, progressivamente dalla v. 1.0 fino all'attuale 2.0, hanno migliorato le cose, per esempio Giuseppe mostra come partizionare in modo furbo e trasparente all'infrastruttura di ASP.NET i dati delle sessioni. In generale continuo a non vedere bene la sessione, preferisco al limite Profile di ASP.NET 2.0 (se proprio ...) o entità custom tipizzate e ottimizzate nella loro persistenza e gestione. Sono anni che sviluppiamo soluzioni senza usare la sessione e, oltre a funzionare :-), scalano pure. In ogni caso è un ottimo esempio di architettura ben pensata il fatto che in ASP.NET abbiano previsto nativamente il partitioning della persistenza dello stato, d'altra parte definire meccanismi di affinità sulla gestione della sessione è comunque pur sempre un grosso vincolo di scalabilità.
- Disegno della soluzione per essere scalabile: altro punto assolutamente fondamentale. Il software non può diventare scalabile, deve nascere pensato per essere scalabile. Quando parlo di WCF sottolineo sempre quanto sia bello vederne l'architettura, capire quali e quanti siano i suoi punti di estensione. Prendere in esame un'architettura come quella di WCF aiuta a capire come dovremmo pensare il software moderno. Di recente mi sono imbattuto in persone che sostenevano che tutto gira solo intorno al concetto di entità, che per altro condivido per la gran parte delle soluzioni, e che poi l'infrastruttura di backend (DAL), la logica di business (BIZ) e tutto il resto ... contano relativamente. Se l'applicazione non è performante a causa della qualità del codice nel DAL ... basta aggiungere ferro e miglioreranno le prestazioni. Primo: scalabile non vuole dire veloce, quindi ritornando al punto di partenza, non ha senso associare i due concetti. Secondo: scalabile significa che aggiungendo ferro abbiamo la possibilità di servire più utenti, mantenendo costanti le prestazioni, non che li serviamo più in fretta se aggiungiamo ferro ... altrimenti vuole dire che la nostra architettura e il nostro codice non vanno bene, la scalabilità non c'entra. Terzo: le entità sono fondamentali in molte soluzioni, per disaccoppiare dallo strato di persistenza e per consentire a chi sviluppa la logica di non preoccuparsi dello strato fisico sottostante. Da qui a dire che a 'sto punto lo strato fisico di persistenza può essere fatto anche male, meglio comprare RAM o dischi che non perder tempo a scriverlo bene ... ne passa ...
Insomma: ottimo post, leggetelo!