Site icon bizzIT.it – Magazine di Information Technology B2B

Reversibilità operativa: per la sovranità serve un brokering continuo

reversibilita-operativa-per-la-sovranita-serve-un-brokering-continuo

L’Europa ha una dipendenza tecnologica dal cloud Usa. Bisogna uscirne, ma per iniziare serve un punto d’appoggio. Una strada molto interessante è partire dal disaster recovery e poi andare avanti fino a un ripristino indipendente dal fornitore. E qui ci sono varie sorprese.

Il punto non è semplicemente usare più fornitori cloud, magari con qualche workload su fornitori europei. Ma anche il multicloud può produrre lock-in: API proprietarie, database gestiti, identità, formati dei dati e servizi di rete possono legare un’applicazione a un singolo ecosistema. La vera domanda è quanto una dipendenza tecnologica sia sostituibile, con quali tempi, costi e rischi.

Ecco il concetto di reversibilità operativa: non la possibilità teorica di migrare, ma la capacità di ricostruire ed eseguire un workload altrove, con procedure conosciute e periodicamente provate. Il punto d’appoggio può essere questo. Il disaster recovery è un punto di partenza concreto perché obbliga già a separare produzione e ripristino, definire RPO e RTO, copiare i dati e verificare che possano essere recuperati. Il passo successivo è fare in modo che il ripristino non dipenda dallo stesso fornitore dell’ambiente primario.

Il passaporto dell’applicazione

Per arrivarci, una strada sarebbe descrivere l’applicazione per ciò che richiede, non per il cloud sul quale gira. Sviluppare quindi un passaporto dell’applicazione, una sorta di manifest come vediamo in tante soluzioni software-defined. Un passaporto machine-readable dovrebbe indicare, tra gli altri vincoli, capacità di calcolo e memoria, API di storage, database, localizzazione ammessa, latenza, banda, RPO, RTO, requisiti di sicurezza e compliance, costo massimo e dipendenze indispensabili.

Il passaporto sarebbe un cambio importante in generale, ma soprattutto per l’AI. Invece di prescrivere un certo numero di GPU di uno specifico modello, il workload può esprimere una prestazione: throughput, latenza, qualità accettabile, area geografica e costo. CPU, GPU, NPU o combinazioni ibride diventano alternative da valutare quando soddisfano lo stesso requisito. Un esempio di questo tipo di valutazione è già disponibile in ONNX Runtime (ne parlo qui), che attraverso gli Execution Provider permette di eseguire modelli AI su hardware diversi, comprese CPU, GPU e NPU.

Lo stesso vale per il software. Kubernetes, OCI e S3 offrono contratti tecnici diffusi; Score e Humanitec aiutano a descrivere workload e dipendenze; Terraform, OpenTofu e Cycloid possono contribuire alla riproducibilità dell’infrastruttura. Nel brownfield bisogna ridurre progressivamente le dipendenze esistenti; nel greenfield, invece, si cerca la portability by design.

Un catalogo autoaggiornato delle risorse

Se il passaporto descrive la domanda, per descrivere l’offerta serve un altro strumento. La prima cosa che viene in mente è un semplice catalogo. Non un listino di VM, ma un Resource Catalog capace di rappresentare compute, storage, database, rete, localizzazione, certificazioni, giurisdizione e costi.

Ci stanno provando Focus (FinOps Open Cost and Usage Specification), che normalizza dati di costo e terminologia tra fornitori, e Gaia-X, che lavora su descrizioni machine-readable, verificabilità e trust. Certo manca ancora un capability model abbastanza ricco da mettere in relazione prestazioni, localizzazione, acceleratori, memoria, latenza, certificazioni e portabilità e abbastanza elastico da durare nel tempo.

Anche la rete deve entrare nel catalogo. Un’applicazione non dovrebbe chiedere la fibra di un certo operatore, ma banda, latenza, jitter, SLA e ridondanza. Fibra, 5G e connettività satellitare possono così essere valutate rispetto allo stesso requisito. In Europa anche IRIS² potrà aggiungere un’opzione di connettività sicura senza diventare una nuova dipendenza.

Il re-brokering è continuo

Quando domanda e offerta sono confrontabili entra in gioco il brokering. Un broker potrebbe scegliere le risorse compatibili con il passaporto, esclude quelle che non rispettano policy e compliance, confronta costi e prestazioni e prepara il provisioning.
Anche le policy, quindi, devono diventare machine-readable, entrando in azione prima dell’ottimizzazione economica. Un workload soggetto a GDPR, NIS2, DORA o AI Act deve usare soltanto risorse conformi ai requisiti del suo specifico profilo. Anche la cybersecurity deve cambiare forma. La crypto-agility è già un obiettivo tecnico formalizzato dal NIST: nel futuro andrebbe inserita nel passaporto e nel processo di brokering, includendo la gestione nel tempo di situazioni quali l’Harvest Now, Decrypt Later (esfiltrazione: dati cifrati che l’attacker conserva in attesa di capacità quantistiche future) e le considerazioni di PQC, crittografia post-quantistica. Il passaporto dovrebbe quindi includere durata della confidenzialità, esposizione quantistica, readiness alla crittografia post-quantistica e crypto-agility. NIST ha già pubblicato i primi standard PQC: anche algoritmi, chiavi, certificati e protocolli devono essere sostituibili.
Tutto questo sembra un marketplace, ma non lo è. Rispetto a un marketplace, infatti, qui il processo non finisce con l’acquisto. Prezzi, disponibilità e tecnologie cambiano: il brokering dovrebbe quindi diventare continuo e proporre un re-brokering quando il vantaggio supera il costo del cambiamento.

Reversibilità del dato

La reversibilità riguarda anche il dato. Backup, recovery, persistenza e provenienza dovrebbero essere funzioni separabili, così da poter cambiare storage o strumento di ripristino senza ricostruire tutto lo stack. StratoFoundry/KARL può rappresentare la storia e la provenienza del dato, Cybee/Restic il backup e il recovery, Cubbit uno storage distribuito compatibile S3.

Per l’Europa questo è il passaggio decisivo. La sovranità non coincide soltanto con la nazionalità del provider: significa anche sovranità della scelta. Partire dal disaster recovery consente di costruire questa capacità in modo incrementale, fino a trasformare il ripristino in un vero test di indipendenza tecnologica. Il contrario del lock-in non è usare più cloud. È poter cambiare davvero.

Penso che un giorno così non lo vedremo mai

Exit mobile version