Come stabilire un perimetro di competenze tra fornitori e migliorare la collaborazione tra stakeholder

di Daniele Pizzolli, Team Cloud Italia del Dipartimento per la trasformazione digitale

Come gestire una migrazione in cloud quando l’hardware è fornito da un’azienda, il software da un’altra e i servizi vengono gestiti da un terzo operatore? Nell’esercizio delle proprie funzioni, le pubbliche amministrazioni si avvalgono spesso di una pluralità di fornitori ed è quindi necessario suddividere le responsabilità a un livello appropriato di competenze. Un’operazione che può essere condotta grazie a strumenti tecnici e modelli di gestione efficaci, utili a costruire, operare ed evolvere un’infrastruttura cloud a disposizione di multipli fornitori, senza entrare nel merito di questioni contrattuali e amministrative.

Per prima cosa, è bene sottolineare che la responsabilità ultima del buon funzionamento di un servizio, anche quando erogato tramite fornitori esterni e cloud provider, rimane sempre in capo all’amministrazione. Delegare compiti, infatti, non significa sottrarsi alle responsabilità: ad esempio, nel caso della migrazione di un servizio tramite lift and shift, quando lo spostamento in cloud avviene importando l’immagine dell’host di partenza o migrando il software su una virtual machine a partire da un modello messo a disposizione dal cloud provider, l’aggiornamento del sistema operativo dell’host rimane in carico all’amministrazione, anche se a livello gestionale può essere delegato a un fornitore terzo.

Nella pratica, gli scenari nei quali si trova a operare una Pubblica Amministrazione sono diversi, ciascuno con particolari profili di rischio e opportunità. È possibile, però, individuare delle situazioni ricorrenti, come la configurazione degli ambienti del cloud provider (che può offrire vari strumenti per isolare risorse e reti), la gestione degli accessi (che attribuisce agli utenti determinati diritti) e la condivisione di una strategia di disaster recovery (per indirizzare le soluzioni dei possibili incidenti al giusto livello). Vediamole più nel dettaglio.

Un ambiente ottimale dove collaborare in sicurezza

Documentazione

L’ostacolo maggiore alla collaborazione in ambienti dove è necessaria la condivisione di informazioni per portare a termine un compito specifico, come ad esempio la messa in produzione di un nuovo servizio, è che nessuno degli attori coinvolti nel progetto, che spesso lavorano per PA e aziende diverse, abbia la visibilità totale sul sistema.

La documentazione condivisa, quando esiste, è una mappa spesso imprecisa e in molti casi non aggiornata. Inoltre, migrare un servizio in cloud e documentarlo in centinaia di pagine, poi distribuite sotto-forma di manuale, spesso in un formato non editabile, è un freno al cambiamento.

L’obiettivo a cui tendere, invece, è gestire la documentazione come se fosse codice, o come fossero commenti al codice di un sistema di deployment basato sull’Infrastructure as Code (IaC). Le buone pratiche per gestire infrastrutture non mancano e sono riassunte nell’articolo come gestire una migrazione al cloud.

Collaborazione e osservabilità

Un tipico esempio di collaborazione si ha quando il responsabile della rete deve configurare un accesso esterno tramite un router o un firewall (con porte e appositi indirizzi IP) a un nuovo servizio interno, gestito da terzi. Se dovesse avvenire un errore nella comunicazione degli indirizzi o delle porte, chi gestisce il servizio non ha modo di sapere immediatamente cosa è sbagliato, ma vedrà solo che qualcosa non funziona. Allo stesso modo, chi configura la rete spesso non dispone di tutte le informazioni per testare il servizio o ritiene che non sia un suo problema.Per individuare dove si annida l’errore, occorre che ogni soggetto coinvolto controlli bene tutti i parametri, anche se è convinto di averlo già fatto, prima di dichiarare che il problema è legato all’operato di altri.

Per ovviare a questi inconvenienti, un suggerimento è quello di avere dei sistemi di reportistica e delle dashboard condivise, che aumentino l’osservabilità del sistema. Di solito ogni cloud provider mette a disposizione degli strumenti di analisi e monitoraggio, che di norma possono essere usati per la verifica dei servizi in produzione. In alternativa, o in setup più complessi, per esempio nel caso si utilizzino deployment multi-cloud, si possono usare strumenti di analisi multi-cloud o adattati appositamente. In questo modo, ogni fornitore potrà avere un accesso con delle viste personalizzate dove controllare lo stato dei sistemi dei quali è responsabile.

Organizzare privilegi e accessi amministrativi al servizio

Il responsabile della PA che gestisce gli account presso uno o più fornitori di servizi cloud, dovrà creare e delegare gli accessi amministrativi dei vari fornitori a vari servizi, tenendo sempre presente che un’efficace organizzazione dei permessi è alla base di una corretta gestione dei servizi cloud. Ad esempio, un fornitore potrebbe aver bisogno di un insieme di macchine virtuali e di servizi Platform as a service (PaaS) per installare il proprio applicativo: in questo caso sarebbe opportuno garantire appositi accessi amministrativi all’interno di un progetto isolato, creato appositamente per l’esigenza del fornitore, fissando all’occorrenza anche dei limiti di spesa ben definiti.

Anche se con il fornitore esiste un rapporto di fiducia consolidato, non è consigliabile concedere più privilegi di quelli necessari. Concedere a tutti gli utenti i privilegi di amministratore è una scorciatoia che può risultare conveniente nelle fasi iniziali del progetto, ma ben presto ci si renderà conto che per fretta, distrazione o incompetenza potrebbe mettere a rischio il sistema stesso e le sue preziose informazioni. Una situazione che risulterà spiacevole per tutti e che potrebbe minare i futuri rapporti di collaborazione.

In generale, le deleghe alla gestione dei vari componenti di un servizio cloud devono essere ben definite, documentate e testate. A loro volta, le persone che sono delegate a eseguire un compito, come ad esempio il monitoraggio o il backup, il ripristino o le operazioni per il disaster recovery, devono avere chiari i loro limiti di azione e le figure con cui coordinarsi in caso di necessità.

Per esempio, a un fornitore che richiede una virtual machine, si possono dare i permessi per accendere e spegnere la macchina virtuale, per gestire gli accessi e anche il backup. Non dovrebbe però essere necessario concedere anche i permessi per creare e distruggere la virtual machine o per sovrascriverla con un restore nelle operazioni di manutenzione ordinaria. In casi eccezionali, come nell’aggiornamento a una versione successiva o durante test e procedure di recovery, si potrà concedere il permesso di creare e distruggere la macchina virtuale solo per il tempo strettamente necessario alle operazioni.

Parlare la stessa lingua

Ogni_ cloud provider_ usa delle terminologie leggermente diverse per la sua offerta di servizi e configurazioni, e spesso oggetti dallo stesso nome sono in realtà molto diversi. Questo è un grande ostacolo per chi deve gestire servizi su più provider. Termini generici come owner, admin, principal e manager possono infatti avere ruoli molto diversi a seconda del provider e anche del servizio fornito da una stessa azienda. Motivo per cui deve essere posta grande attenzione in fase di definizione dei ruoli e delle regole di accesso.

Per esempio, a seconda del provider il dominio fondamentale per l’organizzazione si può chiamare: “account”, “progetto” o “organizzazione”, le deleghe date a un utente per accedere a un servizio si possono chiamare “service account” o “service principal”, i limiti e le quote possono avere significati leggermente differenti, che vanno in ogni caso a impattare sulla gestione. Chiarezza e condivisione di terminologie e significati rafforzano la qualità delle interazioni fra fornitori e amministrazione, rendendo i processi legati ai servizi cloud più semplici ed efficaci.

Gestione dell’identità e degli accessi

Con Identity and access management (IAM) si indicano gli strumenti e le procedure per la gestione delle identità e degli accessi. In pratica** a ogni soggetto che entra in un sistema si associano un’identità e un insieme di credenziali, permettendogli di gestire determinate funzionalità messe a disposizione dal cloud provider**. Ogni cloud provider ha un suo particolare modo di implementare lo IAM, ma i concetti generali di fondo restano invariati. Di norma c’è un account radice che dispone di privilegi illimitati. Tale account è gestito dal responsabile tecnico della PA. Il responsabile può creare degli altri account e assegnarli con determinati diritti d’accesso ai suoi collaboratori oppure a fornitori esterni.

