Lo zEnterprise nelle nuvole le rende sicure


Non ricordo dove (mi sembra su Twitter), ho letto un riferimento ad un articolo su Millennial Mainframer dal titolo The Mainframe on the Cloud scritto da Sarah Dandia. Come al solito li ho contattati e chiesto il permesso di tradurre/citare i loro post e, con grande disponibilità, mi ha risposto Sean McBride permettendomi di aggiungere il loro sito tra quelli gemellati (vedi la lista nel menu a sinistra).

Sarah sostiene che […] sebbene le parole “cloud computing” e “mainframe” non sono, di solito, utilizzate all’interno della stessa frase, non sono così dissimili come potrebbe sembrare. Il mainframe all’interno del cloud è un argomento di discussione sempre più presente negli ultimi mesi all’interno della communità tecnica […]. Il post prosegue sostenendo che le caratteristiche che si richiedono al Cloud Computing sono le stesse che il mainframe rende disponibili da molto tempo, quindi il mainframe è la piattaforma ideale per il Cloud.

Queste considerazioni sono vere anche se, a mio avviso, lo zEnterprise come piattaforma ibrida si presta alle realizzazioni di architetture per il Cloud Computing. Anzi, il mio parere è stato, fino a poco tempo fa, quello che lo zEnterprise nel Cloud avesse l’unico ruolo di “fornitore di mattoni” per costruire il Cloud. Dico fino a poco tempo fa perché ho letto un whitepaper che parla di zEnterprise nel Cloud in modo diverso dalla mia visione. Non come base su cui costruire tutto, ma come nodo essenziale per svolgere tutte le funzioni su un aspetto specifico per il Cloud: la sicurezza.

Il white paper si intitola Consolidated security management for mainframe clouds ed è uscito a Febbraio di quest’anno; è possibile scaricare il PDF da questo link oppure qui in FTP. I questo dicumento si ipotizza, viste le naturali doti di sicurezza del mainframe di concentrare tutte le funzioni su questa piattaforma che diventa il guardiano del Cloud.

Ecco che […] le caratteristiche che fanno del mainframe una piattaforma ideale per le applicazioni critiche – un hardware robusto, un sistema operativo, meccanismi di Systems Management e di sicurezza affidabili – possono essere utilizzate per utilizzarlo come Security Hub in un Cloud […]. Quindi sia i meccanismi di autenticazione ed autorizzazione, la gestione delle identità federate, la gestione dei certificati digitali, i meccanismi di prevenzione delle intrusioni e le funzioni di controllo ed audit possono essere concentrate all’interno del mainframe ed ad esso demandate per tutto il Cloud. Il documento si conclude con una sintetica panoramica dei Sw utilizzabili a tal scopo.

Questo ruolo ipotizzato per il mainframe mi ha fatto ricordare un fatto accaduto verso l’inizio del 2000. Stavo da un cliente parlando di sicurezza nell’ambito mainframe ad una platea folta di persone (20-30) quando ad un certo punto vengo fatto bersaglio, come esponente di IBM, del fatto che (cito le memorabili parole) “l’IBM sullo z nasconde le sue falle di sicurezza non diffondendo le informazioni, ne è prova il fatto che non ha ancora reso disponibile un antivirus per il suo sistema operativo di cui ce ne dovremmo sbarazzare al più presto“. Confesso che rimasi inizialmente interdetto sia per il contenuto che per la veemenza delle accuse. Poi feci notare che l’attenzione alla sicurezza, sia sul sistema operativo che nei sottosistemi, è da sempre stata una fissa dei laboratori ben prima che la parola antivirus uscisse dall’ambito medico/biologico per infettare il mondo dell’informatica. Le PTF di tipo HIPER (High Impact/Pervasive) esistono da prima degli anni ’80 e servono, appunto, per eliminare errori con alto impatto sulla affidabilità dei sistemi; inoltre esistono le PTF classificate di Sicurezza che indirizzano esplicitamente tali problematiche. Dissi anche che un antivirus per lo z/OS come per gli altri sistemi era lo stesso z/OS che isola i differenti address space in modo che non possano danneggiarsi reciprocamente o li manda in ABEND quando tentano di fare operazioni non permesse.

