Tre approcci alla Converged Infrastructure: il punto di vista del Partner System Engineer

Recentemente si parla molto di converged infrastructure. Questo articolo vuole cercare di chiarire cosa si intende e come differiscono i diversi approcci.

Come molti sanno, converged infrastructure o in italiano, infrastruttura convergente non identifica un prodotto, bensì delle soluzioni standardizzate e automatizzate, in grado di semplificare il flusso dei processi, 

ridurre i costi, massimizzare l'efficienza e la flessibilità del business: in definitiva avere un'infrastruttura che renda il provisioning applicativo il più semplice possibile.

L'obiettivo finale vuole essere quello di investire meno tempo possibile nel management infrastrutturale, per potersi concentrare sulle applicazioni, vero motore del business aziendale.

La domanda potrebbe nascere spontanea: abbiamo davvero bisogno di un'infrastruttura convergente? Un approccio tradizionale non risolve già tutti i requisiti infrastrutturali dell'IT?

In questo articolo cercherò di chiarire perché questo approccio, pur non essendo la panacea di tutti i problemi infrastrutturali, è senz'altro vincente per molti clienti, in particolare per quelli della media impresa.

Già qualche anno fa diversi analisti e blog (IDC, Gartner, Wikibon ecc) hanno previsto un'evoluzione nell'approccio all'infrastruttura. Inizialmente l'approccio era soprattutto tradizionale: un cliente acquistava server, storage,

networking e backup, assemblava il tutto e solo successivamente poteva dedicarsi alle proprie applicazioni e ad estrarre conoscenza dai propri dati.

Questo approccio, pur valido, non permette di avere un Go-To-Market sufficientemente rapido per il datacenter di oggi. Per questo motivo si prevede una crescita significativa di due approcci alternativi:

reference architecture, ovvero una serie di componenti HW e SW studiate per uno specifico carico applicativo e single SKU, ovvero singolo codice acquistabile, che identifica tutta l'infrastruttura atta a servire una o più applicazioni. 

Evoluzione dell'approccio infrastrutturale 

Proponendo delle analogie, possiamo pensare ad un CIO, come ad una persona che vuole una torta. 

Può prepararsela autonomamente, scegliendo accuratamente tutti gli ingredienti: questo approccio pur essendo il massimo della flessibilità (scelgo esattamente

quali e quanti ingredienti inserire) prevede di dover dedicare diverso tempo (ore/uomo), sia alla scelta degli ingredienti stessi, che alla creazione dell'impasto: ultimo ma non ultimo anche alla perfetta "interoperabilità" del tutto.

La torta è, per molti versi, simile all'infrastruttura di un datacenter: anche se ad alcuni piace cucinare, il fine ultimo non è preparare la torta, ma mangiarla! Allo stesso modo il setup infrastrutturale è il mezzo per ottenere un'infrastruttura

efficiente, non il fine ultimo.

Un approccio alternativo consiste invece nel considerare un preparato, che mi permetta di avere comunque una certa flessibilità (posso sempre scegliere come guarnire la torta) pur prevedendo delle linee guida che ne semplifichino la "preparazione".

L'ultimo approccio è quello invece di comprare una torta già pronta: il "go to market" è immediato, anche se devo acquistare la torta così com'è, senza possibilità di personalizzazioni. 

Le "ricette" dell'Infrastruttura IT

Traducendo in ottica IT i tre approcci appena descritti possiamo pensare a:
"Best In Class Products" dove scelgo separatamente server, storage, networking. Compro ciò che voglio, ma devo occuparmi personalmente di verificarne l'interoperabilità e devo prevedere un certo delay nel Go-To-Market.

Il secondo approccio, interessante a mio avviso per la maggior parte dei clienti e partner, si chiama VSPEX.
VSPEX consiste in una serie di "ricette" per ottenere una BOM (Bill of Material) infrastrutturale partendo da requisiti applicativi o della piattaforma di virtualizzazione che il cliente intende utilizzare.
Mediante dei whitepaper (le "ricette" di cui sopra) o tramite un configuratore web, posso specificare quali e quante macchine virtuali voglio poter gestire, piuttosto che dettagliare i parametri salienti della mia applicazione
(Oracle, SQL, Exchange ecc) lasciando che i requisiti vengano tradotti automaticamente in una configurazione storage, network e backup.

