La mia e' una opitesi, non so se e' davvero quello che si intende.
Comunque mandare il tutto in formato compresso, stile filmato, non sarebbe piu' pesante di uno stream di youtube.
Certo la qualita' sarebbe quella 
Ma e' di questo che stiamo parlando? Zero, illuminaci
No non è di questo. Non parlo di calcolo distribuito 3D e mignottate alla marketing Sony
Azure funziona con un doppio concetto (che non è un concetto di Azure, ma la base per i sistemi di cloud computing), le applicazioni distribuite (che possono essere Web, RIA o semplci client) ed i worker process. I worker process sono replicabili e distribuibili su base geografica e, sostanzialmente sono un loop che si autodiagnostica e capisce quando le cose vanno prestazionalmente male (così si "clona" per mantenere le prestazioni elevate). Se la tua applicazione risiede nel cloud (perché è una Web Application, o una RIA, oppure un pluggozzo flash) anch'essa godrà dei vantaggi di replicazione e distribuzione amorfa.
Con un worker process puoi fare ad esempio il processo che aggiorna lo stato del mondo di gioco. Il vantaggio è che non esiste mai un solo worker process, ne esistono tanti quanti ne servono, sincronizzati tra di loro. Ogni worker process è in grado di valutare se sta "soffrendo" e lo comunica alla piattaforma, che magari lo replica se hai ancora quota a disposizione.
Immaginiamo una situazione che già adesso è piuttosto tipica nei giochi: il mio server gestisce tutto il traffico tra i client. Funziona tutto, il mio server (ed i miei client) perdono tantissimo a fare byte packing e a comprimere per non congestionare il flusso in tempo reale (o per non richiedere una connessione da qualche megabit obbligatoria). Il problema è che gran parte dei contenuti che trasferisco sono risorse per lo più statiche o di importanza secondaria rispetto al protocollo sincrono di cui ho bisogno per il gameplay, ammesso che abbia bisogno di un protocollo veramente sincrono e non possa simularlo.
Quello che fa il mio gioco è aggiornare costantemente dei database, fare l'appello dei client ad ogni network tick e applicare le regole di gioco poco altro. Gran parte di ogni tick lo perdo con il DB e gran parte del tempo di sviluppo lo perdo ad ottimizzare come aggiornare il DB senza che esso rimanga inconsistente permettendo exploit. Spesso i client mi fanno fare sempre le stesse cose con le stesse informazioni (come quando attacco con la mia arma o quando un nemico attacca me). In alcuni casi (giochi con eventi molto dinamici) parte dei risultati di script delle quest o delle missioni, devono essere mandati al client ogni volta che accadono. Non è semplice gestire tutta sta roba.
Ora, ottimizzazioni a parte, ad oggi questi scenari possono essere mitigati utilizzando le normali tecnologie web a disposizione (come i Web Service o le comunicazioni distribuite in generale), che sanno fare bene una cosa: il caching delle query e la gestione delle cose on demand. EVE Online è completamente gestito così (anche se sembra un gioco sincrono), Dofus, Wakfu, Trackmania anche (i server di Trackmania sono deployabilii anche come semplici script PHP). La sincronicità nella maggior parte dei giochi è del tutto non necessaria server-side (forse solo i giochi di sport e gli FPS la richiedono) e viene simulata client side. Inoltre, ormai nn esiste nemmeno più il modello alla ultima online, dove lo stato del mondo viene salvato ogni N tick: tutto è sincronizzato subito, paradossalmente questo vuol dire che sino a che il client non interagisce per modificare qualcosa, per il server sarebbe meglio se quel client non fosse proprio attivo! E questo col cloud computing riesci a farlo bene. Ci sono ambiti dove anche un protocollo usato in polling con un formato molto inefficiente per il real time (come i Web Service SOAP) è comunque migliore di un protocollo sincrono gestito a mano, proprio perché a me non serve controllare paranoicamente tutti i client ad ogni frame di rete!
Quello che fa il cloud è spingere in concetto un pelino più avanti: il DB non mi serve proprio. Piuttosto che usare un vero database (che non mi risolve i problemi e serve per fare altro, in sostanza), strutturo un sistema ad oggetti relazionale distribuito, con diversi modelli di storage (ma integrabili tra di loro), in grado di autosincronizzarsi su base geografica tramite una backbone ad alte prestazioni. In questo modo creo i presupposti per i miei client di lavorare in maniera quasi-sincrona anche su base planetaria (cosa che oggi non è possibile), senza degrado percettibile delle prestazioni, grazie anche al fatto che ogni mio nodo di storage è replicato almeno a 3 volte. Inoltre, spostando tutto da un real time ad un quasi real time, ho il vantaggio di lasciare un sacco di tempo in idle sui server per fare altro (in questo altro ci va pure la gestione delle app distribuite di qualcun'altro). Questa è la ragione per cui EVE riesce a tenere anche qualche migliaio di giocatori "a vista" con un server unico (la lag che si percepisce è un problema di client, non di server): se un client non fa nulla, non aggiorna nemmeno la sua posizione e non ha keepalive da mantenere o tick da gestire.
Lo scenario è sicuramente molto buono per giochi che hanno uno scarso bisogno di sincronicità ma che vogliono però garantire una infrastruttura online omogenea per i suoi giocatori. Se ci pensate non sono pochissimi. Anche i giochi sincroni (ad es FPS) possono trarne molto vantaggio: ad esempio per i sistemi di matchmaking centralizzato o per le contact list, le friend list, i gruppi, etc... Sono attività che se fatte utilizzando le tecnologie moderne distribuite si fanno in pochissimo tempo con risultati di molto superiori ad una gestione dedicata (questo è perché Microsoft ha un ottimo sistema come Live mentre gli altri sono ancora a delle proto-piattaforme: Microsoft sa come è fatto un sistema distribuito a servizi di classe enterprise e lo ha semplicemente replicato per la sua piattaforma di gioco).
Si parla addirittura di fare l'offload di task sincroni non criticissimi, come ad esempio le collisioni con l'ambiente, che normalmente non vengono calcolate ad ogni tick, come avviene invece per le traiettorie dei proiettili e la posizione dei giocatori.
Anche solo poter mettere sul cloud la gestione di aspetti secondari per un gioco online come la chat, la gestione dei contatti, elementi di gioco secondari come la posta, le auction house, il crafting, etc.. ha un vantaggio altissmo sui costi di gestione. Anche SOE in piccolo ha una struttura simile per gli elementi secondari dei suoi MMOG e non a caso, tranne Microsoft è l'unica che offre un sacco di servizi web ai propri giocatori, tutti innestati direttamente nella sua piattaforma online. Solo che SOE ne paga la gestione in prima persona e con poche applicazioni è vero che ottimizzi ma non ottimizzi molto.
Qui si tratta di far sincronizzare tutta sta roba ad un attore terzo che più applicazioni ha e più, paradossalmente, riduce i suoi costi di gestione ed i tuoi costi d'esercizio (anche se ho 10 applicazioni che sono a fare qualcosa il 90% del tempo, con quello che rimane ho le risorse per gestire una undicesima applicazione).
Ho banalizzato tutto per far capire il senso generale.
