Linux su mainframe? Sentiamo IBM e Redhat


Image

Ormai è da tanti anni che Linux annovera tra le piattaforme supportate il System z. Sono più di dieci, con una quantità di utilizzatori in espansione, sia come numero di aziende che come sistemi installati.

Però, sopratutto in Italia,  penso che sia ancora un’opzione presa poco in considerazione da molti CIO. Sia da chi ha un mainframe già in casa e sia da chi non considera affatto l’ipotesi di uno zEnterprise solo Linux!

Ecco un’occasione, per sentire il punto di vista di IBM e Redhat su questo connubio, l’evento dal titolo IBM Red Hat Z Linux Roadshow che si terrà il 12 Marzo a Milano.

Andrea Negro (IBM), Antonio Leo (Red Hat), Alessandro Camerra (IBM) e Rafael Godinez Perez (Red Hat) descriveranno le potenzialità di questa scelta architetturale. Mentre Lorenzo Raggi De Marini (Ignazio Messina & C.), Maurizio Priano (Delphis Informatica) e Marco De Felice (Zetacloud) parleranno della loro esperienza e della convenienza di usare uno zEnterprise come server per Linux.

Per iscrivervi e vedere l’agenda della giornata andate a questo link.

 

Quando il responsabile IT della “ACME Limited” mi chiamò per parlare di Disaster Recovery…


…io ripassai tutte le definizioni di Continuità Operativa (BS25777, ISO27001, BS25999, ISO24762), per poi scegliere quella a mio avviso più sintetica e completa: “La gestione della continuità operativa comprende tutte le iniziative volte a ridurre a un livello ritenuto accettabile i danni conseguenti a incidenti e catastrofi che colpiscono direttamente o indirettamente un’azienda.” (“Normativa di vigilanza sulla continuità operativa delle banche” – Banca d’Italia).

Rimasi quindi spiazzato quando il cliente mi propose la sua definizione di Disaster Recovery: “Per me le soluzioni di Disaster Recovery costano troppo, soldi spesi per macchine di fatto inutilizzate; se malauguratamente se ne avrà bisogno non funzionerà, ma nonostante la bassissima probabilità che a noi possa accadere un incidente serio, dobbiamo comunque dimostrare di averla.”

“Ora, poiché l’Azienda mi ha chiesto di lavorare in questa direzione, ho deciso di studiare le esigenze di protezione (Analisi dei Rischi, Business Impact Analysis); una volta completate queste analisi, faremo partire lo studio dei modelli adottabili e la valutazione del budget da allocare per la soluzione.”

Quando tornai a trovarlo, mi mostrò l’output della Analisi dei Rischi che, con dovizia di particolari, spiegava qual’era la probabilità di poter incorrere in un incendio, di un allagamento, di un atto terroristico e via dicendo con decine di tipologie di eventi indesiderati.

Obiettai che un’analisi così corposa e dettagliata è sovradimensionata per la valutazione delle esigenze di Disaster Recovery se, come nel suo caso, non si dispone di nessuna protezione da disastro: “l’effetto di uno qualsiasi di questi eventi può potenzialmente portare alla perdita dei propri dati e alla prospettiva di dover interrompere i servizi IT per mesi: la probabilità di questi eventi moltiplicata per i danni potenziali (l’azienda può correre il rischio di perdere i dati e/o di interrompere per mesi l’erogazione dei servizi?) rende di fatto obbligatoria la soluzione DR, senza bisogno di analisi particolarmente profonde.”

“L’analisi dei rischi ha la sua utilità nel ridurre la probabilità di incorrere in eventi indesiderati irrobustendo la propria infrastruttura, ma poiché questa probabilità non può essere azzerata, la soluzione di Disaster Recovery si rende comunque necessaria.”

Mi richiamò 6 mesi dopo per analizzare l’output della Business Impact Analysis che aveva svolto nel frattempo.

Riguadagnai la sua stima quando affermai che la BIA è assolutamente necessaria perchè stabilisce formalmente l’impegno reciproco tra i responsabili del business e l’organizzazione IT: io pago affinchè tu protegga.

