Infinidat Blog

CRESCITE IMPROVVISE (BURST) NEL… CLOUD PRIVATO?

Per anni abbiamo dimensionato la nostra infrastruttura sulla base del periodo critico dell’anno, lasciandola sottoutilizzata per la maggior parte del tempo. Dopo la virtualizzazione questo problema è migliorato, ma lontano dall’essere risolto; per questo
motivo la gestione di crescite improvvise nel cloud (cloud bursting) è stato un argomento che ha destato così grande interesse.

Nessuno vuole pagare in anticipo per l’infrastruttura se non la usa, in particolare in questo momento di incertezza economica. Tuttavia, i tuoi stakeholder sono frustrati quando tu non disponi di risorse sufficienti per soddisfare un picco di richiesta. Inoltre, questa incertezza economica sta causando imprevedibilità. Le aziende che costruiscono con successo la propria infrastruttura con la capacità di gestire i picchi di richiesta quando necessario spenderanno un importo minimo in anticipo e l’importo ottimale durante il loro picco stagionale. Se è così, come mai solo una piccola percentuale delle aziende riesce a metterlo in pratica con successo?

Prima di immergerci

La causa principale di questa sfida è al centro della sua risoluzione:

Tradizionalmente, l’unico modo di costruire un’infrastruttura IT consisteva nel pagare in anticipo per quello che si stimava di aver bisogno a breve termine, accettando che:

  • un sottodimensionamento poteva comportare ritardi nei nuovi progetti
  • un sovradimensionamento poteva aumentare i costi dell’infrastruttura e ridurre il ritorno degli investimenti
  • I modelli di consumo del cloud privato sono più economici, ma mancano dell'elasticità propria del cloud pubblico.

Parliamo delle sfide relative alla crescita improvvisa (burst) nel cloud pubblico:

Sfide operative

Il burst nel cloud richiede che i team operativi siano in grado di mantenere i propri SLA e soddisfare conformità, governance e tutti gli altri requisiti. La combinazione di più infrastrutture cloud crea nuove sfide:

  • Come avere i dati sul cloud, senza interrompere il servizio?
  • Come riportare i dati fuori dal cloud quando il picco è finito?
    La maggior parte dei cloud provider si concentra su strumenti per accelerare il trasferimento dei workloads nel cloud e non per riportali fuori dal cloud.
  • Come mantenere coerenti i backup quando provengono da più fonti?
    Cosa succede se il backup dell'ultima settimana è stato eseguito on premise ed è ora necessario ripristinarlo sul cloud pubblico?
  • Quanto costa riportare i dati on premise?
    Per dataset di grandi dimensioni ciò potrebbe influire sul TCO dell'intero progetto.
  • Quali strumenti di governance sono richiesti? Sono implementati nel cloud pubblico?
  • Quali strumenti di sicurezza sono richiesti, dal momento che viene aumentata la
    “superficie di attacco”?
  • Come si testano soluzioni DR intrinsecamente più complesse?

Alcune di queste sfide operative sono rese più semplici da microservizi che consentono ai clienti di eseguire la stessa applicazione in due posizioni contemporaneamente, ma introducono altre sfide:

  • Come garantire la coerenza dei dati tra piattaforme diverse?
  • Gli strumenti di orchestrazione/automazione variano tra cloud privati e pubblici.
  • Come si controlla quale parte del servizio viene eseguita in ogni location?
    Qual è l'implicazione di ciascuna di tali decisioni sul TCO complessivo?

Sfide finanziarie

Ad ogni evento al quale sono intervenuto (quando ancora era possibile avere un pubblico durante gli eventi), proponevo un sondaggio agli IT manager, con le stesse 3 domande:

  1. State spostando nuove applicazioni sul cloud?
    Tutti alzavano la mano.
  2. Lo state facendo perché vi fa risparmiare denaro?
    Nessuno alzava la mano. Le persone mi guardavano come se fossi impazzito.
  3. Lo state facendo per guadagnare agilità aziendale?
    Di nuovo tutti alzavano la mano e le persone capivano che no, non mi mancava qualche rotella.

