Enterprise IT

Enterprise Grade Requirements for IT Solutions deployment and related economic

considerations

IBM (International Business Machine) è un’azienda che è sul mercato da 110 anni, nata inizialmente
per creare delle macchine (devices) per il business, non per i privati. È un’azienda che non punta al
mercato di largo consumo, tipicamente solo delle aziende acquistano questi prodotti o servizi.

Sommario
Enterprise IT e Requisiti non funzionali ........................................................................................................................ 2
Cos’è una Enterprise? ................................................................................................................................................... 2
Enterprise-level solutions ........................................................................................................................................ 2
Lo sviluppo delle applicazioni richiede la considerazione di molti aspetti .............................................................. 2
Esempio ..................................................................................................................................................................... 3
Dove si inserisce Z nell’Hybrid Cloud ........................................................................................................................ 4
Application Programming Interface (API) ................................................................................................................ 4
Ambienti di sviluppo .................................................................................................................................................... 4
Requisiti non funzionali (NFRs) .................................................................................................................................. 5
Reliability & Availability ......................................................................................................................................... 5
Serviceability (aka Supportability) ......................................................................................................................... 7
Security ..................................................................................................................................................................... 7
Performances ............................................................................................................................................................ 9
Scalability ................................................................................................................................................................. 9
Enterprise IT e Implicazioni Finanziarie ..................................................................................................................... 11
Esempio ....................................................................................................................................................................... 11
TCO and Business Value ........................................................................................................................................... 11
IT Economics – Linux TCO Comparison on 5 years .............................................................................................. 12
The Z Hardware platform ......................................................................................................................................... 14
Z Systems have several types of Processors ......................................................................................................... 15
Logical Partition (LPAR) ...................................................................................................................................... 15
Memory Spairing ................................................................................................................................................... 15
IBM z15 ................................................................................................................................................................... 16
Sfide con il modello dei prodotti x86 ......................................................................................................................... 16
Far fronte ai picchi ..................................................................................................................................................... 17
Statistical multiplexing models ............................................................................................................................. 17
Passaggio al cloud per sfruttare l’elasticità .............................................................................................................. 18
Cloud approaches: IaaS, PaaS, SaaS ........................................................................................................................ 19
ESEMPIO .................................................................................................................................................................. 19
Visione moderna della strategia cloud delle aziende ............................................................................................... 20
L’importanza dell’open ............................................................................................................................................. 20
Enterprise IT e Requisiti non funzionali
Cos’è una Enterprise?
Una enterprise è una grande impresa, come un’azienda o un ente governativo o un ente pubblico,
ovvero un ente sofisticato che ha certe caratteristiche.
Tipicamente un’enterprise è una grande società o un’organizzazione che
• Gestisce un numero di clienti molto elevato (da migliaia a milioni o più); un esempio tipico
sono gli operatori telefonici che gestiscono milioni di clienti. Lavorare e pensare ad un alto
numero di clienti permette di creare una scalabilità d’impresa che porta dei benefici per tutti:
per l’azienda perché ha margini di profitto molto elevati, ma anche per i clienti che possono
avere dei servizi erogati a costi minori perché il costo di ammortamento iniziale di servizio
viene distribuito su più possibili clienti.
• Ha centinaia o migliaia di impiegati che lavorano per essa.
• Offre un servizio che deve essere disponibile 24x7 (o 24x7x365); un esempio tipico è il
bancomat che è sempre in funzione.
• Tipicamente opera all’interno di una industry strettamente regolata, ovvero una sorta di
mercato in cui si trova ad operare la enterprise. In realtà è anche più di un mercato, perché al
suo interno esiste un contesto di regole al quale è necessario sottostare; ad esempio, se
volessimo aprire una banca o una compagnia aerea, non potremmo farlo così dal nulla, idem
per diventare tassista serve la licenza.
- Supponiamo che vi sia una banca, il cui edificio è stato distrutto da una catastrofe
naturale. Ciò che ci auguriamo è che i server della banca siano replicati in luoghi
differenti, ma questo fa parte del regolamento della industry, ovvero nella industry
bancaria esiste una regola (o un constraint) che impone alle banche di avere un sistema
di disaster recovery tale per cui i loro sistemi informativi devono essere replicati
almeno due volte in due posti distanti almeno un certo numero di centinaia di
chilometri.
• Fornisce servizi rispettando Service Level Agreement (SLA) molto stringenti.
• Deve essere in grado di gestire picchi di domanda (anche fino a migliaia di volte superiori
alla media); ad esempio, pensiamo ai picchi di domanda gestiti dai siti di e-commerce durante
il black friday. Se calibrassimo il sistema per gestire la media della domanda, allora al
verificarsi di un picco non funzionerebbe più niente.
• Deve supportare richieste di servizio che possono essere milioni o miliardi per unità di
tempo.
Enterprise-level solutions
Sono soluzioni molto sofisticate che soddisfano i requisiti di enterprise, sono implementate a larga
scala e richiedono un’attenzione di specialistica IT molto sofisticata.
Lo sviluppo delle applicazioni richiede la considerazione di molti aspetti
Ad esempio, per lo sviluppo di un’applicazione che garantisca l’esecuzione di transazioni è necessario
utilizzare un Application Server: offre, oltre a fornire i servizi offerti da un Web Server, dei servizi di
tipo transazionale, ovvero è in grado di gestire più richieste in parallelo garantendo che le transazioni
siano ACID.
Oltre ai classici aspetti relativi al Middleware e alla piattaforma, esistono tutta un’altra serie di aspetti
che non sono rilevanti per un sistema piccolo, ma lo sono per uno di livello enterprise, come ad
esempio: data replication, partitioning, system management, tuning, security, orchestration, load
balancing, ecc. Tutto ciò si trova al di sopra della parte hardware, la quale può essere: on premise (“in
casa”) oppure cloud.
Esempio
Supponiamo di avere aperto una nuova linea di scarpe di lusso.
Supponiamo poi che ci vengano ordinate 10 paia di scarpe da un negozio nella stessa città: paghiamo
50€ per effettuare una consegna con un Minivan e abbiamo risolto il problema del trasporto.
La vendita ha avuto grande successo, la voce si è diffusa e veniamo contattati da un negozio fuori
città per una consegna di 100 paia di scarpe: paghiamo 100€ per effettuare la consegna con un
autocarro che riesca a contenere tutte le scatole di scarpe.
Il successo continua a crescere fino ad arrivare a dover consegnare 100'000 paia di scarpe in un altro
continente: ci mettiamo d’accordo con una delle tante aziende di delivery internazionale che ci chiede
un importo pari a 50'000€.
• Domanda: quale dei precedenti trasporti è stato il più dispendioso per l’azienda?
• Risposta: il primo, perché lì abbiamo pagato 5€ per ogni paio di scarpe, mentre nell’ultimo
siamo arrivati a pagare solamente 0,50€ per ogni paio.
Tutto questo discorso vale anche nel mondo IT, perché finora abbiamo sviluppato applicazioni sul
nostro computer che possono andar bene per piccole attività private, ma quando il business comincia
a crescere abbiamo bisogno di server un po’ più sofisticati. I server tipicamente vengono messi in un
data center, all’interno di armadi (o rack) in cui sono riposti orizzontalmente (prendendo il nome di
rack, perché sono come dei cassetti) oppure verticalmente (prendendo il nome di blade, perché sono
come delle lame). Esistono anche dei server più grandi che corrispondono a 4-unit rack o server di
tipo enterprise chiamati classe Z da IBM. Tutti questi tipi di server servono per svolgere diversi tipi
di servizi analogamente ai diversi mezzi di trasporto esaminati nell’esempio precedente.
Dove si inserisce Z nell’Hybrid Cloud
Le applicazioni quotidiane che utilizziamo con il nostro smartphone vengono chiamate System of
Engagement, cioè vogliono “ingaggiare” quando vogliamo utilizzare un’applicazione per chattare o
fare acquisti online, ecc. Questa parte di applicazione tipicamente si collega ad una serie di servizi,
applicazioni che girano sul cloud per fornire una serie di informazioni di supporto, e poi vanno a
prendere le informazioni nei cosiddetti System of Records. Per cui nelle applicazioni tradizionali
esistono due tipi di sistemi che sono quasi sempre presenti nel cosiddetto back office:
• System of Engagemen: stanno nel mezzo tra le App e i System of Records.
• System of Record: in questo abbiamo i dati, le nostre informazioni. Ad esempio, per un sistema
di acquisto online qui avremo un sistema di gestione della transazione, un sistema di gestione
del magazzino, un sistema di gestione degli ordini, un sistema di gestione delle consegne, ecc.
Se questi sistemi di tipo enterprise non funzionano correttamente il problema è grave, perché
devono essere sempre attivi. Z sta per zero downtime e rappresentano l’evoluzione di
tradizionali Mainframes.
Application Programming Interface (API)
Sono gli elementi critici per accedere a tutti questi servizi, in particolare è l’insieme delle istruzioni
di programmazione e standard per l’accesso alle applicazioni software.
Consideriamo lo Use Case di acquisto di un biglietto aereo. Per acquistare il biglietto utilizziamo o
un’app o un’applicazione web e forniamo i dati necessari (data, aeroporto di partenza, destinazione,
numero di persone, ecc). A questo punto l’app mostrerà una lista di voli disponibili per diverse
compagnie aeree, ma cosa è successo sotto il cofano (under the hood)?
L’applicazione avrà mandato le informazioni ad un System of Engagement, che a sua volta avrà
comunicato con un System of Record, che avrà effettuato delle query ad un DB e quindi si sono
verificate tutta una serie di transazioni che hanno poi riportato il risultato alla nostra app. Sicuramente
però non siamo stati gli unici ad inviare una richiesta all’applicazione in quel momento, eppure il
risultato ci viene fornito in tempi molto brevi! Solitamente se il risultato non viene ottenuto dopo
mezzo minuto, si riavvia l’applicazione.
Quando si parla di tempi di risposta brevi si sta parlando di requisiti non funzionali di tipo enterprise.
Ambienti di sviluppo
1. Development
2. Test
3. Pre-Production aka QA (Quality Assurance)
4. Production
5. High Availability
6. Disaster Recovery
Quando sviluppiamo le nostre applicazioni sul nostro computer, tutto il lavoro avviene lì, pertanto
esso consiste nel nostro ambiente di sviluppo.
Quando però svolgiamo un progetto di gruppo, lo stesso software gira anche su altre macchine, altri
ambienti (ambiente di test), che sono utilizzati per fare il test in maniera indipendente.
L’ambiente di produzione è dove viene eseguito il software ufficiale da utilizzare quando si accede
al servizio. Riferendoci all’esempio di prima, si tratta del server dove c’è il software che interroga il
database per fornirci un risultato. Questo è un ambiente delicatissimo, quindi se va giù, anche per
pochi minuti, è un casino!
Per tale motivo esiste un ambiante chiamato preproduzione o QA, che tipicamente è una copia
identica dell’ambiente di produzione, in cui viene provata l’applicazione dopo che è stata testata, ma
prima di essere messa in esercizio. Qui possiamo verificare che l’applicazione sviluppata si
comporterà come previsto una volta messa in commercio.
L’ambiente di elevata affidabilità serve per assicurarsi che se qualcosa va male (e.g. si rompe un
disco, va via la corrente, cade la connessione, ecc) c’è un altro ambiente che ha le stesse informazioni
e fornisce i servizi in maniera trasparente.
L’ambiente di disaster recovery è quel “posto lontano” che deve fornire i servizi nel caso in cui
l’ambiente di produzione è colpito da una catastrofe naturale.
Abbiamo dunque questi sei ambienti in cui viene eseguito più o meno lo stesso software, che deve
soddisfare tutta una serie di requisiti non funzionali.
Requisiti non funzionali (NFRs)
• Reliability & Availability
• Serviceability
• Security
• Performance
• Scalability
Reliability & Availability
• Un 99% di availability significa 3 giorni e 15 ore di downtime annuale.
• Un 99.999% di availability significa 5 minuti di downtime annuale.
Per cui la disponibilità di un sistema si misura in termini di “numero di 9”.

