KNOWLEDGE BASE

Knowledge Base
1Backup
Acronis
Antivirus
Email
Firewall
GFI Software
Mail
Monitoring
N-Able
Sicurezza
TSPlus
Diventa Autore per CoreTech | Scopri di più

Vai al Video

Cloud o non Cloud? Che soluzione è meglio?

La crescente diffusione del Cloud computing pone gli operatori IT delle aziende e in generale chi utilizza infrastrutture IT di fronte al dilemma del valutare se proseguire sulla strada del “tutto on site” o se in effetti la virtualizzazione dell’infrastruttura IT potrebbe essere la strada futura e quindi se sia il caso di passare dall’on-premise al Cloud, passando per le soluzioni di Cloud ibrido.

Per aiutarvi a schiarire le idee, in questo tutoriakl ndremo a introdurre il concetto di Cloud a livello tecnologico, passando da quello che attualmente si trova on-premises fino ad arrivare proprio alle tecnologie Cloud ed al modo in cui possiamo mettere in Cloud ciò che è on-premise, magari su una scala molto più ridotta rispetto a ciò che è già disponibile all'interno dei grandi Cloud Provider.

Spiegheremo anche le strutture ibride (ossia l’estensione dell’infrastruttura di “casa nostra” su Cloud mantenendo entrambe) e di quello che può essere identificato come il momento più critico all’interno di un'azienda, che è quello in cui si decide di passare da on-premise a Cloud e viceversa.

Cloud computing: le basi di valutazione

Vediamo innanzitutto gli elementi da tenere in considerazione per partire con quello che è il pensiero “cloud-oriented” che sono sicuramente i requisiti tecnici: CPU, memoria, storage e networking. Questi sono i quattro elementi attorno ai quali orbitano tutte le infrastrutture. Con riferimento all’immagine seguente, vediamo che la virtualizzazione teorizza quattro livelli di astrazione: dal primo, che è quello più vicino alla realtà fisica, al 4, che è il più astratto.

Nel primo livello di astrazione si va a virtualizzare e quindi ad astrarre la risorsa computazionale, che non è quindi fisica ma virtuale; si va anche a delineare le due configurazioni di flusso dei dati, che sono Nord-Sud - Est-Ovest. Questo è un modo di rappresentare il nostro nostro Data Center secondo il percorso del traffico dati: Est-Ovest sarebbe a dire tra le macchine virtuali e Nord-Sud significa dentro e fuori dalla nostra infrastruttura Cloud.

Altra cosa molto importante del primo livello è il concetto di tiering dello storage, cioè dobbiamo pensare che non esiste solo un gruppo di dischi ma esistono diverse risorse di storage.

Questa riaggregazione di elementi costituisce poi quello che è il secondo livello di astrazione, ossia sia il Virtual Data Center (vDC); ciò significa che possiamo comporre diverse configurazioni formate da varie potenze computazionali, diverse performance di storage (soprattutto in termini di I/O PS) e anche diversi livelli di security networking (possiamo garantire sia Est-Ovest che Nord-Sud). Quindi aggreghiamo tali elementi e con essi costruiamo un tiering lato Virtual Data Center.

Da qui possiamo definire la performance e anche cominciare a introdurre concetti di Integration e  Automation, nel senso che possiamo automatizzare queste infrastrutture, perché una volta che astraiamo dall’hardware al software si tratta di operare su un pezzo di codice e questo, come tale, può essere mantenuto come se fosse un codice. Possiamo quindi affermare che abbiamo a che fare con un Software-Defined Data Center (SDDC).

Non a caso nel terzo livello troviamo il discorso dei container, del database è ancora Integration e Automation che vengono riportati a un livello più “platform”.

Il quarto livello di astrazione è quello del servizio, ossia in Cloud possiamo avere diversi servizi che sono a loro volta aggregazioni di più elementi presenti nella piattaforma; tradotto in pratica significa che non solo l’infrastruttura IT (IaaS) e la piattaforma (PaaS) sono astratte, ma che anche i software applicativi possono essere fruiti da Cloud come servizio 

Dal fisico al Software-Defined

Altro concetto introdotto siano nell’on-premise che nel Cloud è quello del software-defined: e sta a indicare la possibilità di riarrangiare dell’hardware e delle risorse da software; in pratica, poter combinare risorse fisiche mediante software.

In quest’ambito trovano collocazione tre concetti, il primo dei quali è quello già esposto nella definizione di Virtual Data Center:

  • Software-Defined Data Center; con questo termine commerciale si estendono concetti della virtualizzazione come astrazione, pooling e automazione a tutte le risorse dei data-center e ai servizi correlati, dando vita all’Information Technology as a Service (ItaaS) che sostanzialmente vuol dire fruire di un’infrastruttura (come peraltro potrebbe essere fatto on-premise) virtualizzata in maniera modulare;
  • Software-defined storage (SDS); questo termine indica la fornitura e gestione da software di storage indipendente dall’hardware sottostante;
  • Software-Defined Networking (SDN); è un approccio al Cloud che facilita la gestione della rete e consente una configurazione di rete programmaticamente efficiente al fine di migliorare le prestazioni e il monitoraggio della rete

