Il problema non è più dove gira, ma come è stato scritto
Chi come me gestisce infrastrutture enterprise per lavoro lo sa bene: negli ultimi anni la parte “difficile” della sovranità digitale ha cambiato natura. Fino a poco tempo fa il collo di bottiglia era l’infrastruttura. Oggi l’infrastruttura sovrana è pronta. Datacenter certificati sul territorio, hypervisor maturi, storage all-flash, fabric di rete a bassa latenza, orchestrazione Kubernetes on-prem: tutto questo esiste, è collaudato e regge il confronto con gli hyperscaler su latenza, throughput e affidabilità.
Il vero attrito è un altro, ed è più insidioso perché non lo risolvi con un budget hardware: convincere gli applicativi a cambiare filosofia di sviluppo. Quando sposti un carico su infrastruttura sovrana o on-prem, non è la macchina a rifiutarsi di girare. È il software, e soprattutto è il modo in cui è stato pensato, che resiste.
L’esperienza sul campo: l’infra non si è mai rotta
Nella mia esperienza diretta di migrazione verso infrastruttura sovrana, non ho incontrato problemi lato infrastruttura. Le VM si accendono, i volumi si montano, la rete instrada, i cluster fanno scheduling. Il layer sotto fa il suo lavoro senza drammi. Questo è il dato che va detto con onestà a CIO e CISO: la scommessa infrastrutturale della sovranità è vinta.
La difficoltà vera, quella che consuma settimane di lavoro e riunioni, è di natura culturale e architetturale. Molti applicativi enterprise portano dentro assunzioni implicite maturate in anni di sviluppo cloud-centrico o legacy monolitico. Quelle assunzioni non sono “errori” nel senso stretto: sono scelte progettuali che avevano senso in un altro contesto e che, spostate su infra sovrana, diventano zavorra.
Cosa significa “cambiare filosofia” in pratica
Il nodo non è tecnico nel senso banale del termine. È il rifiuto — spesso del team di sviluppo o del vendor — di ripensare il modo in cui l’applicativo si relaziona all’ambiente. Le resistenze tipiche che vedo ricorrere sono:
- Dipendenze da servizi proprietari: managed database, code di messaggi, funzioni serverless, object storage con API specifiche di un singolo provider. Non è impossibile sostituirli, ma richiede che qualcuno accetti di riscrivere l’integrazione invece di dare per scontato che “il servizio ci sia”.
- Endpoint e configurazioni hardcoded: URL, regioni, credenziali e path incisi nel codice invece che esternalizzati in configurazione. Portabilità zero per design.
- Assunzioni implicite su storage e rete: latenze, modelli di consistenza, banda “infinita”, elasticità automatica date per garantite come fossero leggi di natura.
- Modello di licenza: vincoli contrattuali che presumono un deployment specifico o che penalizzano l’esecuzione su infrastruttura diversa da quella “benedetta” dal vendor.
Il punto è che l’infrastruttura sovrana chiede all’applicativo di essere disaccoppiato dal fornitore. E il disaccoppiamento è un lavoro di ingegneria del software, non di sistemistica.
Il trade-off vero è organizzativo, non tecnologico
La negoziazione più dura non l’ho fatta con un hypervisor o con uno switch: l’ho fatta con chi scrive e mantiene il software. Il trade-off da mettere sul tavolo è chiaro: o si investe nel refactoring per rendere l’applicativo agnostico rispetto all’ambiente, oppure si accetta di trascinarsi dietro dipendenze che minano il senso stesso della sovranità.
Dove si può, la strada è esternalizzare configurazioni, astrarre le integrazioni dietro interfacce, sostituire i servizi proprietari con equivalenti open o self-hosted (PostgreSQL al posto del database managed, MinIO o storage S3-compatibile on-prem, broker di messaggi standard). Dove il vendor non collabora, il compromesso è isolare la dipendenza in un perimetro controllato e pianificarne la sostituzione, senza raccontarsi che “poi lo sistemiamo”.
Quando dico al cliente di aspettare
Quando arriva la richiesta “convertiamo tutto adesso”, la mia risposta non è mai automatica. Il segnale concreto che uso per capire se un applicativo non è pronto a cambiare filosofia è questo: se per farlo girare fuori dal suo ambiente originario devo mettere le mani nel codice, e non solo nella configurazione, allora l’applicativo non è portabile — è prigioniero.
In quei casi consiglio davvero di rallentare:
- Quando le dipendenze proprietarie sono strutturali e non incapsulate: migrare significa riscrivere, non spostare.
- Quando il team di sviluppo o il vendor non è disposto a fare il lavoro di disaccoppiamento: senza quel commitment, la migrazione produce solo un sistema fragile e più costoso da mantenere.
- Quando mancano i test per validare il comportamento fuori dall’ambiente d’origine: senza rete di sicurezza, la conversione è una scommessa al buio.
Il criterio pragmatico è: prima si rende l’applicativo portabile, poi lo si sposta. Invertire l’ordine è la ricetta per un rollback in produzione.
Verdetto: conviene muoversi o aspettare?
Il mio verdetto è 0: aspettare, ma in modo attivo. Non perché l’infrastruttura sovrana non sia pronta — lo è, e senza riserve. Ma perché convertire tutto oggi, con applicativi che non hanno ancora cambiato filosofia di sviluppo, significa trasportare il lock-in dentro casa e chiamarlo sovranità.
La mossa giusta non è la migrazione di massa immediata, ma investire da subito sul disaccoppiamento del software: esternalizzare configurazioni, astrarre le dipendenze, coinvolgere sviluppatori e vendor nel ripensamento architetturale. Quando l’applicativo diventa agnostico rispetto all’ambiente, la migrazione su infra sovrana diventa un non-evento. Fino ad allora, chi deve cambiare filosofia non è l’hardware: è il software, e chi lo scrive.