SOURCES:
• https://en.wikipedia.org/wiki/High_availability
• https://searchunifiedcommunications.techtarget.com/tip/The-truth-about-five-nines-
availability-in-unified-communications-networks

Ad esempio, se due sistemi sono entrambi affidabili al 99.9% qual è l’affidabilità del sistema
complessivo? Essa è data da 99.9% ∗ 99.9% = 99.8% ⇒ l’affidabilità decresce!
Lavorare sull’affidabilità quindi è fondamentale, ma lo è anche la considerazione del numero di
sistemi che dobbiamo gestire, perché più questo numero cresce e più l’affidabilità diminuisce.
Quando si parla di requisiti di Reliability & Availability spesso si legge 24x7, ma oltre a ciò dovrebbe
esserci anche l’informazione sul livello di affidabilità (in termini di numero di 9) che sta ad indicare
la probabilità che il sistema sia ON. Oppure può essere specificato il downtime, ovvero il tempo in
cui il sistema non è in grado di erogare il servizio.
Molte industry hanno una serie di requisiti di affidabilità dettati dallo SLA della industry (come la
banca europea).
N.B.: a volte è il mercato che detta i requisiti di affidabilità, altre volte è la industry. Ad esempio,
provando ad accedere ad un sito di e-commerce, se dopo un tempo breve non riusciamo ad accedervi
perché il caricamento è molto lento, allora molto probabilmente rinunciamo ad entrare su quel sito e
ne scegliamo un altro. In questo caso non è la industry che impone un livello di affidabilità elevato,
il problema persiste lo stesso perché il mercato me lo impone. Mentre, per quanto riguarda le banche,
i requisiti di alta affidabilità e di disaster recovery sono dettati dalla industry.
Come abbiamo già detto, al crescere del numero di sistemi cresce anche il numero di failure ed ecco
che entrano in gioco i sistemi di tipo enterprise: avere una macchina con affidabilità pari a 99.99% o
averne 1000 con la stessa disponibilità fa la differenza quando si calcola l’affidabilità del sistema
complessivo. Ovviamente avere una macchina che ha un’affidabilità pari al 99.99% rispetto ad una
con affidabilità più bassa è come paragonare un aereo con un’automobile, per cui i prezzi sono
totalmente differenti, ma non è che uno costa caro e l’altro no, erogano semplicemente due servizi
diversi.
ITIC-corp
È un’organizzazione che fa analisi di affidabilità dei vari sistemi presenti sul mercato.