Quando però mi presentò lo studio, in cui erano elencati decine di processi di business con associati a ciascuno di essi le esigenze di continuità (RTO = tempo massimo di indisponibilità, RPO = perdita dati massima), mi chiese anche in questo caso la ragione del mio scetticismo.

“Tutti i processi che hanno relazioni applicative tra loro (e si scambiano dati) non possono essere assoggettati ad esigenze di continuità diverse, perchè si correrebbe il rischio di avere la copia dei dati (per DR) inconsistente dal punto di vista applicativo; quindi non decine di processi, ma poche isole di recovery (cioè aggregazioni di processi in relazione tra loro, accomunati dagli stessi livelli di continuità).”

“Le coppie di RTO ed RPO sostenibili dalla tecnologia sono poche; a titolo di esempio, i valori di RPO passano da una perdita dati di pochi minuti (mirroring asincroni) a valori superiori alle 24 ore (salvataggi con cadenza giornaliera più il tempo per la loro produzione ed allontanamento dalla sede di esercizio): in mezzo a questi due valori (pochi minuti, più di 24 ore) non ci sono soluzioni possibili (salvo rarissime eccezioni).”

“In conclusione, sapendo che i processi con relazioni tra loro devono essere aggregati e che i valori di RTO e RPO sostenibili dalla tecnologia sono pochi, la stessa analisi poteva essere fatta con lo stesso rigore spendendo molto meno tempo e soldi.”

Ma il colpo di grazia alle conclusioni della BIA arrivò da lì a poco, cioè quando fu analizzata la coerenza tra esigenze di continuità e budget stanziato per la soluzione.

Non avemmo subito la percezione del problema, perchè quando gli comunicai la stima dei costi per le soluzioni applicabili lui confermò che era in linea con il budget, salvo poi scoprire che io parlavo di costi annui e lui del budget per i cinque anni successivi…

E qui scattò la rincorsa al contenimento dei costi, giocata su due piani paralleli:

  • la riduzione del perimetro dei processi da proteggere e l’abbassamento dei livelli di continuità attesi (smantellando di fatto nel giro di poche ore i risultati della BIA…);
  • “l’ottimizzazione” della soluzione tecnologica.

Furono quindi identificati “i servizi critici” scegliendone un sottoinsieme da proteggere, come prima fase della soluzione.

Provai a sostenere i limiti di questo approccio: “se considerassimo lo scenario di disastro peggiore (quello che a mio avviso TUTTE le soluzioni di Disaster Recovery devono onorare), cioè un evento in grado di distruggere o rendere indisponibile per mesi il proprio centro di calcolo, avere o non avere una soluzione per alcuni dei servizi critici non è certo una soluzione di continuità; se fosse accettabile per un’azienda andare avanti per sei mesi solo con questi servizi, c’è un’alternativa migliore per tagliare i costi: spegnere da subito gli altri servizi, senza aspettare un disastro….”.

“Una soluzione di questo tipo sottintende in realtà un altro scenario di disastro: “speriamo che in una settimana riusciamo a risolvere il problema ed intanto andiamo avanti con alcuni servizi”; più che una soluzione di continuità, una soluzione “di agonia”.”

Alla sua obiezione che questa soluzione costituisce una prima fase, e che quindi successivamente la protezione sarebbe stata estesa al resto del perimetro dei servizi critici, risposi che forse è preferibile non spendere nulla piuttosto che spendere poco per una soluzione insufficiente.

A questo punto discutemmo le sue linee guida per “l’ottimizzazione tecnologica” della soluzione:

  • riutilizzo, per disaster recovery, di tecnologie dismesse in produzione;
  • riduzione della capacità di calcolo in recovery, rispetto a quella impiegata in produzione;
  • “alleggerimento” degli scenari di test, con conseguenti economie di scala;
  • uso della configurazione di disaster recovery per servizi “minori”, ritenuti sacrificabili in caso di indisponibilità dei servizi critici;
  • rinuncia ad interventi in ambiente di esercizio (razionalizzazione dei server e dello storage) perchè costosi, adottando di conseguenza un’eterogeneità di strumenti per alimentare il sito di disaster recovery.