Ma fu inutile, non riuscii a parole nel convincere quella persona. Comunque ad oggi ancora hanno gran parte dei loro workload su mainframe.


Ho iniziato un’attività di diffusione per cui raggiungere mainframeitalia sarà possibile in modi diversi:

– da un qualsiasi lettore o aggregatore di RSS. utilizzate i link riportati a sinistra sotto il titolo RSS Feeds
– su Twitter basta diventare followers di @mainframeitalia
– su Facebook potete usare il bottone mi piace, sempre nel menù a sinistra, per seguire la pagina di facebook.
– dalla mail; inserite il vostro indirizzo nel menù a sinistra

Iscriversi con uno di questi meccanismi è anche un modo per far arrivare il vostro sostegno agli autori dei post. Ovviamente, ribadisco, un’altro modo di sostenere questa iniziativa è tramite la partecipazione attiva (anche saltuaria o una-tantum) pubblicando, come autori, le vostre riflessioni, considerazioni o consigli.

Il mainframe ibrido nella nuvola? No, io nelle nuvole!


Leggendo il n.12 del Corriere delle Comunicazioni mi sono soffermato, incuriosito, sull’articolo La doppia faccia della nuvola: “Da una recente ricerca svolta dagli Osservatori del Politecnico di Milano emerge che il 67% delle grandi aziende italiane adotta le tecnologie cloud. In particolare, il 56% utilizza già almeno un servizio cloud, mentre l’11% ha in corso limitate
sperimentazioni. Il 25% delle aziende del campione si è dichiarato interessato all’introduzione e solo l’8% dichiara di
non utilizzare il cloud e di non avere alcun interesse a introdurlo.”

Ora io non ho alle spalle grandi esperienze di Cloud, ma l’affermazione che il 67% delle aziende italiane adotta tecnologie cloud mi ha fatto l’effetto di un suono stonato; mi è venuta spontanea la domanda: quali sono le tecnologie Cloud? Non ho saputo rispondermi.

Mi veniva in mente la virtualizzazione: ma non è una tecnologia prettamente Cloud, CPU, I/O e memoria sono risorse virtualizzate fin dagli anni ’70 e non si parlava certo di Cloud. Successivamente con l’avvento di modelli applicativi di tipo Client/Server, di architetture distribuite e, sopratutto, grazie all’abbassamento dei costi dell’Hardware è avvenuta una diffusione spinta di “server reali” prevalentemente con sistemi Windows o Unix. Ma siamo alla fine degli anni ’80 e negli anni ’90 dove di cloud se ne parlava solo nei meteo in lingua Inglese.
Poi mi sono venuti in mente i Software di deployment dei sistemi; ma anche per questi abbiamo una genesi che, proprio per l’aumento della diffusione dei server distribuiti, risale alla seconda metà degl anni ’80.

Insomma lo ammetto: non sono stato capace di trovare qualche “tecnologia cloud”! Pensando al mainframe mi veniva istintivo di pensarlo adatto al cloud, ma non di considerarlo una “tecnologia cloud” se non altro perché esiste da un pò più di tempo; inoltre mi sembrava strano che da una fonte accademica come il Politecnico di Milano si parlasse di “adozione di tecnologie cloud” se non con proprietà di linguaggio. Quindi dovevo indagare e saperne di più.

Il primo passo, lo confesso, è stato Google, ho scritto cloud technoloy e via di ricerca. Come spessisimo accade la prima entrata è Wikipedia, ma è la definizione di Cloud Computing e effettuando un find nella pagina per la parola technology la prima occorrenza è nella definizione di virtualizzazione vista come una delle caratteristiche del Cloud Computing. La definizione di Cloud Computing riportata in Wikipedia è: “Cloud computing is the delivery of computing and storage capacity as a service to a heterogeneous community of end-recipients. The name comes from the use of a cloud-shaped symbol as an abstraction for the complex infrastructure it contains in system diagrams. Cloud computing entrusts services with a user’s data, software and computation over a network. There are three types of cloud computing: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)”.