SOURCE: WWW.ITIC-CORP.COM

Vedendo questi dati, per fare un semplice progetto universitario va benissimo White Box x86
(computer senza marca che assembliamo noi), perché se ogni tanto è necessario un reboot o qualche
riparazione non è un problema, ma per erogare dei servizi ad un livello più alto questo sarebbe
inaccettabile.
Serviceability (aka Supportability)
Si riferisce all’abilità del personale di supporto tecnico di mantenere la corretta erogazione dei servizi
e in caso di problemi deve essere in grado di risolverli in tempo reale.
Per cui l’obiettivo della serviceability è di ridurre i costi operativi e di manutenzione, assicurando una
business continuity. Ad esempio, è come cambiare una ruota alla macchina o fare un tagliando mentre
la macchina sta camminando. Alcuni servizi è possibile offrirli con una certa probabilità di successo,
altri no.
Per fare un esempio, ormai è comune che sui server di fascia non altissima è possibile effettuare
l’hotswap dei dischi, ovvero mentre il server è attivo è possibile sostituire il disco (che è una delle
parti che viene sostituita con maggior frequenza).
Dunque, per serviceability si intende la pianificazione della sostituzione dell’hardware o l’upgrade
del software (manutenzione simultanea per entrambi), dove il prodotto è progettato per consentire
aggiornamenti hardware efficienti con tempi minimi di downtime del sistema (e.g. hotswap dei
componenti).
Security
È un requisito molto importante, perché ad oggi la probabilità che un’organizzazione abbia un data
breach nei prossimi 24 mesi è del 28%. Per cui non si dice più: “speriamo che la nostra azienda non
sia colpita”, bensì: “speriamo che riusciamo a rilevare l’attacco in tempi brevi in modo tale da
risolvere”, quindi gli attacchi e le intrusioni sono comunque presenti e costanti, e dobbiamo avere un
sistema in grado di proteggersi da attacchi esterni. Molte piccole aziende trascurano i problemi legati
alla sicurezza.
Secondo lo European Union GDPR (General Data Protection Regulation), legge europea resa
operativa nel 2018, se qualcuno entra nel nostro sito e copia i nostri dati personali e noi non
denunciamo l’accaduto entro 24 ore, siamo soggetti a possibili multe pari al 4% del fatturato annuale
mondiale.
Encryption dei dati
Uno degli elementi più importanti della sicurezza è anche quello della encryption dei dati. Questo
permette anche di proteggere internamente da chi riesce ad entrare nel sistema, facendo sì che
vengano copiati dei dati criptati. I problemi che possono però insorgere sono:
• Quali dati dovrei criptare?
• Quando dovrei criptare i dati?
• Dove memorizzo questi dati?
• Chi è responsabile della encryption?
Approccio di encryption iniziale (storicamente) è il selective encryption: se i dati per i quali do
l’autorizzazione per la memorizzazione sono i dati personali, allora cripto i dati personali, ma nel
momento in cui viene effettuato un attacco su 10TB di dati di cui 100KB sono criptati, si intuisce che
i dati sensibili sono quelli criptati. Per cui il selective encryption metteva in risalto “il tesoro”,
successivamente si è passati al full disk encryption che però non soddisfa tutti i vari requisiti: il disco
è tutto criptato, ma restano delle problematiche relative al passaggio dei dati tra il DB e l’application
server che possono risiedere su server diversi ed essere trasferiti in plaintext, inoltre senza un sistema
dedicato all’encryption questo risulta essere oneroso per il processore che si deve far carico di
effettuare encryption e decryption dei dati.
A livello enterprise l’approccio utilizzato è una pervasive encryption: encryption di tutto e ovunque
(quindi non solo su disco ma su tutto il sistema), ha focus sull’eliminazione delle barriere:
• andiamo a disaccoppiare l’encryption dalla classificazione (non ci sono dati importanti e non
importanti per l’encryption);
• evitiamo modifiche all’applicazione, perché diamo per scontato che dietro vi sia un sistema
che gestisce la crittografia e non la facciamo a livello applicativo (anche perché spesso non
siamo esperti di crittografia e non siamo in grado di ottimizzarla);
• c’è il problema di proteggere le chiavi di crittografia, oppure di non cambiare le chiavi e
riusarle più volte.
Per cui la strada è quella di adottare dei sistemi dedicati di tipo enterprise che fanno questo lavoro:
• effettuano l’encryption di tutti i dati (senza classificazione) a livello di SO e di firmware, in
accordo con le politiche di sicurezza della enterprise e senza interrompere le operazioni di
business;
• c’è dell’hardware dedicato a fare questo lavoro, quindi è ottimizzato ed adotta algoritmi
affidabili;
• utilizzano dei Secure Service Container che semplificano la gestione delle chiavi di
crittografia (le memorizzano, le aggiornano, sollevano dalla responsabilità di conoscere tali
chiavi).
Performances
Quando si parla di performances di computer ci sono tantissime metriche che possono essere
utilizzate a seconda di quale aspetto di performance ci interessa. Ad esempio:
• tempo di risposta
• velocità di processamento
• capacità del canale
• latenza
• larghezza di banda
• throughput
• efficienza
• …
Per i Systems of Records una misura delle performances estremamente importante è il numero di
transazioni per secondo (TPS) che sono in grado di essere erogate dal sistema.
Per fare un esempio, possiamo pensare ad un acquisto effettuato in un negozio mediante carta di
credito: il terminale di pagamento (POS) manda tutta una serie di informazioni al System of Records
che c’è dietro per verificare se la carta è abilitata o è stata ad esempio cancellata o rubata, quali sono
i massimali di acquisto, ecc. Quindi fa tutta una serie di verifiche per dare l’autorizzazione
all’acquisto e possiamo pensare una transazione come il ciclo di attività appena descritto. In realtà
una transazione di questo tipo (transazione applicativa) è composta da più transazioni sul DB.
Al crescere del business della enterprise, cresce anche il numero di TPS necessarie: se abbiamo 1000
punti vendita sul territorio italiano, ciascuno dei quali possiede 4 o 5 registratori di cassa, allora il
numero di TPS sarà dell’ordine delle 4000 o 5000.
Scalability
Il problema della scalabilità per una impresa è che, se il business ha successo, inizia ad aumentare il
numero di punti vendita e bisogno di un sistema informativo in grado di supportare e offrire servizi
per numeri sempre più alti di punti vendita e di conseguenza in grado di erogare un numero di TPS
che cresce.
Ci sono due principali approcci di scalabilità:
 • Scale Up aka scalabilità verticale: si sostituisce il vecchio computer con uno più potente in