Nessuna di queste linee guida è sbagliata “a priori”, ma molto spesso questo mix di interventi porta ad una soluzione di Disaster Recovery incompleta sul piano delle garanzie, con incertezza circa il reale funzionamento perchè non soggetta a test esaustivi.

Oggi la tecnologia ed il mercato offrono modalità per contenere i costi complessivi delle soluzioni DR, mantenendone l’affidabilità e la rispondenza alle esigenze di continuità:

  • l’uso di infrastrutture e risorse condivise, con le stesse certezze d’accesso in caso di bisogno rispetto alle soluzioni proprietarie;
  • l’efficientamento della produzione, laddove il contenimento dei costi e l’incremento di efficacia della soluzione DR è “solo” un beneficio accessorio, rispetto alla riduzione dei costi di gestione in esercizio;
  • l’adozione di architetture Cloud in recovery, con la possibilità di predisporre in tempi rapidissimi configurazioni ed ambienti in linea con le esigenze contingenti, rendendo dinamicamente redistribuibili gli ambienti operativi;
  • l’armonizzazione tra le contromisure di component recovery (cioè le ridondanze locali pensate per far fronte a problemi di componente, ad esempio i cluster) e le esigenze di Disaster Recovery.

Il responsabile IT della ACME si mostrò interessato ai punti da me sollevati, dicendo che sarebbero stati oggetto di approfondimenti nei nostri successivi incontri, ma sono passati più di 4 mesi e non mi ha ancora chiamato…..

Dell arroccata da Microsoft – Riflessioni dovute


DellNell’ultimo post parlando della mossa annunciata, ho esposto le mie riflessioni principalmente su Microsoft. Ma leggendo nuovi commenti mi sembra corretto rivedere il tutto anche dal punto di vista di Dell.

Lo scorso anno ho espresso il mio parere sullo stato di salute non buono di Dell e sul fatto che, cercare di ampliare la sua offerta con i servizi e reindirizzarla sul mercato enterprise, non avrebbe dato i risultati sperati, sopratutto nel breve periodo e quindi…..

Ma “quindi” è il problema, è l’ostacolo posto non tanto dal mercato che compra i prodotti Dell, quanto dal mercato che compra le azioni Dell. Troppo spesso frasi come le pressioni del mercato, le esigenze del mercato, imputano al primo pressioni ed esigenze dettate dal secondo.

Ora se Dell (in realtà qualsiasi azienda) deve agire all’interno della tempistica dettata dal mercato che compra le azioni non riesce quasi mai ad avere il tempo per pensare, e portare a termine, quelle innovazioni che vengono apprezzate dal mercato che compra i prodotti. Ricerca e sviluppo non sono facili da piegare alle necessità trimestrali dei mercati finanziari.

Ecco perché, sulla mossa Microsoft-Dell, si legge che alcuni azionisti importanti resistono all’idea della privatizzazione e “il principale azionista indipendente di Dell ha dichiarato che voterà contro la proposta . Si tratta di Southeastern Management che ha dichiarato ufficialmente che la cifra di 13,65 dollari per azione offerta agli investitori , nonostante che porti un sovrapprezzo del 25 per cento sul valore dell’azione di un mese fa , è ancora troppo bassa e non la approverà.“. La Southeastern Management ovviamente non è interessata all’azienda Dell, ma al suo profitto che reputa non soddisfacente.

Ma perché per Dell è importante privatizzare? Cosa cambia per l’azienda se le azioni sono sul mercato o possedute interamente da pochi privati? In questo caso Microsoft-Michael Dell (il fondatore)-Silver Lake. In un post di qualche giorno fa è spiegato bene: Michael Dell, consapevole della criticità del momento, vuole riuscire ad imprimenre una svolta concreta all’azienda e per far questo deve essere “lontano dai riflettori e le pressioni finanziarie di Wall Street.