Non tutti gli account devono per forza avere dei privilegi di creazione, modifica o cancellazione di risorse, ma ci possono anche essere account che hanno accesso in sola lettura. Questo potrebbe essere il caso di un account di monitoraggio dei costi, che può essere delegato a una persona con mansioni amministrative. Allo stesso modo, un account in sola lettura potrebbe essere assegnato a un apposito software di monitoraggio o di controllo conformità, che può leggere lo stato delle risorse e generare report periodici o fornire dashboard in tempo reale.

Ma è nella gestione degli account che hanno privilegi di creare, modificare o distruggere risorse che bisogna prestare più attenzione.

Idealmente ogni persona che ha accesso al sistema dovrebbe avere un account personale. Le identità condivise non permettono di associare i log degli eventi ad una persona responsabile e contribuiscono a creare pratiche deleterie, come lo scambio di password su canali insicuri. È bene discutere con i fornitori la gestione dei “segreti”, come password, chiavi, certificati, token, e in particolare dei token che possono o devono essere usati per automatizzare la gestione. Una percentuale importante delle compromissioni dei sistemi dipende dai comportamenti di chi usa il sistema e anche in questo caso prevenire significa aumentare la sicurezza di dati, informazioni e servizi.

Isolamento a livello di risorse

Il responsabile tecnico della PA, o chi da lui delegato, deve tendere alla creazione di ambienti cloud il più possibile isolati. Ogni fornitore dovrebbe avere il suo progetto/organizzazione, o se il fornitore gestisce più servizi, per ogni servizio ci dovrebbe essere il progetto corrispondente. Come è facile intuire, più i progetti sono frammentati più ci saranno delle complicazioni nella gestione dovute al cambio di contesto.

La possibilità di automatizzare anche la parte di gestione degli accessi permette di isolare i sistemi al giusto livello, senza dover ripetere manualmente le stesse configurazioni più volte. Il vantaggio di questa configurazione consiste nel fatto che l’ambiente messo a disposizione al fornitore è standard e riproducibile: il fornitore parte da una configurazione conosciuta e documentata, sulla quale può installare o reinstallare la sua soluzione in maniera automatica o facilmente automatizzabile.

Isolamento a livello di rete

Di norma ogni servizio installato in un progetto dovrebbe essere completamente isolato a livello di rete ed esporre solo gli endpoint necessari verso l’esterno oppure verso altri servizi. In primo luogo l’isolamento può avvenire attraverso i firewall, ma sono possibili e auspicabili anche accessi mediati da certificati, token, sistemi di autenticazione distribuita.

All’interno di un'infrastruttura cloud, che possiamo chiamare anche virtual data center, ogni fornitore potrebbe gestire in autonomia le configurazioni della rete. Una corretta gestione prevede, di solito, che ci sia una segmentazione delle reti, per esempio che i database gestiti sulle virtual machine o come Database as a Service (DBaaS) non siano direttamente esposti sulle reti pubbliche e condivise.

Se più fornitori necessitano di un accesso a una risorsa condivisa, le amministrazioni dovrebbero valutare caso per caso le migliori soluzioni, che possono spaziare da un accesso tramite rete (virtuale) condivisa, una VPN, oppure via endpoint pubblici o, ancora, tramite certificati. L’isolamento a livello di rete permette di definire e ridefinire le regole di accesso in maniera dinamica, oltre che consentire il monitoraggio del traffico per identificare e prevenire tempestivamente attacchi al sistema.

Backup, Restore e Disaster Recovery

Uno degli aspetti più critici dei servizi messi in esercizio attraverso l’ausilio di più fornitori è la gestione degli incidenti e delle emergenze. Situazioni dove è fondamentale identificare subito il livello in cui mettere in atto le prime contromisure e gestire le comunicazioni in fase emergenziale.

Qualche anno fa un cloud provider, a seguito di un incendio all’interno di uno dei suoi data center ha concluso l’annuncio dell'incidente con: vi raccomandiamo di attivare il vostro piano di disaster recovery. Per quanto la formula possa sembrare inopportuna, questo è quello che a volte accade nella realtà. E anche se i software qualificati da ACN offrono tutte le funzionalità necessarie per eseguire i backup e restore, la responsabilità ultima del funzionamento di un servizio rimane sempre in capo all’amministrazione.** **Avere un piano di disaster recovery per dei servizi cloud vuol dire, infatti, per la PA, **eseguire dei monitoraggi costanti, avere dei backup e soprattutto disporre di procedure condivise e aggiornate fra i fornitori **per procedere al ripristino dei sistemi in modo tempestivo.

La migrazione verso il cloud offre gli strumenti per implementare la business continuity e i piani di disaster recovery. In generale ogni fornitore ha chiaro come gestire il proprio sistema, ma non deve per forza essere a conoscenza di come questo si inserisce nel quadro dei servizi complessivi gestiti dalle amministrazione.

Per questo l’amministrazione deve accertarsi che per i fornitori sia chiaro come gestire le situazioni di emergenza, coordinandosi sulle risorse, come persone e hardware disponibile, sulle responsabilità, che devono essere preventivamente individuate, sulle tecnologie e sugli strumenti, per fare in modo che i livelli di servizio (SLA, Service Level Agreement) e, nei casi più gravi, gli obiettivi di punto e tempo di ripristino (RPO e RTO, Recovery Point/Time Objective) siano rispettati.

Le procedure di test per garantire la continuità di servizio sono onerose, sia in termini di risorse consumate (dovranno essere attivate delle virtual machine, dello storage, dei servizi PaaS aggiuntivi), sia di tempo (le persone devono trasferire, accendere, riconfigurare i servizi dal backup, controllare che tutto funzioni). Un processo che potrebbe essere lungo e faticoso, specialmente se le procedure non sono automatizzate. L’obiettivo a cui tendere è rendere la procedura sempre più automatica e testabile, per aumentare la resilienza generale del sistema.

Per una matrice delle responsabilità

Dopo aver analizzato i principali scenari in cui una Pubblica Amministrazione si trova normalmente a operare, è possibile ricostuire una matrice di gestione delle responsabilità, partendo come spunto da una situazione semplificata, con una Pubblica Ammnistrazione (PA), un fornitore generico, come può essere una software house, e un cloud provider (CP), che offre servizi cloud. Con la terminologia del modello di piano di migrazione adottato ai sensi del regolamento Cloud di AgID, un modello ripreso anche dagli Avvisi per il finanziamento della migrazione pubblicati su PA digitale 2026, possiamo così individuare le seguenti attribuzioni:

Oggetto	Migrazione con trasferimento	Migrazione con aggiornamento
Mantenimento Sistema Operativo	PA	Compreso nel SaaS
Mantenimento Servizio Custom su CP	Fornitore	/
Mantenimento Servizio in PaaS/SaaS direttamente da CP	/	CP
Mantenimento Servizio in PaaS/SaaS da Fornitore su CP	/	Fornitore
Mantenimento Infrastruttura CP	CP	CP

Per esteso, ci si aspetta che la PA, in caso di migrazione con trasferimento continui a gestire l’aggiornamento dei sistemi operativi sui quali è installato il servizio personalizzato che sarà gestito dal fornitore. Al cloud provider rimane in carico la gestione dei servizi cloud. In caso di migrazione con aggiornamento, la manutenzione del sistema operativo è compresa nel servizio SaaS (di norma questo avviene dietro le quinte, senza interruzioni di servizio). Il mantenimento del servizio sarà a carico di chi lo fornisce (CP o Fornitore) e ovviamente il mantenimento dei servizi cloud rimane in carico al CP.

Pur nella consapevolezza di non essere esaustivi, siamo certi che tracciare un perimetro chiaro delle responsabilità di ogni singolo attore in campo contribuisca a rafforzare la qualità dei progetti di migrazione, senza contare che l’adozione di strumenti come dashboard di controllo, vocabolari condivisi, segmentazione degli accessi nonchè di piani per il disaster recovery renda la gestione di un’infrastruttura cloud più efficace e performante, a tutto vantaggio dei cittadini.

Per rimanere aggiornato sui prossimi approfondimenti resta in contatto con noi su Slack Developers canale #cloud, iscriviti alla nostra mailing list e continua a seguirci sugli account Twitter di Developers Italia e Designers Italia.

Questo blog è redatto da Developers Italia

Principi e scelte pratiche per trasferire con successo dati, servizi e applicativi