A differenza delle PMI, le grandi aziende godono di economie di scala nel loro cloud privato, quindi finiscono per pagare un extra quando si trasferiscono nel cloud pubblico, la cosiddetta "cloud tax" (e non mi soffermerò a parlare di quanto è alta quella tassa: è sufficiente dire che tutti i clienti a cui l’ho chiesto hanno stimato numeri a due cifre).

Quindi le grandi aziende devono affrontare la seguente equazione:

  • Cloud pubblico = più agile, ma costoso.
  • Cloud privato = meno agile, ma economico.

Poiché le grandi aziende hanno bisogno sia di risparmiare che di essere agili, le scelte possibili sono tre:

  1. Rendere il cloud pubblico più economico.
    A meno di non incontrare di persona la fatina dei denti, questa strada non è possibile.
  2. Consumare servizi di cloud ibrido, sfruttando l'agilità del cloud pubblico solo quando è necessario, riducendo quindi al minimo i costi aggiuntivi.
    Questo approccio è generalmente limitato dalle sfide operative sopra menzionate.
  3. Rendere il tuo private cloud in grado di gestire efficacemente picchi di richiesta (burstable).
    Per farlo dobbiamo tornare alla causa principale che ha dato il via a tutto ciò.

Rendere il tuo private cloud in grado di gestire efficacemente picchi di richiesta.

Siamo partiti dalla causa principale del nostro problema: il modello di consumo del cloud privato richiede di dimensionarlo in anticipo, il che significa assumersi il rischio. Ma, proprio come il cloud pubblico può assumersi questo rischio servendo molti clienti, i fornitori di
cloud privato dovrebbero offrire la stessa funzionalità.

Con la componente computazionale virtualizzata/containerizzata è molto facile scalare verso l’alto e la rete non scala con la stessa facilità, quindi nella maggior parte dei casi non è il fattore limitante. È il livello di dati/storage a essere il fattore limitante. La soluzione al burst dello storage risolve di conseguenza il problema finanziario della " cloud tax" ma rimuove anche tutti i problemi tecnici del burst in un cloud pubblico.

Esistono vendor che offrono storage con “cloud bursting” su cloud privato, ma con importanti controindicazioni:

  • È una soluzione costosa e, sostanzialmente, porta la “cloud tax” nel cloud privato.
  • È applicabile solo a una piccola percentuale dello storage.
  • Obbliga il cliente a utilizzare i modelli di consumo OpEx, che non tutti i clienti vogliono/possono usare.
  • Fa affidamento sulla spedizione fisica di nuova capacità in caso di crescita, il che aggiunge spese generali operative così come il rischio di ritardi.

Questi fornitori non riducono realmente il rischio dell'investimento nell’infrastruttura, fanno ricadere il costo del rischio sul cliente, non risolvendo realmente il problema.

Uno storage realmente in grado di gestire i picchi

Il modello “Elastic Pricing” di Infinidat elimina queste limitazioni del vendor, consentendo ai clienti di espandersi fino al 500% senza dover investire in nuova capacità e permette ai clienti di utilizzare il modello che preferiscono, CapEx, OpEx o entrambi contemporaneamente, anche all'interno di un unico sistema. Riduce i costi e consente ai clienti di pagare solo per ciò che utilizzano, evitando una pianificazione inaccurata della capacità. Cosa più importante, non richiede compromessi in termini di prestazioni, affidabilità o disponibilità. Per saperne di più.

Informazioni Eran Brown
Eran Brown is the EMEA CTO at INFINIDAT.
Over the last 14 years, Eran has architected data center solutions for all layers — application, virtualization, networking and most of all, storage. His prior roles include Senior Product Management, systems engineering and consulting roles, working with companies in multiple verticals (financials, oil & gas, telecom, software, and web) and helping them plan, design and deploy scalable infrastructure to support their business applications.