Ieri si è tenuto l’evento dedicato agli sviluppatori in cui è stato annunciato iPhone OS v.4.0 e tutte le novità in esso contenute. Ovviamente ho seguito con molto interesse quanto il re mida Jobs stesse regalare al mondo intero.

Dopo appena 30’ mi accorgo di aver già sentito questo abuso della parola multitasking poiché seguo con molto interesse anche il filone Windows Phone 7. Alla fine ho trovato questa slide del MIX 10 che assomiglia tanto, a quanto detto da Apple ieri. Insomma un Multitasking gestito che non tratta tutti allo stesso modo sia per fornire performance e reattività istantanea che per risparmiare preziose risorse come batteria e potenza elaborative.

Dunque questo Managed Multitasking, che si avvale di un certo numero di processi privilegiati che forniscono servizi in background (per Windows Phone sono Zune, fonia, notifica e Location) esattamente come nell’elenco della presentazione odierna di Apple.

Sia pure per ragioni temporali questa volta è Apple che “copia” a Microsoft o, più semplicemente, entrambe, scavando nei loro database di utilizzo, convengono che non tutto debba girare sempre e che questo pregiudica la possibilità di avere applicazioni che reagiscano rapidamente.

Fosse finito qui si tratterebbe di una semplice convergenza nell’analisi dei dati di utilizzo. Invece, sfruttando un fenomeno spontaneo nato sulle capacità multimediali di iPhone e iPod touch, Apple crea un ecosistema per i video giocatori visto che la sua console è quella con il maggior numero di titoli e con la diffusione più alta rispetto alle console portatili.

Se elenchiamo le funzionalità che potete leggere in questa slide le funzionalità coincidono esattamente con il Live di Xbox 360.

Già Sony si era prodigata in un simile lavoro di fotocopia ma Apple non si disturba neanche a cambiare i nomi delle funzionalità riconoscendo vincente un modello che ha contribuito all’indubbio successo di Xbox prima e Xbox 360 ora e che, guarda caso qualche settimana fa, è stato annunciato anche su Windows Phone 7.

Dopo anni di accuse dalla mela verso Redmond per una volta è indispensabile far notare il contrario.

Ho letto con la solita attenzione il post di Massimo in particolare perché il titolo coincideva stranamente con le riflessioni che sto facendo per decidere la strada da prendere nell’evoluzione della nostra piattaforma virtuale.

Il punto di vista di Massimo è strettamente tecnico/operativo e nello specifico credo che l’unica considerazione mancante riguarda un fattore molto importante che manca nell’equazione.

Non è infatti solo un problema di rapporto CPU/RAM con VM ma, pur rimanendo nel campo esclusivamente tecnico, di ben altri fattori.

Nella mia esperienza di erogazione di servizi internet su Farm virtualizzate i fattori di scelta, per l’evoluzione delle farm, sono:

• Ridondanza
• Performance
• Manutenibilità
• Alta disponibilità

Il principio guida della ridondanza è di non mettere (traducendo forzatamente dall’inglese) tutte le uova in un paniere ed assicurare adeguata copertura anche in caso di failure hardware. Questo è sicuramente un tradeoff di una eventuale scelta di downsizing.

Le performance sono merce preziosa, soprattutto quando è necessario coniugare il consolidamento con la variabilità dell’incremento di carico dovuto agli utenti. Inoltre, almeno nella mia personale esperienza, ci sono dei ruoli che poco si addicono ad essere virtualizzati (DBServer e Fileserver) e per loro natura richiederebbero discorsi di scale-up.
Nonostante VMware si affanni ad affermare che il gap di performance è minimo, il bus di un server, i suoi dischi, la connessione in SAN è pur sempre condivisa e le macchine virtuali sono sempre al di sotto delle performance nominali di un hardware corrispondente alle risorse assegnate.

La concorrenza con Microsoft e Cytrix ha spinto VMWare ad integrare sempre più funzioni all’interno del suo ESX. Non ho ancora in produzione una 4 ma già dalla 3.01 alla 3.5 è visibile l’aumento di complessità dell’infrastruttura e dei servizi esterni accessori. Questo è un fattore moltiplicativo della complessità della farm che ospita generando un numero di vincoli in costante ascesa. Anche l’eventuale scale-over di una farm ha delle ripercussioni sulla sua manutenibilità: l’aggiunta di server dai core diversi, di fatto, neutralizza i vantaggi di aggiungere un nodo dovendo disabilitare alcune funzionalità di failover e resource management.