grado di erogare gli stessi servizi;
• Scale Down aka scalabilità orizzontale: si aggiungono più server accanto a quelli già presenti,
mettendo su un’architettura in grado di fare un workload balance, ovvero distribuire il carico
di lavoro sui vari server.
Come si può notare dalle frecce rosse in
figura, il primo approccio introduce un costo
via via esponenziale all’aumentare della
capacità del server che viene sostituito. Nel
secondo caso invece, la crescita del costo
introdotto è lineare all’aumentare del numero
di server acquisiti.
In una enterprise abbiamo vari ambienti,
quindi nel total cost of ownership bisogna
tener conto di tanti aspetti: hardware,
software, networking (switches, hubs, ecc),
spazio (e.g. affitto di locali, aria condizionata,
ecc), persone (e.g. IT administrators).
Purtroppo, nella realtà i costi crescono linearmente nel caso di scale up e crescono esponenzialmente
nel caso di scale out, come mostrato dalle frecce rosa in figura. Il motivo è che, come abbiamo visto,
oltre all’ambiente di produzione abbiamo un ambiente di test, un ambiente di alta affidabilità, un
ambiente di sviluppo e potrei averne anche uno di disaster recovery. Ad esempio, se il business di
una azienda con 50 server raddoppiasse, avrebbe bisogno di 100 server (scale out approach). Il
problema è che l’aumento di server deve avvenire in ogni ambiente! Proprio per questo motivo non
è raro che per banche, di dimensioni medie, si arrivi ad avere 10'000 server o più, per una singola
applicazione
Purtroppo, l’approccio di scale out è molto comune, perché si tratta dell’approccio più semplice per
le aziende che partono con poche risorse “di prova” e ne aumentano il numero a mano a mano che il
loro business cresce.

