W H I T E P A P E R 2018

CLOUD
Le applicazioni cloud native:
caratteristiche e sicurezza
Che cosa sono le applicazioni cloud native? Perché
se ne parla e aumenta il loro utilizzo? In questo
white paper si affronta il complesso tema
dello sviluppo applicativo che è al centro
della trasformazione digitale delle
aziende. Proprio lo sviluppo di app e
servizi IT sta infatti vivendo grandi
evoluzioni caratterizzate, per
esempio, dalla disponibilità del
serverless computing e dalla
possibilità di utilizzare i microservizi.
Si parte dal presupposto che il paradigma
di progettazione software fondato sulla nuvola è in grado di offrire una serie di
opportunità. Lo scopo del documento è quindi quello di illustrare le nuove
tecnologie e di suggerire dove e quando è meglio prediligere una o l’altra a
seconda dei vantaggi che possono determinare nei diversi contesti di utilizzo.
 SCENARIO
pag. 3 Applicazioni cloud-native: come crearle secondo nuove
SOMMARIO prospettive di sviluppo

pag. 6 Come cambia lo sviluppo software per realizzare il business

digitale

METODOLOGIA
pag. 13 Applicazioni serverless: cosa sono e come si proteggono

FOCUS
pag. 19 Serverless computing: i vantaggi per il business e gli sviluppatori

pag. 20 Cosa sono i microservizi in informatica e quali vantaggi

generano?

pag. 23 Software Container: come si possono gestire e quali sono i

vantaggi per l’utente

LE TECNOLOGIE
pag. 27 Breve viaggio tra strategie e prodotti software container

FOCUS
pag. 32 Container e data mirroring per creare backup ad alta disponibilità
più economici e veloci

2 Z e r o U n o WH IT E PAPER 2018 - CLOUD - 1

 
W H I T E P A P E R C l o u d - 1 torna aL sommario

Applicazioni cloud-native:
come crearle secondo
SCENARIO nuove prospettive di sviluppo
Il paradigma di progettazione software fondato sulla
nuvola, assieme al modello ‘API-Application programming zati dai grandi player e provider globali, come Google, Ama-
interface-first’, libera gli sviluppatori dai vincoli dei server zon, Microsoft…
fisici, garantendo loro vantaggi di agilità e praticità: ma
Le applicazioni cloud-native sono progettate e ingegne-
usare questi metodi di sviluppo, che rappresentano una
vera e propria nuova filosofia, richiede una adeguata rizzate apposta per sfruttare appieno la natura dell’infra-
forma mentis e l’apprendimento di varie conoscenze struttura cloud: in confronto a quelle tradizionali, che usano
server permanentemente designati al loro supporto, le app

O
realizzate per ottimizzare i vantaggi dell’uso della nuvola
funzionano affidandosi a una capacità di elaborazione che
rmai l’attività di progettazione delle moderne app risulta disaccoppiata dalla rigida appartenenza a specifiche
sta palesemente aderendo al paradigma ‘cloud-native’, un fe- risorse hardware. Questa abilità di astrarre il funzionamento
nomeno alimentato dalla diffusione in questi anni dell’onda dell’applicazione dal legame con determinati server fisici
d’innovazione del cloud: dopo la sua nascita, i servizi della porta vari benefici: chi sviluppa la app non si deve più pre-
nuvola si sono febbrilmente evoluti, attraverso ricerca e svi- occupare di amministrare e manutenere l’infrastruttura fi-
luppo, applicazioni, modelli innovativi in larga parte realiz- sica, risparmia risorse, personale addetto, ha minori rischi

3 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Applicazioni cloud-native...
 Lo sviluppatore che vuol creare applicazioni
Clicca per
leggere il
whitepaper
e, soprattutto, può finalmente concentrarsi su
ciò che per lui realmente conta, cioè lo svilup-
po dell’applicazione e delle sue funzionalità.
Chi migra verso l’approccio cloud-native per
ottenere tutti questi benefici di praticità e con-
venienza non può però certo prescindere
dall’abilità di padroneggiare la tecnologia che
sta dietro le quinte di queste sfolgoranti oppor-
tunità di business.
4 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
Verso il modello di sviluppo
‘API-first’
cloud native deve prima di tutto cambiare
mentalità e guardare la progettazione da una
nuova prospettiva: basta continuare a pensare
che il codice applicativo debba per forza avere
accesso diretto alle risorse hardware, come
nelle tradizionali applicazioni monolitiche: la
nuvola, certo, non avrebbe difficoltà a gestirle,
ma creare app moderne, a proprio agio nel
cloud, abili nello sfruttare i pregi di un’infra-
struttura distribuita, elastica, scalabile a piaci-
mento nell’utilizzo delle risorse IT, è tutta
un’altra cosa.
Per la natura stessa del cloud, sviluppatori di
app cloud-native si diventa soltanto attraverso
una metamorfosi, dopo la quale il paradigma di
sviluppo ‘API-first’ assume una priorità assolu-
ta, venendo prima della definizione di qualsiasi
altro requisito di progetto: prima, quindi, dell’i-
deazione di qualunque funzionalità della app
mobile, o del dispositivo IoT (Internet of Things)
che si sta sviluppando.
Partire con lo sviluppo ‘API-first’ prima di

P A P E R C l o u d - 1 torna aL sommario
ogni altra cosa sottintende un accurato pro-
cesso di documentazione, progettazione e co-
struzione della API (application programming
interface) dell’applicazione, e questo si potreb-
be considerare un inaccettabile vincolo di pro-
getto, che obbliga a ‘congelare’ la creazione di
tutte le altre caratteristiche e funzionalità
dell’applicazione, finché non si è terminato lo
sviluppo della API. Se non fosse che, fortunata-
mente, oggi sono accessibili online piattafor-
me open source di documentazione delle API,
come API Blueprint: quest’ultima fornisce un
linguaggio di descrizione ad alto livello per le
API web, e permette di progettare e creare
prototipi di API da realizzare, o di documenta-
re e collaudare quelle già create. In sostanza,
API Blueprint consente di attivare un mockser-
ver API di test, che combina perfettamente con
la documentazione della API, e con cui è possi-
bile costruire e collaudare le integrazioni per la
stessa rispetto a un reale servizio, ancor prima
che la API venga completata.
Uno dei principali vantaggi dell’approccio
API-first risiede nel fatto che è una filosofia di
sviluppo in cui una scelta progettuale non pre-

Applicazioni cloud-native...
 clicca
per guardare
il video
Elementi base delle API in 3 minuti
giudica definitivamente altre variabili di pro-
getto, ma è reversibile: non sempre infatti ha
senso applicare questo approccio in qualunque
caso d’uso, e se in fase di sviluppo ci si accorge
che è inutile, si può sempre abbandonarlo sen-
za perdere i progressi compiuti, o calare la pro-
duttività; d’altro canto, il rovescio della meda-
glia è che se si costruisce un’applicazione che
richiede questa strategia senza prima pianifi-
care lo sviluppo della API, ci si può infilare in
un tunnel di problemi tecnici da cui uscire può
richiedere molto tempo.
5 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
Filosofia serverless: far funzionare
una app ‘senza i server’
Premesso che lo sviluppo API-first e lo svi-
luppo di applicazioni cloud-native sono con-
cetti che non si escludono mutualmente, per-
ché è possibile creare un’applicazione
cloud-native senza una API, ed è possibile rea-
lizzare un’applicazione API-first senza il cloud,
esiste un caso in cui questi due concetti si fon-
dono armonicamente assieme, ed è quello de-
gli ambienti ‘serverless’: il modello serverless,
attualmente, si può collocare al gradino più al-

P A P E R C l o u d - 1 torna aL sommario
to di evoluzione tra i livelli di astrazione oggi
disponibili per lo sviluppo applicativo.
Ma cosa significa davvero serverless? Natu-
ralmente, non vuol dire che la app, o la API, può
funzionare senza server: significa invece che,
al posto di usare i tradizionali server di un
cloud provider geograficamente dislocati in
precise località fisiche, la app funziona senza
un’infrastruttura permanente, perché i server
necessari vengono auto-creati solo per un de-
terminato tempo (anche pochi millisecondi),
scalati in base alla necessità della app, e poi so-
no eliminati quando non servono più, perché
hanno terminato l’elaborazione dei suoi dati e
funzioni. Questo approccio basato su microser-
vizi significa per gli sviluppatori poter realizza-
re app e API serverless, in luogo delle tradizio-
nali API REST: con una API serverless si evitano
i problemi si sovracapacità nella creazione dei
servizi di backend; i server scalano in automa-
tico, e non si paga per il tempo in cui rimango-
no inattivi; l’infrastruttura gode di una solida
affidabilità e disponibilità, e non ha necessità di
funzioni di load-balancing, né di patch di sicu-
rezza. (G.F.) 