Software designed è quindi il risultato del livello di astrazione: se possiamo combinare le risorse hardware mediante un codice che può ridefinire queste risorse, allora siamo nel mondo del software defined.

 

Una tale configurazione implica problemi di storage e di switch, perché all’aumentare dei server aumenta la richiesta di risorse; per quanto riguarda gli switch, in realtà sono un simbolo che nello schema indica tutti i livelli di networking, compresa la sicurezza. Quindi immaginate che al posto degli switch ci sia un capiente firewall: aumentando il numero di server (nel vaso della virtualizzazione, di VM) aumenta la superficie totale attaccabile dalla rete e bisogna adottare tecnologie di protezione, la cui consistenza e il cui costo non crescono in maniera lineare, ma a gradini. Si arriva perciò a un limite di potenza superato il quale bisogna decidere se non crescere più o se affrontare i costi del caso.

Questo concetto di crescita non lineare è valido soprattutto per le architetture tradizionali; oggi sono alcuni sistemi storage che comunque hanno un modello di crescita lineare.

L’ultimo ritrovato (anche se già da diversi anni se ne parla) è il Software Defined Storage già esposto: riferendosi alla prima configurazione, i server erano privi di dischi perché avevano uno storage centrale che li serviva e questo garantiva un livello di resilienza tale da fare progetti di Disaster Recovery e quant’altro.

Oggi c’è una tendenza a rivalutare il disco rigido con l’introduzione dei sistemi software defined storage, dove abbiamo ripreso i dischi, li abbiamo messi a fattore comune e abbiamo costruito un’intera risorsa che oltre a scalare le componenti di CPU e di memoria, scala anche quella di storage in maniera lineare; quindi stiamo approcciando al discorso di crescita lineare e qui apriamo al concetto di iperconvergenza (hyperconvergence, disegno centrale della figura precedente) dove lo storage “affonda” all’interno dell’infrastruttura fisica, ma con un livello di astrazione virtuale viene messo a disposizione di tutti i sistemi.

Aziende come Nutanix, HPE simplivity piuttosto che Dell e la stessa VMware con Vsan, aprono al mercato di questo tipo; in pratica si prende un server “commodity”, gli si astraggono tutte le componenti e a questo punto anche lo storage diventa una componente virtuale che può essere redistribuita e rimappata.

Quanto al livello di networking e degli switch, oggi si applica il concetto di software define networking, ossia non abbiamo una catena di switch ma siccome cambiano le topologie e le esigenze, tanto che più si cresce più aumenta il livello di banda da gestire: al crescere delle macchine virtuali, avete idea di quanto traffico si genera tra server e server fisico, ma anche che problemi si creano a livello di verifica che il traffico sia pulito e sicuro? Questo è materia dell’SDN, che tramite l’overlay astrae e va a prelevare un pezzo di potenza computazionale da ogni server e lo mette a disposizione di quelle che sono le esigenze di sicurezza dell’infrastruttura. Quindi se è vero che un anti-malware necessita di potenza computazionale, anziché comprare un grosso firewall ridistribuiamo le risorse firewall direttamente server per server. 

Quindi l’insieme di SDS, SDN e SDC crea un Building Block Data Center che vuol dire avere una crescita lineare di costi e risorse all’aumentare delle esigenze.

Il discorso fatto sinora è molto importante, perché ancor prima di decidere di andare in Cloud bisogna valutare se abbiamo la tecnologia che può supportarci, ossia dobbiamo imparare a entrare in Cloud in maniera consapevole, che sarebbe a dire entriamo, scegliamo ed evitiamo soprattutto di entrare in quello che in gergo si ama lock-in.

Paradigma As-a-Service e differenze tra On-Premise e Cloud

Infrastruttura, platform e application sono i tre elementi che costituiscono il Cloud Computing e che permettono di utilizzare risorse sotto forma di servizio fruibile secondo una certa tariffazione. Non dimentichiamo che i dipartimenti IT una volta erano un centro di costo e oggi diventano un punto di riferimento per le aziende, perché tramite il paradigma “as a service” si possono finalmente quantificare le risorse per i vari dipartimenti dell’azienda stessa.

Come schematizzato nell’immagine seguente, Cloud è tutto quello che consente di fruire, in maniera distinta o globale, dell’infrastruttura, di una piattaforma di sviluppo e offerta di software, nonché di applicazioni, in ambiente virtualizzato.

Dalla configurazione tradizionale al Building Block Datacenter