Enterprise IT e Implicazioni Finanziarie

Esempio

Prendiamo un server. Su di esso dobbiamo considerare hardware e

software, ma come software consideriamo solo il DB.

Spesso abbiamo utilizzato DB come MySQL o MariaDB, che sono database open-source e anche questi nel
mondo enterprise vengono utilizzati, ma non sono free of charge. Questo perché un’azienda di tipo enterprise
vuole avere un technical support, ovvero al verificarsi di un difetto dovuto al software utilizzato potrebbe
essere necessaria una patch, perché il problema potrebbe essere bloccante e impedire l’erogazione dei servizi
fino all’ottenimento di tale patch. Quindi anche utilizzando software open-source viene pagata una fee da
parte della enterprise per ricevere technical support da parte dell’azienda che lo offre e questa fee è legata al
numero di core.

I software si pagano per licenza di software e questa licenza è legata ad un qualcosa a seconda del tipo di
software. Ad esempio, una licenza per un sistema operativo può essere legata ad un server (come nel caso di
Windows), mentre per un database tipicamente è legata al numero di core.

Esempi di database non open-source sono invece: Oracle Database, Amazon DynamoDB, Microsoft SQL
Server, IBM DB2. Qual è la modalità di licency e il suo costo per questi database?

Esercizio: fare una ricerca dei database di mercato e open-source, con relativi prezzi di acquisto e di
manutenzione.

Ipotizzando di avere un ambiente con 100 core in produzione, abbiamo bisogno di 100 licenze per
tale software, ma con 4 ambienti diversi abbiamo 400 core e quindi abbiamo bisogno di 400 licenze.
Per cui anche se siamo i proprietari dell’applicazione sviluppata, quindi non dobbiamo pagarla, ma
andiamo a svilupparla al di sopra di un database, dobbiamo utilizzare quel software e quindi far fronte
ai costi di licenza.
TCO and Business Value
I software necessari per far girare un’applicazione sono parecchi, si parla di software stack che
include: database, application server, virtualizzatore, sistema operativo (anche quelli open-source
prevedono una fee annuale), ecc.
Alla fine, è importantissimo quando si parla del costo di una soluzione, considerare il Total Cost Of
Ownership (TCO), che è ben diverso e molto maggiore del Total Cost Of Acquisition (TCA).
Il TCA comprende: hardware (e.g. servers), software (e.g. DB, application server, virtualizzatore),
cloud services.
Tipicamente per badare ad un server basta un controllo ogni una o due settimane da parte di un IT
administrator, ma quando il numero di server comincia a crescere, ogni 30 server c’è bisogno di un
cosiddetto full time equivalent (FTE), ovvero l’equivalente di una persona full time (40 ore a
settimana per l’intero anno) assegnata; nella pratica non c’è sempre corrispondenza 1:1 tra FTE ed
impiegato. Se avessimo bisogno di supporto 24x7 potremmo avere 3 persone nell’arco della giornata
(33% del tempo ciascuno) ognuna delle quali supporta anche 120 o 150 server.
Per cui oltre ai TCA c’è da tener conto dei costi legati alle persone (e.g. IT administrator), alla rete,
ecc. Inoltre, ci sono da considerare anche altri aspetti:
• questi costi vanno moltiplicati per il numero di ambienti
• quality of services
• vincoli di business (e.g. SLA penalties)
• tempo, ovvero in un TCO tipicamente si considera una finestra temporale di cinque anni,
perché il refresh dell’hardware viene fatto ogni tre o quattro anni. Ad esempio, un’azienda
con 10'000 server può stabilire un refresh cycle della durata di tre anni e quindi ogni anno
viene fatto il refresh di circa 3500 server (non vengono refreshati tutti insieme alla fine del
ciclo), anche questo spalmato su tutto l’arco dell’anno (250 o 300 server al mese). Per cui c’è
da considerare il tempo di upgrade, refresh, ecc.
Il TCO tiene conto di tutto ciò che abbiamo detto finora!