Come cambia lo sviluppo software
per realizzare il business digitale
SCENARIO
Le app si trasformano adattandosi ai nuovi contesti
business. Le aziende leader riorganizzano le proprie
strutture con l’obiettivo di rilasciare in modo agile prodotti,
non solo digitali, programmabili e smart con estrema
rapidità: “faster, better and cheaper”, per intercettare i
business moment e soddisfare la customer experience.
Ecco un’analisi compiuta da Gartner a questo proposito
I
l Business Digitale cambia la natura delle Applicazio-
ni, che non si scrivono più su piattaforme separate di IT In-
frastructure (per il Dipartimento It) o di Talent management
(per l’HR) o di Leadership (per l’organizzazione) ma su una
piattaforma Business che si appoggia su tutte le altre (vedi fi-
gura 1).
6 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
Con l’avvento del “Nexus di forze” (il modello teorizzato
qualche anno fa da Gartner e che definisce di estremo valore
per l’innovazione e il business di impresa la convergenza di
social, mobile, cloud e information) ogni piattaforma è abili-
tata a integrarsi con ogni altra piattaforma, in cloud, in rete
social, con terminali mobili. Con l’intelligence e gli analytics,
il quarto attore del Nexus, le informazioni, si insedia come
superpiattaforma che arricchisce le App e i processi di cia-
scuna delle altre. In pratica, secondo Gartner, il business de-
ve essere digitale e application driven, programmabile e ca-
pace di interagire attraverso API e con funzioni smart per
assistere in real time le decisioni di ogni processo con
analytics ed intelligence.
 
W H I T E P A P E R C l o u d - 1 torna aL sommario

always on; scalabili on demand; estendibili e

Come cambia lo sviluppo software... modificabili; responsive e reattive.
Fattori concomitanti che cambiano la natura
intrinseca delle Applicazioni sono:
E tutto questo deve poggiarsi su una piatta-  cresce lo sviluppo del concetto self-ser-  la Customer experience (Cx) o la più ge-
forma di Software Delivery in grado di suppor- vice. nerale User experience (Ux). È sempre più pro-
tare un processo di produzione più economico, Tutto Il nuovo processo si fonda su DevOps babile che l’ingaggio di un potenziale cliente
di miglior qualità e più veloce, per una innova- e il progressivo ricorso all’Automazione. Le sia digitale per cui la Cx determina la probabili-
zione e rinnovamento delle App “a getto conti- App diventano così: globali, interconnesse, tà che questa continui in parallelo all’esperien-
nuo”. pervasive; operabili da tutte le “mani”, busi- za fisica;
ness e It; intelligenti sia per contestualità sia in  gli oggetti (things). Diventano usabili a
Le trasformazioni radicali modo predittivo; affidabili ossia sicure, etiche, tutti i livelli dell’organizzazione come sensori
dello sviluppo software
L’ Application Delivery, chiave di volta per
un business sempre più digitale, poggia su tra-
sformazioni consistenti:
 deve essere la concretizzazione di una
chiara strategia “Digital first” applicata in mo-
do consistente ad application, information e in-
tegration;
 il disegno dell’App deve fortemente pun-
tare a una Customer experience capace anche
di “improvvisare” a cogliere l’elusivo Business figura 1
Moment;
La piattaforma business è in
 vi devono essere team specializzati in realtà una mutipiattaforma

una “Lean product delivery”;

Fonte: Gartner, 2017

7 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Come cambia lo sviluppo software...
per “sentire cosa intorno all’oggetto avviene;
 i servizi interni. Questi devono affiorare
per dipendenti, clienti, partner, in mobilità e
ovunque. È necessario non solo offrire i propri
servizi, ma consumare quelli di altri attraverso
gli Ecosistemi: usare cose e servizi che non si
posseggono e accettare che altri usino risorse
ottenendo servizi dai nostri sistemi, questo è
fondamentale per non essere tagliati fuori.
I 12 princìpi chiave per l’App
Architecture nel Business Digitale
Come si scrive una Business App? Obiettivo
della Business App è un outcome con Cx agile
a cogliere un effimero momento di business.
L’Architettura applicativa a essa funzionale
deve abilitare, con velocità e facilità, un conti-
nuo “Change, Replace, Scale, Decide, (Re)In-
vent e Fail” dell’App, per testare l’outcome e
continuamente migliorarlo.
In questa prospettiva diventa inapplicabile
la progettazione monolitica: sono invece 12 i
8 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
princìpi chiave identificati per scrivere appli-
cazioni per il digital business e considerando
appieno anche il fenomeno IoT:
1. Orientamento Servizi
Fondamento di tutti i principi successivi, è
l’impostazione classica, ereditata dal modello
client-server anni 90, di una Logica di Request
(le richieste dell’utente del servizio) ospitata

P A P E R C l o u d - 1 torna aL sommario
dal client che opera nel front-end su differenti
canali, mentre il server ospita sia una logica di
business, che lavora nel backend, sia i dati,
collegati attraverso Api al client e al server.
Ogni client, inoltre, può operare in senso inver-
so (ossia tanti client si rapportano a un unico
server), agendo da “Composite” (termine con il
quale Gartner intende che un unico client può
diramare le sue richieste a più backend).
2. Separation of Concern
Per promuovere agilità, efficienza e resi-
lienza, le app di business ereditano dalla SOA
figura 2
L’API Mediator si
interpone tra i Servizi e
loro 4 possibili utenze
(App, altri Servizi, Digital
Twin, Event Handler)
Fonte: Gartner, 2017

Come cambia lo sviluppo software...
(Service Orientd Architecture) il principio di
separazione (o di modularizzazione) dei crite-
ri di attenzione (concern). Tale separazione è
strategica perché se concern diversi sono indi-
rizzati in moduli diversi, non è necessario ri-
testare del codice già verificato solo perché si
trova nella stessa App che richiede modifiche
(e quindi nuovo test). Sono da tener separate ad
esempio Funzioni business diverse, tipi di atti-
vità diverse o con frequenza di cambiamento
diverso, con scopo di visibilità diverso (es. ser-
vizi esposti all’esterno, a un esterno condiviso
per riuso, o solo interni all’App), con esigenze
di sicurezza, privacy, sensitività, con dipen-
denze diverse.
3. Mediated Services attraverso la Media-
zione delle loro API
Quando aumentano esponenzialmente le
utenze dei Servizi (che possono essere App, al-
tri Servizi, Digital twin, Event Handler), i Servi-
zi all’interno di un App backend vengono rag-
giunti attraverso un API Mediator che:
9 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
controlla la legittimità dell’accesso in base a
policy, fornisce una serie di funzioni di valore
aggiunto (traduzione, orchestrazione, routing,
load balancing, ecc) (figura 2). La stessa Inte-
gration platform è una forma di API Mediator,
specializzata per l’integrazione. Nell’API Me-
diation è fondamentale il rispetto della discipli-
na: se si lascia che delle App aggirino l’API Me-
diator per accedere direttamente ai servizi, se
ne fa scadere il valore (per esempio nel con-
trollo di Security).

P A P E R C l o u d - 1 torna aL sommario
4. Macroservizi, Miniservizi o Microservizi
I MacroServizi, nati con la SOA, facilitano il
riuso per integrazioni e composizioni in am-
biente multi App. I MicroServizi, non esposti
all’esterno, nascono con i grandi Web provi-
der come Twitter o Facebook le cui App in li-
nea devono riuscire a cambiare non due volte
all’anno come un SAP, ma molte volte al gior-
no: consentono così il massimo di iperagilità e
iperscalabilità. I MiniServizi non hanno tutta la
rigida disciplina dei MicroServizi, offrono un
giusto compromesso fra riuso e agilità: Gartner
li raccomanda alle aziende che non hanno le
esigenze di iperscalabilità e iperagilità dei gran-
di Web provider per le Business App che devo-
figura 3
Dai microservizi ai
macroservizi
Fonte: Gartner, 2017
 
W H I T E P A P E R C l o u d - 1 torna aL sommario

trice”, vedi principio 3) che, in modo automati-

