I data center hyperscale (HDC) sono poco più di 500 nel mondo, mentre erano meno di 400 nel 2017, secondo le stime di Synergy Research, concentrati per circa il 40% negli Usa, la maggior parte di proprietà dei grandi cloud provider o dei principali gestori di social come Google, Amazon, Microsoft, IBM, Facebook.
L’interrogativo è se sia possibile per le imprese utilizzare la logica hyperscale per avere vantaggi analoghi, in termini di automazione e ottimizzazione, a quelli dei cloud provider, dando per scontato che il cloud pubblico non potrà sostituire i data center (DC) delle imprese medio-grandi. A questa domanda hanno cercato di rispondere i partecipanti alla tavola rotonda Hyperscale for Enterprises, in occasione di NetEvents Global IT Summit 2019, tenutasi a Saint Jose, nel cuore della Silicon Valley, coordinata e introdotta da Brad Casemore, Research Vice President, Datacenter Networks, IDC.
“Molte imprese, guardando all’infrastruttura dei loro DC, nutrono una sorta di invidia per l’hyperscale. Come soddisfare questa domanda?”, esordisce l’analista IDC, sottolineando come il vero driver del percorso di evoluzione dell’infrastruttura IT che molte imprese hanno intrapreso sia la trasformazione digitale che ha significative implicazioni per l’infrastruttura. “Nei DC sono spesso presenti architetture tradizionali e sorpassate, modelli operazionali che vanno aggiornati: c’è un problema di progettazione, deployment e di sviluppo operativo”, precisa.
È dunque utile capire cosa stia accadendo nel modo del cloud che va visto non solo come una destinazione per i workload aziendali, ma va analizzato nei suoi principi operativi.
Osservando le strutture hyperscale, si può capire come sia possibile realizzare processi di una dimensione e un’agilità senza precedenti e acquisire la capacità di risolvere i problemi in modo rapido ed efficace. In questi DC è stata realizzata una completa automazione anche a livello network, grazie all’adesione pionieristica ai principi del Software Defined Network (SDN), all’adozione di architetture scalabili in modo eccezionalmente efficiente ed efficace, all’utilizzo in modo crescente di real-time analytics e streaming telemetry. Il risultato è l’evoluzione da un approccio reattivo a uno proattivo anche all’interno delle reti, realizzato in parte attraverso le giuste astrazioni e grazie alla disaggregazione così da poter innovare velocemente su uno strato o sull’altro, nel software e nell’hardware, con la possibilità di accelerare la trasformazione.
La tavola rotonda si è interrogata su come trasportare l’hypescale a livello di imprese per poter conseguire analoghi benefici, con una focalizzazione sulle tematiche del networking.
La centralità del networking
È importante la focalizzazione sul networking, secondo Mike Capuano, Chief Marketing Officer, Pluribus Networks, un tema che torna fuori tutte le volte che si cerca di automatizzare un DC: “Mentre ci sono molti progressi nella virtualizzazione e nell’automazione dello storage e del computing, la rete resta il tallone d’Achille”, dice, ricordando che Pluribus, è focalizzata sull’automazione della rete, la sua virtualizzazione e sul controllo SDN, anche in DC di medie dimensioni.
Da parte sua Apstra, pioniere nell’intent-based networking, grazie a un software che si colloca sopra l’infrastruttura di rete, punta a fornire automazione e astrazione sull’intero ciclo di vita dei servizi di rete. Mansour Karam, CEO e Founder, ricorda che le imprese clienti che hanno installato il software Apstra hanno migliorato del 99% l’agilità dell’infrastruttura, del 70% il tempo medio di soluzione dei problemi e del 83% l’efficienza operativa, misurata in termini di ore-uomo necessarie per adempiere a uno specifico compito relativo all’infrastruttura.
“Ci siamo chiesti: possiamo costruire sistemi on-premise non tanto ispirati al public cloud, ma che siano di fatto come il public cloud?”, dice Kyle Forster, Founder, Big Switch Networks, che nasce con il proposito di creare on premise la stessa esperienza che le persone hanno con il cloud.
Differenze fra cloud provider e imprese: focus sull’automazione
Tuttavia trasportare i livelli di automazione e di efficienza di un HPC tipico di un cloud provider nel DC di un’impresa non è scontato. “C’è differenza fra l’hyperscale realizzabile in un’impresa e quello nel cloud: si deve capire come le imprese possano perseguire un diverso modello, che chiameremo l’hyperscale per le masse”, sottolinea Kevin Deierling, Vp Marketing, Mellanox Technologies, spiegando che mentre nelle imprese generalmente si dispone di un protocol stack fornito dal vendor e ci si limita a fare po’ di automazione del monitoraggio, nel cloud, al contrario, si dispone di un ridotto protocol stack ma si fanno tanta automazione e monitoraggio, una differenza da approfondire nella discussione.
“Come fornitori vediamo che gli ambienti delle imprese sono più complessi del public cloud, che ha un certo insieme di applicazioni in qualche modo limitato. Mentre l’ambiente di ciascuna impresa è differente e contiene un mix di applicazioni moderne, spesso cloud native, e ambienti legacy. La sfida è dunque creare un prodotto capace di distillare quei benefici che l’automazione fornisce ai cloud provider”, sostiene Karam. Casemore evidenzia, da parte delle imprese, una domanda di agilità, flessibilità, di affidabilità, di adattabilità che gli hyperscaler hanno nelle loro reti. Ma nonostante le imprese diventino sempre più digitali, molte di esse continuano ad avere asset e prodotti fisici e un mix di applicazioni ben più complesso degli hypersaler del cloud. Il tema è come rendere la logica hyperscale più ‘consumabile’ e più semplice per poterla implementare nel loro ambiente, visto che non hanno grandi team di super-esperti di cui cloud provider dispongono.
Capuano suggerisce di affrontare la sfida confrontando il livello di automazione dei DC delle imprese con quello degli hyperscaler che hanno enormi statistiche IT e quantità di esperti che scrivono codice. “Dobbiamo dunque focalizzarci su come realizzare una SDN. In un DC di grandi dimensioni i server esterni da gestire e i diversi controller per il livello SDN, per il livello di virtualizzazione della rete e gli stack di server per l’analisi della rete di fatto ‘scompaiono’, mentre sono un grosso problema per un DC più piccolo”.
Pluribus Networks punta a sfruttare le risorse presenti in switch sviluppati dai principali vendor, dotati di processori piuttosto potenti, RAM e unità flash al loro interno, realizzando codice distribuito intelligente per eseguire la funzione SDN, la virtualizzazione della rete, l’analisi della rete. L’obiettivo è operare in DC di piccole e medie dimensioni, secondo un’evoluzione da un modello un centralizzato a uno più distribuito, in logica Edge.
Disaccoppiare hardware e software
Deierling torna alla domanda iniziale: come realizzare l’automazione senza essere Google, Amazon o Microsoft? “La chiave sta nell’utilizzo di piattaforme open e nella disaggregazione di hardware e software per evitare il vendor lock, poter scegliere l’hardware migliore e integrare tutto grazie alla nozione di open network”, è la sua risposta. Anche Karam concorda con l’idea di disaccoppiamento e fornisce un consiglio alle imprese in fase di trasformazione dell’infrastruttura: “Non scegliete come partner strategico il vostro fornitore storico che vi ha accompagnato negli ultimi 20 anni”. Suggerisce invece di pensare prima al software poi allo strato di automazione e allo strato che interagisce con le applicazioni business; solo quando tutto questo è definito scegliere l’hardware che certo è critico ma deve essere disaccoppiato dalle scelte sul software.
Una proposta che convince Casemore che conferma: “Abbiamo trovato che l’ambiente delle imprese tradizionali, in termini di reti e DC, ha un ciclo di vita di 5-7 anni, mentre le imprese software driven, tendono ad avere maggiori benefici hardware grazie a un ciclo più veloce”.
Capuano ribadisce il valore del disaccoppiamento, che consente di sfruttare l’innovazione sia sul versante hardware che su quello software che spesso seguono tempi diversi. Evidenzia al tempo stesso il ruolo degli analytics, fondamentali, ad esempio, per evidenziare picchi anomali che possono derivare da attacchi DDoS, che possono essere bloccati in modo automatico. Anche Deierling considera gli analytics indispensabili per evidenziare se sia o meno responsabilità della rete quando accade qualcosa nel DC e le applicazioni hanno scarse performance.
E Casamore conclude ribadendo la centralità del networking ma anche le responsabilità connesse: “In genere il networking team viene biasimato per tutto quello che non funziona”.
