Microsoft muove ed arrocca Dell


English version

A Roma “nun te tieni ‘n cecio ‘n bocca!” Si dice di uno che non riesce a mantere il più piccolo segreto e ne va subito a parlare in giro. Ora anche se non è un segreto io mi sento in dovere di parlare subito della notizia su Microsoft e Dell. Notizia che il sito di Repubblica titola in modo sensazionalistico Microsoft rileva Dell per 24,2 miliardi insieme al fondatore e a Silver Lake, ma più correttamente il Wall Steet Journal si chiede Why is Microsoft Investing in Dell? e Microsoft in tono formale comunica il suo Statement on Loan to Support Dell Privatization. Parto dal colosso di Redmond che annuncia di “aver fornito un prestito di 2 miliardi di dollari al gruppo che renderà Dell privata“. Per privata si intende non quotata in borsa, ma posseduta interamente da una azienda o un gruppo di aziende. “Microsoft si impegna per il successo nel lungo termine dell’ecosistema dei PC ed investe pesantemente in molti modi per costruire l’ecosistema del futuro. Siamo in un mercato che si evolve di continuo. Come sempre noi continueremo a cercare le opportunità che permettano ai nostri partner impegnati nell’innovare ed a basare le attività su loro prodotti e servizi disegnati sulla piattaforma Microsoft.”
Secondo il WSJ I motivi di questa mossa sono duplici: da una parte Microsoft vuole difendere il mondo Windows dagli attacchi provenienti da tutti i lati. Dall’altra vuole aumentare la sua penetrazione nei sistemi aziendali. Poi il WSJ percorre “l’intrigante storia degli investimenti di Microsoft” indicando i riferimenti di Nokia del 2011 e dei 240M$ investiti in Facebook nel 2007 senza ottenere nemmeno un posto nel consiglio di amministrazione (board of directors) che hanno portato soltanto alla cooperazione tra il social network ed il motore di ricerca Bing. L’articolo continua spiegando che i server Dell e la sua offerta infrastrutturale saranno il cavallo di Troia all’interno dei dipartimenti IT delle aziende.
Questo per aumentare la presenza di Microsoft nelle aziende che stanno dirigendosi sempre più verso servizi Cloud del tipo SaaS come Salesforce.com.
Letta cosí Dell sembra un’azienda destinata soltanto ad essere funzionale a Microsoft ora che il duopolio Wintel è sotto attacco (potete leggere i post su Intel e Dell dello scorso anno sull’Almanacco 2012). Ma indubbiamente l’azienda di Redmond dalla fine degli anni ’90 ha usato la sua liquidità per fare investimenti che aumentassero la sua posizione entrando in aree strategiche.
Il mio parere é che questa intenzione non è stata affiancata da una strategia chiara e precisa. Rileggendo il percorso dei soldi di Microsoft troviamo nel ’97 1B$ in Comcast Corp un cable-provider rivenduto nel 2009; 150M$ nel ’97 in Apple per sviluppare Sw per Mac; nel ’99 5B$ nell’AT&T per garantirai l’utilizzo di Windows nei set-top box del provider che non sono mai decollati; solo 10M$ per la Bungle Studio, l’azienda creatrice del videogioco Halo. Si continua con una telecom Coreana nel 2001; con l’acquisizione delle aziende Great Plains e Navision che contribuirono con Sw di tipo aziendale; l’investimento di 6.3B$ nell’azienda di pubblicità online aQuantive dichiarato fallimentare nel 2012; nel 2008 500M$ per acquisire la Danger che con la sua decennale esperienza doveva far sbarcare Microsoft nel mercato dei telefonini, ma produsse soltanto il Kin Phone nel 2010, non proprio un successo (sono solo 3 anni fa, voi lo ricordate?). Ancora Yahoo, Nokia, Skype e Nook.
Cavi, telecom, videogiochi, pubblicitá online, libri per la scuola ed ora Dell. Se c’è non capisco qual’è la strategia.
Nel panorama Entrprise vedo un’altra grande azienda di Sw che agguanta un produttore di Hw, non proprio splendente per proporre dei bundle alle aziende vincolanti su una piattaforma specifica. Non prodotti innovativi con una flessibilitá architetturale che lasciano libertà di scelta sulla definizione dello stack Sw adeguato.