di Daniele Pizzolli, Team Cloud Italia del Dipartimento per la trasformazione digitale

Il cloud della Pubblica Amministrazione è una nuvola digitale dai contorni sempre più definiti. Dopo la presentazione dei Piani di migrazione, lo scorso 28 febbraio, è infatti il momento, per le amministrazioni interessate, di passare all’azione per gestire al meglio il trasferimento in cloud di dati, servizi e applicativi. Una fase da condurre avendo cura dei riferimenti tecnici e normativi necessari per completare una migrazione di successo, con una serie di elementi chiave ai quali prestare particolare attenzione.

I riferimenti tecnici e normativi

Per una PA alle prese con la migrazione di dati e servizi in cloud è bene tenere anzitutto in considerazione il più ampio contesto fornito da:

• Codice dell’Amministrazione Digitale (CAD), che individua il digitale come la modalità principale per assicurare la disponibilità, la gestione, l’accesso, la trasmissione e la conservazione di dati, documenti e informazioni;
• articolo 33 septies del decreto legge n.179 del 2012, che ha fissato, con il Consolidamento e la razionalizzazione dei siti e delle infrastrutture digitali del Paese, l'obbligo di migrazione al cloud per le PA;
• aggiornamento del Piano Triennale al 2024, che ha mantenuto il principio cloud first tra i suoi elementi guida, stabilendo che in fase di definizione di un nuovo progetto e di nuovi servizi le PA adottino il cloud come “paradigma di riferimento”, ovvero come complesso di regole metodologiche, modelli e soluzioni tecniche a cui attingere;
• Strategia Cloud Italia, che fornisce alle PA l’indirizzo strategico e indica i passi amministrativi necessari all’implementazione di soluzioni cloud, con particolare riguardo agli aspetti legati a tutela di privacy, autonomia tecnologica, controllo sui dati e resilienza del sistema;
• Manuale di abilitazione al cloud, che da un punto di vista tecnico accompagna le PA nel percorso che parte dall’identificazione degli applicativi da migrare in cloud fino ad arrivare alla valutazione degli indicatori di risultato a migrazione avvenuta.

Oltre a questi riferimenti, e a quelli imprescindibili legati alla cybersecurity promossi dall’Agenzia per la cybersicurezza nazionale (ACN), una migrazione in cloud considerata di successo deve tenere sotto stretta osservazione anche alcuni accorgimenti tecnici generali, come la riduzione del rischio lock-in (non solo tecnologico), il miglioramento delle strategie di recovery e l’incremento della continuità di servizio, ovvero della resilienza dei sistemi. Questi tre obiettivi hanno un impatto determinante sulla buona riuscita di una migrazione, e possono essere gestiti tramite un approccio DevOps e Infrastructure as Code (IaC, dove l’infrastruttura è gestita automaticamente tramite ricette in forma di codice). Vediamoli più in dettaglio.

Riduzione del rischio lock-in

A un livello molto astratto il cloud può essere definito, con la debita attenzione, come “il computer di qualcun altro”. Per questo motivo, fra gli obiettivi del Piano Triennale troviamo chiaramente indicata la necessità di mitigare il rischio del lock-in, ovvero la difficoltà a svincolarsi da scelte effettuate in precedenza, incluse la scelta del fornitore con il relativo contratto. Non ci sono ricette miracolose per perseguire questo obiettivo, perché il rischio può manifestarsi a diversi livelli e occorre prestare attenzione a tutti gli aspetti organizzativi, tecnologici e operativi della migrazione, nonché a quelli di tipo economico.

A tale proposito, il Manuale di abilitazione al cloud contiene una sezione specifica per riconoscere possibili situazioni di lock-in, oltre a indicare buone pratiche tecnologiche, di metodo e contrattuali. Il caso più comune, per una PA, è quello inerente i fornitori, con i quali si instaurano spesso dei rapporti di lungo periodo. Avere un rapporto consolidato con un’azienda non è necessariamente un fatto negativo; tuttavia conviene essere consapevoli dei limiti che si possono incontrare nella gestione dei dati, nella manutenzione degli applicativi e nei vincoli contrattuali. I software qualificati da ACN offrono comunque tutte le funzionalità necessarie a mitigare i rischi di lock-in, ad esempio attraverso l’export di dati tramite API documentate, come evidenziato anche nel successivo paragrafo dedicato al Repurchase/replace.

Nel processo di migrazione si può inoltre scegliere di rimpiazzare soluzioni proprietarie, per esempio il database, con soluzioni open source, che sono disponibili anche come PaaS qualificato, ovvero in possesso dei requisiti di sicurezza stabiliti da ACN. Si possono scegliere soluzioni che integrano lo scambio di dati tramite API e formati standard, o favorire l’utilizzo di strumenti e framework di sviluppo open rispetto a soluzioni sviluppate internamente e di difficile manutenibilità per altri fornitori. Ulteriori azioni di mitigazione sono contenute nella sezione Come mitigare il lock-in del manuale di abilitazione al cloud al quale si rimanda per gli approfondimenti.

Recovery (dal backup)

La valutazione del rischio e la scelta delle modalità dell'erogazione di un servizio rimane sempre in capo all'amministrazione. Allo stesso modo l'ente delega l'esecuzione del servizio, ma non le responsabilità connesse. Il sistema di classificazione di dati e servizi elaborato da ACN è lo strumento principale per orientare le scelte dell'amministrazione. Per una migrazione di successo, le amministrazioni dovrebbero anzitutto effettuare un’analisi approfondita, comprensiva di una solida fase di test dei sistemi di backup e soprattutto di recovery offerti dalle soluzioni adottate, o ancora da attivare in caso non siano presenti nativamente. Questo per evitare che si creino disservizi, anche prolungati nel tempo, a tutto svantaggio di cittadini e imprese. In generale, quindi, è sempre possibile, oltre che auspicabile, cautelarsi con apposite strategie di disaster recovery e di backup dei database e degli applicativi seguendo i suggerimenti del Manuale di abilitazione.

Per quanto riguarda il backup, è necessario pianificare dei test periodici di ripristino complessivo dei sistemi, oltre a definire la frequenza temporale, la quantità di dati da salvare e il loro periodo di conservazione. La strategia di disaster recovery va decisa in base ai tempi di ripristino desiderati, alla quantità di dati che un ente ritiene accettabile perdere e ai costi da sostenere. Per loro natura, gli ambienti cloud permettono un ripristino più rapido dei sistemi IT, grazie alla ridondanza e a servizi specifici di solito offerti dal provider. Sono aspetti che vanno considerati in fase di contrattualizzazione del fornitore, con l’obiettivo di assicurare la continuità di servizio e prevenire malfunzionamenti.

Continuità di servizio e resilienza agli attacchi ransomware

Particolare attenzione deve essere posta nell’avere sempre un backup recente disconnesso o in sola lettura, per tutelarsi dagli attacchi di tipo ransomware. Una delle ultime ondate di cyberattacchi, ad esempio, ha sfruttato una vulnerabilità nota di sistemi non aggiornati, quella dell’hypervisor, lo strato software che di norma è gestito dal cloud provider. In questo caso, per (ir)responsabilità del provider, anche avendo aggiornato applicativi, dipendenze e sistemi operativi, un’amministrazione può rimanere comunque colpita. E il costo della perdita dei dati o del pagamento del riscatto è di certo superiore alla messa in campo, in via preliminare, delle opportune contromisure.

In base al regolamento della qualificazione ACN, un fornitore di servizi qualificati deve testare il restore dei dati almeno una volta all’anno. Ciò non toglie la possibilità alla PA di negoziare test più frequenti e livelli di servizio superiori agli standard minimi. Le amministrazioni, inoltre, grazie all’utilizzo degli strumenti di automazione che permettono di testare il backup con frequenza arbitraria, di norma settimanale o giornaliera, possono verificare autonomamente e in maniera continuativa il restore dei dati in ambiente di test.

Come migliorare la migrazione in cloud grazie a un approccio DevOps

Gli esperti sulla sicurezza e sulla continuità di servizio lo dicono chiaramente: non ha senso chiedersi se avverrà un disservizio, perché avverrà sicuramente. Meglio quindi essere pronti. E le attuali buone pratiche raccomandano di automatizzare il più possibile il processo di bootstrap, gestione, ripristino e migrazione di un’infrastruttura. Un modo per poter agire tempestivamente in caso di eventi avversi o per essere pronti a cogliere nuove opportunità, che potrebbero presentarsi, come un nuovo requisito da soddisfare velocemente o come la migrazione verso un altro cloud provider che offre migliori condizioni.