Gli ambienti devono necessariamente essere tutti isolati?

Alcuni ambienti sono totalmente isolati, come l’ambiente di produzione, l’ambiente di preproduzione
(QA) e l’ambiente di disaster recovery. Per quanto riguarda l’ambiente di sviluppo, potrebbe anche
non essere grande come quello di produzione, ovvero potremmo avere 100 server nel primo e 20
server nel secondo, questo perché non è necessaria una potenza di elaborazione pari a quella di
produzione. Stesso discorso può essere fatto per l’ambiente di test, però resta il fatto che il team di
sviluppo deve poter essere indipendente dal team di test e quindi deve poter lavorare sui propri server
per fare delle modifiche sfruttando i propri dati e analizzando i risultati.
IT Economics – Linux TCO Comparison on 5 years
Spendere decine di milioni di euro per mettere su un ambiente di tipo enterprise è una cosa comune.
Una tipica banca che vuole offrire un nuovo servizio dovrà far fronte a costi simili a quelli riportati
di seguito.
* DATA FROM A MAJOR EMEA BANK EVALUATING THE SAME WORKLOAD DEPLOYED ON EQUIVALENT
ENVIRONMENTS IN TERMS OF PERFORMANCES.

Per erogare lo stesso servizio è possibile adottare la soluzione proposta nel Case 0, oppure quella
proposta nel Case 1. Come possiamo osservare, i due server di tipo enterprise hanno un costo di
acquisto e di supporto molto superiore rispetto a quello dei 77 server (più del doppio), però il costo
del software ha un impatto decisamente maggiore nel secondo caso.
Il costo per il disaster recovery potrebbe
rappresentare la somma di tutti i costi
precedenti, ma questo dipende
dall’obiettivo dell’azienda, ovvero se, in
caso di disaster, volesse essere in grado
di continuare a fare tutto ciò che era in
grado di fare con il primo ambiente. In
Case 1 il disaster recovery è un
ambiente in grado di erogare tutti gli
stessi servizi dell’ambiente main site.
Una volta messo in esercizio tutto l’ambiente, i costi annuali variano a seconda della soluzione che è
stata adottata.

