I sistemi distribuiti solitamente sono pensati per servire una moltitudine di utenti. Essi quindi si portano dietro nativamente il problema di scalabilita'.

Ma che cosa significa scalabilita'? Saper service 1.000.000 richieste al secondo? Essere installato su 1000 server? Mettere un servizio per server? “Scalabilita'” non vuol dire quello, ma vuol dire piuttosto che il nostro set di servizi sono in gradi di garantire il servizio all'aumentare delle richieste incrementando semplicemente (mica tanto, ma per dare l'idea) delle risorse, siano hardware o di rete. Un sistema distribuito di servizi perfettamente scalabile potrebbe essere installato su 1 solo server cosi' come su 400 server. L'amministratore decidera' autonomamente come installarli in base ai consumi di risorse.

Possiamo quindi porci la domanda sul perche' chiamiamo sistema distribuito se poi alla fine potrebbe stare tutto su un singolo server. La risposta e' semplice, minimizzare i costi. Perche' far pagare al cliente N server (hardware, software, reti, manutenzione, ecc) quando per il carico di utenti iniziale e' basso? Nel momento in cui aumentano i consumi di risorse, l'amministratore puo' decidere di “spostare” i servizi (nel caso anche uno solo) piu' esigenti su un'altro server e il tutto deve funzionare (on/off).

Ma come scrivere un insieme di servizi che permattano all'aministratore dei decidere? I nostri servizi dovrebbero essere progettati con il concetto dell'operation in mente. Una serie di servizi perfettamente monitorabili permettono di dare all'amministratore (cliente) gli strumenti per decidere. Come fare? Per esempio leggersi il “Design for Operation” :-)

Basta questo a rendere il nostro sistema scalabile? Ovviamente no, ma se facciamo uso di una buona infrastruttura di messaggistica (es, Windows Communication Foundation) allora il lavoro diventa gia' piu' semplice. Mancano ancora molti tasselli al mosaico, ma da qualche parte bisognera' ben iniziare, no?