Non vi ricorda l’ostinazione con cui Steve Jobs non voleva pagare i dividendi? Non vi sembra che le aziende tecnologiche debbano porre nuovamente la ricerca e l’innovazione al centro delle loro iniziative e sacrificare meno “attenzioni” sull’altare delle borse? La mossa di Michael Dell è l’unica possibile per evitare di diventare ua mucca da mungere dal mercato azionario e, una volta prosciugata, essere mandata allo sfacelo (facendo guadagnare le borse anche in questa discesa….)?

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

Almanacco 2012 di @mainframeitalia


Almanacco 2012 Cover

Ho modificato i menu a Dx del blog per guadagnare un po’ in semplicità. In questo lavoro ho aggiunto la pagina dal titolo i Quaderni di mainframeitalia dove sono raccolti i riferimenti per scaricare le nostre pubblicazioni. Sono in vari formati e si possono scaricare da iTunes, da Google Books, dallo spazio su Box o da Scribd. Spero che vi basti!

Con l’occasione è uscito l’Alamanacco 2012. l libro raccoglie tutti i post usciti su mainframeitalia.com nel 2012. Lo scopo quello di conservare, in modo facile da consultare, tutti i link ed i riferimenti proposti nell’anno. Alcuni articoli sono disponibili tradotti in Inglese.

Mi raccomando valutate la pubblicazione, direttamente sui siti da dove lo scaricate oppure votando questo articolo sulle stellette in alto!

__________________

I reworked the right menu of the blog to improve its usability. In this work, I added the page titled i Quaderni di mainframeitalia where references are collected to download our publications. They can be donloaded in different formats iTunes, Google Books, the space of Box or from Scribd. I hope you have enough!

In the same time it has been published the Almanacco 2012. This book contains all 2012 posts published on mainframeitalia.com. It want be an easy to access repository of all links and documents reference provided during the year. Some posts are available translated in English.

Please rate this book, or from the site where you dounload it or in this posts using the stars on top of it!

2012 #BMC Mainframe Survey


BMC BS09025-06Ho letto il report annuale della BMC dal titolo 2012 BMC Mainframe Survey Spotlights Mainframe Growth and Pains.

E’ un’indagine efettuata su un campione di 1264 intervistati suddivisi secondo quanto riportato nei grafici che ho riassunto qui di fianco.Screen Shot 2013-01-28 at 11.52.10 AM
Il dato evidente fin dalle prime pagine, è che il 90% degli intervistati considera la piattaforma mainframe come una scelta di lungo periodo fondamentale per il business. Per il 40% è una scelta per supportare l’esistenza delle applicazioni esistenti, mentre per il 50% serve alla crescita delle applicazioni attuali e come piattaforma per nuovi workloads. L’altro aspetto che emerge è la difficoltà di mantenere il focus sulla riduzione dei costi e contemporaneamente dare spazio a sviluppi nell’area della mobility su pressione del business.

Le motivazioni che fanno preferire questa piattaforma sono, per chi ci lavora da molto tempo, abbastanza scontate e si basano sull’aver riscontrato alti livelli di:
– disponibilità
– sicurezza
– through-put transazionale
ed un eccellente impiego come data server centralizzato.

La mia sensazione è che stia aumentando sia il numero di iniziative di nuovi workload sul mainframe che di ammodernamento delle applicazioni esistenti. Questo perchè aumentano il numero di intervistati che vedono sempre più “Web services/ SOA integration projects” avviati su mainframe e che considerano i “Transaction through-put requirements” facilmente rispettati da questa piattaforma.

Vi invito a leggere il report sul link che ho messo sul titolo, è ricco di dati che fanno riflettere. Io sono stato colpito dalla percentuale in aumento, rispetto ai precedenti anni, di intervistati (29%) che dicono di rimanere sul mainframe perché i costi delle piattaforme alternative sono elevati o non sono evidenti i ritorni degli investimenti dovuti alla migrazione….

PS. Grazie a Valeriano Bassi per la segnalazione.

2012 in review


Condivido il report di sintesi del 2012 è un’infografica simpatica da scorrere verso il basso. Vi ricordo di votare per il sondaggio Cosa Intendi per mainframe disponibile inbasso nel menu a sinistra….

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 8,100 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 14 years to get that many views.

Click here to see the complete report.