La flessibilità in fase di deployment, ovvero la modalità in cui si installano e configurano i servizi, è un asset importante. E anche se non ci sono specifici finanziamenti e normative che impongono l’adozione di un modello di deployment basato sul ciclo DevOps e la pratica di Infrastructure as Code, è opportuno adottare questo approccio.

L’adozione del paradigma cloud, infatti, è un processo aperto: le amministrazioni devono partire dal presupposto che ogni componente del software può essere migliorato o sostituito. Il perfezionamento può avvenire su diversi fronti: dalle prestazioni del sistema alla modalità di deployment. Cambiare tutto in colpo solo può quindi esporre a rischi notevoli e, in linea di massima, vale il principio che più è grande un cambiamento, maggiore è il rischio che qualcosa non vada come previsto.

Per questo motivo è consigliabile l’adozione di strumenti e modalità di lavoro iterative a piccoli passi, sostituendo un componente alla volta e verificando che tutto funzioni dalle procedure di test. L’automazione nella gestione dei componenti è ormai internazionalmente riconosciuta come insieme di pratiche DevOps, di cui la creazione e prima configurazione dell’infrastruttura è una parte fondamentale, tale da meritare la definizione di Infastructure as Code (IaC).

L'approccio DevOps, si può applicare in tutti i casi di migrazione previsti. In generale i servizi cloud, che siano Iaas, PaaS o SaaS devono offrire delle API per la configurazione e la gestione. Le API sono il punto di contatto fra il cloud e gli strumenti DevOps. Più un servizio è supportato dagli strumenti DevOps, più opportunità di integrazione e gestione automatizzata ci saranno.

L’approccio DevOps, può essere attuato direttamente dall’amministrazione o richiesto al fornitore per qualsiasi tipo di servizio. Per esempio un servizio di norma erogato come SaaS come la posta elettronica può essere configurato tramite API, facilitando la gestione dei dati. L’aggiunta di un utente, la configurazione delle quote e dei redirect, le politiche di retention, l’_export _dei dati e il backup possono essere gestiti in maniera automatica.

Le due modalità di migrazione

Come stabilito dal Regolamento cloud, il 28 febbraio scorso è scaduto il termine per la presentazione dei Piani di migrazione da parte delle pubbliche amministrazioni sulla base del modello standard definito dal Dipartimento. Nel documento, così come nei fondi messi a disposizione dal Piano nazionale di ripresa e resilienza su PA digitale 2026, viene chiesto alle amministrazioni di scegliere fra due modalità di migrazione:

• il trasferimento in sicurezza dell’infrastruttura IT;
• l’aggiornamento di applicazioni sicure in Cloud.

Per ognuno dei servizi oggetto della migrazione è opportuno che le PA valutino con attenzione vantaggi e svantaggi, per individuare il modello di migrazione più adatto alle loro esigenze. Vediamoli più in dettaglio.

Trasferimento in sicurezza dell’infrastruttura

Definizione contenuta negli avvisi pubblicati su PA digitale 2026:

“L’opzione di trasferimento in sicurezza dell’infrastruttura IT consente di sfruttare la strategia di migrazione Lift&Shift (anche detta Rehost), cioè la migrazione al Cloud dell’infrastruttura già esistente, senza la necessità di reingegnerizzare le applicazioni. Tale modalità consiste nel migrare l’intero servizio, comprensivo di applicazioni e dati su un hosting cloud senza apportare modifiche agli applicativi, ovvero replicando il servizio esistente in un ambiente cloud.”

Il trasferimento in sicurezza dell’infrastruttura avviene quando l’applicazione viene spostata in cloud senza modifiche sostanziali. Di solito, in questo caso vengono riconfigurati gli indirizzi IP; tuttavia anche il semplice _re-host _può nella pratica articolarsi in diversi sottocasi.

Semplicità nella migrazione

In linea di massima il_ re-host_ prevede di modificare il meno possibile l’applicazione e il sistema operativo sul quale è installata. È tuttavia possibile passare da un sistema installato direttamente sull’hardware a una macchina virtuale, che può poi avere lo storage fornito come dischi (volumi) locali, o come dischi di rete. Poter disaccoppiare lo storage dalla macchina permette di avere un livello di flessibilità nella gestione che prima della migrazione non era possibile. Una flessibilità che, a sua volta, permette di accedere alle funzionalità basilari IaaS del cloud, come la scalabilità verticale (il poter far ripartire la macchina virtuale con più risorse: CPU, RAM, ma anche storage) o la gestione degli snapshot (le fotografie dei volumi usati come storage) e dei backup dei volumi, che possono essere anche inviati ad un sito remoto da attivare in caso di disaster recovery.

Difficoltà di mantenimento nel medio/lungo termine

Un servizio, per essere definito “cloud” deve prevedere la fatturazione a consumo. Di norma il prezzo di un hardware dedicato è superiore a quello di una macchina virtuale, ma, di contro, le prestazioni sono garantite, rispetto ad una soluzione virtuale che per sua natura prevede la condivisione delle risorse con altri utenti. Le macchine virtuali sono però offerte con taglie di risorse più granulari rispetto all’hardware fisico, rendendo possibile un dimensionamento senza sprechi che porta all’ottimizzazione dei costi.

Il problema principale di una migrazione Lift&Shift è che l’applicazione migrata non sfrutta i paradigmi più innovativi del cloud computing e che quindi, a medio/lungo termine diventerà sempre più onerosa perché non ottimizzata, complessa nella manutenzione in quanto poco automatizzata e automatizzabile, e più difficile da gestire all’interno di un piano per il disaster recovery. Il semplice trasferimento in cloud andrebbe considerato solo per servizi in dismissione, poco utilizzati e che consumano poche risorse, quando il valore aggiunto di un ammodernamento dell’applicazione non sarebbe ammortizzabile nel bilancio di un ente.

Con il re-host si ha la possibilità di gestire le risorse in maniera elastica offre l’opportunità di migliorare notevolmente gli aspetti di backup e recovery e di resilienza.

Aggiornamento di applicazioni sicure in Cloud

Definizione contenuta negli avvisi pubblicati su PA digitale 2026:

“L’opzione di Aggiornamento di applicazioni sicure in Cloud offre la possibilità di migrare le applicazioni utilizzando una tra le strategie repurchase/replace e replatform. Per repurchase/replace si intende l’acquisto di una soluzione nativa in cloud, in genere erogata in modalità Software as a Service, mentre per replatforming si intende la riorganizzazione dell’architettura applicativa sostituendo intere componenti del servizio in favore di soluzioni Cloud native in modo da usufruire dei benefici dell’infrastruttura Cloud.”

Codice Amministrazione Digitale e Servizi Qualificati

In generale, l’adozione di nuove soluzioni informatiche presso la PA è soggetta alle prescrizioni del Codice dell’amministrazione digitale. In particolare, gli articoli 68 e 69 (rispettivamente “Analisi comparativa delle soluzioni” e “Riuso delle soluzioni e standard aperti”), impongono che gli enti effettuino un'analisi comparativa delle soluzioni acquisite, e prevede che queste vengano messe disposizione nel Catalogo curato da Developers Italia se sviluppate per una Pubblica Amministrazione. Per le soluzioni cloud, inoltre, la Strategia Cloud Italia disciplina un percorso di qualificazione dei servizi offerti dai fornitori con la collaborazione attiva dell’Agenzia per la Cybersicurezza Nazionale, che attualmente gestisce il Catalogo dei servizi cloud per la PA qualificati.

Repurchase/replace

I passaggi più delicati, nell’aggiornamento di un’applicazione tramite una strategia di repurchase/replace, sono legati alla migrazioni dei dati, all’integrazione con i sistemi esistenti e anche ad aspetti relativi alla formazione del personale. Nel valutare la scelta di quest’opzione, per l’amministrazione è opportuno soppesare con attenzione la facilità di importazione dei dati, l’usabilità delle interfacce e la compatibilità con i sistemi esistenti.

