Come gestire i burst nel cloud privato

Per anni, le aziende hanno dimensionato l’infrastruttura sulla base dei carichi di lavoro critici, lasciandola sottoutilizzata per la maggior parte del tempo. Dopo la virtualizzazione questo problema è migliorato, ma è ancora lontano dall’essere risolto. Per questo motivo la gestione di crescite improvvise e non prevedibili nel cloud (cloud bursting) è un argomento che desta grande interesse.

Le cause del cloud bursting

Nessuno vuole pagare in anticipo per l’infrastruttura se non la utilizza al massimo della capacità, soprattutto in questo momento di incertezza economica. Tuttavia, gli stakeholder sono frustrati quando non ci sono risorse sufficienti per soddisfare un picco di richiesta. Le aziende che riescono a costruire la propria infrastruttura con la capacità di gestire in maniera adeguata i picchi di lavoro dovranno investire meno in anticipo e l’importo ottimale durante il loro picco stagionale. Ma se è così semplice, come mai solo una piccola percentuale delle aziende riesce a mettere in pratica questa strategia con successo?

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.

Le sfide relative al cloud bursting

Se si prendono, inoltre, in considerazione le sfide relative alla crescita improvvisa (burst) nel cloud pubblico, è possibile dividerle in due tipologie: operative e finanziarie.

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 workload 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

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;

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. Ma ad oggi questa strada non sembra 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, però, è generalmente limitato dalle sfide operative sopra menzionate.
3. Rendere il 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 private cloud in grado di gestire efficacemente picchi di richiesta

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.

Preferire modelli di “elastic pricing”

Modelli di tipo “elastic pricing” eliminano queste limitazioni del vendor, consentendo ai clienti di espandersi fino al 500% senza dover investire in nuova capacità e permettendo ai clienti di utilizzare il modello che preferiscono, CapEx, OpEx o entrambi contemporaneamente, anche all’interno di un unico sistema. Ciò 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à.