Il cloud muove un giro di affari considerevole a livello globale. L’azienda che per rendite annuali (si prevono oltre 10 miliardi a fine 2016) è ai vertici del mercato è ben nota a tutti, Amazon Web Services o AWS, pioniere del settore che scommettè sulla nuvola nel “lontano” 2006. E fin dall’inizio i vertici AWS furono abbastanza chiari: il termine “cloud” era esclusivamente sinonimo di “cloud pubblico”, linea di pensiero accettata anche da altri provider giunti successivamente sulla scena (es: Google).
Negli ultimi tempi sembra tuttavia essere emerso un nuovo trend, quello di rendere disponibili delle versioni private (quindi in locale ed utilizzabili nell’infrastruttura proprietaria del cliente) delle piattaforme cloud pubbliche. Microsoft è stata la prima a captare l’inedita tendenza annunciando Azure Stack, una variante in miniatura dell’hardware e software di Azure con le medesime qualità di quest’ultima – inzialmente prevista per l’ultimo trimestre 2016 ed in concomitanza con Windows Server 2016, è stata posticipata al 2017. Google sta invece pianificando futuri aggiornamenti al cluster controller di Kubernetes, al fine di implementare OpenStack ed altri componenti. AWS non ha ancora annunciato niente ma le voci riguardanti il lancio di un fantomatico “AWS on premise” sono insistenti.
Quali requisiti per una piattaforma in “miniatura”
Creare una versione privata di una piattaforma cloud pubblica non è facile come sembra: occorre prima di tutto riadattare un’infrastruttura in grado di scalare su region multiple, data center e milioni di server ad un ben più circoscritto scenario caratterizzato da poche migliaia o al massimo decine di migliaia di macchine, preservando inoltre la flessibilità e l’economicità della soluzione di riferimento. Nel caso di AWS ed in generale, i provider dovranno infatti fornire una soluzione che sia allo stesso più conveniente di un’infrastruttura proprietaria ma più costosa della piattaforma cloud pubblica d’ispirazione.
Le region e le availability zone sono alla base dell’infrastruttura AWS. Ogni region è completamente autonoma e dispone di un numero variabile di availability zone. Queste ultime sono indipendenti tra loro ma collegate da connessioni a bassa latenza – Fonte AWS
Bisogna poi considerare l’importante investimento da effettuare per il mantenimento dell’intero sistema che andrà a supportare il nuovo prodotto: dalla catena di rifornimento dei componenti hardware fino al reparto logistico necessario per la consegna dei sistemi certificati – è probabile che il modello seguito da AWS ed altri sarà simile a quello Microsoft, ovvero il rendere disponibile la piattaforma privata solo su sistemi testati ed assemblati da una lista di partner ufficiali. Ed attualmente AWS sembra l’unica a disporre di tutti i requisiti grazie ad Amazon, il famoso portale di ecommerce.
La prossima fase
Secondo alcuni esperti, le versioni private delle piattaforme cloud sarebbero in realtà un modo per accelerare il passaggio delle aziende nel pubblico. Una volta che i clienti avranno le proprie versioni on premise (di AWS, Azure etc.), sarà molto più facile convincerli al grande passo. Ora non resta che capire se le aziende si orienteranno effettivamente verso questa soluzione. Dagli ultimi trimestri finanziari appare evidente che i big del settore continuano a crescere senza sosta: quale sarà la prossima fase di mercato? Buona parte del successo dipenderà dall’accoglienza che le imprese riserveranno alla versioni “in miniatura” di Azure, Google Cloud Platform etc. e dalla convenienza (prezzo/prestazioni) di scegliere un modello “cross cloud” piuttosto che “ibrido”.
Quote di mercato e rendite dei principali provider nel secondo trimestre 2016
Nel caso in cui AWS lanciasse effettivamente una versione privata della propria piattaforma, ciò costituirebbe una risposta quasi certa alla domanda che ci siamo posti alcune righe prima. Gli esperti pensano tuttavia che sul lungo periodo le soluzioni ibride potrebbero costituire un problema per i sostenitori del cloud pubblico: la concezione stessa di ibrido potrebbe infatti mutare passando dall’attuale “esecuzione dei workload su ambienti interni ed esterni” ad un’idea più “cross cloud” e quindi di “esecuzione dei workload su più tipologie di cloud”.