Come cambia lo sviluppo software... co e programmabile, sceglierà l’opportuno ge-
store dell’evento (figura 5); questo, a sua volta,
può aggiungere ulteriori Event Handler che
no “pensare agilmente” per poter rapidamente l’App riporta l’evento (per esempio un ordine non hanno impatti diretti sull’applicazione di
cambiare onde modificare l’offerta per soddi- ricevuto dal canale e-commerce) a un Event partenza. L’Event Handling è un meccanismo
sfare la Cx (figura 3). Broker (in pratica un’API cosiddetta “media- open ended, aperto a scalare, per esempio su
5. Think IoT
IoT è una formidabile ondata di innovazione
business, applicativa e architetturale. I digital
twin sono specchi digitali di oggetti fisici e son
circondati da API e si possono considerare co-
me MicroServizi perché incapsulano i loro da-
ti, presentandosi al mondo esterno a tutti gli ef-
figura 4
fetti come oggetti, nel senso in cui
Il Digital Twin circondato da
storicamente la Object-oriented Technology
Api, incapsula le proprietà
(anni 80) definisce un Oggetto ai fini della sua software dell’oggetto fisico

programmabilità dall’esterno: un Oggetto deve

essere dotato di Proprietà e Metodi d’uso e ca-
pace di Ereditarietà, di Persistenza e Polimorfi-
sno o non è un Oggetto programmabile con
tecnologia object oriented. (figura 4).
6. Think Events figura 5
In un mondo Event Handling dove cioè la
Event Handling, la
gestione degli eventi è fondamentale in quanto mediazione dell’Event
Broker per un servizio
un evento passato determina le azioni future,
Fonte: Gartner, 2017

10 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

 
W H I T E P A P E R C l o u d - 1 torna aL sommario

Software Delivery di App con innovation e re-

Come cambia lo sviluppo software... novation continue (figura 7):
1. Costruire gli skill.
2. Organizzarli (o riorganizzali) in team
parallel computing, secondo Gartner “È la tec- do di gestire il nuovo processo di App delive- misti in grado di auto dimensionarsi per un
nologia più avanzata, ma è al livello della SOA ry. Gartner mette in fila i passi cruciali per con- approccio multidisciplinare (tipicamente
di 10 anni fa, scarsi ancora gli skill e i tool” (fi- ferire a un’organizzazione la capacità di front-end developer orientati al business con
gura 6).
7. Think Digital Business
8. Think Consumer Experience (vedi ap-
proccio Design Thinking, descritto più avanti)
9. Think Cloud, qui la raccomandazione è
“build for scale” in caso di hybrid cloud;
10. Think Integration
figura 6
11. Think Real Time
Esempi di Alert ad Event
12. Think in Contest Handler sottoscrittori presso
Event Broker
Per questi ultimi 6 princìpi, Gartner ritiene
inutili ulteriori raccomandazioni essendo auto-
esplicativi.

La riorganizzazione aziendale alla

base del nuovo processo di sviluppo
Ma c’è un 13° principio: “Le organizzazioni figura 7
rigide non creeranno mai software agile”. Il
Il nuovo scenario del
principio afferma la necessità di organizzare o processo di Sviluppo di
Applicazione Business
riorganizzare una struttura mettendola in gra-
Fonte: Gartner, 2017

11 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

 
W H I T E P A P E R C l o u d - 1 torna aL sommario

driven. Misurare il Business Outcome di

Come cambia lo sviluppo software...
un’App capace di una data Cx (quanti Business
Moments ha intercettato, con quale risultato fi-
back-end developer). di budget alla conclusione di ogni iterazione nanziario) è cruciale quanto i KPI nelle Appli-
3. Assegnare pratiche e policy. con una fase di “learn e measurment” (figura cazioni tradizionali a fronte dei Requirement.
4. Promuovere i nuovi principi core di Ar- 9). Così il ciclo di vita di un’App di Business è (R.M.) 
chitettura app business. non più Requirement, ma Business Outcome
5. Approccio bimodale.
È determinante che il team auto-costituitosi
si organizzi per il “Design thinking”, così ven-
gono chiamate le sessioni di lavoro del Gruppo
ibrido intorno a una data Cx: dalle fasi di Em-
pathize e di Define in cui si ricercano per em-
patia gli interessi del cliente, derivandone un
figura 8
consenso sui bisogni “compelling”, il Gruppo I passi del Design Thinking

passa a una fase di Ideate (generazione di idee

a fronte dei bisogni) e Prototype (in cui le idee
da sviluppare vengono testate a tavolino e il
Business generabile valutato). Il Design thin-
king si conclude con il Test, che è già una fase
di rifinitura con la misurazione di Business
Outcome sul mercato (figura 8).
Il Prodotto Software così lanciato ha natural- figura 9
mente un Product Manager che guida il pro- Il ciclo di vita di
un’Applicazione Business
gressivo processo di rifinitura dell’App attra-
verso tutto il suo ciclo di vita, dall’allocazione Fonte: Gartner, 2017

12 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Applicazioni serverless: cosa sono
e come si proteggono
METODOLOGIA
Le applicazioni serverless possono essere davvero
soluzioni potenti, ma solo se caratterizzate da una
sicurezza intrinseca. Lo sviluppo di applicazioni cloud
native, basate su microservizi, richiede infatti regole di
protezione specifiche. Gli esperti di TechTarget spiegano
come funzionano le applicazioni serverlesse e cosa fare
per renderle sicure
C
he cosa sono le applicazioni serverless? La rispo-
sta è semplice: sono applicazioni cloud native che possono
essere sviluppate e gestite senza dover gestire l’infrastrut-
tura server di supporto necessaria, connotate da microser-
vizi mirati che svolgono operazioni specifiche in concomi-
tanza con il verificarsi di determinate condizioni.
13 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
Applicazioni serverless:
facili fino a un certo punto
Nell’era del cloud, la familiarità con le logiche dell’As a
Service e del pay per use è cresciuta notevolmente. Ma, av-
vertono gli specialisti, non è tutto oro quello che luccica: pia-
nificare le applicazioni serverless per cercare quelle più
utili al proprio business è solo una parte dell’attività. L’im-
plementazione di un’Infrastructure as a Service, ad esempio,
richiede comunque di dover seguire le dinamiche associate
alla gestione delle patch, di disegnare i percorsi delle reti vir-
tuali, di fornire un’appliance di sicurezza sottostante, il tutto
risolvendo una serie di altre attività complesse esattamente
come se le applicazioni si trovassero ospitate in un data cen-
ter on premise.

Applicazioni serverless...
In ambienti come Google Cloud Functions o
AWS Lambda, la funzionalità applicativa viene
attivata tramite eventi. L’applicazione è proget-
tata per rispondere ai suddetti eventi, rila-
sciando porzioni funzionali di codice di picco-
le dimensioni. L’ambiente si occupa di fornire
la funzionalità in maniera scalabile in modo da
rispondere alla domanda. Il vantaggio? Come
detto, come per tutte le formule in cloud, si pa-
ga solo per ciò che si utilizza (in questo caso
singole funzionalità invece di un’intera appli-
cazione, tanto da essere stato recentemente co-
niato il termine Functions as a Service).
Qual è la differenza tra queste piattaforme e
“normali” PaaS? Concettualmente poco, ma
spesso anche in un contesto PaaS è comunque
necessario specificare a livello previsionale
l’utilizzo delle risorse; la scalabilità quindi
non è del tutto trasparente come invece lo è
nel FaaS. Analogamente, la configurazione di
servizi specifici legati a un contratto di PaaS
(come possono essere un database o un servi-
zio di posta) potrebbero richiedere una cono-
14 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
scenza esplicita di tutta l’infrastruttura sotto-
stante. Quindi si potrebbe dire che il FaaS è una
sorta di PaaS++.
La sicurezza delle applicazioni
serverless: 4 cose da sapere
Mettere in sicurezza un’applicazione server-
less non è come mettere in sicurezza un’appli-
Le 3 principali caratteristiche delle architetture serverless
Tutte le architetture di elaborazione serverless
presentano alcune caratteristiche chiave, che ri-
assumiamo brevemente di seguito.
 Ridotta complessità. Con un’archi-
tettura di serverless computing diventa più sem-
plice lanciare un gruppo di VM (Virtual machine)
auto scaling (in grado di scalare da sole) dietro
un load balancer (bilanciatore di carico). Si può
più facilmente prolungare l’architettura applica-
tiva in più regioni per permettere la ridondanza
geografica. Gli sviluppatori possono concentrar-
si completamente sulla scrittura del codice per-
ché i server che invocano tali funzioni sono ge-
stiti dai cloud provider.

W H I T E P A P E R C l o u d - 1 torna aL sommario
cazione tradizionale monolitica o presidiare
un qualsiasi altro rilascio in cloud. Riassumia-
mo i 4 principali punti di attenzione:
 La prima cosa da sapere è che la capaci-
tà di interagire con qualsiasi cosa al di sotto
del livello 7 (Application layer dello standard
di rete ISO/OSI) è praticamente inesistente.
Questo significa che non è possibile introdur-
 Scalabilità incorporata (built-in). questa attività viene delegata al provider. Il ser-
Una delle maggiori difficoltà nella creazione di vizio Aws Lambda, ad esempio, viene eseguito
applicazioni web scale (che possono girare su su un parco gestito di istanze Elastic Compute
tutto il web) è la configurazione dell’auto sca- Cloud (EC2).
ling per i server virtuali, in quanto va trovato l’e-  Eliminazione delle risorse inatti-
quilibrio che permette all’architettura di espan- ve. Un altro vantaggio offerto dall’elaborazione
dersi, a fronte di picchi di traffico, e serverless è che viene addebitato solo il tempo
ridimensionarsi quando le richieste di accesso in cui le istanze eseguono il codice applicativo.
diminuiscono. Ma ciascuna applicazione tende a Con i server tradizionali, invece, il cliente paga
comportarsi in modo differente da un’altra. Scri- una tariffa oraria anche per l’esecuzione di
vere le impostazioni che permettono di ottimiz- istanze che sono lasciate inattive. (R.C.) 
zare i costi e fornire le migliori prestazioni a ogni
applicazione diventa così un compito tutt’altro
che facile. Con l’elaborazione serverless anche

Applicazioni serverless...
 problemi registrati a livello applicativo. Se è
Clicca per
leggere il white
paper di
Deloitte
re un’appliance per la rilevazione delle intru-
sioni sulla rete virtuale o installare strumenti
di scansione malware sul sistema operativo
sottostante. Ecco perché è molto importante
comprendere il modello di minaccia associato
alla logica che si sta implementando in modo
completo e concreto.
 In secondo luogo è necessario assicu-
rarsi della robustezza del codice che si sta svi-
luppando. Gli ultimi attacchi hanno conferma-
to come la sicurezza delle applicazioni sia un
aspetto che non deve essere mai sottovalutato
dai programmatori. Gli injection attack, ad
15 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
esempio, sono ancora in cima alla lista dei
vero che i bug ci sono sempre stati, è anche ve-
ro che la capacità di garantire un’applicazione
serverless è direttamente correlata alla capaci-
tà di comprendere la logica della programma-
zione, andando a rimuovere o a mitigare i pro-
blemi potenziali, mantenendo alta la qualità
dei codici e monitorando l’ambiente. Come ri-
badiscono gli esperti, non è questione di scien-
za pura, ma di vera e propria disciplina.
 Terzo punto è la modellazione delle mi-
nacce, altro aspetto chiave della sicurezza.
Questa attività, che aiuta a rendere più robuste
le applicazioni, ha ancora più valore in un con-
testo serverless. Non solo consente di mappa-
re e analizzare sistematicamente i punti di in-
terazione tra le varie componenti, ma produce
anche una mappa dei flussi di dati come parte
integrante del processo. Sebbene non si possa
avere la massima visibilità nella meccanica sot-
tostante di memorizzazione o di calcolo dei da-
ti, una mappa virtuale di come gli elementi
dell’applicazione interagiscono è comunque

P A P E R C l o u d - 1 torna aL sommario
sempre utile, al di là dell’analisi del modello di
pericolo. È così possibile considerare quali op-
zioni siano disponibili per isolare la logica ap-
plicativa in modo da offrire maggiore visibilità
o controllo delle operazioni. Sono stati quindi
progettati strumenti per consentire di pac-
chettizzare alcune funzioni in modo tale da
renderle trasparenti allo sviluppatore. Inoltre
è possibile scegliere di implementare una stra-
tegia di clusterizzazione in autonomia, che può
aiutare a trovare e filtrare gli injection attack.
 Come ultimo punto gli esperti ricordano
sempre e comunque di prestare attenzione al
monitoraggio. Oltre al controllo degli accessi e
delle identità, bisogna tenere conto di tutte le
anomalie che non sono conformi alle regole
operative del business.
In conclusione, le applicazioni serverless
possono essere strumenti potenti, ma garantire
la sicurezza di questi strumenti non è sempre
così facile. Per i team di sviluppo si tratta di
un’occasione importante per far crescere lo
skill del personale, non solo andando a costru-
ire delle nuove abilità ma anche andando ad
aumentare la maturità delle applicazioni azien-
dali sviluppate. (L.Z.) 
 
W H I T E P A P E R C l o u d - 1 torna aL sommario

Serverless computing: i vantaggi

per il business e gli sviluppatori
FOCUS

In questo capitolo sono approfonditi nel dettaglio i

benefici riconducibili all’utilizzo di Faas e serverless
computing da due punti di vista. Guidati dagli analisti di
Forrester sono infatti esaminate le opportunità di questa
tecnologia nello specifico per gli sviluppatori da un lato e
dall’altro per il business. E per finire si darà uno sguardo a
quel che ci si può attendere dal futuro

hanno oggi un grande potenziale nell’integrazione di molti

M
entre da una parte DevOps cerca di riunire lo svi-
luppo con le operation, FaaS e serverless computing man-
tengono i due aspetti distinti, caratterizzandosi per la filo-
sofia operativa che si basa sull’esecuzione di differenti
funzioni in risposta a eventi asincroni che coinvolgono sor-
genti dati distribuite. Le applicazioni del serverless/Faas
servizi periferici o cloud laddove, per esempio, ci siano da
elaborare le segnalazioni automatiche da sistemi IoT. Per
contro, l’approccio appare ancora immaturo nelle applicazio-
ni business anche se potrebbe essere solo una questione di
tempo e maturazione. Ed è a questa tematica che è dedicato
il report Forrester Demystifying serverless computing del
quale riportiamo alcuni highlight, focalizzandoci in partico-
lare sulle opportunità che il serverless computing offre.

16 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Serverless computing: i vantaggi...
I vantaggi del serverless computing
per le applicazioni business
Lo sviluppo in ambiente serverless ricalca
quello delle architetture software di tipo “losely
coupled” (dove un modulo non dipende da altri
per funzionare) e aiuta gli sviluppatori a velo-
cizzare i rilasci e ad adottare il disegno a mi-
croservizi nell’innovazione delle applicazio-
ni. Tra i maggiori vantaggi di business
associati con la logica dei servizi serverless c’è
il fatto che il costo, misurato in frazione di
centesimi, è calcolato per ogni esecuzione del
codice, estremizzando il modello pay-per-use
del cloud a vantaggio, in particolare, delle spe-
rimentazioni e prototipazioni. Benché sia pos-
sibile usare l’approccio serverless con più job
concatenati tra loro, gli sviluppatori possono
sfruttare gli eventi e la messaggistica asincro-
na per lanciare tante procedure in parallelo,
per esempio, laddove le funzioni devono servi-
re un numero imprecisato di utenti. Se da una
parte gli sviluppatori hanno la possibilità di
17 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E P A P E R
Cos’è il FaaS e quando utilizzarlo
Una delle ultime incarnazioni dell’IT come servizio è quella che
può essere definita come Function-as-a-service con l’acroni-
mo FaaS, una tipologia di computing altrimenti nota come
serverless o anche event-driven.
Secondo la definizione degli esperti, FaaS è un modello di ero-
gazione dei servizi cloud che permette agli sviluppatori di
usare soltanto la quantità di risorse di cui hanno bisogno e
quindi pagare il provider in funzione delle funzioni volta a
volte utilizzate, quando un evento predefinito ne ha atti-
vato il codice e il relativo servizio.
Come accade con altri modelli di cloud, lo sviluppatore può con-
centrarsi sulle funzionalità applicative e non doversi più preoccu-
pare di aspetti come il provisioning di server e sistemi operativi.
Nel Faas tutta l’infrastruttura d’erogazione dei servizi è
esternalizzata al provider e trasparente a chi sviluppa.
I compiti di business sono svolti da un insieme di microser-
vizi che eseguono singole funzioni; in questo modello di
cloud non esistono applicazioni monolitiche e le applicazioni so-
no riscritte come insieme di microservizi, ciascuno indipendente,
scalabile con un costo che varia in funzione dell’effettivo utilizzo.
Con il Faas non serve pagare un canone per disporre di server,
storage o di un application server in cloud: il conto è proporzio-
nale all’impegno effettivo delle funzioni da parte degli uti-
lizzatori finali. Va da sé che questo modello di cloud risulti ide-
ale, per esempio, in applicazioni aperte al pubblico di cui è

C l o u d - 1 torna aL sommario
difficile stimare a priori il livello di successo e quindi di utilizzo.
L’astrazione del Faas può essere vantaggiosa rispetto, per
esempio, all’impiego del cloud Iaas dove analoghe funzioni
richiederebbero il provisioning di macchine virtuali, sistemi
di sicurezza e per il bilanciamento dei carichi di lavoro.
FaaS non è comunque la panacea del mondo cloud. Gli svilup-
patori devono valutare con attenzione quando sfruttare
questa opzione e quando è meglio guardare altrove in at-
tesa di migliori soluzioni.
La tecnologia non è adatta per le applicazioni che compor-
tano un forte impegno di elaborazione numerica, come ap-
plicazioni scientifiche e analitiche. Non è inoltre adatta per
grandi processi batch. FaaS va molto bene in alcune aree
verticali come, per esempio, la traduzione di comandi voca-
li, l’analisi di immagini grafiche: singole attività che devono
essere eseguite in modo veloce e asincrono dal resto delle appli-
cazioni.
Al pari di altre interpretazioni dell’IT in cloud, FaaS ha il vantag-
gio della scalabilità, ma alcuni provider possono imporre
dei limiti superiori nell’uso di singole funzioni. Prima di ba-
sare su Faas le applicazioni critiche sotto il profilo della scalabilità
è quindi utile verificare se le aspettative sono compatibili con le
condizioni di servizio offerte dal provider. (P.T.) 

Serverless computing: i vantaggi...
scrivere il codice di “aggancio” delle funzioni
serverless con gli eventi, dall’altra i fornitori di
servizi propongono opzioni prefabbricate per
le esigenze più comuni, come l’accesso allo
storage o per collegare le API più diffuse.
L’approccio basato su eventi è funzionale
alle architetture distribuite, quindi a servizi
che operano in luoghi diversi e sotto differen-
ti autorità. Secondo Forrester, se propriamente
usato, l’approccio serverless riduce i costi sia
dello sviluppo sia dell’utilizzo dei servizi in
produzione. Questo perché aumenta la veloci-
tà di sviluppo del codice e riduce gli oneri con-
nessi con il provisioning delle risorse nelle fa-
si di prototipazione. L’architettura è ideale per
espandere le applicazioni esistenti in nuove di-
rezioni, e segnatamente dove serve integrare
differenti Web service in job complessi. Per
esempio, può essere impiegata per raccogliere
eventi e dati derivanti dalle interazioni degli
utenti con i servizi online, unirli con altri dati
18 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
rilevanti, elaborarli e quindi restituire all’uten-
te altre informazioni tramite e-mail o SMS. Al-
tra possibilità riguarda l’elaborazione di eventi
del mondo reale, come i guasti ai macchinari di
una linea di produzione o le segnalazioni d’e-
mergenza. Il modello di calcolo dei costi d’uso
associati ai servizi serverless è ideale laddove
serva gestire le risposte ad eventi di frequenza
non prevedibile come le interazioni con clienti
o le segnalazioni inviate da dispositivi IoT.
I vantaggi del serverless computing
per gli sviluppatori
Come abbiamo accennato, l’approccio ser-
verless libera gli sviluppatori dalla necessità di
gestire l’infrastruttura, quindi di occuparsi del-
le prestazioni al di là dei limiti contrattuali im-
posti dal fornitore del servizio. L’accesso “on
demand” all’elaborazione risolve le necessità
di potenza di carichi molto impegnativi come
simulazioni in ambito finanziario, analisi in

P A P E R C l o u d - 1 torna aL sommario
tempo reale di grandi moli di dati. Gli svilup-
patori che hanno già utilizzato istanze di cloud
pubblico per ottenere potenza elaborativa più
velocemente e con minori costi rispetto ai ser-
vizi del data center troveranno gli ambienti
serverless molto più efficaci e flessibili nella
scalabilità, con servizi pagati in funzione dell’u-
so e non per le istanze dormienti che attendo-
no d’essere avviate. Secondo Forrester, il mo-
dello è ideale per sperimentare nuove app
rivolte al pubblico, o comunque laddove sia
impossibile prevedere il successo e quindi la
domanda di risorse. L’architettura serverless
aiuta gli sviluppatori a prepararsi per un futuro
vicino in cui il loro lavoro sarà quello di assem-
blare componenti, collegarli nell’elaborazione
e nell’esecuzione, senza la necessità di mettere
mano all’intera applicazione. Tutto questo spe-
rimentando i vantaggi (e i rischi) connessi con
il disegno del software a microservizi.

Serverless computing: i vantaggi...

Cos’è la customer experience analytics? Forrester spiega come e perché conoscere i clienti
clicca
per guardare
il video
Cosa attendersi per il futuro
in ambito serveless
Secondo gli analisti di Forrester, dobbiamo
aspettarci ulteriori sviluppi sia sul fronte delle
architetture severless sia dei servizi offerti dai
fornitori, molto al di là dei primi “database as-
a-service”. Tra le diverse possibilità c’è quella
di far girare soluzioni serverless in container
standardizzati, capaci di dare agli sviluppatori
19 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
per le transazioni distribuite o gestite in
blockchain. La blockchain si sposa molto bene
con le caratteristiche di storage, comunicazio-
ne ed elaborazione distribuita supportate dal
serverless computing a patto ovviamente di
più controllo, ma anche di evitare il lock-in nei avere le funzioni per controllare l’integrità del-
riguardi del service provider. L’integrazione tra le transazioni. Se da una parte l’approccio ser-
servizi ospitati su cloud diversi, già oggi uno verless scherma agli sviluppatori i problemi
dei campi d’impiego per il serverless compu- infrastrutturali che continuano ad affliggere
ting, potrà avvantaggiarsi nel lungo termine chi opera con DevOps, dall’altra non masche-
dalla definizione di nuovi standard nella ge- ra l’esigenza di conoscere alcuni aspetti ope-
stione degli eventi presso la Cloud Native rativi di alto livello, per esempio per garantire
Computing Foundation. i tempi di risposta ad eventi IoT, la collocazione
Altro miglioramento atteso è il supporto geografica dei dati e la sicurezza. (P.T.) 

Cosa sono i microservizi
in informatica e quali vantaggi
FOCUS generano?
Quando utilizzare i microservizi per poter sfruttare tutti i
benefici che potenzialmente offrono? In questo capitolo si
spiegherà come superare eventuali barriere all’adozione di
queste soluzioni e, in generale, viene illustrato come si
stanno comportando le aziende rispetto a questo tema.
Emerge un trend che porta a preferire un approccio multi-
technology
L’
idea di base che sta dietro al concetto di micro-
servizi è quella di suddividere una grande applicazione in
una raccolta di servizi orientati ai task. Al contrario, le clas-
siche applicazioni sono costruite come unità monolitiche,
che spesso includono front-end e Html per interagire con gli
utenti finali. Sebbene queste architetture abbiano funzionato
20 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
per anni, oggi le applicazioni devono supportare un maggior
numero di utenti e gli aggiornamenti diventano più difficili.
Poiché i componenti di un’applicazione monolitica sono
strettamente accoppiati, anche una leggera modifica al codi-
ce lato server può richiedere un update completo dell’app la-
to client.
Nell’approccio a microservizi un’applicazione è alimen-
tata da tanti piccoli servizi, ciascuno con poche responsabi-
lità. Ogni microservizio può guastarsi senza fermare l’intero
sistema. Le piccole dimensioni dei microservizi permettono
ai piccoli team responsabili di individuare e risolvere veloce-
mente il problema.
Un’architettura basata su microservizi è caratterizzata da
accoppiamenti laschi: ogni microservizio è indipendente e
 
W H I T E P A P E R C l o u d - 1 torna aL sommario

Cosa sono i microservizi...

 Quanto sono utilizzati Il 69% degli intervistati ha dichiarato di uti-

Clicca per
leggere il
white paper
di Xpeppers
può gestire in autonomia uno stack di tecnolo-
gie; i team che si occupano di quel microservi-
zio possono modificare la tecnologia sotto-
stante senza fermare l’intera applicazione. La
minore complessità dei microservizi (rispetto
ad altre tecnologie) riduce infine la barriera di
accesso allo sviluppo di nuove funzionalità
applicative anche da parte di piccoli team di
sviluppo.
i microservizi?
Quanto e come vengono utilizzati i micro-
servizi? È la domanda che si è posta Red Hat e
da cui l’azienda è partita per realizzare questa
ricerca sugli utenti di Red Hat JBoss Middlewa-
re e Red Hat OpenShift. Non si tratta quindi di
una indagine su un campione statisticamente
rappresentativo, ma comunque è interessante
soffermarsi sui risultati per capire quali van-
taggi possono derivare dall’uso dei microservi-
zi e quali ostacoli ne impediscono l’adozione.
Tra le prime evidenze emerse nel sondaggio
si legge che i microservizi tendono a essere
promossi come ideali per progetti completa-
mente nuovi, senza menzionare i vantaggi che
invece possono portare in caso di aggiorna-
mento di progetti già esistenti; comunque, la ri-
cerca ha mostrato che le aziende usano i mi-
croservizi anche per riprogettare applicazioni
esistenti e proprietarie.
lizzare i microservizi sia per sviluppare appli-
cazioni nuove che per riprogettare quelle esi-
stenti.
Nel corso di questa survey, è apparso poi
chiaramente come non ci sia un’unica piatta-
forma runtime o framework ideale per i mi-
croservizi. È stato inoltre sottolineato come il
45% degli interpellati creda nell’utilizzo degli
“strumenti giusti per i compiti giusti”, piuttosto
che scegliere un’unica tecnologia, runtime o
framework di riferimento. Secondo la ricerca,
inoltre, l’87% dei clienti ha dichiarato di stare
usando, o prendendo in considerazione, tecno-
logie differenti per lo sviluppo dei microservi-
zi.
Sono risposte che mostrano come un ap-
proccio multi-technology stia diventando la
norma, e che sempre più organizzazioni ten-
dono a utilizzate via via lo strumento adeguato
alle necessità specifiche.

21 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Cosa sono i microservizi...
Quali benefici sono generati
dall’adozione di microservizi?
I partecipanti alla ricerca hanno identificato
svariati benefici che stanno già sperimentan-
do a seguito dell’implementazione dei micro-
servizi. Questi i principali vantaggi che sono
stati messi in luce:
1. integrazione continua (CI) / Implementazio-
ne continua (CD);
2. agilità;
4. migliore scalabilità;
5. time-to-market più veloce;
6. maggiore produttività degli sviluppatori;
7. debugging e manutenzione più semplici.
Inoltre, molti degli intervistati (33%) sono
stati in grado di riconoscere i benefici ottenuti
tra i due e i sei mesi dall’iniziale implementa-
zione dei microservizi, a conferma della ve-
locità del processo di ramp up e della pos-
sibilità di ottenere vantaggi in modo molto
veloce.
22 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
Quali ostacoli alla loro adozione?
Adottare i microservizi non risolverà tutti i
problemi legati al software in azienda, anzi gli
stessi microservizi portano con sé una serie di
problematiche specifiche. Secondo la ricerca,
le principali problematiche legate all’imple-
mentazione di microservizi che gli intervistati
si sono trovati ad affrontare sono: sfide legate
alla cultura e organizzazione aziendale; ge-
stione dei microservizi; diagnosti-
ca e monitoraggio; disponi-
bilità di tempo e risorse.
Parallelamente, que-
ste sono le princi-

P A P E R C l o u d - 1 torna aL sommario
pali attività che le aziende intervistate hanno
indicato per contribuire a superare queste pro-
blematiche: sviluppo/implementazione di too-
ling per microservizi in-house; riorganizza-
zione; collaborazione con vendor esperti/
utilizzo di un vendor come consulente di rife-
rimento; acquisto o utilizzo di una piattafor-
ma/soluzione dedicata ai microservizi. (R.C.) 

Software Container: come si possono
gestire e quali sono i vantaggi
FOCUS per l’utente
Vediamo come sono fatti e come funzionano i software
container; quali pro e contro offrono non solo in ambito di
sviluppo applicativo, ma, più in generale, al business e
all’IT rispetto alle macchine virtuali e come se ne può
governare l’impiego in vista d’una eventuale adozione
P
er comprendere cos’è un software container, come
funziona e perché venga visto non solo come mezzo abilitan-
te lo sviluppo e delivery delle applicazioni composite, ma an-
che come valido sostituto delle macchine virtuali (la soluzio-
ne che oggi domina nell’I&O – infrastruttura e operazioni), ci
si deve fare una domanda: perché virtualizzare un intero si-
23 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
stema quando se ne usa solo una parte? Una VM, lo dice il no-
me, è una macchina. Senza “ferro” ma completa d’ogni parte
logica, con un sistema operativo che accede all’hardware
tramite l’hypervisor, uno strato software che gestisce le
istanze di tutte le VM che insistono sul server fisico. Ma
un’applicazione, specie se è un semplice servizio come quel-
li che vanno a formare le nuove soluzioni, non ha bisogno di
tutto questo.
Per cui si è cercato di creare un ambiente dove l’applica-
zione possa girare restando isolata dalle altre ma sfruttando
direttamente, sia pur in modo condiviso, le risorse del ser-
ver host tramite il kernel del sistema operativo del server
stesso. Agli inizi l’idea si è sviluppata lavorando sulle doti na-
 
W H I T E P A P E R C l o u d - 1 torna aL sommario

Software Container... Nato e tuttora gestito come progetto open

source, creato nel 2013 e dal giugno 2014 di-
sponibile come release commerciale supporta-
tive multi-user e multi-task di Unix, e da tempo Dai Linux Container a Docker e oltre ta dall’omonima società, il software Docker au-
infatti sia IBM AIX, sia Oracle Solaris offrono Chiunque usi Linux può quindi usare dei tomatizza il deployment delle applicazioni nei
tecnologie del genere. Ma la vera innovazione container (Linux container Lxc), e ciò da anni. container e ne facilita la gestione. Al suo svi-
dei software container è legata a Linux e al mo- Perché allora se ne parla tanto adesso? Perché luppo, sostenuto prima da Red Hat e poi da Mi-
vimento open-source. se i container non sono una novità, lo è invece crosoft, Oracle e dalla stessa VMware, contri-
Nella nascita dei software container (SWC) Docker, che, un po’ come ha fatto VMware per buiscono sia cloud provider (Google
Google ha avuto un ruolo determinante. Si deve le VM, ne sta facendo decollare l’adozione esal- ovviamente, e Amazon, Azure, eBay, Spotify…),
infatti alla Casa di Mountain View se dal 2008 tandone le doti e rendendone pratico l’uso. sia vendor come IBM, HPE, Dell-EMC, NetApp
il kernel Linux di base comprende funzioni
che abilitano sia controllo dell’hardware
(cgroups) sia l’isolamento (spacename) neces-
sari affinché ogni processo abbia una visione
del sistema diversa dagli altri e si possano ese-
guire più applicazioni in una singola istanza
all’OS Linux. Questi strumenti innalzano il li-
vello di astrazione, che dall’hardware si porta
al sistema operativo. Per cui sebbene nel con-
tainer ci sia solo il codice sorgente con le bina-
ry-libraries, l’applicazione vede le risorse di si-
figura 1
stema (file system, cpu, ram, disk I/O…) come Confronto tra
virtualizzazione su VM e
se fossero interamente dedicate alla sua esecu- virtualizzazione su
container
zione.
Fonte: Forrester Research

24 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Software Container...
 Kubernetes (“timoniere”, in greco), un “orche-
Clicca per
leggere il white
paper di
Capgemini
e tanti altri. Questa confluenza tra fornitori lea-
der in hardware, software e servizi sta gene-
rando un’offerta vivacissima di strumenti e
plug-in per controllare il versioning e la condi-
visione, creare repository, fare auditing e an-
che per usare gli SWC con database e infra-
strutture proprietarie.
Ma proprio il successo dei container spinto
da Docker ha mostrato i limiti dello strumento
nel governo dei carichi di lavoro al crescere del
numero di host e di SWC ospitati. Ancora Goo-
gle, i cui servizi sono tutti in SWC, ha proposto
25 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
stratore” che opera sui container gestibili con
Docker sfruttando due nuovi concetti. Uno è il
pod, un gruppo di SWC che viene dispiegato
insieme su uno stesso host. L’altro è il label,
un’etichetta che marca gli attributi del pod, co-
me l’appartenenza a un nodo di calcolo, facili-
tandone l’organizzazione. Kubernetes ha atti-
rato l’interesse della comunità open-source,
che vi si è molto impegnata, e Docker vi ha ri-
sposto con Swarm, un tool che usa analoghi
modelli di clustering e gestione per gruppi di
container. Difficile dire oggi quale sarà l’orche-
stratore vincente, se mai ve ne sarà uno.
Quanto costa adottare i software container?
Se il software Docker di base è gratuito, si paga-
no i suoi tool di servizio e quelli forniti dai part-
ner, indispensabili per usare gli SWC in azien-
da. Stante i molti tipi d’implementazione e la
turbolenza del mercato, fare un’analisi econo-
mica è praticamente impossibile. Possiamo pe-
rò dire che a parità di servizi erogati nell’unità

P A P E R C l o u d - 1 torna aL sommario
di tempo, analisti e blogger concordano nel de-
finire il costo d’una struttura su SWC molto in-
feriore rispetto ad una su VM e hypervisor.
Software container e VM: insieme o
contro?
Premesso che nel considerare le differenze
tra SWC e VM dal punto di vista dei vantaggi
per l’It e il business intendiamo SWC ‘Docker-
capable’ integrati dei soli tool necessari nelle
singole situazioni, il primo vantaggio di un
SWC rispetto a una VM sta nella leggerezza.
Non avendo un proprio sistema operativo, il
peso di un SWC è solo di qualche decina di Mb
contro i gigabyte di una VM. Ciò significa minor
richiesta di potenza di calcolo (basta un laptop
per ospitare centinaia di container) e maggiore
velocità, non avendo l’overhead dell’hypervi-
sor.
I servizi containerizzati sono quindi dispo-
nibili in una frazione di secondo per essere
eseguiti oppure aggiunti, rimossi o aggiornati
nell’applicazione; ciò facilita la gestione dei
cicli di rilascio e si riflette sulla customer ex-
perience, specie nel mobile, dove la velocità di

Software Container...
risposta è basilare. Queste doti permettono an-
che di spalmare l’applicazione su un gran nu-
mero di micro-servizi, con un controllo più
granulare della sua eseguibilità e un migliore
sfruttamento delle risorse di sistema. Infine,
chiudere i servizi in componenti distribuibili e
configurabili con una sola riga di comando,
senza badare all’ambiente runtime, accelera di
molto il rilascio di applicazioni complesse, at-
tuando efficacemente le pratiche DevOps. In
effetti, chi punta al DevOps di regola opta an-
che per gli SWC. Questi vantaggi riguardano
soprattutto lo sviluppo e deployment applicati-
vo nei suoi effetti sul business. Ma gli SWC so-
no una soluzione anche per l’I&O (infrastrut-
tura e operazioni) grazie alla loro portabilità.
Facendo a meno di hypervisor proprietari, le
comunità open-source e Docker hanno svilup-
pato un formato interoperabile che permette di
eseguire i servizi in container su host eteroge-
26 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
nei. Non occorre dire cosa ciò significhi in un
ambiente cloud pubblico o ibrido: in pratica i
carichi di lavoro si possono spostare sulla piat-
taforma che al momento, per prestazioni o per
economicità, risulta più conveniente. Senza do-
ver restare legati a un dato provider per le pe-
culiarità della sua o della nostra tecnologia.
Ma vi sono punti in cui ‘vincono’ le macchi-
ne virtuali? Sì, almeno due: uno è la sicurezza
operativa e la resilienza infrastrutturale data
da tecnologie più che collaudate; l’altro è il
supporto dei vendor VM alle applicazioni di
back-end. Non sono cose da poco e infatti l’opi-
nione corrente è che SWC e VM andranno a
convivere dividendosi le aree d’impiego tra il
front-end, web e mobile, e appunto il back-end.
Tanto più che va detto che solo se occorrono le
massime prestazioni un SWC è implementato
“bare-metal”, ma di solito il suo server “fisico”
è in realtà una macchina virtuale. (G.C.B.) 

Breve viaggio tra strategie e prodotti
software container
LE TECNOLOGIE
Il mondo dei software container vive oggi un’estrema
effervescenza. Ecco in questa breve rassegna una
disamina ragionata delle proposte più significative offerte
da software house, produttori hardware e piattaforme
cloud pubbliche. Emerge il supporto quasi unanime alla
tecnologia Docker per lo sviluppo dei contenitori e la
leadership di Kubernetes come piattaforma di
orchestrazione e gestione
L
eggeri e facilmente portabili all’interno di un’infra-
struttura ibrida che può partire dal data center aziendale
(magari costituito da sistemi convergenti o iper-convergenti
come quelli proposti da NetApp, Dell EMC, Cisco, HPE, IBM,
Nutanix ecc.), ed espandersi attraverso un cloud o, addirittu-
ra, più cloud, i software container, come abbiamo visto poco
27 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
sopra, rappresentano la nuova frontiera dello sviluppo sof-
tware. Una delle loro peculiarità, grazie appunto alla loro leg-
gerezza e portabilità, è quella di adattarsi molto bene al mo-
dello emergente multicloud, per cui un’applicazione
complessa, formata da più applicazioni container (che con-
tengono database, business application, ecc.), può estendersi,
grazie ai motori di orchestrazione, fra più piattaforme cloud
contemporaneamente.
L’avvento della tecnologia dei container (oggi in massima
parte creati utilizzando il tool Docker, ma distribuiti e gestiti
con diversi software di orchestrazione, primo fra tutti Kuber-
netes) non si prevede che manderà in pensione la virtualiz-
zazione tradizionale: quella basata sull’utilizzo di hypervisor

Breve viaggio tra strategie e prodotti...
(installate sull’hardware bare-metal) e VM (veri
e propri sistemi virtuali contenenti applicazio-
ni, dati, versione virtuale di un sistema operati-
vo, in grado di utilizzare le risorse hardware
virtualizzate dall’hypervisor).
Tecnologie più alleate
che concorrenti
Entrambe queste tecnologie hanno diversi
pregi e difetti, e quindi nella pratica si rivelano
strumenti alternativi e/o complementari nelle
mani dei team IT composti da sviluppatori e re-
sponsabili delle operation (che si occupano di
provisioning di risorse infrastrutturali e gestio-
ne delle infrastrutture e del software in eserci-
zio). Lo sanno bene i maggiori player della sof-
tware virtualization, come VMware, Microsoft
o Red Hat, che evolvono in parallelo, e in modo
integrato, le rispettive tecnologie di virtualizza-
zione tradizionale e container.
Due anni fa VMware ha introdotto vSphere
Integrated Containers (VIC), una soluzione
28 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
che permette di far girare e di gestire in modo e manutenzione del software, interoperabilità,
integrato, su una piattaforma comune, appli- larga disponibilità di componenti software re-
cazioni sia tradizionali sia container. La cosa peribili in repository sul web, limitate dimen-
interessante è che ciascun container, sviluppa- sioni fisiche e necessità di risorse hardware.
to con la tecnologia Docker presente in VIC, è Dal canto suo, anche Microsoft ha deciso di
ospitato all’interno di una VM. Più VM conte- lavorare in stretta alleanza con Docker e il
nenti istanze container, che devono lavorare in frutto di questa collaborazione è la tecnologia
collaborazione, possono essere integrate dagli Windows Containers. La tecnologia offre due
sviluppatori in un container host virtuale (Vir- modelli di implementazione diverse dei contai-
tual Container Host, o VCH). In pratica, la solu-
zione di VMware si propone di offrire i vantag-
gi delle virtual machine tradizionali in termini
di sicurezza (dovuta al perfetto isolamento del-
le VM fra loro), di resilienza (le VM, a differenza
dei container, contengono un’immagine com-
pleta del sistema operativo necessario per farle
girare) e di gestibilità (nel caso dell’ambiente
VMware, si utilizza il molto popolare vSphere
Web Client).
Allo stesso tempo vSphere Integrated Con-
tainers permette di godere benefici della tecno-
logia Docker legati alla semplicità di creazione

Breve viaggio tra strategie e prodotti...
 cio ai container che passa attraverso la
Clicca per
leggere il white
paper di Open
Connectivity
Foundation
ner: il primo, Windows Server Containers, per-
mette di creare container Docker che sfruttano
il kernel del sistema operativo Windows Server
2016; il secondo è Hyper-V Containers, dove i
container sono inseriti in VM che contengono
una propria versione del kernel Windows, con
il risultato di accrescere l’isolamento.
Passiamo a un vendor che utilizza e propone
solo tecnologie open source come Red Hat. Il
fornitore della distribuzione di Linux Red Hat
Enterprise Linux (Rhel) propone un approc-
29 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
Platform-as-a-Service (PaaS) OpenShift 3, ba-
sata su Rhel. Con il modulo Red Hat OpenShift
Container Platform, gli sviluppatori possono
creare, testare e fare il deployment di container
Linux Docker; per l’orchestrazione e la scalabi-
lità dei container viene utilizzato Kubernetes.
L’altro concorrente nel mercato Linux, Suse,
ha introdotto invece la Suse Containers as a
Service Platform. La soluzione permette di
creare container Linux in formato Docker.
Anch’essa si avvale della tecnologia Kuberne-
tes per l’orchestrazione. Suse ha anche svilup-
pato Suse Linux Enterprise MicroOs, un siste-
ma operativo ottimizzato per i container.
Un approccio Platform-as-a-Service è stato
adottato anche da HPE e IBM. La prima propo-
ne HPE Helion Stackato, una soluzione che si
basa sulla tecnologia PaaS open source Cloud
Foundry. HPE Helion Stackato può essere uti-
lizzato per lo sviluppo e il deploy di applicazio-
ni cloud native che possono essere fatte girare
su un mix di infrastrutture come, ad esempio,

P A P E R C l o u d - 1 torna aL sommario
data center virtualizzati con VMware, hybrid
cloud create con la soluzione HPE Helion Open-
Stack, e public cloud come AWS di Amazon. La
PaaS IBM, invece, si chiama IBM Containers
on Bluemix e si può integrare facilmente con
le soluzioni Watson (cognitive computing) e
IoT di Big Blue.
Hardware per data center
e cloud pubbliche
Già, ma dove girano i container? Gli hardwa-
re vendor stanno puntando in questo momento
sull’offerta di soluzioni innovative che ruotano
sulla convergenza infrastrutturale (a supporto
degli obiettivi di Continuous Integration / Con-
tinuous Development) e sull’ottimizzazione
delle funzionalità di storage per i container. Ec-
co Nutanix proporre, a corredo delle proprie
infrastrutture iper-convergenti, la soluzione
Acropolis Container Services (ACS), che inte-
gra, fra le altre cose, la gestione semplificata
del ciclo di vita dei container, uno storage per-
sistente enterprise-class e funzionalità per far
convivere applicazioni containerizzate e vir-
tualizzare sulla stessa piattaforma. NetApp ha
lanciato Trident, un progetto open source per

Breve viaggio tra strategie e prodotti...
facilitare e migliorare il provisioning e l’or-
chestrazione di funzionalità storage contai-
ner per chi usa le soluzioni del vendor. La solu-
zione fa leva su Kubernetes e sull’impiego dello
standard iScsi). Dell EMC ha lanciato Dell EMC
Unity, una famiglia di storage midrange all-
flash o ibrida che offre storage convergente fi-
le-blocchi, è basata su un kernel Suse Linux e
supporta Docker container.
Per chi non volesse investire in infrastruttu-
re on premises per lo sviluppo, il deployment e
la distribuzione di container, è piuttosto ricca
ed efficiente l’offerta dei cloud provider. Ecco
alcune segnalazioni. Amazon, sul suo Amazon
Web Services (AWS) offre Amazon EC2 Con-
tainer Service (ECS), un servizio per lo svilup-
po, la produzione e l’orchestrazione di contai-
ner Linux. In versione beta è disponibile anche
il supporto a Windows Container. Nel 2016
Oracle ha arricchito la Oracle Cloud Suite con
Oracle Container Cloud Service (Occs), su cui
è possibile approvvigionarsi di molte Linux
machine per fare girare Docker container già
30 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
W H I T E
sviluppati. La completa Oracle Application
Container Cloud Service (Accs), una PaaS che
facilita lo sviluppo e la messa in produzione di
applicazioni container anche a chi non è esper-
to di Docker. Anche Google, con Google Cloud
Platform, Microsoft, con Azure e il suo Contai-
ner Service, e IBM, con Softlayer, continuano
a rilasciare a getto continuo nuove funzionali-
tà e servizi per aiutare gli sviluppatori e le
aziende IT a capitalizzare sulla nuova tecnolo-
gia container.
Aziende impegnate a evitare silos
e lock-in con i container
Nell’era della digital transformation le azien-
de non possono permettersi un’IT ingessata da
silos tecnologici e lock-in verso singoli vendor.
La tecnologia container rischia di far cadere le
imprese in queste trappole? In teoria no. Il sof-
tware container mira a permettere lo sviluppo
di applicazioni che possono essere distribuite
e fatte girare su qualsiasi sistema operativo o
cloud. Inoltre, già all’inizio della filiera di pro-