L’HA di VMware è sicuramente una funzione utile ma non alla sua piena maturazione nella 3.x: è sempre necessario rimanere nei parametri di disponibilità di risorse indicate dalle varie guide e/o software altrimenti possono verificarsi spiacevoli situazioni di risorse contese tra più host o interruzione delle connettività. In questo caso, la strada del downsizing è assolutamente impraticabile. L’alta disponibilità, a mio giudizio, non è solo la possibilità, come accademicamente definita, di proteggere un servizio dalla indisponibilità ma, e soprattutto, di farlo garantendo un livello di perfomance adeguato al suo utilizzo a regime.

Se a questi fattori puramente tecnici aggiungiamo i fattori economici (licenze acquisite) è chiaro che non è possibile parlare di uno scale down ma, almeno questa è la conclusione a cui sono arrivato io, ad un license optimization che permetta di ridurre il numero di server (ma senza esagerare) aumentandone la potenza del singolo, mantenendo una manutenibilità accettabile e aumentando le performance.

Come accontentare necessità infinite con risorse limitate…

Vi riporto un articolo che mi ha passato il buon flammabledev riguardo i dubbi di uno sviluppatore sul Cloud computing.

Ieri non aveva nessun commento oggi ne ha diversi esattamente come quello che ho aggiunto:

I guess you dont now about what problem the Cloud address. Please think about: resilency, on-demand scaling, business continuity and other problems that are becoming more and more complex to address inside organization.

Obviously to solve these problem the application must observe some rule by design. These rules are enforce on the cloud but not on the 99% of the other software platform.

Then, for a sysadmin like me, as these policy are enforced by infrastructure is much much simple to grow, to protect to enpower infrastructure

 

Molti hanno risposto esprimendo esattamente quello che Azure è. Qualcuno quello che potrebbe diventare.
In sostanza il problema è che oggi gestire la crescita di una infrastruttura che deve funzionare sempre, rispondere correttamente ai carichi ed erogare un gran numero di servizi eterogenei non è fattibile senza un apporto di regole e implementazioni tali da conoscere intimamente come una farm scala o affronta una failure.

Per fare un paragone pensate all’energia elettrica: nessuno si preoccupa di capire come arriva, da chi arriva, quanto carico viene erogato in una zona perché la Cloud si occupa di questi problemi chiedendo in cambio solo l’osservanza rigida e fedele di certe regole. Eccovi il cloud computing. Un meccanismo per forzare, by design, l’utilizzo di regole che farebbero parte dell’accademia del buon sviluppo.

Sappiamo tutti che, anche il progetto meglio impostato, risente di vincoli che sono, in quel momento, più forti di queste regole e quindi sempre più spesso il software non viene sviluppato come dovrebbe. Meglio un sistema dentro il quale il rispetto di alcuni principi sia vincolo per l’ingresso piuttosto che, come il sottoscritto, scatenare sempre guerre sante tra sviluppo e sysadmin.

Seguo spesso il blog di Mark Russinovich che ritengo uno dei principali esperti di Windows al mondo.

Mai avrei pensato che lui potesse rivedere la sua posizione sul SID che per molto tempo è stato lo spauracchio della virtualizzazione di macchine Windows.

Ricordo ancora quanti finti problemi ci siamo fatti relativamente alla duplicazione pura e semplice di un PC Windows pensando sempre a problemi derivanti dal SID. Spesso questo ha causato il lancio proprio dell’utility NewSID che ora è stata, giustamente, ritirata dal mercato.

La cosa più significativa è che il tanto temuto problema di sicurezza spesso indicato come legato al SID è invece dovuto al SID dei well-know-principal che è sempre lo stesso.

Grazie Mark, ma potevi anche chiedertelo prima però ;-:

Leggo spesso articoli che riguardano le infrastrutture dei big di Internet alla ricerca di preziosissime cose da imparare dall’esperienza altrui.

Questo bellissimo articolo sul blog di Dare Obasanjio riporta quanto raccontato dai ragazzi di Facebook riguardo l’infrastruttura che sta erogando il sito più trafficato del mondo.

Sinceramente la cosa che più mi ha colpito non è la tecnologia utilizzata, piuttosto comune, ma la profonda impronta che ogni singolo membro del team tecnico di Facebook lascia nell’infrastruttura.

Insomma Facebook investe pesantemente nelle persone poiché sono le uniche che possono affrontare (e risolvere) certe problematiche.

