Capisco sembri una questione di pura semantica e quindi di lana caprina rispetto all’obiettivo fondamentale di utilizzare soluzioni cloud, ma la distinzione tra Ibrido vs Multi nel cloud è invece di fondamentale importanza.

Oggi molto spesso i due termini, sembrano, per assonanza, simili. Vengono associati in modo intercambiabile e all’interno della stessa frase e non è inusuale ascoltare affermazioni quali: “la nostra strategia di cloud è ibrida e comunque multi-cloud.”

Già in tempi non sospetti (anni 2016 – 2018), esperti del settore facevano riferimento a questa differenziazione come fondamentale per riconoscere gli strumenti di automazione, di gestione e le aspettative della soluzione implementata.

Implementare una soluzione ibrida, solitamente mette al centro dell’attenzione la soluzione, appunto, che è realizzata seguendo uno schema di lavoro che implica la “collaborazione” tra diverse entità tipicamente implementate on-prem e off-prem.

Nel caso di multi-cloud invece parliamo:

  • della possibilità di utilizzare vari cloud provider allo stesso tempo per eseguire differenti funzioni
  • o la capacità di essere intercambiabile per una specifica funzione tra vari cloud provider.

La differenza è fondamentale ed è necessario focalizzarsi su cosa vogliamo ottenere come obiettivo e non sulle definizioni puramente accademiche, facendo attenzione che l’una non implica l’altra e viceversa.

Non sono assolutamente d’accordo con chi definisce ibride le soluzioni transitorie (on-prem, off-prem) e quelle multi-cloud come l’obiettivo da raggiungere.

Non sono d’accordo perché il punto di vista deve essere quello della soluzione. L’obiettivo è dare un servizio. Per fornire quel servizio dobbiamo per forza mescolare differenti soluzioni che insieme garantiscono l’esecuzione del tutto. Ibrido o multi-cloud non è semplicemente una conversazione su come si distribuisco i workload ma soprattutto un modello che pone l’efficienza e l’efficacia al centro degli obiettivi di un architetto di soluzione.

Efficacia vs efficienza

Ibride, quindi, devono essere considerate le soluzioni e non le strategie. Si scelgono soluzioni ibride quando è necessario essere efficaci nel fornire un unicum che utilizzi al meglio le risorse sottostanti.

E’ ibrida una realizzazione di una soluzione che utilizzi l’autenticazione in single sign on fornite in SaaS che utilizza a sua volta un Directory Service in casa per verificare le credenziali, che abiliti alla esecuzione di una soluzione di CRM online (sempre in SaaS) i cui dati sono memorizzati in uno IaaS di un cloud provider e il cui backup è protetto tra le mura amiche.

Dal punto di vista dell’utente finale ho una soluzione efficace che vede la collaborazione di più’ ambiti in modo trasparente. Ci piace dire che Ibride sono le applicazioni non le strategie.

Ora pensiamo ad ogni singolo elemento che stiamo utilizzando in quella soluzione e poniamoci la domanda: che grado di libertà ho di utilizzare questo o quell’altro strumento mantenendo la fruizione da parte degli utenti qualitativamente elevata o addirittura migliorandone l’esperienza.

In altre parole, se volessi efficientare la mia soluzione che grado di mobilità (libertà)  potrei avere?  In altri termini cosa succederebbe se la strategia di acquisto della mia azienda cambiasse sul singolo elemento?

Nell’IT tradizionale questo corrisponde più o meno a cambiare vendor in una specifica funzionalità. Nell’IT tradizionale abbiamo imparato a standardizzare il computing (x86), lo storage (accesso SCSI su FC o NAS via IP) e rete (switching e routing). Se l’azienda cambiasse strategia di acquisto, ferme restando le caratteristiche sopra esposte, ogni IT manager sarebbe in grado di implementare le soluzioni e di continuare a mantenere i livelli di servizio.

Nel caso del cloud siamo sicuri di poter essere così agili nel cambiare fornitore dei miei elementi essenziali? Siamo sicuri che cambiando i fattori nel mondo IaaS il prodotto non cambi?

Ogni Cloud Provider per quanto riguarda i servizi IaaS (computing, storage e networking)  ha caratteristiche profondamente diverse sia nel modo in cui i servizi stessi vengono proposti che nel modo in cui si possono giustapporre per formare una soluzione. Le differenze sono sulle prestazioni fornite dai sistemi di computing, sulle prestazioni in termini di I/O di ogni singola risorsa storage ed, inoltre, sulla interazione tra compute e storage in termini di capacità di utilizzo di banda, throughput e quindi IOPS.

Per raggiungere la massima efficienza devo essere in grado di poter cambiare i fornitori di servizio senza incorrere tutte le volte in piani di migrazione e di re-ingegnerizzazione delle soluzioni stesse.