P A P E R C l o u d - 1 torna aL sommario
duzione dei container, non esistono vincoli
verso specifici linguaggi di programmazione.
Apparentemente, quindi, niente di più anti-
tetico rispetto a silos e lock-in. Ma in realtà non
è tutto così semplice. Fino a pochi mesi fa, per
esempio, si parlava di estesa portabilità dei
container solo assumendo che tutti i target (gli
host) utilizzassero un kernel Linux. Un passo
avanti verso una maggiore apertura della tec-
nologica container è avvenuto grazie alla col-
laborazione fra Microsoft (azienda che ha un
amplissimo installato a livello mondiale) e Do-
cker. Microsoft ha potuto così adattare l’archi-
tettura di Windows Server 2016 per far girare
container Docker realizzati ad hoc (Windows
container). E i container Linux? Negli ambienti
Windows, questi sono supportati su sistemi
dotati del software di virtualizzazione Micro-
soft Hyper-V oppure sul cloud pubblico Mi-
crosoft Azure. Anche Amazon Web Services e
Google Cloud Platform supportano i container
sia Linux sia Windows.
Siamo sempre più nell’Eden? In realtà, an-
che se la caratteristica open source di queste
tecnologie permette che vengano adottate su

Breve viaggio tra strategie e prodotti...
larga scala e che i problemi di compatibilità si-
ano risolti dalle community, la stessa natura
può essere la causa di disallineamenti, soprat-
tutto dovuti alla frammentazione in diversi
progetti. La stessa tecnologia Docker viene
messa in discussione, non perché non sia vali-
da, ma perché altri attori vorrebbero che si
giungesse alla definizione di formati di contai-
ner image e runtime comuni, gestiti dalla Open
Container Initiative (Oci). Ancora più fram-
mentato è il mondo dei software d’orchestra-
zione, necessari per la distribuzione e la ge-
stione di container su larga scala. La soluzione
leader in questo momento è l’open source Ku-
bernetes, alla base di diverse offerte commer-
ciali. Ma sono molto utilizzati anche Mesos,
Docker Swarm e gli engine di orchestrazione
degli stessi cloud pubblici.
La tecnologia container, in ultima analisi,
prevede l’integrazione di diversi strumenti. Le
31 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
aziende che hanno la possibilità di dotarsi di
molte risorse formate sui software container
possono permettersi di adottare un approccio
“ibrido” che integra il ricorso a soluzioni com-
merciali (ad esempio nell’ambito delle piatta-
forme infrastrutturali convergenti e ipercon-
vergenti), con l’impiego in house di strumenti
di sviluppo, testing, deployment e gestione del
software container e di orchestrazione. Per le
altre è preferibile la scelta di un partner (o di
più partner, con un capofila) che abbia dimo-
strato di essere innovativo, aperto agli stan-
dard, attivo nelle community e collaborativo
con i clienti. (R.C.) 
 