Continua a leggere

Annunci

Il batch è un dinosauro in estinzione o uno squalo che naviga anche nelle nuvole?


English version

Leggendo una presentazione su un prodotto di schedulazione, ho pensato che sono un esemplare in via di estinzione. Sono tra le poche persone che ricordano, per averlo vissuto, come funzionava il turno notturno nei CED: dopo la chiusura dell’IMS e di tutte le applicazioni utilizzate per le attività online, arrivava il momento del cambio turno.

Io lavoravo all’interno di una sala macchine di pianta quadrata, con un lato di 60 metri (si, avete letto bene era un unica “stanza” di 3600 mq) ed il tavolo degli operatori, dove c’erano circa 15 terminali, si svuotava del personale del pomeriggio ed arrivavano gli schedulatori. Ciascuno prendeva posto dietro una consolle, i due capi-turno, che avevano già lanciato i JOB per stampare i piani notturni, raccolto e suddiviso i tabulati in tanti pacchi, iniziavano a distribuirli. Quei tabulati erano la pianificazione del batch e riportavano diagrammi fatti di quadrati e losanghe con dentro tanti nomi di JOB. Ciascun schedulatore iniziava dal primo foglio del suo piano e alla consolle faceva partire il primo JOB o procedura indicato nel primo riquadro. A seconda dei JOB, dall’altro lato dello sanzone, c’erano altri operatori e le unità dei nastri. Dalle loro consolle vedevano i messaggi di MOUNT che indicavano di montare un certo nastro su una unitá con un indirizzo specifico. Gli operatori allora prendevano, da carrelli predisposti, la bobina con l’etichetta del nome richiesto e la montavano sull’unitá a nastro indicata nel messaggio. Quando le operazioni su quel nastro erano finite un messaggio di UNMOUNT li avvisava di toglierlo e quindi poteva essere riposto nel carrello.

Intanto, sull’altro lato della stanza, gli schedulatori tenevano d’occhio le console e verificavano l’andamento dei JOB che avevano avviato. Se un JOB terminava con il Condition Code zero, con una matita si segnava un baffo sul box del tabulato e si seguiva il ramo della losanga con scritto OK, se il JOB terminava con un CC previsto facevano le operazioni stampate sul tabulato, e se terminava con un CC non previsto seguivano il percorso che dalla losanga partiva da un NO. Spesso per alcuni problemi si richiedeva l’intervento dei sistemisti di sala che, con la loro esperienza e le loro conoscenze, trovavano il modo di far proseguire i lavori. Dopo aver riempito di baffi il loro tabulato lo firmavano, lo restituivano al capo turno e ne prendevano un’altro.
In tutto tra capi turno schedulatori, operatori dei nastri e delle printer, e sistemisti di sala, dalle 50 alle 60 persone passavano la notte per far eseguire tutte quelle operazioni necessarie a completare le attività svolte online il giorno precedente e le operazioni propedeutiche a far ripartire le applicazioni online il giorno seguente.

A metà degli anni ’80 arrivarono i Sw di automazione della schedulazione. L’Operations Planning and Control (OPC) e poi la versione Advanced OPC\A ridussero i turni notturni a “sole” 20-30 persone. I proceduristi, che prima si limitavano a scrivere le JCL per i JOB notturni, furono incaricati anche delle attivitá di pianificazione e di preparare i piani automatici da far girare di notte; quindi molti operatori smisero di fare i turni e furono “promossi” proceduristi.
Ma se all’inizio fu solo una scelta di convenienza, si rivelò ben presto un passaggio obbligato per riuscire a gestire il numero di batch in continuo aumento e la finestra del Bach che poteva andare solo dalle 20:00 alle 7:00 che da comoda diventava sempre più stretta.

Se questi prodotti di schedulazione si fossero limitati, nel tempo a fornire un orologie ed un calendario con cui eseguire il JOB scritti con JCL, molto probabilmente oggi sarebbero assimilabili a dinosauri in via di estinzione.