La sintesi di questo discorso è che lo stesso servizio può essere erogato o con 4 rack contenenti 78
server, per un totale di 1672 core di tipo x86, oppure, nel caso enterprise, 1 singolo rack replicato per
l’ambiente di disaster recovery, per un totale di 108 core.
Lo z15 corrisponde all’evoluzione classica del Mainframe, ovvero è la 15-esima versione della
macchina Z e tipicamente su di esso sono in esecuzione N sistemi operativi; mentre il LinuxONE è
l’evoluzione del Mainframe dedicata al mondo Linux, ovvero è una macchina in grado di supportare
solo carico di lavoro su sistema Linux.
The Z Hardware platform
La caratteristica principe della piattaforma Z è quella di essere organizzata per essere un ambiente
virtuale che si presenta come se fosse: per ogni utente una macchina dedicata a quell’utente, nel
complesso, come se fossero N macchine anche di tipo completamente diverso.
La piattaforma architetturale di un Mainframe parte dal concetto di avere N CPU condivise. C’è un
firmware particolare che ha l’obiettivo di condividere tutte le risorse a disposizione: processori,
memoria, rete, dischi, I/O, long term storage, ecc. Quindi l’hardware del mondo Z viene visto come
un data center in un box, per cui non è corretto paragonare una macchina Z ad un server, bensì sarebbe
più corretto paragonarla ad un data center con N server più i sistemi di networking, i sistemi di storage,
i dischi san, ecc. L’ambiente Z è stato progettato per condividere queste risorse in maniera virtuale.
Sopra al firmware di partizionamento tipicamente gira un virtualizzatore, ovvero un sistema di
virtualizzazione chiamato z/VM, che crea delle macchine virtuali dal punto di vista hardware (non
software), quindi ha una grandissima efficienza. Il Mainframe è nato con l’idea di far girare N
virtualizzatori dal punto di vista hardware e su ciascuno di essi girano N sistemi operativi diversi, ad
esempio: z/OS, z/VSE, Linux on Z (che può essere qualunque distribuzione), z/TPF, ecc.
Questo partizionamento permette un utilizzo di CPU pari al 90% regolarmente.
Z Systems have several types of Processors
Oltre ad avere più processori, sulla piattaforma Z abbiamo anche diversi tipi di processori che sono
dedicati a svolgere compiti specifici.
• Central Processor (CP): processori classici per normali sistemi operativi e applicazioni
software.
• System Assistance Processor (SAP): processori dedicati alla gestione dell’I/O.
• Integrated Coupling Facility (ICF): processori dedicati a far collaborare macchine diverse che
lavorano in modo accoppiato. Per cui è possibile configurare due macchine per essere
accoppiate, scegliendo anche il tipo di accoppiamento, e questi processori faranno in modo
che queste due macchine verranno viste all’esterno come se fossero una singola macchina
(utile anche nel contesto del disaster recovery).
• Integrated Facility for Linux (IFL): processori dedicati al workload Linux.
• zAAP: processori dedicati all’esecuzione di codice Java, sono quindi ottimizzati, ad esempio,
per minimizzare le operazioni di garbage collection. Fanno parte dei processori dedicati a
supportare un singolo workload.
• zIIP (Integrated Information Processor): processori dedicati per il workload dei database.
IFL, zAAP e zIIP sono configurazioni particolari di CP che hanno lo scopo di minimizzare i costi.
• Spare: sono delle CPU aggiuntive di scorta, in modo che se un processore dovesse fallire,
uno spare processor verrebbe attivato per sostituirlo. Nella maggior parte dei casi la
sostituzione avviene senza interruzioni di sistema, anche per l’applicazione che era in
esecuzione sul processore fallito.
MORE INFO: http://www.redbooks.ibm.com/abstracts/sg248852.html
Logical Partition (LPAR)
È come se fosse una suddivisione del sistema Z in una macchina logica configurata da noi. È un
concetto molto simile alla creazione di una VM con un virtualizzatore, per cui si può scegliere la
quantità di memoria, il tipo di CPU, il livello di utilizzazione della CPU, ecc. La differenza è che la
LPAR viene fatta anche dal punto di vista hardware (quindi è estremamente efficiente) e inoltre sono
completamente isolate a livello hardware, per cui un crash di una LPAR non può compromettere il
crash dell’intero sistema. Per questo motivo, poiché un server Z è sempre configurato in N LPAR, si
tratta di una macchina che resta up and running per decine di anni.
Le LPAR possono avere processori dedicati o condivisi, mentre invece la memoria deve essere
dedicata per ogni LPAR.
MORE INFO: http://www.redbooks.ibm.com/abstracts/sg248851.html?Open
Memory Spairing
Esistono i cosiddetti dischi RAID (Redundant Array of Independent Disks) che sono un insieme
ridondante di dischi indipendenti ed è possibile avere diversi tipi di ridondanza a seconda della
configurazione di questi dischi. Ad esempio, possiamo avere 5 dischi di cui 4 contengono i dati e uno
contiene dei check-bit. In questo modo se un disco si rompesse, dall’informazione del quinto disco
riusciremmo a risalire ai dati che avevamo. Con una ridondanza completa i dati vengono memorizzati
sempre su almeno due dischi.
Il RAID appare all’esterno sempre come un unico disco, per cui se collegassimo un RAID al nostro
computer, facendone il mount come se fosse il disco D, e se il RAID fosse composto da due dischi
da 3TB ciascuno configurati in modo tale che siano uno ridondato rispetto all’altro, allora facendo il
mounting del RAID sembrerebbe esserci un unico disco e la scrittura di un dato avviene
contemporaneamente su entrambi.
RAIM (Redundant Array of Independent Memory) è una memoria RAM che funziona come i dischi
RAID: ci sono più banchi di memoria, tali che se un banco di memoria ha un problema è possibile
recuperare i dati su tale banco. Per cui, mentre il software è in esecuzione i dati vengono memorizzati
anche su queste altre celle di memoria, in modo tale che la perdita dei dati durante l’esecuzione sia
quasi impossibile. Il RAIM prende il 20% della memoria disponibile e non è possibile utilizzare
un’opzione non-RAIM su queste macchine.
MORE INFO: http://www.redbooks.ibm.com/abstracts/sg248852.html
IBM z15

Sfide con il modello dei prodotti x86

Il problema principale nel mondo x86 è che le macchine hanno il proprio hardware e possono
utilizzare un hypervisor al di sopra di esso ma non possono condividere tra loro le proprie risorse.

Al crescere del carico di lavoro, il data center appare come una fila sterminata di server da andare a
gestire e la probabilità di avere un problema aumenta all’aumentare del numero di server. Diversa è
la situazione in cui abbiamo un singolo server di tipo enterprise o un numero ristretto di essi che
permettono di erogare la stessa potenza elaborativa di tutti i singoli server x86.
Far fronte ai picchi
L’approccio tipico per far fronte a dei picchi di domanda è quello di calibrare il sistema in maniera
tale che possa essere in grado di far fronte a dei picchi quando essi si verificano. Con questo approccio
però, durante il normale utilizzo del sistema, registriamo un’utilizzazione delle risorse molto bassa
(tipicamente < 20%; raramente < 30%) e di conseguenza vi è un grande spreco di risorse e un
innalzamento dei costi e del consumo energetico. Ciò che tutti vorremmo è che il numero di risorse a
disposizione vari al variare della domanda, ma ottenerlo non è così semplice.
Un approccio è quello di utilizzare un ambiente
cloud, che risulta essere un ambiente elastico che in
poco tempo riesce a darci risorse che non abbiamo e
paghiamo solo per quelle che utilizziamo.