W H I T E P A P E R C l o u d - 1 torna aL sommario

Container e data mirroring per creare

backup ad alta disponibilità
FOCUS più economici e veloci
I backup tradizionali per l’IT non costituiscono più un
metodo efficace di ripristino dei dati. I consigli degli
esperti per creare sistemi ad alta affidabilità, passando una sorta di rassegnata accettazione.
attraverso una governance più evoluta, legata alle nuove
Le contromisure attuate dalle squadre IT per ridurre al mi-
tecnologie di virtualizzazione, per poter sempre contare su
sistemi robusti su cui far girare le proprie applicazioni o nimo l’inattività dei sistemi ancora oggi sono tutte incentrate
che comunque abbiano veloci tempi di ripristino sulla velocità di recupero dei dati dai backup.

I
tempi di arresto di un qualsiasi sistema informativo,
hardware o software, possono avere un impatto anche molto
significativo sul business. È vero anche che, da quando l’ICT
è entrato nelle organizzazioni, interruzioni non pianificate e
costi associati al cosiddetto downtime IT sono entrate a far
parte della vita aziendale e, proprio per questo, vissuti con
Come migliorare backup e tempi di recovery
In passato l’evoluzione tecnologica ha comunque portato a
notevoli migliorie negli strumenti di backup. Eppure per
molte organizzazioni i tempi di ripristino non sono ancora
sufficienti. Inoltre, va tenuto conto che un sistema ad alta di-
sponibilità può essere fuori dalla portata finanziaria della
maggior parte delle organizzazioni. Oggi, però, esiste un
metodo più efficace ed economico per garantire ai data cen-