La presentazione che ho letto, parla dell’ultimo release del Tivoli Workload Scheduler (TWS), che è l’attuale evoluzione dell’OPC.  In questa presentazione è evidente come questo Software abbia ampliato le sue funzionalità adattandosi alle mutevoli esigenze degli ambienti batch. Dalla schedulazione mono-piattaforma è diventato un riferimento per la pianificazione delle attività di un centro, grazie alle sue capacità accresciute secondo due dimensioni: una prima orizzontale, che ha permesso di includere, come ambienti oggetto delle pianificazioni, praticamente tutte le piattaforme presenti in un centro ITC.
La seconda verticale, che estende le condizioni utilizzabili per la pianificazione ed amplia le tipologie di attività che è possibile schedulare.

Le evoluzioni architetturali hanno introdotto, quelli che, per semplicità, io chiamo pattern-batch totalmente nuovi. Nell’era che ho descritto prima oserei dire che esistevano solo 2 pattern batch:

1) Attività avviata ad un determinato tempo che, una volta conclusa, rende disponibile il suo output
2) Attività avviata dopo il completamento di un’altra attività che, una volta conclusa, rende disponibile il suo output

Entrambi i pattern avevano una caratteristica in comune tipica del batch: che l’utente destinatario dell’output non è in attesa durante l’elaborazione. Nell’online se l’utente è una persona fisica sta dietro il terminale ad attendere, se invece è un’applicazione si mette in wait del risultato.

L’ultimo TWS è in grado di avviare delle attività anche sulla base di eventi e di farle eseguire su l’ambiente migliore disponibile in quel momento oppure, interfacciandosi con strumenti di provisioning, di chiedere il dispiegamento di nuovi ambienti per eseguire le attività richieste.  in modo da poter rispettare dei Livelli di Servizio predefiniti. Potrei sintetizzare che, grazie queste interfacce, il TWS è diventato un metronomo in grado di coordinare attività di ambienti cloud, sia provvedendo alle esigenze batch di tali ambienti, che sfruttandone le peculiarità per i propri obiettivi. Per approfondire nei link precedenti potete scaricare la presentazione originale e vedere tutti i dettagli.

E’ chiaro quindi che quello che poteva far la figura di un dinosauro, invece appare come lo squalo che, sebbene esista da più di 400 milioni di anni, dopo successive evoluzioni, ancora nuota nelle nostre acque.

Parliamo di “vile danaro”


Abbiamo visto tanta tecnologia, ci siamo entusiasmati dalle opportunita’ offerte dai mainframe, ma occorre sempre fare i conti con qualche cosa di piu’ prosaico: i costi, il cosiddetto “vile danaro”.
Sara’ anche vile, ma ne facciamo continuamente i conti. Ogni Azienda e’ attentissima ai costi, ed in periodi di crisi lo e’ ancora di piu’. L’argomento e’ quindi cruciale, le decisioni vengono sempre prese favorendo le soluzioni con le piu’ favorevoli condizioni economiche.
Il pricing dei prodotti software non sempre si basano su regole lineari e spesso prevedono condizioni di utilizzo che offrono opportunita’ di risparmio.
Scopo di questo thread e’ condividere le esperienze che hanno permesso di ottenere saving nelle bollette software.
Comincio parlando di Subcapacity. Tramite la Subcapacity c’e’ la possibilita’ di pagare le licenze software su Mainframe in base all’effettivo consumo. Il consumo e’ desunto dai record SMF. Un tool che prende in input i record SMF del mese, calcola le MSU consumate dai vari prodotti software.
Diciamo che la sola l’adozione della Subcapacity produce dei vantaggi. E’ improbabile che una macchina venga usata sempre alla sua massima capacita’, se cio’ accadesse la bolletta software in Subcapacity corrisponderebbe a quella standard, negli altri casi sarebbe inferiore.
Altre evoluzioni del tema e’ scomporre il carico in partizioni specializzandole per prodotto software. Cio’ non sempre e’ possibile, ma dove possibile si pagherebbe ciascun prodotto esattamente per quanto viene utilizzato.
Scopo di questo thread e’ la raccolta e lo scambio delle esperienze in tal senso.