Tipicamente creiamo il nostro ambiente in base al tipo di carico, ovvero una enterprise crea un nuovo
ambiente per ogni nuovo tipo di servizi e questi risultano utilizzati soltanto in parte.

SOURCE: “DATA CENTERS IN THE WILD: A LARGE PERFORMANCE STUDY”, R. BIRKE, L. CHEN, E. SMIRNI.
IBM RESEARCH RZ 3820, 2012.

L’utilizzazione è bassa perché con gli ambienti di virtualizzazione che girano sul mondo x86,
tipicamente si può virtualizzare poco carico.
Statistical multiplexing models
Supponiamo di avere un ambiente singolo e vogliamo capire qual è il carico di lavoro di questo
ambiente. Tra la media del carico e il picco possiamo avere una distanza molto elevata (minimo 6
volte tanto, ma delle volte anche 10 o 20 volte). Esistono tutta una serie di studi concettuali sullo
statistical miltiplexing che affermano che se abbiamo un carico composto da tanti carichi diversi, su
un certo sistema che eroga dei servizi, allora il picco di uno raramente coinciderà col picco di un altro
e la probabilità che tutti i software contemporaneamente abbiano un picco di richiesta è estremamente
bassa. Per cui si può dimostrare che su server di tipo enterprise, sui quali possono arrivare centinaia
di workload che girano contemporaneamente, si può avere che la distanza tra la media e il picco sia
molto molto limitata.
Bisogna anche tenere a mente che una macchina di tipo Z è stata pensata per lavorare ad un livello di
utilizzazione molto prossimo al 100%, a differenza del livello di utilizzazione di normali server x86.

Tutto ciò porta ai vantaggi di utilizzo delle risorse in maniera molto ottimizzata.
Passaggio al cloud per sfruttare l’elasticità
Il cloud parte dall’idea di essere un ambiente remoto composto da tanti server che potrebbero anche
essere di tipo enterprise e a mano a mano che abbiamo bisogno di più risorse queste ci vengono messe
a disposizione e paghiamo solo per queste.
La trasformazione del “modo di fare informatica” ha seguito le strade mostrate nella seguente
immagine.

Dal punto di vista dello sviluppo oggi ci troviamo con il DevOps: un Agile spinto in cui lo sviluppo
e l’operation avvengono in contemporanea.
Dal punto di vista delle architetture applicative oggi ci troviamo con le applicazioni a microservizi
ed è possibile deployare questi microservizi all’interno di container invece che su dei server virtuali
(o fisici come si faceva in passato), questi container si possono deployare facilmente nel mondo cloud.
Per tutti i vantaggi che offre il cloud, dobbiamo essere in grado di saper aiutare le aziende a sviluppare
o a fare una loro transizione nel mondo del cloud, perché è la chiave di volta per utilizzare e
massimizzare le risorse, o avere a disposizione una serie di risorse praticamente infinite.
Cloud approaches: IaaS, PaaS, SaaS

SOURCE: https://www.bigcommerce.com/blog/saas-vs-paas-vs-iaas/#the-key-differences-between-
on-premise-saas-paas-iaas

Nel caso On-Premises siamo noi i padroni dell’hardware, della rete, dello storage, ecc.
Nel caso di IaaS acquistiamo dal cloud provider che gestisce la rete, lo storage, i server, la
virtualizzazione hardware, quindi ci vengono messe a disposizione le risorse hardware e sopra di esse
mettiamo il SO, il middleware e le nostre applicazioni.
Nel caso di PaaS oltre alla parte hardware viene messo a disposizione anche il SO, il middleware e il
runtime, quindi la piattaforma e noi dobbiamo solo mettervi sopra la nostra applicazione.
Nel SaaS viene messo tutto a disposizione dall’esterno e quindi gestito dall’esterno.
ESEMPIO
Questo esempio ci fa capire che il mondo del cloud è il futuro, è la piattaforma sul quale gli
investimenti principali stanno vertendo da parte delle aziende. Però bisogna fare attenzione al fatto
che il passaggio verso il cloud non significa che l’approccio tradizionale viene abbandonato, bensì si
andrà sempre più verso un mondo di hybrid cloud e multicloud.

Visione moderna della strategia cloud delle aziende

Non si tratta solo di passare alcuni software su public cloud, ma di supportare un hybrid cloud
composto di software che possono essere cloud ready ma che girano all’interno del nostro sistema,
altri all’esterno su dei public cloud e non fare vendor lock in su un singolo cloud ma di sfruttare il
multicloud proprio per evitare questo.
L’importanza dell’open
L’open-source ha cambiato completamente il modo di sviluppare software. I software open evitano
il vendor lock in perché possono essere forniti da varie aziende con le proprie distribuzioni che sono
leggermente diverse, ma permettono la portabilità dall’una all’altra. Inoltre, c’è un ecosistema di
molti sviluppatori e c’è un grande fermento, dal punto di vista dell’evoluzione, per fornire nuove
funzionalità. Molto spesso dietro il software open-source ci sono grandi aziende.
Che un software sia open-source significa poter avere il codice sorgente condiviso da tutti quanti, ma
si può pagare per la sua installazione, compilazione e soprattutto per avere supporto o per fornire altri
servizi. Oggi il software open-source è la strada fondamentale per avere i client value sopracitati.