32 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1


Container e data mirroring...
ter aziendali sistemi di backup ad alta dispo-
nibilità: sfruttare il mirroring dei dati, combi-
nato al cloud e alla containerizzazione.
La containerizzazione può aiutare a risolve-
re alcune delle grandi sfide dei sistemi ad alta
disponibilità. I container, che a tutti gli effetti
sono sistemi autonomi che girano su un singo-
lo host, aumentano l’utilizzo delle risorse con-
sentendo ai reparti IT di distribuire anche inte-
re applicazioni senza dover lanciare un’intera
virtual machine per ogni applicazione.
Si prenda il caso di una serie di dati che so-
no stati tutti mirrorizzati su un sito seconda-
rio. Nel momento in cui il sito primario cade,
automaticamente si è abilitati ad accedere al si-
to secondario. Ma che ne è delle applicazioni?
Pur avendo la piena disponibilità delle infor-
mazioni, infatti, ci vuole del tempo perché il si-
to secondario riesca a caricarle permettendo
così di gestire operativamente i dati recuperati.
L’alternativa? Esiste ma è molto costosa e con-
siste nel pagare una cifra esorbitante per avere
una versione live delle applicazioni che girano
33 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1

W H I T E P A P E R C l o u d - 1 torna aL sommario
nel sito primario.
I container, invece, capitalizzando le tecno-
logie di virtualizzazione, possono ospitare in-
tere applicazioni in un unico sistema di picco-
le dimensioni. Mentre le macchine virtuali
importano qualsiasi elemento nello stack, dal
sistema operativo a salire, i container ospitano
solo quello che serve, condividendo il sistema
operativo sottostante con altri container.
Riprendendo l’esempio citato, per evitare il
downtime, i team IT potrebbero archiviare una
serie di container a basso costo in un sito se-
condario. Nel caso il sito principale abbia dei
problemi, è possibile velocizzare il ripristino
dei dati attivando in pochi minuti il container
che contiene le applicazioni necessarie, abili-
tando così un più rapido accesso ai dati di ba-
ckup.
Gli esperti sottolineano che una metodologia
di backup debba tenere conto delle diverse ne-
cessità aziendali. Se il backup non ha particola-
ri esigenze di velocità e l’archiviazione non ri-
guarda dati mission critical, mettere il sito