Allo stesso tempo conviene fin da subito valutare anche il costo di dismissione e migrazione ad altre soluzioni per mitigare il lock-in. In generale, è possibile (oltre che auspicabile) migliorare il livello di autonomia tecnologica ricorrendo a soluzioni open source o a soluzioni disponibili come servizi qualificati presso più fornitori. In ogni caso, la scelta di software qualificati da ACN garantisce alle Pubbliche Amministrazioni di avere a disposizione programmi che rispettano requisiti stringenti in materia di gestione, interoperabilità e portabilità: una gestione remota via API (utilizzabili anche con un approccio DevOps), avere API ben documentate e avere la possibilità di export dati in formati aperti diminuisce il lock-in.

Replatform e re-architect, verso il cloud native

Di norma con l’aggiornamento tramite replatform, parti dell’applicazione sono sostituite con del software IaaS, PaaS o SaaS: ad esempio il database interno può essere sostituito con un database as service, oppure lo storage su disco viene sostituito da un object storage. Dal punto di vista tecnico, il replatform è una modalità più complessa di trasferimento in cloud rispetto al rehost, in quanto è necessario intervenire su componenti di più basso livello del sistema. Si tratta però dell’opzione con le maggiori prospettive di miglioramento.

In caso di replatform è possibile inoltre incrementare il livello di autonomia tecnologica scegliendo componenti che sono disponibili su più cloud provider e sviluppando delle ricette di deploy che siano il più possibile agnostiche rispetto al cloud di destinazione.

I bandi del PNRR possono prevedere inoltre anche una terza modalità di migrazione con aggiornamento: la possibilità di un re-architect, ovvero del cambiamento di gran parte del software della soluzione, per esempio per dividerla in microservizi da gestire poi con sistemi di orchestrazione nativi del cloud. Da un certo punto di vista, il replatform si può anche vedere come il primo passo verso un re-architect: tempi e rischi, però, aumentano con l’entità dei cambiamenti necessari.

Il modello di sviluppo di applicazioni al quale tendere è quello cloud native, che mira a costruire ed eseguire applicazioni scalabili in cloud che tramite un robusto sistema di automazione possano essere modificate frequentemente per un miglioramento continuo.

In questo caso, saranno l’automazione e la gestione cloud native dell’applicazione, che miglioreranno in maniera naturale gli aspetti relativi al backup, restore e disaster recovery.

Per una nuova normalità

La migrazione al cloud non è qualcosa di magico che permette in un solo colpo di ammodernare l’infrastruttura e i servizi della PA: è piuttosto un processo che presenta rischi e opportunità. Se i finanziamenti del PNRR, insieme agli interventi di sistema promossi dagli Avvisi pubblicati sulla piattaforma PA digitale 2026, sono pensati per accompagnare la PA nel percorso di trasformazione digitale, ai singoli enti non deve mancare consapevolezza nella scelta di soluzioni lungimiranti. In futuro, infatti, il campo dell'Information Technology offrirà servizi sempre più fluidi e sviluppati secondo una metodologia agile, con il cambiamento costante che sarà la nuova normalità: tocca alle amministrazioni scegliere se governarlo oppure esserne governate.

Per rimanere aggiornato resta in contatto con noi su Slack Developers canale #cloud, iscriviti alla nostra mailing list e continua a seguirci sugli account Twitter di Developers Italia e Designers Italia.

Se hai dubbi o vuoi approfondire altri aspetti, consulta la sezione Domande frequenti dedicata al cloud su PA digitale 2026.

Questo blog è redatto da Developers Italia

Finestre di manutenzione e livelli di servizio: l’importanza di pianificare il trasferimento di dati e applicativi in cloud

di Daniele Pizzolli, Team Cloud Italia del Dipartimento per la trasformazione digitale

“Siamo spiacenti, il servizio non è al momento disponibile”: quante volte ci siamo imbattuti in un messaggio di cortesia che ci avvisa dell’indisponibilità di un servizio online? Spesso i picchi di traffico, la manutenzione ordinaria, attacchi informatici o altre evenienze rendono difficile l’esperienza degli utenti. Garantire la continuità di servizio diventa così uno degli aspetti fondamentali da tenere in considerazione per la Pubblica Amministrazione che intende offrire servizi pubblici disponibili 24 ore su 24 per cittadini e imprese, come previsto dalla Strategia Cloud Italia. Bastano infatti pochi accorgimenti per azzerare i disservizi, massimizzando la soddisfazione degli utenti.

In particolare, il Piano nazionale di ripresa e resilienza (PNRR) prevede una serie di interventi per rafforzare le infrastrutture digitali e l’abilitazione al cloud nella Pubblica Amministrazione. Grazie ai fondi messi a disposizione dalla Misura 1.2 Abilitazione e facilitazione migrazione al Cloud, ad esempio, numerose amministrazioni italiane, in particolare Comuni e scuole, hanno così la possibilità di migrare e aggiornare i servizi offerti tramite internet.

Per rendere più efficace la migrazione in cloud di dati e servizi applicativi è però opportuno che, per ogni servizio erogato, le amministrazioni pongano attenzione alle finestre di manutenzione e ai livelli di servizio (ad esempio il tempo di disponibilità del servizio, il tempo medio che intercorre tra i guasti, il tempo di risposta e soluzione dei problemi ecc.), elementi che è necessario rispettare anche a seguito dei processi di migrazione.

_{^{Some rights reserved – Copyright gatus.io Apache License 2.0}}

Finestre di manutenzione e livelli di servizio

Le finestre di manutenzione di norma sono posizionate lontane dai picchi di richiesta del servizio e, nel caso siano straordinarie oltre che interessare la platea dei cittadini, è buona prassi che siano comunicate con largo anticipo. Per esempio per un servizio di protocollo, che avrà i picchi in orario di sportello e la maggioranza degli utenti attivi in orario d’ufficio, la finestra di manutenzione dovrebbe partire dopo la chiusura dell’ufficio.

Tra i livelli di servizio più importanti, invece, c’è la disponibilità del servizio, ovvero il tempo durante il quale un servizio è disponibile. Di norma si indica come percentuale su un intervallo temporale. Per esempio una disponibilità del 99.9% in orario 7-21, su base giornaliera significa che il servizio potrebbe essere indisponibile al massimo per 8 minuti e 24 secondi nelle 14 ore considerate. Questo vuol dire, per un servizio che prevede l’invio di un documento a un sistema di protocollazione, che il funzionario di un Comune potrà attendere al massimo poco più di 8 minuti consecutivi, prima che questo possa essere considerato un disservizio.

Con l’esclusione dei sistemi di emergenza, di comunicazioni istantanea e di raccolta dati in tempo reale, che già dovrebbero essere ridondanti – ovvero avere ogni componente del servizio disponibile in multiple istanze – oppure che necessitano di processare immediatamente i dati in locale, come ad esempio quelli degli ospedali e degli aeroporti, in generale i servizi della PA, e in particolare quelli rivolti al pubblico, non hanno bisogno di avere dei livelli di disponibilità così elevata da rappresentare un grave ostacolo alla migrazione. Anzi, è molto probabile che più un servizio sia organizzato per garantire alte disponibilità, maggiori siano le ridondanze previste per permettere di fare manutenzione e migrazione senza interrompere in maniera drastica il servizio.

_{^{Some rights reserved – Copyright Joel Carnat (joel at carnat dot net) www.tumfatig.net}}

Pianificazione della migrazione

Il modo di gestire la continuità di servizio è diverso a seconda della modalità di migrazione scelta, della maturità tecnologica del servizio di partenza e anche dalle competenze e dalla documentazione interna in uso in quella specifica amministrazione. La pianificazione della migrazione dovrà inoltre tenere in considerazione i livelli di servizio da rispettare e l’impatto che possono avere sulla strategia di migrazione.

Ad oggi, nel caso di Comuni e scuole, sono finanziate con i fondi del PNRR due modalità di migrazione, in linea con quanto previsto dal Regolamento cloud:

• il trasferimento in sicurezza dell’infrastruttura IT (Lift & Shift, anche detta Rehost);
• l’aggiornamento in sicurezza di applicazioni in Cloud (tramite repurchase/replace o replatform).

Valutare la scelta migliore è un’attività che richiede vari passaggi. Il primo è una mappatura delle competenze interne e/o dei fornitori, in modo da avere un quadro realistico della padronanza, da parte del gruppo di lavoro, delle competenze necessarie per gestire una migrazione; il secondo è stabilire l’ordine di migrazione degli applicativi, che è parte integrante del processo di migrazione e può pregiudicarne il risultato.