Ma insomma io ho dubbi sulle “tecnologie cloud” e Wikipedia non ne riporta alcuna mensione? Non solo ma la definizione che da non mi soddisfa. Dire che Cloud Computing è (se riesco a tradurre bene…) “distribuire capacità elaborativa e di storage come un servizio ad un insieme eterogeneo di utenti finali” allora anche il TSO da solo lo posso considerare Cloud Computing? Mi si stavano smontando tutte le mie (poche) sicurezze sul tema.

A questo punto ho spostato la mia indagine di approfondimento verso la fonte dell’articolo ed ho trovato disponibile nel canale Youtube del Corriere delle Comunicazioni l’intervista a Raffaello Balocco della School of Management del Politecnico di Milano che potete vedere anche qui:

E il primo dubbio me lo sono tolto: Raffaello Balocco non parla di “tecnologie cloud” (che vengono mensionate dall’intervistatore), ma di adozione e diffusione di “soluzioni cloud”, il che mi lascia meno smarrito. Poi alla domanda:
“Quali sono i vantaggi, per una grande azienda ed anche per una piccola azienda dell’adozione di tecnologie Cloud based?”
(a Roma si direbbe: aridaje! adirittura di tecnologie cloud-based!) Raffaello Balocco risponde:
“Inanzitutto l’adozione di un sistema Cloud porta ad una maggiore standardizzazione del sistema informativo aziendale. La roadmap di utilizzo ed adozione del Cloud richiede che, come primo passo, vengano standardizzate le diverse componenti del sistema informativo e poi successivamente virtualizzate. Allora standardizzazione e virtualizzazione portano evidentemente dei vantaggi di efficenza e di flessibilità. Dal punto di vista organizzativo, la direzione IT può focalizzarsi, a livello di competenze, su degli aspetti di elevato livello: competenze di natura architetturale, di natura sistemistica, di Project Management […] demandando, viceversa, all’esterno quelle che sono le competenze più operative”.

Ne parla in modo chiaro e semplice evidenzioando, secondo me correttamente, i vantaggi iniziali visti sopratutto da un’osservatorio che può essere quello di un CIO. In qualche modo consolida anche la mia opinione che le piattaforme ibride, rispetto alle tradizionali, sono quelle che si prestano di più a sostenere una simile trasformazione. Questo perché lasciano una grande libertà nel realizzare, e modificare, architeture applicative su differenti piattaforme introducendo meccanismi di monitor e deployment che. dal punto di vista infrastrutturale, portano delle notevoli semplificazioni che implicano riduzioni di costi e di tempi.

Però i dubbi di fondo sul Cloud mi sono rimasti, così ho proseguito le ricerche anche perchè in molte entrate trovate su Google si parla di Cloud dando per scontato che il lettore sappia di cosa si parla. Ma così facendo ho letto di Cloud secondo le più differenti accezioni e forzature. Dietro la parola Cloud ho letto di offerte di hosting, ma anche di solo housing, di connettività di rete e chi più ne ha ….

Allora ho continuato a cercare fino a quando mi sono imbattuto nella definizione di Cloud del NIST. Quella che l’Istituto Nazionale degli Standards e delle Tecnologie Statunitense ha pubblicato non 3 o 5 anni fa, ma solo lo scorso anno il 25 Ottobre con il titolo Final Version of NIST Cloud Computing Definition Published. Non saranno rapidi, non saranno esaustivi ma quando pubblicano qualcosa quelli del NIST di solito è un riferimento che dura nel tempo, infatti questo è un documento di 7 pagine di cui solo 2 sono dedicate ad una definizione di 5 righe, all’elecazione delle caratteristiche essenziali, dei Service models e dei Deployment models. Finalmente leggo (liberamente tradotta da me, ma potete verificare l’originale seguendo il link): “Il Cloud computing è un modello per abilitare degli accessi tramite rete, su richiesta, convenienti e in modalità ubiquitous ad un insieme di risorse condivise e configurabili che possono essere rapidamente rese disponibili (deployed) e rilasciate con il minimo sforzo di gestione e con interazioni minime con l’erogatore del servizio. Questo modello è composto da 5 caratteristiche essenziali, 3 modelli di servizio e 4 modelli di deployment.”