direttore responsabile
Stefano Uberti Foppa
stefano.ubertifoppa@zerounoweb.it
articoli di
Giampiero Carli Ballola,
Valentina Bucci, Riccardo Cervelli,
Rinaldo Marcandalli,
Piero Todorovich, Laura Zanotti
editore
Ict & Strategy srl
società del Gruppo
Digital360 Srl opera nell’offerta B2B
di contenuti editoriali,
servizi di comunicazione e marketing,
lead generation, eventi e webinar,
advisory, advocacy e coaching,
nell’ambito della Trasformazione Digi-
tale e dell’Innovazione Imprenditoriale
34 Z e r o U n o WH IT E PAPER 2018 - Cloud - 1
Container e data mirroring...
secondario in un container oppure in un cloud pubblico ha
costi talmente bassi da rendere la scelta equivalente.
Nel caso in cui l’azienda abbia effettivamente bisogno di
aumentare la velocità del recovery, le prestazioni dei con-
tainer diventano decisamente più interessanti e, rispetto ai
costi legati ai fermi aziendali, estremamente più conve-
nienti.
Non a caso, gli analisti di 451 Research hanno previsto che
il mercato della containerizzazione movimenterà oltre 2,7
miliardi di dollari entro il 2020, rispetto ai 762 milioni di dol-
lari registrati nel 2016.
Per le aziende che hanno bisogno di una continuità ope-
rativa serrata con soglie di tolleranza dei downtime davvero
minime, è possibile effettuare una rotazione dei container
costante, piuttosto che gestire forme di archiviazione che ne
prevedano l’utilizzo solo quando è davvero necessario. Certo,
il costo sarà più elevato ma in questo modo, se il sistema pri-
mario cade, il sistema di backup è in grado di attivarsi prati-
camente in tempo reale. È possibile anche ridurre ulterior-
mente i costi, acquistando risorse più flessibili: in questo
modo un container che non viene utilizzato non consuma
CPU o risorse di rete. In caso di stallo o caduta dei sistemi, ai

W H I T E P A P E R C l o u d - 1 torna aL sommario
responsabili IT basterà attivare le risorse che servono, quan-
do servono.
Mirroring dei dati: le cose da sapere
Gli analisti ricordano comunque come il mirroring dei da-
ti non sia una soluzione facile come sembra. La distanza tra
il sito primario e il sito secondario, ad esempio, è una que-
stione importante: più lontano si trova il sito deduplicato,
più è necessario considerare la latenza esistente ma anche
la difficoltà di mantenere la fedeltà dei dati. Il tutto valutan-
do anche come, in caso di compromissione dei dati, il rischio
sia di andare a deduplicare anche la parte corrotta.
Il consiglio? Dotarsi sempre e comunque di strumenti ca-
paci di garantire massimo controllo e massima visibilità su
tutti i processi della governance dei sistemi, in modo da as-
sicurare ai processi di backup la necessaria sicurezza, oltre
che efficienza. (L.Z.) 