Vediamo come sono cambiate le architetture dalla configurazione tradizionale alla cosiddetta building Block Data Center; con riferimento all’immagine seguente, vediamo a sinistra il modello tradizionale, in centro l’Hyperconvergence e a destra il Building Block Datacenter. Il primo è ancora presente in molti Data Center ma è il modello che via-via verrà abbandonato o comunque si tende ad abbandonare; questo perché abbiamo un elevato livello di storage e dei server che lo consumano ed abbiamo una serie di switch.

 

Ma qual è la differenza tra la parte on-premise e la parte Cloud? Beh, il paradigma as a service è uguale, il livello di tecnologie più o meno uguale (poi ogni Cloud Provider ha la sua specificità) ma la cosa importante è capire i dettagli che fanno la differenza e che al netto di tutti i progressi tecnologici fanno scegliere se stare on-premise oppure passare in Cloud.

Sicuramente il primo fattore che fa la differenza è la proprietà dell’infrastruttura, della piattaforma o del software, che esiste nell’on-premise, mentre nel paradigma as a service si affitta ciò che serve: infrastruttura, piattaforma, servizio. Una buona scelta deve tenere conto sia della convenienza economica, sia di cosa accadrebbe se un giorno si decidesse di tornare all’infrastruttura propria e quindi traslocare dal Cloud all’on-premise.

Il secondo fattore è la collocazione e disponibilità dell’infrastruttura Cloud, perché quando si fa un progetto su Cloud può essere importante sapere da quali zone del mondo diventa accessibile; sicuramente Cloud Provider globali come Amazon offrono una copertura worlwide.

I contratti sono il terzo aspetto importante: nella scelta di un Cloud Provider bisogna valutare non solo la tipologia di servizio che ci vendono (dalla semplice VPS al vDC, addirittura allo sviluppo di progetti aziendali) ma anche e soprattutto i concetti di SLA e di assistenza, ossia la differenza da chi vi fornisce l’infrastruttura e poi dovete occuparvi di tutto il resto e chi invece vi presta assistenza tecnica continuativa, trasparenza ecc. In questo contesto rientrano le garanzie e le penali applicabili al provider in caso di mancato rispetto del contratto, perché magari lo SLA senza le penali è un po’ ' debole e poi vediamo in che termini sono queste penali. Molto importante è la exit strategy, ossia in caso di disservizio da parte del provider qual è la exit strategy che per trasparenza questo ci viene a comunicare.

Quarto aspetto rilevante è il licensing perché cambia dall’on-premise al Cloud: nel primo caso si acquisisce la licenza di utilizzo del software applicativo, mentre nel secondo caso quest’onere non c’è più, perché se lo accolla chi fornisce il Software as a Service. Però visto nell’ottica della migrazione dall’on-premise al Cloud, significa che nel momento in cui si migra non ci si può portare dietro le licenze esistenti né queste hanno più valore, perché ciascuna licenza è concessa per una determinata applicazione e sicuramente quella di un server di proprietà non vale su un’infrastruttura virtuale.

Il Cloud Provider ha un proprio licensing con delle regole che deve rendere note. Prendiamo l’esempio di VMware: se abbiamo una licenza per un’infrastruttura on-premise non possiamo trasferirla nel Cloud Provider, a meno che quest’ultimo non si limiti a fornire il cosiddetto Bare Metal ossia un server cloud dedicato a voi; in tale evenienza le licenze possono essere trasportate perché i server sono formalmente nostri.

Invece se traslochiamo verso un provider che ha già un suo livello di licensing, queste licenze riprendono il paradigma as a service, quindi le paghiamo a consumo, il che da un lato è un notevole vantaggio perché paghiamo solo quando “accendiamo” le macchine virtuali. Pensate a una licenza di tipo Enterprise Microsoft, cui si passa se si supera un certo numero di server perché è più conveniente a livello di costi. Ad ogni modo la cosa importante da considerare è come affrontare il problema della cosiddetta macchina in più: se abbiamo una macchina virtuale Microsoft non stiamo a comprare la licenza Microsoft, perché andiamo in cloud e il provider la comprende dentro il costo mensile, il che per certi versi può essere più conveniente.

Oracle è tutto un discorso a parte, nel senso che eroga qualcosa di as a service solo se entrate nei suoi Data Center; poi Oracle ha anche degli altri modelli di licensing che forse possono aiutare un po’ nella scelta del Cloud Provider.

Problematiche relative a connettività e costi

La connettività disponibile è determinante nella scelta di andare o no in Cloud, perché l’Italia non è tutta “cablata e connessa” come si potrebbe credere e non tutta la connettività disponibile fornisce le stesse prestazioni; senza una connettività all’altezza non c’è Cloud, perché avere la potenza e la velocità di infrastrutture virtualizzate in Cloud se disponete di una connessione lenta o discontinua non serve.

