In questo articolo ragiono sulla libertà di evolvere le proprie scelte infrastrutturali su dove e come far girare le applicazioni. Decisioni che sembrano tecniche, ma che condizionano l’organizzazione nel lungo periodo: la capacità di adattarsi, quando il contesto cambia, non è mai scontata.
Dove far girare le proprie applicazioni è una di quelle decisioni che all’inizio sembrano quasi banali, e che invece si rivelano tra le più difficili da correggere.
Chi ha costruito applicazioni sul cloud pubblico lo ha fatto per ragioni precise: velocità di attivazione, scalabilità e flessibilità operativa. Chi è rimasto sull’on premises aveva, e spesso ha ancora, motivazioni altrettanto solide. Chi esplora scenari ibridi sta cercando un equilibrio tra esigenze che non si lasciano ridurre a una scelta sola.
Tutte posizioni ragionate. Il problema nasce dopo, quando il contesto cambia: i requisiti di compliance evolvono, le priorità si ridefiniscono. È un po’ come scegliere dove vivere: la casa giusta a trent’anni non è necessariamente quella giusta a quaranta. Non perché la scelta fosse sbagliata, semplicemente nel frattempo è cambiato qualcosa.
E quando si decide di cambiare, si scopre spesso che la tecnologia adottata non lo permette. O lo permette, ma ad un costo che nessuno aveva messo in conto.
Cloud pubblico, cloud privato e on premises non sono equivalenti, e le differenze non riguardano solo l’architettura tecnica. Ognuno implica un compromesso specifico tra livello di controllo sull’ambiente e costi di gestione nel lungo periodo.
Per restare nella metafora: il cloud pubblico assomiglia all’affitto, è flessibile e con meno responsabilità dirette, ma anche con meno controllo. Il cloud privato offre più controllo e personalizzazione, a fronte di costi e complessità maggiori. L’on premises è la proprietà: massimo controllo, ma piena responsabilità sulla gestione.
La metafora però ha un limite importante. A differenza di una casa, cambiare infrastruttura non significa solo traslocare (e quindi preparare qualche scatolone). Significa spesso rimettere mano alle applicazioni stesse e alle integrazioni che ci girano sopra. Correggere la rotta a posteriori è complesso e costoso molto più di quanto si immagini all’inizio.
Le recenti evoluzioni normative sono un esempio concreto di come il contesto intorno a una scelta infrastrutturale possa cambiare. Organizzazioni di ogni settore si stanno ponendo domande sempre più concrete: i nostri dati sono sufficientemente protetti? Chi può accedervi? Siamo in grado di dimostrarlo? Domande che nei settori più regolamentati – come il finance, il sanitario e la pubblica amministrazione – sono già diventate obblighi normativi con requisiti di sicurezza precisi, ma che riguardano in misura crescente qualsiasi organizzazione che tratti dati sensibili o strategici. Ed è qui che la scelta infrastrutturale diventa rilevante: soddisfare certi requisiti di sicurezza – sulla localizzazione dei dati, su chi può accedervi e in quali condizioni, sulla cifratura – richiede che l’infrastruttura sottostante sia progettata e certificata per farlo. Non tutte lo sono.
Nel contesto della Pubblica Amministrazione italiana, ad esempio, il Regolamento ACN definisce vincoli precisi su dove possono risiedere i dati pubblici in base alla loro criticità. Non basta scegliere un cloud affidabile: bisogna scegliere un cloud qualificato, con la certificazione ACNper il livello di criticità dei dati che tratta.
A questo punto entra in gioco una domanda che raramente viene posta quando si sceglie come sviluppare le applicazioni: la tecnologia che stiamo adottando ci lascia liberi di evolvere l’infrastruttura in futuro?
Lo sviluppo tradizionale offre grande flessibilità in fase di costruzione, ma vincola le applicazioni a scelte architetturali pensate per un ambiente specifico. Chi ha costruito sfruttando servizi nativi di un cloud provider, come funzioni serverless, database gestiti, code proprietarie, si trova spesso a scoprire che quell’applicazione non gira altrove senza essere in parte riscritta. Quando quell’ambiente cambia, bisogna già mettere in conto questo tipo di lavoro.
Per accelerare i tempi, molte organizzazioni guardano alle piattaforme low-code. Ma accelerare non significa automaticamente essere più liberi: anche queste piattaforme possono introdurre dipendenze forti sull’infrastruttura, se la portabilità non è un principio architetturale esplicito. Il rischio è lo stesso: quando si decide di cambiare, ci si trova a dover ripartire da zero.
Nel nostro lavoro con i clienti abbiamo cercato una risposta concreta a questo problema e la nostra scelta è ricaduta su Mendix di Siemens. È una piattaforma low-code la cui architettura è progettata per essere indipendente dall’infrastruttura sottostante: le applicazioni girano su runtime standardizzati, distribuibili su cloud pubblico, cloud privato o on premises senza modifiche sostanziali. Cambiare infrastruttura non significa riscrivere le applicazioni, significa spostare dove girano.
In più, è possibile esportare il codice Java sottostante: se le esigenze dovessero cambiare radicalmente, l’organizzazione potrebbe uscire dalla piattaforma portando con sé il codice. Il lock-in non è eliminato, ma è reversibile, un aspetto che ho approfondito in un altro mio articolo.
Sul fronte normativo, Mendix Cloud ha ottenuto la certificazione ACN di Livello 2 (QC2) come PaaS, il che lo abilita al trattamento di dati critici nel rispetto dei requisiti italiani. Per chi è soggetto a questi vincoli, come le pubbliche amministrazioni, non è un dettaglio opzionale. E la portabilità non riguarda solo la scelta tra cloud e on premises. Endemol Shine Group, ad esempio, ha migrato la stessa applicazione da Azure a Google Cloud Platform per poi andare in produzione su AWS, senza toccare il codice. La libertà di cambiare non si ferma alla prima scelta, ma accompagna l’organizzazione nel tempo.
La scelta infrastrutturale, quindi, non viene imposta dalla piattaforma. Rimane nelle mani dell’organizzazione e può evolvere nel tempo, senza riscrivere le applicazioni e senza perdere il codice.
Non ho una risposta universale alla domanda del titolo. Ho lavorato con una piattaforma low-code che affronta seriamente il tema della portabilità e questa è la prospettiva da cui scrivo. L’unica cosa che mi sento di suggerire, a prescindere dalle scelte che farete in azienda, è questa: non date per scontata la possibilità di poter evolvere le scelte infrastrutturali di dove girano le vostre applicazioni.
*Articolo a firma di Virginia Lazzari, Business Consultant in WEGG
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