Migrazione con trasferimento

È il caso più semplice: l’applicazione viene spostata in cloud con modifiche minime. La modalità più comune per effettuare una migrazione con trasferimento (lift & shift) è spegnere il servizio, trasferire software e dati, per poi riaccendere l’applicativo. Se le finestre di manutenzione previste per ogni servizio sono abbastanza ampie da permettere la sincronizzazione, il problema della continuità di erogazione può essere considerato inesistente.

Se le finestre di manutenzione sono invece troppo strette, o le dipendenze fra i servizi sono tali per cui non è possibile migrare più servizi in una finestra di manutenzione, si possono mettere in atto correttivi temporanei, per esempio mettendo in comunicazione il servizio locale (on premise) con quello remote (in cloud) tramite una rete privata temporanea (VPN), tramite un proxy o un sistema di reindirizzamento del traffico.

Il concetto di migrazione al cloud è ormai radicato, e per questo esistono soluzioni specifiche, sia prodotte direttamente dalle software house che titolari del software, sia dai cloud provider, sia da terzi e dalla comunità che agevolano e automatizzano gran parte della migrazione, e che prevedono anche passi graduali: dalla macchina fisica in locale si passa ad una macchina virtuale (VM) in locale che si avvale di dischi virtuali (chiamati volumi) per i quali esistono appositi strumenti di sincronizzazione con il corrispondente volume remoto in cloud. Suddividendo i passi nella migrazione si suddividono anche i tempi di fermo servizio ed i rischi, favorendo così la continuità del servizio.

Migrazione con aggiornamento

Nel caso di una migrazione con aggiornamento, la continuità del servizio dipende fortemente dalle condizioni di partenza e di arrivo, che possono essere molto diverse. Con questo tipo di migrazione, i casi di arrivo previsti sono due:

• repurchase/replace, ovvero ricomprare un servizio come rimpiazzo completo, ad esempio partendo da una soluzione di posta elettronica installata in casa si arriva a un servizio gestito in SaaS (Software as a Service);
• rearchitect, ovvero ri-fattorizzare il servizio per renderlo più aderente al modello cloud. In questo caso, partendo da un'applicazione monolitica si possono spacchettare le varie funzionalità anche in funzione delle caratteristiche del cloud, per esempio riprogettando l'applicazione per reagire ad i picchi di richiesta con un’elasticità orizzontale data dalle risorse del cloud provider.

In entrambe le modalità è possibile garantire una continuità di servizio senza grandi interventi, a patto che il nuovo sistema, il nostro punto di arrivo, sia anzitutto predisposto per importare in ogni momento i dati di quello “vecchio” e, contemporaneamente, che i dati presenti nel punto di partenza siano resi indisponibili oppure in sola lettura.

Un servizio che può essere facilmente migrato con l’export continuo è per esempio la posta elettronica. I messaggi che temporaneamente, durante la fase di passaggio dal vecchio al nuovo (di norma chiamata switchover), arrivano al vecchio sistema possono essere automaticamente importati nel nuovo. Nessun messaggio sarà perso, ma sarà disponibile nel nuovo punto di arrivo con un leggero ritardo temporale, misurabile in pochi minuti.

In ogni caso è buona prassi che le amministrazioni prevedano, in fase di redazione del piano di migrazione, anche una fase di dimensionamento e di test, in modo da evitare possibili “salti nel vuoto” e di stimare l’impatto della migrazione sull’effettiva disponibilità del servizio, prevedendo, dove necessarie, le opportune azioni di comunicazione.

Suggerimenti conclusivi

Il manuale di abilitazione al cloud è un’ottima fonte per familiarizzare con i vari aspetti della migrazione e può fornire lo spunto per approfondire numerosi temi offerti dal modello Cloud della PA. Il manuale offre una panoramica più fine di quella discussa qui delle modalità di migrazione, comprendendo ad esempio anche il replatform, che è qualcosa di intermedio fra il rehost e il rearchitect, una sorta di rifattorizzazione parziale.

In generale, comunque, nella fase di redazione del piano di migrazione si terrà conto dei livelli di continuità richiesti e si potranno indirizzare le criticità rilevate con diversi strumenti ed artifici tecnici che dipendono fortemente dalle tecnologie in uso. Un confronto con i fornitori attuali e futuri del servizio potrà fornire il quadro tecnico-pratico nel quale muoversi, con l’obiettivo, per ogni PA, di ridurre al minimo – se non azzerare – i messaggi di cortesia che invitano gli utenti di un servizio online a riprovare (tristemente) più tardi.

Approfondisci le prossime tappe della Strategia Cloud Italia e scopri come partecipare agli avvisi del PNRR per la migrazione al cloud dedicati alle amministrazioni.

Questo blog è redatto da Developers Italia

Come Developers Italia e Designers Italia hanno aggiornato uno dei tasselli fondamentali del design system del Paese. Ce lo racconta Andrea Stagi, del Dipartimento per la trasformazione digitale

Il cuore pulsante del nuovo design system del Paese

Designers Italia e Developers Italia hanno avviato una completa revisione del design system del Paese, ovvero degli strumenti e delle risorse necessarie alla realizzazione delle interfacce per i siti e i servizi digitali della Pubblica Amministrazione, così da renderle coerenti, semplici e fruibili da tutti i cittadini. Tra questi strumenti il cuore pulsante è rappresentato dalla versione 2.0 di Bootstrap Italia, un framework di sviluppo front-end basato su Bootstrap 5, del quale si ereditano tutte le funzionalità, completamente open source, e corredato di componenti, griglie e classi di utilità per progettare con qualità tenendo l’accessibilità al centro del design system del Paese.

Togliere la ruggine e rilanciare la community

Il framework Bootstrap Italia è, secondo noi, il modo più semplice e sicuro per costruire interfacce web moderne, inclusive e semplici da mantenere. La sfida di quest’anno è stata quella di aggiornare il vecchio Bootstrap Italia basato sulla versione 4 di Bootstrap e, di seguito, portarlo a Bootstrap 5, migliorando i tool di sviluppo e i componenti grazie a strumenti e tecnologie più moderne e valorizzando i contributi della community.

Come primo passo, abbiamo aggiornato la versione iniziale di Bootstrap Italia risolvendo le issue segnalate e revisionando le pull request (le proposte di contributi) degli utenti. A questa prima fase, è seguito il rilascio di una versione 1.5.0 che comprendeva numerosi miglioramenti delle fondamenta, del core. Insieme a quest’ultima versione abbiamo quindi introdotto Docker (guarda il video della community call su Docker), al fine di facilitare la configurazione dell’ambiente di sviluppo per chi volesse contribuire al codice senza dover impostare un ambiente locale. Ci siamo poi dedicati al rilascio di altre versioni del primo Bootstrap Italia che comprendessero aggiustamenti sull’accessibilità: gli esperti di AgID competenti sul tema hanno collaborato con noi aiutandoci a migliorare accessibilità e usabilità. Questo precedente Bootstrap Italia basato su Bootstrap 4 si trova attualmente alla versione 1.6.3, e da questa versione in poi necessita soltanto di interventi di manutenzione.

Grazie ad un approccio all’accessibilità by design e alle evolutive fatte sulla versione 1.6.3, abbiamo poi avviato la creazione di un repository temporaneo (che sarà presto riportato all’interno del repository principale bootstrap-italia) dove sono iniziati i lavori per il porting a Bootstrap 5, importante passaggio per dare scalabilità e futuribilità a questo progetto, oggi fondamenta del design system del Paese.

La scelta degli strumenti: da Jekyll a Rollup.js

Per mantenere la generazione della documentazione abbiamo confermato, in questa prima fase, la scelta di Jekyll: questo ci ha permesso di concentrarci sulla lavorazione del core evitandoci di dover agire anche sulla parte di documentazione. Docker e Vercel sono stati ugualmente confermati, in quanto tool fondamentali per avere sempre a disposizione anteprime delle modifiche e delle pull request.

Rimaneva da migliorare l’aspetto relativo alla creazione degli asset e dei bundle finali, fino ad adesso gestita con Gulp.js: era necessario sostituirlo con qualcosa di più aggiornato e funzionale alle esigenze di sviluppo web moderne. La nostra scelta è ricaduta su Rollup.js, che oltre a produrre una versione minima di JavaScript e CSS, permette anche di suddividere i vari componenti in moduli JavaScript. Grazie a questa separazione, lo sviluppatore può importare i soli componenti necessari per l’applicazione che sta sviluppando, attuando quello che in termine tecnico si definisce tree-shaking.