Sicuramente ci sono delle tecnologie che permettono l’applicazione di algoritmi di compressione con cui è possibile migliorare i limiti di una connessione lenta, ma la situazione va valutata attentamente: non pensate di accedere in Cloud con un’ADSL da 8 Mbps come accedereste a un server “in casa” con una LAN Gigabit.

Altro dettaglio da tenere in considerazione è che una singola connettività potrebbe non essere sufficiente: conviene disporre di almeno due linee e, perché no, di due operatori differenti e magari su due mezzi differenti, come ad esempio una cablata e una wireless (WiMax) o cellulare HSDPA/LTE. Questo perché se avete tutto in Cloud e la vostra unica connessione va giù, non potete più lavorare.

Non da meno è la sicurezza, ossia l’eventuale crittografia dei dati, perché non si può pensare di scambiare o tenere dati nel Cloud: tutto quello che entra esce dal Cloud deve essere sicuro, sia perché c’è di mezzo una connessione che può essere violata, sia per il fatto che l’infrastruttura non l’avete fisicamente sotto controllo.

Passiamo al problema dei costi da affrontare quando si va nel Cloud, perchè esistono forme di tariffazione e tipologie di offerta; per esempio tendiamo a dare per scontato che il provider che ci fornisce l’infrastruttura ci dà inclusa la connettività, ma non è sempre così (Connection Usage). Soprattutto dipende da quello che è il vostro workload e dal tipo di connessione; l’esempio di Amazon può chiarire il concetto: se bisogna fare una replica interregion e occorre utilizzare due region differenti di Amazon, il traffico interregion vi costa a parte, ossia il resto è compreso nel prezzo ma magari quello tra region non è compreso. Quindi leggete bene il contratto.

In definitiva, un fattore determinante nella scelta di un provider Cloud è come viene tariffato il servizio offerto: a traffico, a tempo, a storage occupato, a risorse assegnate (Computing Usage), a servizio (Service Usage) e via di seguito. Nel costo dello storage va distinto anche a cosa si riferisce, ossia allo spazio e/o all’utilizzo (Storage Usage) perché in quest’ultimo caso va notato che alcuni provider fanno distinzione fra storage caldo e storage freddo: il primo è lo storage ad accesso continuo, lineare e frequente, contraddistinto da un diverso livello di I/O al secondo (quindi dev’essere esclusivo e garantito), mentre lo storage freddo è considerato quello dove si vanno a depositare i dati del cliente e dove l’accesso ai dati non è così fondamentale, critico e comunque è a lungo termine (a livello di archivio).

Perché scegliere il Cloud, i fattori che influenzano la tipologia di Cloud

Facciamo un po’ una carrellata sui Cloud Provider e sulle ragioni che spingono ad andare in Cloud, le quali sono essenzialmente:

  • possibilità di sfruttare opportunità offerte dalle relative tecnologie;
  • miglioramento dei costi, inteso come ottimizzazione ma non sempre il passaggio in Cloud costa di meno;
  • passaggio dal modello CAPEX a quello OPEX, ovvero dal sostenere costi in asset a quelli garantire l’operatività;
  • vantaggi derivanti dal modello di licensing;
  • l’availability (sappiamo che i servizi sono globalmente distribuiti dai grandi provider);
  • la scalabilità in funzione del workload;
  • la possibilità di realizzare configurazioni ibride (ossia una parte in casa e una su Cloud);
  • integrazione di Cloud multipli;
  • riduzione del time to market, ossia dei tempi di avviamento dell’infrastruttura.

Ovviamente esistono anche fattori che influenzano la scelta del Cloud Provider cui affidarsi:

  • la sede del Data Center di appoggio;
  • le regolamentazioni;
  • la disponibilità dei dati (availability) e le zone (MAR e TTR);
  • le certificazioni (quantomeno dev’esserci la ISO 27001) e il tiering del Data Center di appoggio (se c’è anche quella di Uptime Institute è meglio);
  • policy di sicurezza adottate.

Riguardo alle location dei Data Center, occorre verificare dove andiamo ad appoggiare i dati e questo sia per ragioni di sicurezza, sia perché ogni nazione può avere una normativa differente riguardo alla tutela dei dati, alle politiche di sicurezza ecc.

Le policy di sicurezza sono sostanzialmente il modo in cui il provider cura la sicurezza interna e dipendono da molti fattori, uno dei quali è la nazione (con le sue regole) in cui si trova il Data Center di appoggio del Cloud Provider; un altro è la proprietà o meno dei Data Center, perché chi ne ha di propri impone regole stringenti e ferree di accesso (ad esempio su Amazon addirittura a volte non entra neanche il personale e comunque i guest non entrano mai) nonché controlla quali siti e infrastrutture sono ospitati, così da evitare che, magari, un attacco informatico portato o nato in una sezione si propaghi all’intero Cloud.

