giugno 2007 - Posts
Se volete avere un'idea di come e quanto debbano scalare i server di Microsoft ... buona lettura.
Tutto sommato 80 web server in NLB non sono nemmeno troppi per un traffico simile.
Più di una persona mi ha chiesto chiarimenti in merito alla distribuzione dei contenuti nel corso "Intensive SharePoint Training for Developers" che organizziamo a Bologna il 26-27-28 giugno 2007, in collaborazione con GreenTeam.
Qui trovate maggiori dettagli sul corso: http://www.greenteam.it/italiano/formazione/IntensiveSharePoint2007.aspx.
Il dubbio più ricorrente tra i partecipanti è quanto saremo sbilanciati su Workflow e quanto su SharePoint. La mia idea è di fare un 50%/50% o forse, in funzione del parere dei partecipanti, un 60%/40% in favore di SharePoint.
L'idea che ho in mente è di sviluppare per circa un giorno e mezzo (intensive) concetti quali: SharePoint Object Model, Custom column, EventHandler, Features, SharePoint Web Services, WebPart e Master Page, Business Data Catalog.
Poi dedicherei un giorno (circa) a trattare Windows Workflow Foundation, con un punto di vista orientato a capire non sola cos'è e come si usa, ma anche come si innesta sull'infrastruttura di SharePoint 2007. Di solito di WF ne parlo per 3gg, nel corso dedicato all'argomento, quindi non vedremo tutto, ma solo ciò che ha senso conoscere per lavorare con WF e SharePoint 2007.
Infine vorrei chiudere con mezza giornata sullo sviluppo di workflow per SharePoint con WF e Visual Studio 2005, tema sul quale si trova ancora poco materiale in giro e che spero quindi risulti interessante.
Ora: se i contenuti sono in target con il vostro interesse ... iscrivetevi as soon as possible perché mancano solo 10 giorni e il corso è ormai quasi al completo...
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!
Segnalo un post di Luca Bolognese, nostro connazionale e Lead PM di LINQ, che ripercorre gli ultimi 6 anni di vita di LINQ, ricollegandosi ad un post di Matt Warren sulla storia di LINQ to SQL. Fa riflettere ...
Come segnalato da Unverified Claims (geniale il nome!) ci siamo quasi ... tra un mesetto dovrebbe diventare una specifica OASIS definitiva, se tutto va bene.
Segnalo un post interessante, non dal punto di vista tecnologico, ma come spunto di discussione. In sostanza si evidenzia il fatto che Bill Gates, in una intervista del 1987, aveva previsto molto di quello che oggi (20 anni dopo!) è disponibile sul fronte tecnologico. In effetti pensando anche ai libri che Bill Gates scrisse alcuni anni fa, è curioso notare che molto di quello che "sognava" si è realizzato. Pensiamo alla domotica, a Microsoft Surface, ai device Windows Mobile, ecc. D'altra parte non è certo l'unico ad averci azzeccato! In generale non mi soffermerei tanto sul fatto che Bill Gates è in grado di prevedere il futuro :-), ma sul fatto che comunque la tecnologia, e lo sappiamo, corre davvero molto. Sarebbe divertente provare ad immaginare cosa avremo tra altri 20 anni.
Chi vuole scommettere? Secondo me tra 20 anni potremo usufruire dei benifici della tecnologia nella biomedica (penso soprattutto ad ausili visivi e acustici veramente poco invasivi e/o alternativi agli organi attuali. Un bel occhio elettronico o un orecchio elettronico o una voce virtuale) e nell'ottimizzazione dei consumi energetici e di risorse. Non credo troppo ai viaggi nello spazio, né tantomeno alle auto volanti (tanto care ai film di fantascienza) non fosse altro che per ragioni di praticità e di gestione del traffico. Vedo meglio i sistemi, che già stanno iniziando a vedersi, per la gestione della distanza automatica tra i mezzi, per cui alla fine, come in Minority Report, viaggieremo tutti in file disciplinate e a velocità costante, il che francamente non mi entusiasma troppo.
Abbiamo (io e Marco) appena assistito alla presentazione di Luca Bolognese (Lead PM di LINQ) e per la prima volta è stato mostrato pubblicamente PLINQ (Parallel LINQ).
L'idea è assolutamente interessante: sfruttare il modello di sviluppo dichiarativo offerto da LINQ, anziché il classico modello imperativo, per risolvere le query in base al tipo di hardware a disposizione. Ne abbiamo già parlato, come breve accenno ad uno dei possibili sbocchi futuri di LINQ, nel nostro libro. Sono contento che stia effettivamente prendendo forma. Si tratta certamente di una delle ragioni più importanti per passare al nuovo modello di programmazione offerto da LINQ.