Finalmente qualcuno che dice senza fraintendimenti cosa è il Cloud Computing senza il bisogno di dire come è fatto! Non è una tecnologia, non è una soluzione, ma è un modello; sulla base di questo modello, ovviamente utilizzando le tecnologie che meglio si adattano per concretizzare il modello, si possono erogare servizi e proporre soluzioni.

Lascio a voi la lettura completa del documento e continuo a raccontarvi le mie riflessioni. Infatti dopo aver letto il docuento non ho potuto non fare un paragone con lo zEnterprise. Delle 5 caratteristice almeno 3 le soddisfa by-desing. Da un punto di vista infrastrutturale, abbiamo un resource-pooling su tutte le piattaforme dell’ibrido grazie all’utilizzo dei meccanismi di virtualizzazione più appropriati per ciascuna di esse; grazie allo zEnterprise Unified Resource Manager la rapid elasticity è possibile fino allo spegnimento in caso di inutilizzo per ridurre i consumi e, definendo i workload gestiti si ha la caratteristica dei measured services. Per il broad network access ovviamente lo zEnterprise è condizionato al tipo e dimensione della connettività esterna, ma sempre by-design facilita la realizzazione con i meccanismi di gestione delle reti interni che vengono utilizzati dai differenti Virtual Server. L’ultima caratteristica (che nel documento è citata per prima) è l’On-Demand self-service; lo zEnterprise include un meccanismo per il deployment di virtual serve da template ma è più una facilitazione di gestione che un vero e proprio self-service. Per intenderci non è nato per essere reso disponibile ai consumers. Questo genere di funzionalità sono di solito fornite con dei Software Tivoli che permettono anche una grande flessibilità nel definire e realizzare le modalità di sel service.

I risultati delle mie ricerche mi hanno soddisfatto, anzi mi hanno fatto trovare una serie di documenti del NIST sicuramente interessanti che voglio indicarvi:

Se avete altre fonti o indicazioni fatemele conoscere che daremo loro l’adeguata diffusione. Da parte mia sto valutando di apire una pagina su questo sito dedicata al Cloud: mi fate arrivare in qualsiasi modo le vostre opinioni?

Ibridi: un’altra moda o evoluzione?


Per curiosità, stavo guardando la recensione di una nuova macchina fotografica digitale, la Canon EOS 650D, e tra le nuove caratteristiche ho letto “18MP APS-C ‘Hybrid CMOS’ sensor”. Ibrido? Anche per le macchine fotografiche? Ho subito pensato: “ma non è che la parola ibrido sia diventata una moda?”, “il mio caro zEnterprise é frutto di un’operazione fashion di marketing?”. Allora ho voluto approfondire per capire che cosa significasse un sensore ibrido e perché era stata fatta questa scelta.

Di solito le macchine digitali utilizzano dei sensori per catturare la luce e trasmetterla alla parte elettronica che la elabora e ne memorizza il risultato in forma di fotografia digitale. Negli ultimi 10 anni l’evoluzione dei sensori si è mossa verso tre direzioni: densità di pixel per avere maggiori dettagli, aumento della sensibilità alla luce per catturare le immagini in situazioni di scarsa luce o i dettagli delle zone in ombra, e velocità di reazione per permettere all’elettronica di effettuare le misure necessarie prima che la scena cambi.

Questa macchina fotografica utilizza un sensore che, oltre ai classici pixel per rilevare la luce, include anche dei sensori dedicati alla funzione di autofocus. Il classico sistema di rilevare la luce e passare tramite una misura fatta con l’elettronica per comandare i meccanismi di autofocus, inizia ad essere troppo lento soprattutto per le riprese di filmati. Quindi ecco che due componenti con specificità differenti (i due tipi di pixel) coesistono all’interno di uno stesso sistema (il sensore) per ottenere delle migliori prestazioni.