Esistono poi i Gold Cloud Provider che offrono all’utente un servizio molto più accurato, hanno meno workload e minore potenza, ma una capacità progettuale molto più alta.

Vediamo ora, con l’aiuto dell’immagine seguente, sulla base del tipo di azienda quali sono state le scelte nel passato e un po’ nel presente, che oggi si ripercuotono un nelle Diciamo che un po' definiscono le vie che hanno adottato un po’ nella storia.

 

Se parliamo di una startup questa nasce nel Cloud, perché mancando il denaro è più conveniente affittare un’infrastruttura IT e piattaforme o applicativi con la formula as a service piuttosto che comperarla, mantenere i locali dove metterla ecc. Anzi, segnaliamo che sono spesso i Cloud Provider che finanziano le startup.

I Solution Provider sono molto più spostati verso l’on-premise, mentre i Gold Service Provider sono a metà, perché hanno infrastrutture loro ma questo non toglie che per alcuni progetti essi possano scalare in Cloud prendendo altre vie, anche senza che la clientela ne sia a conoscenza: per esempio se le risorse computazionali di cui dispone divengono insufficienti e non può incrementare le proprie, scala su un altro Cloud pubblico, quindi a questo punto aumenta la potenza e dà un servizio migliore, però attinge a soluzioni esterne.

Le Mid sized Enterprises spesso sono portate all’on-premise, ma molte aziende enterprise stanno facendo anche loro il passaggio (scale-out) in Cloud: pensiamo anche a delle Energy Solutions che ultimamente stanno abbracciando un po’ il paradigma del Cloud.

I grandi Service Provider sono spostati sull’on-premise, mentre un settore che fino all’altro giorno era completamente on-premise, via-via si sta spostando su Cloud pubblico.

Passiamo ora ad un aspetto molto importante che è quello delle decisioni che spingono ad andare in Cloud, le quali abbiamo schematizzato nel workflow proposto dall’immagine seguente.

Le motivazioni principali sono la riduzione dei costi e l’aumento delle performance, perché quando il workload cresce, la prima soluzione sembra essere entrare nel Cloud; ma poi arriviamo al punto che il workload cresce al punto tale che raggiunge il punto di Break Even che risulta dal

calcolo di quando si spende andando in Cloud e quanto invece si spenderebbe a restare on-premise

avrei speso stare in casa. Ebbene, il punto è in corrispondenza del pareggio dei costi e quando i primi divengono inferiori ai secondi conviene passare al Cloud. Se invece il Cloud non porta a una riduzione dei costi bisogna pensare al ritorno dell’infrastruttura “in casa” e quindi bisogna essere pronti a fare il cosiddetto “lift and shift” (letteralmente, sollevare e spostare), ossia riprendere il workload in casa.

Un altro fattore che può spingere a decidere per il ritorno on-premise di ciò che era stato trasportato su Cloud è rappresentato dalle SLA and Regulations: ad esempio se il provider non garantisce le richieste policy di sicurezza, piuttosto che se certe normative impongono di avere una location ben determinata dei dati e il Cloud Provider non lo permette, non resta altro da fare che restare on-premise.

Panoramica sui Cloud Provider: Amazon Web Services

A questo punto può essere interessante fare una carrellata sui principali Cloud Provider a partire da uno dei punti di riferimento del mercato che è Amazon (AWS=Amazon Web Services) la quale offre un ampio portafoglio di soluzioni che vanno dal Bare Metal fino alle AWS Lambda che sarebbero sostanzialmente delle funzioni a servizio; ovviamente questo va un po’ ridurre quella che è la quota di cose gestite dall’utente e ad aumentare quelle gestite da Amazon.

L’immagine seguente schematizza l’offerta di Amazon e la relativa struttura con i vari livelli di astrazione.

Amazon offre, come altri provider che vedremo, una formula di prova gratuita dei loro prodotti (Try and buy) e nel caso specifico, la relativa pagina web è https://aws.amazon.com/it/free/.

Google Cloud platform

Con le Google Cloud platform Google è entrata in un meccanismo Cloud orientato soprattutto alle parti di applicazioni e piattaforme; solo recentemente si è estesa al computing, ma soprattutto orientato a quello che è l’ambito dei container, quindi non è proprio computing in senso stretto ma più che altro rientra nel concetto di PaaS, ossia quello che sono le Platform as a Service. Anche Google consente di testare le offerte prima dell’acquisto, visitando la pagina web https://cloud.google.com/free/. L’immagine seguente riepiloga i servizi offerti da Google Cloud Platform.

 

Microsoft Azure