Esempio Exchange di raccolta dei requisiti applicativi per produrre un'Infrastruttura VSPEX

Le tre proposte infrastrutturali EMC

Il vantaggio dell'approccio VSPEX consiste nel fatto di avere flessibilità nella scelta dell'hypervisor di virtualizzazione (posso scegliere vmware, microsoft, citrix ecc), dei server e del networking, in base ai contratti che il cliente o il partner possano avere in essere.
Allo stesso modo, per quanto appena descritto, questo permette di ottenere un'infrastruttura che risponda esattamente ai requisiti applicativi desiderati.

Il vantaggio per il cliente finale consiste quindi nell'avere un'infrastruttura costruita esattamente sulle proprie esigenze, con un Go-To-Market molto rapido.

Cosa significa invece tutto questo dal punto di vista di un partner EMC? Si potrebbe pensare che il primo approccio permetta ad un partner di erogare più servizi a supporto dell'implementazione infrastrutturale.
In realtà l'approccio VSPEX non solo permette al partner di dare un valore aggiunto sul design infrastrutturale (per questo motivo i rack VSPEX possono essere addirittura co-branded EMC/Partner), ma anche di poter erogare servizi a valore, che possano davvero mettere in evidenza le proprie capacità di System Integrator o i propri skill applicativi. Servizi di migrazione dati, Physical to Virtual, Fine Tuning, Porting applicativo e Monitoring remoto sono solo alcuni esempi di servizi a valore che un partner EMC può portare a corredo di un progetto VSPEX.

Vediamo per concludere quali sono i fattori differenzianti rispetto a proposte analoghe dei competitor. Come detto la Converged Infrastructure è un approccio ed EMC non è l'unica a portarlo avanti.

Potremmo citare diversi esempi di valore aggiunto in una Converged Infrastructure EMC rispetto a quelle proposte della competition, ma mi limiterò a citarne 3. Per ulteriori approfondimenti tuttavia, vi invito a contattare un presale EMC.

Infrastruttura Storage: tenendo presente che lo sviluppo del nuovo business è il principale motore innovativo che porta all'adozione di queste tecnologie, avere uno storage in grado di adattarsi perfettamente alle performance richieste dalle applicazioni è il primo grosso valore. EMC VNX, tramite tecnologie come Auto-Tiering e Fast Cache, permette sia di dare boost applicativo in tempo reale, che di gestire il tiering automatico del dato sul medio e lungo periodo, per non sprecare spazio costoso per applicazioni a basse performance e non penalizzare le applicazioni quando queste richiedono alte prestazioni. Se l'obiettivo finale è dedicare tempo alle applicazioni, uno storage in grado di eseguire tuning automatico è il mezzo che permette al cliente di ottenere tale obiettivo.

Protezione del dato: il secondo plus riguarda le tecnologie correlate, necessarie a rendere il dato sicuro e protetto: Backup&Recovery, Business Continuity e Disaster Recovery.
Soluzioni come VPLEX, RecoverPoint, Avamar e Data Domain vengono utilizzate in un approccio VSPEX per completare l'infrastruttura stand-alone. Queste tecnologie, leader di mercato, danno a VSPEX un valore unico sul mercato, ovvero poter proteggere le proprie applicazioni qualunque siano i valori di RPO (Recovery Point Objective) e RTO (Recovery Time Objective) che i clienti desiderino.

Valore dei nostri partner: un partner EMC a valore è in grado di supportare i nostri clienti al meglio, sia nella definizione dei requisiti applicativi, sia nell'evoluzione dell'infrastruttura VSPEX negli anni successivi alla messa in opera.
La stretta sinergia tra EMC e la propria rete di partner assicura al cliente sia l'infrastruttura che più si adatta alle sue esigenze, che le competenze necessarie per un percorso di private/hybrid cloud.

Umberto Galtarossa
Tw: @umberoot