Ho alcuni commenti dopo aver letto il PDF della presentazione ed i due articoli apparsi qui (http://blogs.ugidotnet.org/raffaele/archive/2006/12/29/63835.aspx e http://blogs.ugidotnet.org/janky/archive/2006/12/29/63824.aspx) e vorrei condividerli con voi.
La prima cosa è che tra le cose condivisibili dell'architettura trovo che alcune siano la scoperta dell'acqua calda (ad esempio che l'applicazione deve essere stateless e che si deve usare la cache al meglio, non mi sembra sta gran scoperta!).
L'altra è che mi sembra che la scelta architetturale di eBay parta da un problema molto semplice: che avevano raggiunto breve tempo (1998-2000) i limiti fisici dello strato di database. La scelta di alleggerire al massimo questo strato mi sembra direttamente collegata al fatto che, ad un certo punto, anche acquistando i database server più grossi e ciccioni in grado di ospitare Oracle comunque il loro limite alla scalabilità era il database.
Da questa considerazione nasce il resto dell'architettura, ovvero (per dirla in un altro modo) mi sembra che la scelta di design sia determinata dal fatto che la scalabilità richiesta (i famosi 26 miliardi di query al giorno) non può essere garantita da nessuna piattaforma DB (ne presente ne futura) a meno che le query non fossero extra semplici, quindi eliminando tutto quello che, lato DB, consuma risorse (integrità referenziale e stored procedure) per portarle in un ambiente che scala facilmente.
Le scelte successive (come ad esempio scrivere uno strato di ORM proprietario che immagino consenta di automatizzare la gestione delle parti eliminate dal database) nascono poi da questa necessità di base.
Quindi la mia considerazione è la seguente e nasce da un discorso molto semplice: che l'architettura si deve focalizzare sulla necessità del business e non viceversa. eBay è un business molto particolare la cui richiesta più importante è quella di una grande scalabilità e direi anche che su scala mondiale è probabilmente il sistema "transazionale" che ha questa necessità al livello più elevato. La sua architettura e le sue scelte sono quindi pilotate da questo fattore, che le condiziona in maniera pesante.
Nel momento in cui dobbiamo scegliere un'architettura per la nostra applicazione dobbiamo fare lo stesso ragionamento: quale è la nostra necessità primaria considerando il business? E partire da lì. Non dire "siccome questa architettura la usa eBay la usiamo pure noi". Personalmente alcune delle scelte di un'architettura come quella di eBay (integrità referenziale sugli application server e nessuna stored procedure) mi lasciano estremamente perplesso, a meno di non avere una motivazione forte per sceglierle (e 26*10^9 query al giorno sono una motivazione molto forte, ma quanti altri raggiungono questi volumi anche considerando un anno invece di un giorno????).
E questo ragionamento lo si vede proprio nella presentazione stessa, verificando come l'architettura, nel tempo, si sia evoluta sulle necessità del business. La prima architettura (quella fatta in soggiorno) non scalava per niente ed era probabilmente molto scarsa (memorizzava su file system!), ma rispondeva alle esigenze (andare online in fretta), la seconda si è focalizzata sul rendere il database "partizionabile", quella attuale si concentra sulla scalabilità. Un bell'esempio di come evolvere i propri strumenti in parallelo al proprio business.
L'altra cosa interessante invece io la vedo nella frase "Throw out most of J2EE"... probabilmente partendo adesso potrebbero rifare tutto usando C# e Mono ed ottenere gli stessi risultati...