Le linea evolutiva che va dai CED di decenni fa ai data center degli odierni hyperscaler appare chiara. Il filo conduttore è quello della disaggregazione e della elasticità. Si passa dai server monolitici dedicati per una singola applicazione ai nodi che eseguono decine di macchine virtuali spostabili a piacimento tra uno e l'altro. Fino ad arrivare, oggi, a una visione pesantemente basata sulla containerizzazione. Sull'idea che tutte le risorse IT si possono virtualizzare e rendere adattabili alle esigenze che ciascun workload mostra in ogni momento.

Almeno, questo è lo scenario delineato per le infrastrutture dei grandi hyperscaler del cloud pubblico. E che buona parte delle imprese intende fare proprio adottando il "modello cloud". I vantaggi della "cloudificazione" dei data center tradizionali esistono e sono tangibili. Ma puntare a una trasposizione nelle aziende delle scelte degli hyperscaler è solo una strategia di massima. Poi va contestualizzata. Non tutto quello che fanno gli hyperscaler è traducibile nelle imprese. E di quello che è traducibile, non tutto è davvero di interesse delle aziende.

La principale linea di sviluppo tecnologica e concettuale dei data center va verso una netta disaggregazione di quelli che una volta erano considerati gli elementi "atomici" di una infrastruttura IT, ossia i server. Questo trend è evidente nelle infrastrutture degli hyperscaler. Che hanno le competenze interne e la forza di mercato per progettare - e farsi realizzare - i propri componenti IT su misura. Un approccio che ha portato all'esplosione dei cosiddetti ODM, gli Original Design Manifacturer.
La disaggregazione dei nodi dei data center corre parallela alla ricerca di elasticità permessa dalla virtualizzazione. Se l'obiettivo a tendere di quest'ultima è uno scenario "infrastructure-as-code" - in cui qualsiasi componente hardware può essere presa da un pool comune e allocata in maniera molto precisa per le esigenze specifiche di un workload, in tempo reale - allora disaggregazione delle risorse, componibilità, customizzazione delle risorse allocate a ogni workload sono i tre pilastri dello sviluppo tecnologico da seguire.

Alcune di queste evoluzioni sono già ben note e, come approccio, consolidate. La containerizzazione e le evoluzioni software-defined di storage e networking sono elementi di cui si parla da tempo. Le evoluzioni più recenti e interessanti riguardano la differenziazione della parte "elementare" di computing, ossia il processore. L'idea è che i processori general-purpose siano diventati davvero troppo generici. O che quantomeno, a seconda del workload che devono supportare, vadano affiancati con vari tipi di acceleratori.

A ciascuno la sua funzione

In estrema sintesi, le CPU fanno ancora il computing in senso stretto. Ma delegano le altre funzioni alle GPU per il machine learning (e alle TPU, Tensor Processing Unit), alle DPU (Data Processing Unit) per lo spostamento dei dati, alle FPGA per la loro programmabilità, ai processori delle SmartNIC per il traffico di rete. Una evoluzione che i vendor principali avevano traguardato già da tempo. Altrimenti Intel non avrebbe speso 16 miliardi di dollari per Altera. E più di recente sviluppato una sua strategia GPU con la piattaforma Xe. Oppure Nvidia non avrebbe comprato Arm e AMD non starebbe cercando di acquisire Xilinx.

Immaginiamo CPU, GPU, FPGA, storage, rete e altri componenti di un data center come mattoncini Lego che un workload assembla al volo a seconda delle sue necessità. Un workload, va sottolineato, non un'applicazione monolitica. Anche la parte software è disaggregata in un susseguirsi di microservizi che interagiscono fra loro. Basati su un "atomo applicativo" che è il container. Questa infrastruttura estremamente fluida è la diretta discendente delle Composable Disaggregated Infrastructure di qualche anno fa. Un termine che rende ancora bene l'approccio di fondo, ma che alcuni hanno sostituito con Accelerated Disaggregated Infrastructure. Per sottolineare il ruolo sempre più importante delle componenti di accelerazione: GPU, FPGA, SmartNIC.
Definizioni - anche un po' di marketing - a parte, un data center componibile è funzionale quanto è efficiente la piattaforma che combina le sue risorse in funzione dei workload. C'è quindi bisogno di una stretta integrazione tra parte software e parte hardware. Se puntiamo a un data center completamente programmabile, in sostanza, dobbiamo dotare l'hardware di qualcosa che sia paragonabile alle API delle componenti software. E poi fare in modo che tutto funzioni, magari anche in maniera ottimizzata con un occhio alle performance e al consumo energetico.

Integrare per gestire meglio

Da tutto questo deriva la necessità di una marcata integrazione verticale. Cosa che può apparire in contrasto con l'idea della disaggregazione. Idealmente, in un sistema disaggregato ha senso puntare sui componenti migliori. Se il produttore A fa le CPU più adatte, il produttore B i componenti di networking ideali e il produttore C lo storage migliore, perché non mettere tutto insieme? E anche in scenari magari non altrettanto disaggregati, non può valere la stessa constatazione?

La risposta è: dipende. Oggi nessuno è disposto a scegliere il "meglio" se questo non dialoga bene con il resto dell'IT. In un datacenter che diventa sempre più eterogeneo - e in un'era in cui la Legge di Moore non basta per aumentare le prestazioni di tutto il sistema con una nuova generazione di CPU generiche - l'orchestrazione ottimale delle componenti hardware e software diventa il metodo per avere sempre le performance che si cercano. Ed è impossibile orchestrare qualcosa che non sia allineato con il resto del data center.

Questo non vuol dire che un fornitore tecnologico non possa cercare di differenziarsi con elementi proprietari. Altrimenti rivedremmo lo storico svantaggio dell'integrazione verticale: se è troppa, "cristallizza" tutto frenando l'innovazione. Oggi però i vendor sanno che i loro elementi di differenziazione non devono diventare incompatibilità. Oppure ostacoli nella gestione e nell'orchestrazione dei data center. Gli hyperscaler hanno evitato il problema alla radice. Man mano si sono impadroniti di tutto tutto lo stack tecnologico, arrivando a progettarsi dai server ai processori. Le imprese non possono fare altrettanto, ma hanno tutte le opzioni per fare scelte oculate che proteggano l'operatività delle loro infrastrutture.