Ottimizzare il codice

Grazie al tree-shaking è possibile limitare la dimensione del JavaScript finale, in modo da velocizzare le performance del sito. Un esempio lo potete trovare in questo repository dove abbiamo inserito all’interno di una singola pagina web alcuni componenti di Bootstrap Italia 2.0.

Ma come si utilizzano questi componenti e come entra in gioco il tree-shaking? Ad esempio se volessi utilizzare solo il componente Carousel di Bootstrap Italia, occorre creare il codice markup ad hoc come da documentazione, importare il solo componente “CarouselBI”

import { CarouselBI } from "bootstrap-italia"

e istanziare il componente passando il riferimento all’elemento radice che abbiamo nel markup (nell'esempio un div con id “myCarousel”).

const carousel = new CarouselBI(document.getElementById("myCarousel"))

Utilizzando un bundler che supporta il tree shaking (come Rollup o Webpack), solo Slider e la parte comune di JavaScript verranno inseriti nel bundle finale e non l’intero Bootstrap Italia.

Da alcuni test fatti, le dimensioni del JavaScript finale sono risultate nettamente ridotte rispetto all’importazione dell’intero framework Bootstrap Italia. Ecco qualche dato qui sotto, relativo alla demo:

Dimensioni Bootstrap Italia JS: 344 KB Dimensioni Demo JS: 133 KB

Ovviamente, è possibile intervenire anche sul CSS, in quanto tutti i fogli di stile sono suddivisi per componente e disponibili in formato SASS.

@import "bootstrap-italia/src/scss/custom/slider";

Sempre guardando l’esempio qui sopra, possiamo anche notare una notevole riduzione delle dimensioni del CSS finale:

Dimensioni Bootstrap Italia CSS: 501 KB Dimensioni Demo CSS: 209 KB

L’evoluzione del design system del Paese

Grazie al nuovo Bootstrap Italia, i siti e i servizi digitali della Pubblica Amministrazione e i modelli proposti da Designers Italia per i Comuni e le scuole, permettono di rispettare con più facilità i criteri di accessibilità definiti dalle Linee guida accessibilità e dalle relative WCAG 2.1, permettendo quindi una progettazione e uno sviluppo by default, e by design, più accessibile. Questo, inoltre, consente di facilitare l’adesione alla misura 1.4.1 del PNRR (Esperienza del Cittadino nei servizi pubblici) e di migliorare, in generale, le performance, l’usabilità e la soddisfazione d’uso di tutti i siti internet e i servizi digitali della Pubblica Amministrazione.

Tutti i cambiamenti effettuati su Bootstrap Italia nel passaggio a Bootstrap 5, e i consigli utili per effettuare la migrazione dal precedente Bootstrap 4, sono disponibili sulla pagina dedicata della documentazione.

Scopri di più e partecipa

• Durante il Community lab dello scorso 23 marzo abbiamo iniziato a raccontare il contesto e il lavoro fatto in questi mesi su Bootstrap Italia. Guarda la registrazione.
• Nell’articolo medium Progettare con qualità: l’accessibilità al centro del design system del Paese puoi approfondire gli orizzonti ideali e pratici con cui in questi mesi abbiamo approcciato questo lavoro.
• Il design system del Paese è un progetto in continua evoluzione: invia i tuoi feedback e le tue segnalazioni per aiutarci a migliorare: scrivici su Slack di Developers Italia e Designers Italia.

---

Questo blog è pubblicato sul canale Medium di Developers Italia

Questo blog è redatto da Developers Italia

Vincenzo Di Nicola ci racconta come INPS ha adattato un software di qualità per identificare e segnalare malfunzionamenti tecnici, al fine di migliorare la qualità dei propri servizi.

Nessun prodotto software è perfetto, ed è sbagliato pensare altrimenti. Ricordo bene come 15-20 anni fa chi comprava il Mac era solito recitare il dogma “i sistemi Apple sono sicuri e non hanno virus”.

La realtà è però ben diversa e se ne infischia degli slogan del marketing. Gli stessi colossi tech americani come ad esempio Meta (capitalizzazione 500 miliardi di dollari) hanno spesso problemi tecnici, come abbiamo tutti toccato con mano con i “down” di WhatsApp, Instagram e Facebook.

INPS, Istituto Nazionale Previdenza Sociale, non è un’eccezione, e come tutti i sistemi informatici ha le sue sfide da risolvere. E per alcuni versi quelle di INPS sono ancora più complesse di quelle di una Twitter o una Coinbase. Perché? Queste appena citate sono compagnie tech nate negli ultimi 15 anni, e hanno costruito organicamente la loro codebase da zero e nativamente nel cloud.

INPS invece è stata una pioniera informatica nella Pubblica Amministrazione a livello mondiale, digitalizzando i servizi già negli anni ‘80 (grande merito va alla lungimiranza di Gianni Billia. Va però sempre tenuto bene a mente che i meriti informatici non migliorano nel tempo come un buon vino. Tutt’altro. Senza costante e assidua innovazione, quello che 40 anni fa era un punto di forza oggi si trasforma in una debolezza. Come?

L’INPS serve gli Italiani tramite più di 450 servizi online, in continuo adeguamento soprattutto normativo. Alcuni, i più recenti, sono costruiti secondo le migliori tecnologie moderne. Altri invece affondano le proprie radici su mainframe e Cobol: sistemi e tecnologie che hanno fatto la Storia dell’Informatica, ma che ormai mostrano tutti i segni del tempo.

Sia ben chiaro, questo non riguarda solo INPS e l’Italia: pubbliche amministrazioni, e anche istituti finanziari, ovunque nel mondo hanno lo stesso problema, che si è acuito pesantemente durante la pandemia. I governatori di vari stati degli USA se ne sono ben resi conto: come fai a sostenere emergenze e mettere mano a tecnologie di mezzo secolo fa, quando chi le conosceva ormai è in pensione se non deceduto?

In INPS abbiamo preso una decisione consapevole. Invece di metterci le classiche pezze e creare i cosiddetti “accrocchi”, che nulla fanno se non complicare la situazione, aumentare i costi e posticipare l’inevitabile, in INPS abbiamo deciso di affrontare la situazione di petto e aggiornare man mano sistemi e architetture. Sforzo titanico che, come si dice in America, “will pay dividends” nei prossimi anni. Allo stesso tempo, come conseguenza di questo processo di crescita, potrebbero crearsi malfunzionamenti temporanei o nuovi bug.

Collaborare con la cittadinanza: i primi risultati

40 Milioni di utenti con esigenze molte volte uniche, e più di 450 servizi digitali basati su tecnologie sia moderne che legacy. In una frase questa è la sfida quotidiana all’INPS, e non è sempre semplice affrontarla.

Allo stesso tempo, da quando lavoro in INPS mi ha colpito vedere come tante persone abbiano espresso il loro desiderio di aiutare noi (e di conseguenza, tutti gli Italiani).

Per questo, lo scorso novembre in INPS abbiamo lanciato uno strumento per recepire al meglio la loro voce e fare tesoro dei loro commenti: bugs.inps.it. Si tratta di un sito dove gli utenti possono segnalare malfunzionamenti tecnici e dare ad INPS informazioni utili per la loro risoluzione.

Uno sforzo congiunto della Struttura Tecnica per l’Innovazione Tecnologica e la Trasformazione Digitale e della Direzione Centrale Tecnologia, Informatica e Innovazione in cui, in ottica di totale apertura e trasparenza, abbiamo chiesto aiuto ai cittadini per i cittadini. La risposta è stata davvero incoraggiante. Personalmente ci tengo a ringraziare tutti quanti hanno dedicato un po’ del loro tempo per comunicarci i problemi sperimentati, specialmente se con dettagli e i cosiddetti repro steps. Un esempio è qua sotto.

Non è retorica. È davvero di grande aiuto a noi in INPS per comprendere meglio i malfunzionamenti che, una volta sistemati, risolvono di conseguenza problemi che affliggono tante altre persone. Il commento qui sotto evidenzia molto bene questo circolo virtuoso.

Sia ben chiaro. Stiamo parlando di uno strumento utile ed efficace, ma non certo “rocket science” a livello tecnologico. Questo dimostra che l’innovazione si porta avanti con vari mezzi a grado diverso di sofisticazione: sia a volte usando il bazooka dell’Intelligenza Artificiale, sia altre volte (come questa) abbattendo muri tutti assieme. L’importante è sapere scegliere la soluzione giusta, evitando complessità tecnologiche inutili e focalizzandosi solo sui veri bisogni del cittadino.

Il percorso tecnico: scegliere il sistema

Un’INPS aperta al cittadino deve anche essere aperta nella sua tecnologia. Per questo sin dall’inizio abbiamo pensato a quale sistema Open Source fosse il più adatto per bugs.inps.it. D’altronde, inutile re-inventare la ruota quando ci sono già molti sistemi collaudati che possono essere usati con relativamente poco sforzo di integrazione: il risparmio in termini di tempo, qualità e denaro è evidente.

Bugzilla

Tra i molti prodotti che abbiamo valutato, la scelta iniziale è stata Bugzilla. Soluzione un po’ “vintage” e con una user experience lontana dalla sensibilità attuale, ma allo stesso tempo solida e usata come sistema di bug tracking da progetti come Eclipse e compagnie come Red Hat. Però quando si sceglie un sistema open source la sua storia lascia il passo ad altri parametri ben più importanti, in primis la sua comunità e la manutenibilità del codice.

Valutando Bugzilla, abbiamo constatato che l’ultima sua release stabile risale a 3 anni fa, e c’è scarsa attività di manutenzione del progetto. Abbiamo anche considerato la possibilità di diventare noi, come INPS, contributori attivi del progetto. Purtroppo Bugzilla è scritto in Perl: linguaggio glorioso che amavo usare quando ero sviluppatore a Yahoo! 16 anni fa. Ma ormai è anacronistico pensare di costruire futuro partendo da Perl. Abbiamo quindi abbandonato Bugzilla e valutato altre soluzioni.

Phabricator

La scelta a questo punto è caduta su Phabricator: un sistema moderno di collaborazione e sviluppo software, al cui interno c’è la componente di bug tracking a noi utile. Il sistema è stato sviluppato inizialmente da Facebook, venendo poi rilasciato in modalità open source e usato da enti come Wikimedia (la fondazione creata da Wikipedia).

Phabricator è basato su PHP: linguaggio con tanti pro e contro, la cui popolarità sta progressivamente scemando, ma comunque con una comunità ancora attiva di sviluppatori. Il 29 Maggio decidiamo quindi di usare Phabricator come base per bugs.inps.it e di partire col progetto. Sennonché, come da manuale della legge di Murphy, esattamente il giorno dopo vediamo questo tweet di Hacker News:

Phabricator quindi non ha più un supporto attivo di manutenzione: viene a mancare proprio la cosa più importante di un progetto open source.

Niente da fare. Siamo punto e a capo.

Entra in gioco Developers Italia

“Uniti ci ergiamo, divisi crolliamo”. È una celebre frase di uno dei padri fondatori degli Stati Uniti d’America, e ben riassume l’importanza del lavoro di squadra in questi contesti.

Uno dei problemi che ho percepito in Italia è che le organizzazioni, sia pubbliche che private, spesso tendono a fare tutto da sole senza valutare sinergie o guardare se altrove sia stato già sviluppato software a loro utile. Per questo, a prescindere dall’invito a inaugurare questo blog, ci tengo a ringraziare Developers Italia: il suo ruolo è stato determinante per il successo tecnico di questo progetto.

Come prima cosa, abbiamo valutato assieme a loro il Catalogo del software open source a disposizione della Pubblica Amministrazione. Purtroppo non abbiamo trovato nulla che soddisfacesse i nostri requisiti e che fosse comunque semplice da customizzare. Su consiglio di Developers Italia abbiamo quindi valutato un progetto esterno di una startup spagnola, sempre comunque disponibile in modalità open source: Taiga.

Taiga

Così come Phabricator, Taiga consiste in una suite di servizi di collaborazione e sviluppo software, tra cui il bug tracking. Semplice da usare e scritto in un linguaggio e framework moderno come Python 3 e Django. Ci tengo sempre a rimarcare l’importanza della tecnologia sottostante: è il motore sotto il cofano di una macchina; non si vede, ma l’impatto di una scelta giusta si percepisce immediatamente e diventa determinante nelle evoluzioni future. Nel nostro caso, avevamo bisogno di customizzare Taiga introducendo nuove funzionalità specifiche ai bisogni INPS. Ce ne sono state varie, ma qui ne cito due in particolare:

1. Visibilità pubblica opzionale
2. Login tramite SPID

Visibilità pubblica opzionale

La prima customizzazione (“visibilità pubblica opzionale”) è fondamentale se pensiamo che il cittadino sta segnalando un bug, e potrebbe inserire informazioni personali nei repro steps o negli allegati con dati sensibili. Per questo, a differenza del Bugzilla di Red Hat dove tutto è pubblico, qui abbiamo introdotto il concetto di ruoli e di visibilità pubblica opzionale, con default privato: in questo modo nessun altro utente (a parte chi ha ruolo di operatore di servizio) può vedere il bug. Questa funzionalità è piaciuta così tanto anche al team di Taiga che, in pieno spirito collaborativo e open source, ha deciso di integrarla nei propri prossimi rilasci. Un win-win per tutti.

Login tramite SPID

La seconda customizzazione rilevante riguarda l’integrazione SPID per il login. Oltre ad essere sempre più spinto dalle nuove norme per standardizzare l’interazione cittadino – Pubblica Amministrazione, il login tramite SPID risolve anche alla radice il grande problema dello spam che affligge i sistemi con username/password generati da qualsiasi utente. Un esempio di questo problema, non ancora risolto, lo evidenzia bene Eclipse in questo thread su Bugzilla.

Nel nostro caso invece, l’apertura a tecnologie web moderne e diffuse ci ha semplificato il compito, spalancandoci altre porte. Infatti, abbiamo potuto riutilizzare il codice già pronto e sviluppato da Developers Italia: la Django app per integrazione SPID con SAML2. L’apoteosi del DRY (Don’t Repeat Yourself) & KISS (Keep It Simple, Stupid) nella vera pratica, e per di più tra enti pubblici. Un qualcosa di cui andiamo davvero orgogliosi.

E sulle ali dell’entusiasmo ci siamo permessi qualche licenza “poetica” sugli errori 404 e 401: piccole cose da nerd, che siamo contenti siano state apprezzate dalla comunità tecnica.

Considerazioni finali

Cosa serve per accedere a bugs.inps.it? Non c’è bisogno di alcuna registrazione. Solamente SPID. Il sito è utilizzabile da mobile, consente visibilità pubblica/privata, e mostra gli avanzamenti di stato della segnalazione tecnica. Il tutto gira su public cloud Azure su macchina Debian 11, ed è scritto in Python 3 con framework Django.

In tema di totale trasparenza, crediamo nell’asserzione “soldi pubblici = codice pubblico”. Per di più, essendo bugs.inps.it basato sul progetto Open Source Taiga, ovviamente il codice è pubblico e consultabile alla pagina GitHub di INPS. Commenti e suggerimenti sono benvenuti. Questa è infine la prima attuazione di “Sirio”, il Design System INPS. Infatti, oltre a questo sito, stiamo lavorando attivamente per fornire una esperienza d’uso piacevole e coerente attraverso tutti i servizi INPS. Cos’altro aggiungere? È stata una bellissima collaborazione tra INPS, Developers Italia (iniziativa del Dipartimento per la trasformazione digitale e Agenzia per l'Italia Digitale) e Taiga (progetto di una startup spagnola), con l’implementazione di AlmavivA.

Pubblica Amministrazione, enti del Governo, startup, privato: tutto al servizio del cittadino.

Il mio augurio personale è che questo sia solo il primo di una lunga serie di esempi che facciano comprendere che sì, in Italia si può costruire tecnologia moderna e utile. E soprattutto che la collaborazione tra enti, per quanto diversi tra loro, è la chiave determinante per questo successo.

Vincenzo Di Nicola, INPS – Responsabile della Struttura Tecnica per l'Innovazione Tecnologica e la Trasformazione Digitale

…

Vuoi segnalare un bug in un servizio INPS? Vai su https://bugs.inps.it e contribuisci.

…

Questo articolo è pubblicato anche sul Medium di Developers Italia

Questo blog è redatto da Developers Italia