In effetti il lavoro di progettazione di sistemi tecnologici più o meno complessi, a mio parere, si sta spingendo in due differenti direzioni. La prima è quella di progettare utilizzando componenti specifici di tipo industriale per ciascuna funzione. Questo approccio permette di ottenere dei grossi risparmi e di realizzare dei prodotti che soddisfano delle necessità medie senza particolari pretese. La seconda direzione è quella di combinare in un unico elemento dei componenti con caratteristiche differenti per massimizzare alcune caratteristiche. Chiaramente il secondo approccio richiede uno sforzo di progettazione maggiore, sia come ingegno e sia come risorse finanziarie, portando alla fine un risultato con caratteristiche ibride “da disegno”.

Ed ecco quindi il perché la parola ibrido si sta diffondendo, non come moda, ma come risultato innovativo in vari campi. Inizialmente era un aggettivo tipico dei prodotti frutto della ricerca genetica, ora ne vediamo l’uso nelle vetture con doppia propulsione, in questa macchina fotografica, nei propellenti utilizzati dall’industria aerospaziale, nei pannelli solari che producono elettricità ed acqua calda, ma anche nel settore informatico nei dischi ibridi dove all’interno di una unità disco coesistono tecnologie classiche con quelle SSD (se non erro sia Seagate che Western Digital hanno dei drive di questo tipo).

Quindi, tornando allo zEnterprise, ho rivisto affermate le considerazioni fatte sulla sua caratteristica di sistema ibrido. È un ibrido in quanto include “da disegno” piattaforme per differenti Sistemi Operativi ed anche delle appliance specializzate e questa caratteristica permette di ottenere dei grossi vantaggi di gestione e di flessibilità. Inoltre lascia liberi di coniugare le più disparate scelte architetturali per supportare in modo adeguato le differenti componenti dei carichi di lavoro. La possibilità di considerare tutti i vari sistemi come un unico sistema nello zEnterprise si evidenzia al massimo con il concetto di Ensemble, che anche per problematiche di DR sicuramente introduce ulteriori benefici.

Per con concludere penso che le aziende che scelgono di seguire “la moda dell’ibrido” nei loro rispettivi campi lo fanno sempre più per rendere concretamente innovativi i propri prodotti.

Si allarga l’Hybrid Family


Il Blog DancingDinosaur ha pubblicato un post dal titolo “PureSystems Joins zEnterprise Hybrid Family” ed ovviamente mi ha subito incuriosito visto che la natura ibrida del PureSystem (nel senso che ospita sistemi di differenti architetture e instruction set) rende naturale un parallelo con lo zEnterprise.

Già sul sito IBM è comparsa una pagina che affronta il tema del posizionamento dei due sistemi che come primo impatto hanno due caratteristiche molto simili: la disponibilità di ambienti multipiattaforma e la gestione di questi con un unico strumento: l’Unified Resource Manager ed l’IBM Flex System Manager.

Ma torniamo all’articolo di Alan Radding: a mio parere illustra correttamente come il costo non sia l’unico criterio di scelta, ma piuttosto si debbano considerare le caratteristiche dei workload e la loro necessità di scalare.

[…] “Ad esempio, una blade PowerLinux come componente PureSystems può offrire una migliore rapporto prezzo/prestazioni rispetto ad un Linux in eseguito su un IFL dello z? Analogamente, i carichi di lavoro di Windows devono essere fatti eseguire su un blade HX5 nel zBX o su un PureSystems? In questo momento non ci sono sufficienti dati relativi ai prezzi ed alle prestazioni per poter decidere. […]  Guardando al futuro, IBM sta già pianificando il supporto zBX per la prossima generazione z e promette di integrare più strettamente lo zEnterprise con il PureSystems. Io zEnterprise, zBX, ed l’hybrid computing a quanto pare saranno in giro per un pò.