Sulla stessa strada  Ebay, Google e anche Microsoft, Amazon che fondamentalmente credono che solo un insieme di persone e talenti possono fare la differenza e rappresentare quel vantaggio competitivo che realizza servizi unici al mondo.

Esattamente come in Italia…dove l’innovazione è vista come un elemento eversivo.  

Un bellissimo video che spiega i pochi e semplici concetti alla base di Windows Azure.

<a href="http://video.msn.com/?mkt=en-US&amp;playlist=videoByUuids:uuids:feec9c5d-c6c9-451c-aa9a-b7f4524a6322&amp;showPlaylist=true&amp;from=msnvideo" target="_new" title="What is Windows Azure?">Video: What is Windows Azure?</a>

Non ho fatto in tempo a schiacciare un pisolino che uno dei punti critici evidenziati nel mio post riguardo Android (o Chrome OS) vengono sottolineati direttamente da ARM.

Android su netbook: ARM è poco convinta – Hardware Upgrade – Il sito italiano sulla tecnologia – www.hwupgrade.it.

Basandomi su quanto riportato in questo post (Google’s Chrome OS? Champagne corks are popping in Redmond – Windows Live.) vorrei condividere alcuni aspetti tenuti in scarsa considerazione riguardo a Google Chrome OS.

Premesso che condivido pienamente l’idea che la costruzione di un sistema operativo, per quanto fatta da un talentuoso team di sviluppatori esperti e da una società dal portafoglio robusto, non sia un task facile (in particolare con le funzionalità che gli utenti danno per scontate ma sono complesse e sofisticate) le cose non stanno esattamente come dice Mike Galos.

In particolare la sua analisi, condivisibile in linea generale, non tiene conto dell’evoluzioni avvenute in questi ultimi tempi:

• La rete è pervasiva, veloce e disponibile anche in movimento
• Nel mondo occidentale sono molto diffuse le applicazioni on-line ed utilizzate da un numero crescente di persone non solo per scrivere testi, ma per tutto quanto è possibile fare su un normale PC.
• Il client in questo caso non è affatto stupido, come in proposte precedenti, ma potenzialmente intelligente come un PC.
• Il fenomeno open source decuplica le forse in campo e velocizza la realizzazione di prodotti derivati da soluzioni GPL

Considerando questi tre fattori il “sistema operativo” di Google ha molte più chance di catturare utenti, in particolare tutti quelli che vorrebbero utilizzare Linux ma che rinunciano per la pigrizia di riadattarsi ad applicazioni diverse (e magari, diciamolo pure, meno evolute).

Ed Bott non ha caso ha inoltrato un un twit di @RussB  che vi riporto:

I just deleted all the other apps on my Ubuntu desktop except for the browser. Look! It’s the Firefox OS™ !

Questa frase sintetizza quello che oggi si può dedurre sarà il sistema operativo di BigG e sottolinea il rischio di creare una versione eccessivamente semplificata di sistema operativo che nessuno vorrà usare.

Personalmente ritengo che le criticità che Google avrà di fronte nella costruzione del suo sistema operativo sono altre:

1. Non tutti gli utenti, anche quelli più avanzati, accettano di salvare i dati sui server di BigG e dunque un sistema operativo basato su Chrome dovrà necessariamente saper gestire un filesystem locale e tutto quello che ne consegue.
2. Per quanto bello il design di applicazioni Web oriented non può ancora rivaleggiare con gli omologhi WinForm in particolare se utilizzano i nuovi paradigmi di costruzione delle interfacce.
3. Un sistema operativo girà su una piattaforma hardware terribilmente più complessa di quella di un telefonino. Dunque il paradigma Android potrebbe non bastare se non correttamente inquadrato in un “dialetto di linux” che non costringerebbe i produttori di hardware ad aumentare i costi per la scrittura di nuovi driver. Sostanzialmente, costruire un ecosistema non è facile: per questa ragione Apple continua a non essere Open…

In conclusione condivido lo scetticismo dei più sul successo del sistema operativo della grande G come general purpose OS e reputo l’annuncio di oggi più una schermaglia di marketing che di sostanza.

Oggi mi sono imbattuto in una ricchissima ed utlizziam lista di macchine virtuali per test di prodotti Microsoft molto interessante che potete trovare qui. In ogni caso il riferimento ufficiale di Microsoft è questo link.

Peccato che bisogna usare VirtualPC invece di VMWARE… magari basta il mio amico VmWare Converter.

In questo video, presentato al TechFest, Microsoft illustra come si immagina il futuro. Entusiasmante.