Microsoft con la sua piattaforma Cloud Azure offre una serie di prodotti, anche qui disponibili con la formula Try and buy che vi permette di capire se questo Cloud Provider può supportare i vostri progetti (https://azure.microsoft.com/it-it/free/). Le free trial, pur non fornendo elevate performance consentono di valutare le possibilità offerte dai servizi. Ampia documentazione sui prodotti e le soluzioni offerte da Microsoft può essere trovata su https://azure.microsoft.com/it-it/free/ https://docs.microsoft.com/en-in/azure/#pivot=get-started. L’immagine seguente propone un riassunto di Amazon Azure, da cui vediamo che sono supportati sia Platform as a Service che Infrastructure as a Service in Datacenter divisi in Region.

IBM Cloud

Quella di IBM è una storia atipica, perché era cominciata ancora con il vecchio mainframe, l’infrastruttura on-premise, D7000, infrastrutture power e poi all’improvviso ha fatto un grosso passo avanti saltando una generazione; grazie alla virtualizzazione, soprattutto grazie a VMware ma non solo, grazie anche alle diverse tecnologie che hanno permesso di astrarre anche il livello applicativo, IBM Cloud oggi ha un’offerta molto interessante sia a livello IaaS che a livello PaaS (https://cloud.ibm.com/catalog).

Cloud provider basati su VMware

Molto interessanti, alla fine di questa rassegna, sono i cosiddetti Vsphere Based Cloud Provider che sono molto utili a chi ha già un’infrastruttura virtualizzata in casa basata su VMware; in questo caso la scelta più logica e sensata è quella di avere un Cloud Provider basato su Vsphere (l’immagine seguente schematizza l’ambiente) i cui vantaggi verranno spiegati più avanti in questo stesso tutorial.

Concetti fondanti del cloud ibrido

La soluzione Hybrid Cloud  è quella che consente di superare tutti gli ostacoli e che permette di soddisfare la maggior parte delle esigenze, perché consiste nel tenere una parte on-premise e una parte dell’infrastruttura IT su Cloud. Il Cloud ibrido fondamentalmente si basa su tre cardini:

  • disaster recovery, cioè il Cloud offre l’opportunità di avere un piano di disaster recovery del proprio Data Center senza comprare un altro Data Center;
  • Scale-out (scalabilità) ossia nel momento in cui si verificasse un picco nel traffico della propria infrastruttura on-premise c’è la possibilità di estendere il carico computazionale del Data Center verso un public Cloud;
  • integrazioni, quindi in alcuni casi infrastrutture o interi progetti che partono con workload nel Data Center di casa e arrivano a consumare delle risorse Cloud; per esempio nelle applicazioni di Intelligenza Artificiale e Machine Learning, dove i costi per le risorse sarebbero poco sostenibili, il Cloud può aiutare perché permette di affittare ciò che serve al momento.

Nell’immagine seguente vediamo un esempio di Hybrid Cloud che si basa sul fatto che l’infrastruttura locale deve trovare un corrispondente, a livello di tecnologia, nel Cloud, quindi se disponete on-premise di una macchina virtuale modello blackbox e quindi se avere un workload di questo tipo e tale che non potete entrare nel merito del  contenuto, sicuramente la strada obbligata consiste nell’avere una soluzione a pari tecnologia.

Quindi se “in casa” avete VMware dovete andare su VMware, così come se avete macchine virtuali Hyper-V dovete andare su Cloud Microsoft Azure, perché è necessario fare un movimento 1:1 del relativo workload. In sostanza, se non potete entrare nel merito, la tecnologia delle macchine in casa e del Cloud devono essere simili.

Invece se è possibile entrare nel merito e riusciamo a trovare un livello di separazione tra il livello operativo di ogni singola macchina virtuale e il livello applicativo, possiamo costruire forme ibride ancora più “spinte”: parte dell’infrastruttura di casa si può conservarla e si può avere dei Cross-Cloud con tecnologie differenti, fermo restando che bisogna essere certi di capire come convertire un workload da un’infrastruttura all’'altra.

Salendo di livello, quindi a livello un po’ più “platform” (per esempio la parte dei container) e quindi PaaS, quello che abbiamo in casa si può scalare in Cloud in maniera abbastanza tranquilla, se dall’altra parte (Cloud) vi sono dei sistemi che già accolgono tale workload e così vale anche per il livello applicativo (SaaS).

Scenario IoT, infrastrutture ed estensioni su piattaforme Cloud

Uno scenario molto interessante è quello dell’Internet delle cose (IoT) che è un po’ entrata nel mercato come la tecnologia che permette di affacciare al Cloud e all’IT il mondo comune, quindi tutto quello che può essere la vita di tutti i giorni, e ai processi comuni; una delle problematiche che l’IoT implica è che spesso ha bisogno di un cosiddetto Edge Data Center, che sostanzialmente è un  nodo di Edge Computing dove vengono raccolti i dati dei sensori e compattati prima di essere inviati all’elaborazione in Cloud. Questa forma di pre-elaborazione serve a ridurre il traffico di rete e ad accelerare l’interazione.

A riguardo vi sono più modelli di integrazione tra i diversi Cloud dove il dato viene raccolto e poi successivamente viene analizzato a livello Cloud, come mostra l’immagine seguente.

Apriamo ora un discorso sulle estensioni delle piattaforme in Cloud: quando si sceglie un’estensione a livello infrastrutturale bisogna considerare innanzitutto il livello di network, perché se estendiamo un’infrastruttura on-premise su Cloud possiamo scegliere se utilizzare dei network locali oppure, se si ha il supporto della tecnologia giusta (per esempio la software defined networking) possiamo avere qualcosa in più e addirittura avere una rete estesa dall’infrastruttura in casa al provider Cloud senza cambiare IP address, immaginando magari di fare delle vmotion (quindi spostamenti del workload) dall’on-premise al Cloud in maniera trasparente.

Altro aspetto da considerare sono gli storage, che possono essere connessi: per esempio se abbiamo uno storage lato server e uno storage diverso lato Cloud Provider esistono alcune tecnologie che permettono la cosiddetta replica dall’on-premise al Cloud. Per esempio Nimble storage, che è stata tra le prime tecnologie che in AWS ha messo a disposizione una versione virtuale del proprio storage: i due si interconnettono ed ecco materializzarsi uno storage esteso dall’on-premise al Cloud. Non solo, perché anche Microsoft ha una soluzione di questo tipo, seppure molto Azure-oriented.

Un terzo aspetto rilevante ai fini dell’estensione sono le piattaforme virtuali: come già accennato, è opportuno avere la stessa tecnologia di virtualizzazione sia on-premise che in Cloud. Se andiamo sul livello dei container, per esempio, è buona cosa che l’estensione della piattaforma basata su container dell’infrastruttura IT in casa trovi dall’altra parte (in Cloud) qualcosa come Kubernetes as a service, con la gestione della relativa complessità operata direttamente all’interno del Cloud Provider; questo aiuterebbe a focalizzare l’attenzione su quella che è l’applicazione, dimenticandosi dell’onere della gestione della virtualizzazione.

L’ultimo aspetto è il cosiddetto livello applicativo e riguarda ad esempio le software house: se abbiamo “in casa” la governance del livello applicativo possiamo proiettarci verso i concetti di serverless, vale a dire consumare le funzioni direttamente all’interno del Cloud Provider oppure chiedere risorse dati in maniera serverless (all’occorrenza, all’evenienza e al consumo).

Estensione infrastruttura on-premise su AWS

Vediamo dunque un esempio di estensione su Cloud Amazon, che può essere quello schematizzato nell’immagine seguente: qui, nell’infrastruttura di casa ci sono un po’ di tecnologie abilitanti, tipo VSan piuttosto che NSX.

Attenzione che in AWS non tutto è AWS, perché comunque ha allestito parti della sua struttura Data Center con tecnologia VMware, per fare in modo da estendere il proprio workload e quindi accendere macchine virtuali in AWS come se fossero in casa, con tanti livelli di integrazione.

L’aspetto interessante è che tramite il concetto di VPC di AWS è possibile integrare anche a livelli più alti, con le loro funzioni, per esempio le Lambda piuttosto che le istanze EC2, piuttosto che la parte di EKS e così via.

Estensione infrastruttura on-premise su IBM Cloud

Con IBM Cloud è come giocare in casa, perché le tecnologie sono simili e non solo, in quanto anche IBM Cloud ha un’offerta a livello platform ed una parte abilitata alle funzioni, con la sua parte Function as a Service (immagine seguente).

È anche possibile fare un misto di tecnologie di virtualizzazione. Ovviamente realizzare un ibrido multiCloud potrebbe essere interessante, per esempio, quando vogliamo estendere l’infrastruttura locale ma allo stesso tempo magari scalare e integrare la parte platform; questo dipende fondamentalmente dalle applicazioni coinvolte, perché è l’applicazione a dettare la scelta.

Per esempio possiamo decidere se tenere l’applicazione a livello macchina virtuale, quindi andare a scalare in maniera infrastrutturale, oppure se giocarci la carta (soprattutto nelle applicazioni di ultima generazione) dei container e magari scalarle in Cloud e andare a usare le funzioni (immagine seguente).

L’importanza di conoscere la propria struttura

Prima di valutare il passaggio in Cloud è necessario conoscere la propria infrastruttura, ossia capire qual è lo stato di partenza; solo così è possibile valutare quanto costa allestire un’infrastruttura on-premise e quanto costerebbe avere il workload in Cloud.

Prima di tutto è opportuno fare un assesment che consideri non tanto il costo per macchina ma anche dove sono collocati i Data Center, come vengono popolati i CMDB, Capex e Opex, il costo in termini di Data Center e facility, il costo in personale e consulenza e il fatto che il movimento di alcune macchine potrebbe essere vincolato anche da rapporti consulenziali che avete con terze parti.

Quindi prima di muovere una macchina occorre valutare tutta una serie di cose.

È inoltre importante raggruppare i sistemi per applicazioni, ossia verificare come cade l’applicazione rispetto alle macchine, perché magari ci sono macchine condivise tra più applicazioni e quando spostiamo una macchina critica su cui abbiamo un’altra applicazione, questa applicazione smette di funzionare quando arriva nel Cloud.

Altro punto determinante è calcolare o stimare i rischi e l’impatto sul business durante lo spostamento dall’on-premise al Cloud, i tempi di fermo e i problemi che potrebbero derivare, tipo un’applicazione che non funziona o va aggiornata, dei dati che non sono trasferibili ecc.

Occorre poi porsi la domanda di cosa accadrebbe se il sistema fosse non disponibile per varie ragioni (connettività caduta, provider costretto a un arresto) perché anche un provider grande come Amazon ha subito due grossi fermi nella sua storia e ne trovate documentazione proprio sul portale di amazon AWS.

E bisogna anche chiedersi cosa accadrebbe se i dati andasserro perduti e in caso di incidente SEC.

Quindi è necessario sapere come il provider conduce il Disaster Recovery, tenendo presente che nell’IaaS il Disaster recovery è un qualcosa che va in carico all’azienda cliente e non al Cloud Provider, ovvero se acquistiamo dei servizi in Cloud il provider è tenuto a salvaguardare dati e applicazioni, ma se affittiamo delle infrastrutture il provider potrebbe non essere tenuto a provvedere al Disaster recovery: dipende dal contratto.

In quest’ottica si colloca la verifica del Time to Recovery (TTR) e del Monthly Availability Report (MAR) che il provider deve rendere noti.

Cosa portare dall’on-premise al Cloud

Vediamo cosa è possibile migrare dall’infrastruttura in casa al Cloud: sicuramente applicazioni vecchie, a patto che il deploy avvenga con metodi tradizionali oppure siano modernizzate; attenzione che le vecchie applicazioni spesso significano che avete nel Data Center storage, computin e networking in un armadio, quindi la migrazione può essere insidiosa.

Altro che è possibile migrare sono sicuramente e-mail, Web Application Server, Internet Services,  applicazioni VM centric (ossia sviluppate su macchine virtuali), IaaS simple migration (export-import), IaaS near-zero downtime migration (solo ibrido) ma anche le applicazioni di nuova generazione che sono nativamente Cloud ma possono essere portate on-premise.

 

Ciò che non dovrebbe, invece, essere spostato sono sicuramente i workload che devono rimanere locali, soprattutto quelli di governance; è difficile mettere in Cloud per esempio Local Active Directory perché potrebbe non essere quello centrale ma quello periferico e come tale non si va a mettere in Cloud. Ancora, alcuni file-server condivisi, le applicazioni critiche o che hanno dipendenza dalla parte fisica, perché ovviamente quando entra in Cloud l’applicazione viene virtualizzata e non si può virtualizzare, ad esempio, un Fax Server, a meno di non avere dei “connettori”.

La tecnologia Lift and Shift

Per le ragioni esposte in precedenza, non è detto che quando si entra in un Cloud Provider ci si rimarrà tutta la vita, quindi occorre sempre riservarsi la possibilità di tornare on-premise.

Sul piano tecnico, per avere la governance piena del proprio workload anche anche quando questo workload è finito in Cloud, occorre sposare delle tecnologie sia in casa che in Cloud che abilitino a decidere quando restare in Cloud e quando andarsene.

Un esempio interessante è rappresentato da tecnologie di backup tipo Cohesity e Rubrik che agiscono sul dato e fanno in modo che una volta fatto il backup di un’infrastruttura on-premise oppure dal Cloud verso qualche infrastruttura on-premise questo diventa un monoblocco di proprietà del cliente, che può essere spostare liberamente tra i diversi Data Center, quindi anche tra il proprio Data Center in casa e i diversi Cloud Provider.

Riassumendo, c’è una vastità di soluzioni Cloud e il Cloud non è una soluzione definitiva. Il passaggio in Cloud può mascherare costi nascosti e non sempre è conveniente, quindi va valutato alla luce di quanto esposto sinore. Inoltre, è sempre opportuno combinare le cose in modo da poter tornare indietro e quindi prima del passaggio è bene verificare la possibilità del lift-and-shift; in quest’ottica bisogna ricordare che il passaggio e la scelta del Cloud dipendono dalle applicazioni da trasportare e utilizzare.