Multi-Cloud e Vendor Lock-in

Se questa differenziazione ci vede d’accordo, la domanda seguente sembra essere: avere una strategia Multi-Cloud significa essere riusciti all’annoso vendor lock-in? Su questo tema, mi piacerebbe essere chiaro. Il vendor lock in si ha quando l’azienda è ostaggio di un vendor in termini di migrazioni o di aggiunta di nuove funzionalità rispetto al modello di business. Personalmente non considero vendor lock in quella situazione in cui, il modello di business del vendor preveda aggiornamenti sempre inclusi e soprattutto la possibilità di riutilizzare l’investimento al mutare delle condizioni dell’azienda (ad esempio passare dall’on-prem al cloud).

Per questo motivo sono fermamente convinto della necessità di capire, da parte di un’azienda, quale strategia sia vincente per:

  1. Usare al massimo le potenzialità di ambienti cloud
  2. Per minimizzare le migrazioni dei dati e del modello dei dati
  3. Per essere indipendente da uno specifico cloud provider
  4. Per fornire il massimo della flessibilità.

Avere una strategia Multi-Cloud su ogni componente della soluzione è fondamentale per ricercare quel grado di efficienza, strategico per mantenere l’economicità dell’ azienda. Per fare questo è necessario il più possibile disegnare soluzioni che utilizzano interfacce standard (i.e. RestAPI) o modelli applicativi altamente portabili (i.e. Container).

Anche in questa seconda ipotesi, Pure Storage, fornisce ai clienti le armi per implementare Strategie multi-cloud anche nella parte di persistenza del dato di cluster K8s. Questo ulteriore livello di flessibilità permette di implementare soluzioni Multi-cloud anche quando si utilizzino cluster K8s per la componente di storage persistente.

 

La posizione di Pure Storage

Pure Storage da sempre è impegnata a garantire ai propri clienti e partner un elevato grado di semplificazione. Dal 2009, anno della sua fondazione, fornire sistemi storage agili ad elevate prestazioni è stato obiettivo, pienamente raggiunto, e che ha dettato la linea per tutti gli sviluppi e la ricerca dell’azienda. La nostra flessibilità ha aiutato ad implementare le vere architetture ibride. Grazie alla flessibilità e alla capacità di adattarsi in funzione delle mutate esigenze dei nostri clienti nel ciclo di vita stessa dell’infrastruttura, ha permesso la vera e piena implementazione di un modello Cloud (inizialmente) on prem. Da dove deriva questa affermazione? Implementare una soluzione cloud significa, primariamente, fornire alla componente applicativa quei margini di manovra che rendano il deployment applicativo indipendente dalla infrastruttura sottostante o quantomeno rendendo in vincolari i legami tra le due. In questo contesto la prima pietra della capacità di offrire soluzioni ibride è la soluzione onprem e il suo sistema operativo Purity. Grazie alla agilità di Purity, Pure Storage,  ha potuto presentare la prima soluzione che permettesse l’implementazione di soluzioni Cloud Ibride ossia il Cloud Block Store. Realmente la soluzione si presenta come una soluzione Multi-cloud ossia permette a chi la utilizza di rendersi indipendente dai vincoli e dalle differenze tra cloud provider permettendo di uniformare criteri di capacity planning, di sizing, di capacità richieste e soprattutto di uniformare criteri di DR e BC. Il 2020 per Pure, è l’anno del compimento della strategia Multi-Cloud con adozione della soluzione CBS anche per altri primary Cloud come Azure. Qui potete trovare notizie sulla nostra technical preview.

Conclusione

E’ cavillare cercare di chiarirsi le strategie tra ibrido e multi-cloud? Per noi non lo è affatto. Non sono ovviamente argomenti in contrapposizione ma è necessario, a nostro avviso, indirizzare queste due strategie insieme ma avendo ben chiaro le differenze e le possibilità. La prima per cercare l’efficacia della soluzione la seconda per implementare criteri di efficienza (ad esempio economica) necessari per entrare in ottica di uso Enterprise del cloud stesso. Avere una soluzione ibrida in piedi non significa avere i gradi di libertà di una soluzione multi-cloud, allo stesso tempo essere in grado di cambiare il fornitore cloud, mantenendo inalterato il servizio (ossia essere multi-cloud) non significa avere soluzioni ibride in cui le componenti collaborino tra loro.

Leggi l’articolo su Bitmat: https://www.bitmat.it/blog/news/98137/hybrid-vs-multi-cloud-ha-senso-cavillare

Alfredo Nulli

ALFREDO NULLI // EMEA Office of CTO | Pure Storage

E: alfredo.nulli@purestorage.com | Tw: @alfcloud