Buone pratiche per sviluppare applicazioni e servizi in modo sicuro, leggero e scalabile nel settore pubblico

di Daniele Pizzolli e Fabrizio De Rosa, Team Cloud Italia del Dipartimento per la trasformazione digitale

Ogni tecnologia che abilita il cloud ha un ruolo preciso, proprio come gli strumenti in un'orchestra di musica classica. E perché la melodia sia armoniosa e avvincente è necessaria una perfetta coordinazione tra tutti gli strumenti in scena.

Oggi parliamo dei “container”, dei veri e propri contenitori digitali che suonano il loro spartito in modo efficiente e sincronizzato, costruendo applicazioni e servizi in modo sicuro, leggero e scalabile. A dirigere la musica c'è il maestro d'orchestra, ad esempio Kubernetes, che ottimizza le risorse in sicurezza, permettendo ai container di collaborare insieme senza stonature. È necessario che l'orchestra sia ben affiatata per offrire prestazioni adeguate al funzionamento di organizzazioni complesse come le amministrazioni pubbliche italiane.

In questo articolo esploreremo alcuni dei passi fondamentali per l'utilizzo di queste tecnologie, analizzandone i benefici e le differenze principali con il modello di migrazione lift and shift, ovvero il semplice trasferimento di dati e servizi che rimangono dentro macchine virtuali.

I container e le virtual machine

I container sono una tecnologia che consente di allocare e isolare risorse, come ad esempio la memoria volatile (RAM) e la CPU, utilizzando il sistema operativo senza la necessità di coinvolgere l'hardware, diversamente da quanto avviene con le macchine virtuali.

Il fatto che l'isolamento sia ottenuto tramite il sistema operativo rende i container più veloci ad accendersi e a spegnersi, in quanto non c'è bisogno di inizializzare l'hardware (seppure emulato) e avviare tutto il sistema operativo della virtual machine (VM). Queste ultime risultano meno isolate, venendo a mancare la separazione netta a livello di CPU gestita dall'hypervisor, ovvero lo strato di software che gestisce le macchine virtuali dialogando con l'hardware.

Come in altri ambiti dell'informatica, non è tutto o bianco o nero: la distinzione fra container e VM, a seconda delle tecnologie usate, può non essere così evidente.

Da un lato ci sono container gestiti integralmente dal sistema operativo, dall'altro VM con uno strato di sistema operativo così esiguo da essere assimilabili a container.

Come si costruisce un container

La costruzione dell'immagine di un container è molto simile a quella di una VM, ma per fortuna molto più standardizzata. Se le immagini delle VM sono molto differenti a seconda della tecnologia, per i container c'è una buona standardizzazione de-facto nel formato dell'immagine (Image Format Specification), delle configurazioni (Runtime Specification) e la distribuzione degli artefatti (Distribution Specification) portati avanti dall'Open Container Initiative (OCI).

L'immagine di un container si può trovare sia preparata dal fornitore del software o da system integrator di terze parti, che costruita a partire da immagini di base, di norma condivise direttamente dai vari produttori di sistemi operativi all'interno di un processo automatizzato di Continuouos Integration/Continuous Delivery (CI/CD).

Qui è possibile notare le prime differenze sostanziali con le VM. Le buone pratiche per la gestione dei container prevedono che l'immagine sia stateless, ovvero che non porti con sé nessuna informazione specifica legata alla singola istanza (o al singolo deploy, se preferiamo la nomenclatura inglese). Le configurazioni vengono infatti applicate tramite appositi file o variabili d'ambiente al momento dell'inizializzazione e i dati persistenti sono archiviati in appositi volumi o database, o ancora meglio in sistemi di storage e database distribuiti, al contrario di quanto avviene solitamente con i monoliti nelle VM dove software, configurazioni e dati sono accorpati.

L'immagine di un container deve essere quindi costruita per auto-configurarsi alla partenza, cosa fattibile ma non banale in quanto richiede competenze DevOps.

Se la sicurezza riveste un ruolo prioritario, è meglio introdurre nel gruppo di lavoro anche competenze di tipo DevSecOps.

Un' orchestra per migliorare l'ottimizzazione delle risorse

Per eseguire e gestire un'immagine di un container si possono usare vari sistemi, dai più semplici basati su configurazioni più o meno statiche, eseguite all'interno di una VM, fino a sofisticati sistemi di orchestrazione che prevedono il monitoraggio delle risorse, il rilevamento di condizioni di criticità e la scalabilità automatica, spesso offerti come servizi SaaS dai cloud provider.

I sistemi più semplici sono facili da adottare, ma non consentono configurazioni che permettono di operare risparmi in base all'utilizzo di tali sistemi.

I cloud provider mettono a disposizione varie interfacce ed API per gestire il tutto. Il sistema di gran lunga più diffuso è certamente Kubernetes, un progetto Free e Open Source gestito dalla Cloud Native Computing Foundation (CNCF), il direttore d'orchestra dei container. Di solito ogni provider personalizza l'offerta con varie estensioni più o meno aperte o proprietarie.

La base comune di Kubernetes aiuta a ridurre il rischio di lock-in.

Le personalizzazioni dei cloud provider possono rappresentare un vantaggio gestionale, ma talvolta introducono complicazioni. Il campo dei sistemi di container orchestration è in continua evoluzione e ci sono decine di sistemi che rientrano nella definizione. Tra i più noti menzioniamo Docker Swarm e Nomad. Ci sono poi strumenti di gestione dei sistemi di container orchestration, come OpenShift o Rancher o appunto i sistemi messi a disposizione da ogni cloud provider. A volte le differenze fra i sistemi sono minime, a volte sostanziali. Anche in questo campo l'introduzione di automatismi basati su quello che comunemente viene chiamato “intelligenza artificiale” porterà ad ulteriori possibili scelte gestionali.

La complessità gestionale di introdurre un orchestratore di container è ripagata da un aumento della flessibilità, della resilienza, dell'ottimizzazione delle risorse, ottenibile dopo aver conseguito una certa esperienza.

Se tendenzialmente nelle VM che ospitano servizi in produzione l'accensione e lo spegnimento sono eventi rarissimi, di contro i container dovrebbero essere adottati per essere continuamente accesi e spenti oltre a lavorare in parallelo per ottenere quella che viene definita la scalabilità orizzontale

In questo modo il fallimento del singolo non si ripercuote sul sistema, che può anche essere aggiornato velocemente e gradualmente.

Da virtual machine a container

Bisogna partire da un'analisi dell'applicazione che si vuole migrare. Un buon approccio è sintetizzato nel paradigma dei 12 fattori per le applicazioni, o in generale nelle migliori pratiche della containerizzazione, riassunte qui. Di certo alcuni requisiti, come quello di non usare dati locali, potrebbero essere difficili da soddisfare se l'applicazione è un monolite pensato per lavorare direttamente sul filesystem: in questo caso la componente dello storage dell'applicazione andrà completamente ri-fattorizzata.

Fino a che tutte le buone pratiche non saranno soddisfatte, l'applicazione continuerà a vivere in una VM e solo quando raggiungerà la flessibilità necessaria per essere containerizzata potrà essere migrata sui container.

In questo caso sarà utile, parallelamente al processo di ri-fattorizzazione dell'applicazione, ristrutturare l'ambiente di Continuos Integration (CI) e Continuos Delivery (CD) per produrre le immagini dell'applicazione e per testarle automaticamente. Nell'ambiente di CI si possono inserire anche processi di scansione delle dipendenze per vulnerabilità note, sistemi di controllo della formattazione e della percentuale di codice coperto da test, che contribuiscono a migliorare la qualità del codice dell'applicazione e a tenere sotto controllo gli aspetti più visibili della sicurezza. È possibile trovare un esempio delle raccomandazioni della CNCF qui.

Come risparmiare: un esempio pratico

I container sono eseguiti all'interno di VM o direttamente nelle macchine fisiche o all'interno di cluster condivisi messi a disposizione e completamente gestiti dai cloud provider.

Nel caso venga utilizzato un cluster dedicato, al fine di ottenere dei risparmi legati all'uso delle risorse su scale medio/grandi, il sistema di orchestrazione tiene conto delle risorse richieste in tempo reale e rilascia le risorse non necessarie.

Ad esempio, facendo gestire il carico dei nodi ad un sistema di orchestrazione di container, 100 macchine virtuali con un utilizzo medio della CPU del 50% possono essere ridotte a 63, se teniamo come parametro di utilizzo medio della CPU l'80%.

Se viene rilevato un utilizzo medio delle risorse superiore, il meccanismo di autoscaling aggiungerà nuove VM al cluster. La soglia dell'80% è una soglia arbitraria, da valutare di caso in caso, per esempio, bilanciando i tempi di risposta dell'applicazione con la riserva di CPU che si vuole tenere.

Allo stesso modo, è possibile ottimizzare l'utilizzo della RAM e ovviamente bisogna tenere in considerazione anche il picco di richieste alla rete e le richieste verso lo storage.

Dopo aver messo in piedi il sistema e monitorato le prestazioni per un periodo ragionevole, è possibile analizzare i dati per determinare il numero ottimale di VM da mantenere stabilmente, ottenendo risparmi significativi a lungo termine. I picchi di utilizzo, invece, possono essere gestiti con risorse a consumo, riducendo i costi complessivi.

Un'analisi dei costi dovrebbe anche tenere conto della maggiore resilienza del sistema ai guasti o agli attacchi cibernetici.

Quanto costa un'ora di interruzione dei servizi? Quanto tempo ci vuole a ripristinare un sistema basto interamente su VM? Un sistema basato su container, se progettato e gestito correttamente, può garantire un'elevata continuità operativa, riducendo al minimo le interruzioni. Per una disamina più puntuale sull'analisi dei costi rimandiamo al manuale di abilitazione al cloud.

Anomalie e dove trovarle

Quando si collocano diverse applicazioni nello stesso cluster, è importante considerare attentamente la gestione della sicurezza. La gestione dei container segue le buone pratiche: monitora la sicurezza dell'applicazione anche in fase di costruzione dell'artefatto software (build) ed è integrata in un sistema di CI/CD per eseguire un rapido aggiornamento in caso emergessero problematiche, permettendo in questo modo di predisporre una risposta alle minacce in maniera molto efficace. La dinamicità offerta dai container permette anche di adottare paradigmi del tipo “service mesh” dove il traffico stesso fra i microservizi è oggetto di osservazione e analisi. Questo consente una rilevazione delle anomalie e una segregazione degli eventuali componenti malfunzionanti in maniera molto puntuale e precisa rispetto ad un'applicazione servita da un applicativo monolitico eseguito all'interno di una VM.

Cambio di paradigma: da tutto statico a tutto dinamico

La tecnologia dei container porta con sé un radicale cambio di paradigma, dove alla staticità delle VM si affianca la dinamicità dei container. Per questo non è facile pensare ad una transizione fluida da una tecnologia all'altra. Ci saranno necessariamente dei salti da effettuare, ad esempio nel migrare lo storage locale a quello distribuito, che devono essere progettati con attenzione e testati sul campo prima di arrivare in produzione. Allo stesso modo il paradigma *stateless*, dove i container non devono tenere lo stato dell'applicazione cambia l'approccio alla gestione dei dati. Le operazioni di backup e di restore dei dati, così come la gestione degli aggiornamenti nello schema del database, devono essere adattate agli strumenti e alle pratiche della gestione container.

È importante notare che non tutte le applicazioni (o parti di applicazioni) si sposano bene con il paradigma dei container.

In questo caso si deve valutare se l'applicazione possa essere sostituita da un servizio cloud nativo del provider (per esempio nel caso di database) o mantenuto all'interno di una VM.

Il gioco di squadra è (quasi) tutto

Per arrivare a questo traguardo occorre creare un gruppo di lavoro ben affiatato, aggiornato sulle buone pratiche e con gli strumenti giusti a disposizione. La competenza sui container, oggetti molto più leggeri, ma anche effimeri, rispetto alle virtual machine, non si improvvisa. Esistono però innumerevoli risorse, dai tutorial alla documentazione e al materiale dei workshop liberamente scaricabile, fino a corsi e sessioni pratiche su una particolare tecnologia. Il processo di refactoring di un'applicazione per il cloud dovrà necessariamente far riprogrammare i gruppi di lavoro e la loro organizzazione: prima i developer sviluppavano il software e i sysadmin lo installavano manualmente sulle virtual machine.

Oggi con i container tutto deve essere più fluido e integrato per garantire un funzionamento ottimale.

Se non si dispone di molte competenze interne, per alcune tecnologie o framework di programmazione, i cloud provider, o terze parti, mettono a disposizione degli strumenti di valutazione della prontezza (readiness) dell'applicazione al fine di essere migrata da VM a provider, e in alcuni casi il processo può anche essere automatizzato. Tali strumenti possono essere molto potenti, ma di contro sono molto invasivi e non si consiglia di utilizzarli nell'istanza di produzione con i dati reali. Usare il primo strumento che si trova (spesso richiede solo pochi clic) sarebbe equivalente a consegnare le proprie chiavi di casa ad uno sconosciuto che si propone di valutarla per fare una proposta di ristrutturazione. Fidarsi è bene, non fidarsi del tutto è meglio. Prima di un utilizzo effettivo è necessario valutare l'impatto sulla sicurezza che comporta questo accesso privilegiato.

Che si scelga di affidarsi a una squadra interna o al supporto di consulenti e strumenti specializzati, la migrazione ai container rappresenta un passo importante verso sistemi più resilienti e performanti.

Mappare le competenze

I container sono una tecnologia necessaria per stare al passo con i tempi. In questo approfondimento ci siamo focalizzati sui benefici in fase di gestione, ma la loro adozione permette anche di usufruire di ambienti di sviluppo più controllati, insieme a sistemi di test e staging più facili da gestire, abilitando l'adozione di sistemi e architetture orientate ai microservizi.

La tecnologia e l'offerta di servizi, in continua evoluzione, è certamente matura per essere adottata senza controindicazioni nella maggioranza dei casi.

L'effettiva gestione della VM o del cluster sul quale vengono eseguiti i container può essere delegata ad un modello SaaS (Software as a Service) specializzato, a volte chiamato CaaS (Container as a Service), dove si delega la complessa gestione dell'infrastruttura sottostante al cloud provider per focalizzarsi sullo sviluppo dell'applicazione.

La tecnologia ha raggiunto uno stato di standardizzazione tale che, anche se prendessimo decisioni errate per la migrazione a questo modello, comunque riusciremmo facilmente a cambiare i componenti che non soddisfano più le nostre esigenze o il sistema di orchestrazione senza grossi contraccolpi, assicurando così continuità operativa.

Mappare le competenze è il primo passo fondamentale per adottare i container senza troppi timori. Comincia questo percorso leggendo il manuale di abilitazione al cloud.

:::

Le immagini presenti in questo articolo sono state sviluppate con il supporto dell’Intelligenza Artificiale con l’obiettivo di rappresentare visivamente i temi trattati.

Questo blog è redatto da Developers Italia

Suggerimenti per generare risparmi grazie all’utilizzo di sistemi cloud

di Daniele Pizzolli, Matteo Vabanesi e Fabrizio De Rosa, Team Cloud Italia del Dipartimento per la trasformazione digitale

C’è una regola non scritta tra gli amministratori di sistema on premise: se tutto funziona, non cambiare configurazione. Una consuetudine che non sempre risulta però ottimale quando si passa al cloud, soprattutto quando si parla di bilanci e di contabilità. Grazie al cloud, infatti, le amministrazioni possono generare considerevoli risparmi e migliorare la gestione complessiva dei servizi. Ma come fare? Quali sono le voci di costo sulle quali agire?

Il primo passo è sicuramente quello di monitorare in maniera costante la spesa cloud, un aspetto fondamentale (come sappiamo) per favorire un’efficace allocazione di risorse. Purtroppo, però, tracciare i consumi senza entrare nel merito del contenimento dei costi non è sufficiente, anche alla luce di possibili disallineamenti fra le previsioni di spesa e l’effettivo fabbisogno di risorse collegato a una migrazione in cloud di dati e sistemi informativi. Vediamo alcuni esempi.

Perché i costi sembrano aumentare dopo una migrazione in cloud

Delineare con precisione una matrice dei costi è un’operazione molto complessa, dato che ogni singolo ente può essere considerato come un caso particolare, sia per composizione del conto economico sia per offerta di servizi e forniture. È il motivo per cui, nella stima dei costi, le amministrazioni possono incorrere nel rischio di errori di valutazione, imprecisioni in buona parte riassumibili nelle seguenti tipologie, elencate non in ordine di importanza:

• censimento incompleto dei servizi interessati alla migrazione in cloud e delle loro dipendenze, con conseguenti errori nelle stime iniziali di spesa;
• acquisto di risorse cloud non necessarie, spesso dovuto alle difficoltà di ottimizzare le performance degli stessi servizi cloud e ai vincoli amministrativi delle pubbliche amministrazioni, che può condurre a una sovrastima dei costi alternativa all’approvvigionamento di forniture in corso d’opera;
• fornitura di servizi cloud che non contemplano servizi accessori, ma essenziali, come l’attivazione dei servizi di backup;
• mancata considerazione iniziale dei servizi correlati, che aumentano la sicurezza dei sistemi, come ad esempio web application firewall (per filtrare le richieste a siti e servizi web), log analyzer (per avere sotto controllo lo storico delle azioni e delle richieste), costi di infrastruttura (connettività dedicata, storage addizionale);
• errata stima dei costi per il supporto di personale specializzato, come Cloud Application Architect, Cloud Application Specialist, Cloud Security Specialist, DevOps, System and Network Administrator.

Come rendere effettivo il risparmio grazie al cloud

Anzitutto è necessario sottolineare che in caso di errato censimento dei servizi da migrare in cloud non è possibile attuare alcuna strategia di mitigazione. La buona notizia, però, è che in tutti gli altri casi si possono mettere in campo soluzioni ad hoc per rendere effettivi i risparmi.

Lavorare con il cloud, infatti, rende subito evidenti i costi sottesi alle scelte.

Per esempio, lo storage si paga a consumo e quindi i log vecchi, i risultati delle build oppure i file temporanei, che in un’infrastruttura locale potevano essere dimenticati su dischi comprati e ammortizzati, devono invece essere ruotati, processati, eventualmente compressi ed archiviati in storage a basso costo, oppure eliminati.

Utilizzare una classificazione per tag (o label, per parole chiave) dei servizi attivati in cloud permette di capire dove vengono spese le risorse, e iniziare a dimensionare al meglio le forniture.

Così se l’amministrazione dispone di tre siti web, per semplicità ognuno associato ai servizi di front-end, back-end e storage, con opportune etichette è possibile raggruppare i costi per singolo sito o per servizio, e individuare eventuali correttivi dove le spese sono meno ottimizzate.

Un altro esempio può riguardare l’esistenza di processi duplicati o ridondanti, oppure semplicemente inefficienti. Il caso classico è quello dei cloud provider che si fanno pagare i dati in uscita. Se l’utilizzo di servizi basati su sincronizzazione dati non generava costi all’interno di un’infrastruttura locale, con la migrazione in cloud le spese sostenute per gli stessi servizi sono destinate ad aumentare in maniera significativa. Anche in questo caso, però, la soluzione è semplice: basta modificare il processo di sincronizzazione, passando, ad esempio, da una copia intera a una copia differenziale, per ridurre di conseguenza le spese.

Dove iniziare a mappare gli sprechi

Non occorre essere FinOps (la figura professionale che si occupa del monitoraggio continuo dei sistemi cloud) per iniziare a mappare gli sprechi, anche se, come ovvio, avvalersi di personale specializzato è sicuramente un punto di forza. Questo perché, come abbiamo visto, il primo problema da affrontare è di natura culturale: se tutto funziona, allora non toccare niente. Che significa nessuna riconfigurazione dei servizi cloud. Anche perché, se qualcosa andasse storto, tutti sarebbero pronti a lamentarsi. Quindi per quale motivo prendersi dei rischi?

Eppure è proprio dietro le quinte, mentre tutto “funziona” alla perfezione o quasi, che è possibile attuare delle strategie di risparmio.

Ad alto livello, una razionalizzazione delle modalità di gestione del ciclo di vita del software, mediante metodologie e strumenti condivisi e uniformi, dovrebbe aiutare a consolidare l’esperienza degli operatori, come gli amministratori di rete e di sistema oppure i DevOps.

Ad esempio, se i servizi sono distribuiti su macchine virtuali (virtual machines), magari con diversi software di gestione (hypervisor) e sistemi di orchestrazione di container (cluster kubernetes), sarà necessario avere un esperto in ogni dominio; mentre riuscire a convogliare tutto su un cluster kubernetes, o comunque verso un’architettura nativa cloud, significa sfruttare al meglio le conoscenze del gruppo di lavoro.

Certo, qui entra fortemente in gioco la dimensione della squadra che si occupa della gestione ordinaria, le cosiddette operations: gruppi di lavoro dalle dimensioni ridotte dovranno necessariamente concentrare gli sforzi, mentre avere un team dedicato permette di esplorare soluzioni a più ampio respiro, che consentono anche elevati risparmi. In ogni caso, c’è comunque da sottolineare un aspetto: più le componenti del software utilizzato per gestire servizi cloud appartengono a una soluzione proprietaria, e quindi “chiusa”, più sarà difficile ottimizzare i costi di gestione per un team interno.

Molto spesso, infatti, i fornitori di software (vendor) raccomandano determinate specifiche di macchine virtuali che potrebbero risultare sovradimensionate. Se con le soluzioni on premise questo comportava, per l’ente, l’acquisto una tantum di un server più potente, con il paradigma cloud ciò significa invece sostenere ogni mese dei costi per risorse inutilizzate, come ad esempio CPU e licenze (che di solito sono legate al numero di CPU).

Ottimizzare un’applicazione per il cloud consente di generare risparmi considerevoli, a fronte di un investimento iniziale comunque rilevante.

Ogni applicazione fa storia a sé, ma in generale la migrazione verso un’architettura a microservizi renderà evidenti i servizi più avidi di risorse, indicando la strada per ulteriori semplificazioni. Ad esempio, l’auto-scaling, ovvero l’aumento di risorse per una data applicazione in seguito all’aumento di richieste (immaginiamo un picco di collegamenti al lancio di una nuova iniziativa o all’avvicinarsi della scadenza) gestito in maniera automatica e dinamica dal sistema, è un modo per bilanciare le prestazioni con le spese.

In generale, il consuntivo dei costi nel cloud dovrebbe essere mantenuto al di sotto del 10% di scostamento da quanto preventivato. Ma come trovare il giusto bilanciamento tra costi e servizi cloud offerti dai provider?

Una soluzione potrebbe essere quella di testare diverse taglie di macchine virtuali, oppure il dimensionamento dei cluster a disposizione. Questo naturalmente presuppone che ci siano dei test automatizzati e dei report di prestazioni che guidino nell’ottimizzazione. Se questi non sono presenti, andare per tentativi potrebbe risultare lungo e poco fruttuoso.

Come bilanciare il risparmio con le esigenze di sistema

Se si vuole ottenere un risparmio, o per lo meno contenere le spese, migrare dati e servizi in cloud non dovrebbe limitarsi a un semplice lift and shift.

Ogni servizio andrebbe analizzato per essere adattato alla flessibilità del cloud.

Ad esempio, le elaborazioni periodiche, fatte dietro le quinte, come la generazione di avvisi a una certa scadenza, di solito non necessitano di prestazioni garantite e sono un ottimo esempio di lavoro che può essere delegato a istanze non garantite, che non devono soddisfare requisiti stringenti in termini di performance.

Un’altra situazione ricorrente riguarda gli ambienti di test pre-produzione e il buon funzionamento dei sistemi di backup. In questi casi, infatti, non è necessario avere a disposizione delle macchine virtuali garantite, perché le prestazioni non sono importanti e i dati possono essere creati e distrutti all’occorrenza. Se un test dovesse fallire a causa delle performance non elevate del sistema, sarebbe comunque semplice accorgersene e rilanciare la sessione di test. L’attesa di un nuovo ciclo verrà comunque bilanciata dal risparmio generato.

Un’altra possibilità per generare risparmi è quella di effettuare una ricognizione sulle scontistiche del cloud provider, che spesso offrono pacchetti con varie scadenze e dimensioni. Si possono trovare sconti importanti, se vengono sottoscritti impegni per determinati livelli di consumo annuali oppure, come spesso avviene, per i successivi tre anni; così come è possibile generare risparmi se si scelgono prestazioni limitate, con addirittura lo spegnimento senza preavviso di alcune macchine in caso di scarso utilizzo — macchine che in realtà il cloud provider assegnerà in tempo reale ad altri destinatari.

Ogni cloud provider prevede un set di servizi più o meno compatibili con quelli offerti dalle altre aziende concorrenti. Maggiore è l’acquisto (e l’utilizzo) di servizi diffusi, più sarà facile migrare da un cloud provider all’altro per ottimizzare i costi, specialmente — lo ribadiamo — se questi sono basati su standard aperti o software libero.

Purtroppo, infatti, sono noti alcuni casi in cui fornitori di software, una volta acquisita la proprietà di una tecnologia molto diffusa presso i cloud provider, hanno incrementato considerevolmente il costo delle licenze d’uso, con inevitabili ripercussioni sui costi delle aziende che offrono servizi cloud e sui loro clienti. In una situazione simile è chiaro che minimizzare il lock-in, magari con una strategia multi-cloud, permette alle amministrazioni di rispondere con la massima flessibilità agli aumenti di spesa, spostando parte delle infrastrutture cloud su altri sistemi più economici, nel minor tempo possibile.

Memento: come evitare casi limite

È interessante notare che una gestione poco oculata dei sistemi cloud può portare anche a dei casi limite, nei quali le amministrazioni si trovano a dover sostenere delle spese per errori di configurazione altrui. Alcuni costi sono infatti calcolati per numero di accessi a una determinata risorsa, ad esempio il numero di volte che un file viene scaricato dall’ object storage — una sorta di archivio virtuale di documenti digitali. Semplificando, è così sufficiente che per sbaglio — o per dolo — venga configurato un software in maniera errata perché uno stesso file venga scaricato milioni di volte, facendo così esplodere i costi di gestione cloud.

Si tratta, purtroppo, di un abuso che si è realmente verificato (per fortuna poi risolto senza conseguenze, salvo le notevoli perdite di tempo). In generale, però, risulta evidente come l’assenza di un monitoraggio costante dei servizi, oltre alla mancata limitazione degli accessi che ci vengono addebitati, può tradursi in spiacevoli sorprese.

Un’analisi puntuale delle soglie di traffico, insieme a un’attenta osservazione periodica del funzionamento dei sistemi, permette così di rivalutare i costi, come sottolineato anche nella sezione dedicata del Manuale di abilitazione al cloud messo a disposizione dal Dipartimento per la trasformazione digitale.

La normalità del cloud, infatti, è il continuo cambiamento, e senza questa consapevolezza è difficile fare passi avanti, anche nel contenimento delle spese.

---

Le immagini presenti in questo articolo sono state sviluppate con il supporto dell’Intelligenza Artificiale con l’obiettivo di rappresentare visivamente i temi trattati.

Questo blog è redatto da Developers Italia

Come predisporre strategie di backup, restore e disaster recovery per proteggere dati e servizi cloud

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

“Siamo spiacenti, tutto questo non sarebbe dovuto accadere”. Recitava grossomodo così, la comunicazione ricevuta nei giorni scorsi dai 620 mila sottoscrittori del fondo di investimento Unisuper, dopo che Google, per un “errore di configurazione” (misconfiguration), aveva inavvertitamente cancellato dal cloud l'intero account della società australiana. Una circostanza “unica nel suo genere”, mai verificatasi prima, spiegavano agli associati del fondo il CEO di Unisuper e il responsabile cloud di Mountain View. Eppure a volte tutto questo succede, ed è proprio per minimizzarne gli impatti che è opportuno predisporre una strategia per il disaster recovery, con l'obiettivo di evitare disservizi e, soprattutto, di limitare qualsiasi motivo d'apprensione a persone e imprese.

Il caso Unisuper - per la cronaca finito a buon fine - può essere considerato un evento limite. Tuttavia gli imprevisti sono sempre dietro l'angolo, in particolar modo quando si parla di cloud e digitale. A volte è sufficiente una presa staccata, una procedura errata, la semplice obsolescenza dei macchinari oppure anche una piccola disattenzione, magari di un addetto alle pulizie che tocca qualcosa che non dovrebbe (caso realmente accaduto), per perdere applicativi, dati e la fiducia degli utenti, oltre che la reputazione costruita negli anni. “Prevenire”, “monitorare” e “ripristinare” diventano, così, le parole chiave per un corretto funzionamento dei sistemi per tutto il ciclo di vita dei dati all'interno delle applicazioni.

Partire dalle norme

Nella Pubblica Amministrazione alcuni processi sono ben regolati da normative e linee guida specifiche, al fine di garantire il corretto trattamento dei documenti, come nel caso della disciplina sul Protocollo informatico. Per quanto riguarda i servizi, in particolare per il backup e il ripristino di un generico servizio in cloud, è utile partire dal Codice dell'Amministrazione Digitale (CAD), che nell'articolo 51 parla della “sicurezza e disponibilità dei dati, dei sistemi e delle infrastrutture delle pubbliche amministrazioni”.

Nella Strategia Cloud Italia e nel percorso per la qualificazione dei servizi cloud per la PA, promosso dall'Agenzia per la Cybersicurezza Nazionale (ACN), si definiscono vari livelli d'importanza per i dati gestiti dalle pubbliche amministrazioni:

• dati e servizi ordinari, la cui compromissione può provocare l'interruzione di servizi dello Stato oppure un pregiudizio per il benessere economico e sociale del Paese;
• dati e servizi critici, dove un malfunzionamento può determinare un pregiudizio al mantenimento di funzioni rilevanti per la società, la salute, la sicurezza e il benessere economico e sociale del Paese;
• dati e servizi strategici, ovvero situazioni in cui eventuali problemi possono avere impatti sulla sicurezza nazionale.

Per ogni categoria di dato, i provider di infrastrutture e servizi cloud che offrono servizi alla PA devono ottenere la corrispondente qualifica da parte di ACN. Inoltre, già nelle Misure minime di sicurezza ICT per le pubbliche amministrazioni, l'Agenzia per l'Italia digitale (AgID) dettaglia le caratteristiche delle copie di sicurezza (backup) e obbliga la Pubblica Amministrazione ad “assicurarsi che i supporti contenenti almeno una delle copie non siano permanentemente accessibili dal sistema onde evitare che attacchi su questo possano coinvolgere tutte le sue copie di sicurezza”.

La (non) responsabilità dei provider

Spostare i dati in cloud non sposta, però, la responsabilità della loro tutela, anche se ne esplicita le regole del gioco. Di solito i cloud provider, nelle clausole standard dei loro contratti, non si assumono alcuna responsabilità per la perdita di dati. Come prova, ad esempio, ecco alcuni paragrafi estratti dai termini di servizio di un noto provider di servizi di cloud pubblico, riassunti e condensati per maggiore chiarezza:

Il provider non è responsabile della […] perdita di informazioni aziendali, anche qualora il provider fosse a conoscenza della possibilità di tali danni o se tale possibilità fosse ragionevolmente prevedibile.

Non bisogna stupirsi: i produttori di hardware rimborsano o sostituiscono il disco difettoso, ma non il valore dei dati che conteneva; mentre nel cloud di solito gli indennizzi riguardano solo i canoni per il servizio pagati nei 12 mesi precedenti, non certo eventuali perdite - pensiamo solo ai danni all'immagine - dovute al mancato recupero dati. Suggeriamo quindi di partire al Manuale di abilitazione al cloud, dove è possibile trovare un'introduzione a tecniche e procedure per duplicare dati su supporti differenti, in modo da minimizzare l'effetto di guasti a singoli componenti.

La vecchia regola del 3–2–1

C'è una strategia di backup che continua a resistere alla prova del tempo: è stata pensata nei primi anni Duemila dal fotografo americano Peter Krogh, ed è riassumibile in “tieni 3 copie dei dati, su 2 supporti differenti e tieni una copia fuori sede”. Il motivo è semplice: mentre si effettua una copia, due dispositivi possono essere contemporaneamente corrotti; per mantenere i dati anche in caso di disastro in sede occorre quindi una terza copia in un sito diverso, utilizzando un minimo di due supporti esterni.

La regola del 3–2–1 è molto semplice. È stata concepita prima della diffusione del cloud, e anche se non copre la totalità dei casi avversi, offre di certo dei buoni spunti per delineare una strategia di disaster recovery. Alcune indicazioni sono ad esempio riprese dalla European Union Agency for Cybersecurity (ENISA), come suggerimenti per le piccole e medie imprese. E nel tempo i consigli di Krogh sono stati arricchiti, ad esempio con la formula: 3–2–1–1–0, dove un 1 sta per la copia fuori sede, l'altro 1 sta per la copia disconnessa e 0 sta per zero errori in fase di test del recovery. Ci sono poi varianti come 4–3–2 (quattro copie di dati, in tre siti indipendenti, due disconnesse), che vengono suggerite per massimizzare l'utilizzo dei cloud provider.

In generale, quale che sia la variante, la disponibilità di un backup del quale sia possibile fare il restore, il ripristino dei dati, in un tempo ragionevole è la miglior difesa contro gli attacchi di tipo ransomware che cifrano i dati e chiedono un riscatto per ottenere una chiave di decrittazione. La raccomandazione di AgID, come del resto quella di ENISA, è di avere sempre una copia recente disconnessa e isolata dalla rete.

Come gestire in cloud il ciclo di vita dei dati

Con il progressivo affermarsi dei processi di trasformazione digitale, la maggior parte dei cloud provider ha aggiornato l'offerta dei propri servizi per migliorare la disponibilità di applicazioni utili al disaster recovery. Senza entrare troppo nello specifico:

• per lo IaaS sono disponibili volumi in alta affidabilità (ovvero duplicati su sistemi di archiviazione differenti), snapshot (fotografie) dei volumi, backup dei volumi su object storage (archiviazione basata su oggetti, dove i file sono gestiti da API, in genere per offrire ridondanza nativa e ulteriori controlli sul ciclo di vita dei dati);
• per i servizi DBaaS è possibile invece acquistare servizi specifici, dal cluster in alta affidabilità al backup automatico su region differenti, con vari livelli di granularità, a volte dettagliato fino alla singola transazione.
• per il SaaS di norma il cliente non ha visibilità sulle procedure di backup, ripristino e disaster recovery, ciò comunque non assicura che il provider non perda dati, e proprio per questo, in generale, tramite il regolamento ACN, i provider sono tenuti a fornire delle API al cliente per scaricare tutti i suoi dati in maniera interoperabile.

L'object storage può essere configurato per mantenere un certo numero di copie (versionamento) per un certo periodo di tempo, anche indefinito. Ci sono inoltre servizi di copia e sincronizzazione, attivabili per i database e per lo storage, che insistono su zone di disponibilità o regioni cloud differenti. Alcuni sistemi possono essere anche conformi all'archiviazione a lungo termine, un tema correlato al backup e al ripristino, dove, semplificando, il backup serve per recuperare i dati in uso al momento, qui ed ora; mentre l'archiviazione mira a rendere possibile il recupero dei dati che serviranno in futuro.

La sicurezza dei backup

In ogni caso, c'è un punto a cui prestare molta attenzione: alcuni servizi cloud possono dare l'impressione di avere dei dati ridondati, e quindi disponibili in più copie indipendenti. Ma la ridondanza spesso non è sufficiente per guasti comuni. È il caso, ad esempio, dello snapshot dei volumi: se non ulteriormente specificato, lo snapshot risiede sullo stesso disco o sullo stesso gruppo di dischi del sistema originale. Un guasto fisico ai dischi o alla macchina che li ospita e, oltre ai dati, anche le copie dello snapshot saranno perse.

Per essere ragionevolmente protetti, gli snapshot dovrebbero essere trasformati in immagini e queste, a loro volta, andrebbero caricate in sistemi ridondati, per esempio nell'object storage su un'altra zona di disponibilità o su un'altra cloud region, oppure - meglio - presso un differente cloud provider. In generale, possiamo dire che i backup vanno protetti allo stesso livello dei dati che contengono. Praticamente ad ogni livello è necessaria una criptazione (ovvero la protezione dei dati tramite chiavi e password, in modo da impedire la lettura diretta dei dati a chi, senza autorizzazioni, è in possesso del dispositivo fisico) e una verifica dei contenuti tramite somme di controllo e firme digitali.

Non solo dati: le applicazioni e i vantaggi dei modelli cloud native

I dati sono considerati tra i beni più preziosi dell'economia digitale. Ciò non toglie, però, che anche programmi e configurazioni vadano protette il più possibile. A tale scopo, i cloud provider propongono a catalogo prodotti per il backup e ripristino che dispongono di connettori specifici per i vari servizi, ad esempio per fare backup e restore di un database o di un bucket di un object storage, oppure delle configurazioni di un cluster kubernetes. Alcuni sistemi di backup supportano anche la ripartenza e la riconfigurazione dei servizi su un provider diverso o su un sistema differente da quello iniziale.

A differenza delle applicazioni “tradizionali”, i programmi cloud native potrebbero non aver bisogno di alta affidabilità, disaster recovery e backup come servizi esterni o di terze parti, perché delegano e monitorano questi aspetti ai servizi cloud offerti dal provider:

• non ci sarà bisogno del disaster recovery se l'applicazione è distribuita su vari siti;
• non servirà l'alta affidabilità, intesa come replica di macchine virtuali, perché l'applicazione è orchestrata in container e utilizza database distribuiti;
• non servirà il backup perché tutti i dati sono ridondati e versionati nel database o nell'object storage.

Un'applicazione ben ingegnerizzata, con vari livelli di ridondanza, di certo sarà più resiliente di una applicazione tradizionale monolitica, ma i problemi, come abbiamo visto, capitano (in)aspettati, ed è meglio farsi trovare pronti.

Come predisporre una strategia per il disaster recovery

L'importanza di predisporre opportune strategie per backup, restore e disaster recovery dovrebbe ormai essere chiara. Scegliere però quali servizi attivare può non essere così semplice. Partiamo ad esempio dal caso peggiore: non sapere per quali elementi fare il backup, non avere certezza se funziona il restore e non aver predisposto alcun piano di disaster recovery, con i servizi che sono tutti configurati a mano.

Anzitutto, in questo caso, non ha senso acquistare un servizio di disaster recovery o di alta affidabilità pensando che possa metterci al riparo da ogni malfunzionamento. Piuttosto, il primo passo da fare sarà predisporre un backup di ogni elemento, su un sistema append-only, ovvero che non permette la cancellazione di quanto già incamerato nel backup.

Successivamente è necessario stilare una lista dei sistemi e dei servizi ordinati in base alla loro importanza. Il passo seguente è quello di implementare un sistema di backup e restore dei dati per un sottoinsieme di servizi. Ma quali servizi scegliere? E con che criterio? La risposta purtroppo non è immediata, perché la scelta va determinata tramite un'analisi dei rischi e delle conseguenze di un'eventuale indisponibilità del servizio, detto che di solito i piani di business continuity dovrebbero esaminare le minacce, prevenirne e mitigarne gli effetti, ma soprattutto fornire indicazioni su come ripartire in caso di compromissione di un servizio.

Una volta individuato il sottoinsieme, sarà poi più semplice delineare delle valutazioni su come aggiungere al sistema alta affidabilità e/o il disaster recovery su un'altra cloud region. A tale proposito è possibile seguire anche quanto suggerito dal Manuale di abilitazione al cloud alla voce “disaster recovery”. Con la consapevolezza che, nell'era della trasformazione digitale, alla celebre massima latina “verba volant, scripta manent” andrebbe forse aggiunta la locuzione “data conrumpent“: le parole volano, gli scritti rimangono, i dati (se non adeguatamente protetti e monitorati) sono destinati a corrompersi. A volte per sempre.

...

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

Buone pratiche per ottimizzare la spesa delle pubbliche amministrazioni nella gestione di servizi cloud

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

Quanto pesa una nuvola a bilancio? Il cloud della Pubblica Amministrazione ha delle caratteristiche ben precise rispetto ai servizi offerti sul mercato. Come previsto dalla Strategia Cloud Italia , le infrastrutture che si candidano a ospitare dati e applicazioni della PA devono possedere i requisiti definiti dall’Agenzia per la Cybersicurezza Nazionale (ACN), secondo i criteri individuati dalla normativa. Nel cloud della PA, infatti, la sicurezza dei sistemi viene prima di ogni criterio di natura economica.

Tra le indicazioni operative contenute nel Piano Triennale per l’informatica, i sistemi cloud (qualificati) sono designati come prima opzione per la realizzazione di nuovi progetti o servizi, mentre il contenuto di data center obsoleti deve essere migrato in cloud. Le amministrazioni, inoltre, non possono investire sui propri data center obsoleti.

Per migrare in cloud è possibile accedere ai finanziamenti del PNRR, aderendo alla Misura 1.1 “Infrastrutture digitali” (per PA Centrali, ASL e Aziende Ospedaliere) oppure alla Misura 1.2 “Abilitazione e facilitazione migrazione al cloud” (per Comuni, Scuole, ASL e AO). L’obbligatoria migrazione al cloud, anche con la disponibilità delle risorse messe a disposizione dal PNRR, non pregiudica considerazioni di tipo economico sull’operazione, in un’ottica di miglioramento del rapporto costi/opportunità dell’intero impianto IT, rafforzando l’efficacia e l’efficienza dei servizi offerti ai cittadini.

L’importanza di stimare i costi del cloud

Uno dei punti su cui concordano gli addetti ai lavori è che la stima dei costi del cloud è un’opportunità per migliorare l’efficienza della gestione dei servizi. Un’attività per la quale è utile anche avvalersi, come vedremo, di professionisti qualificati. Fare previsioni sui costi può rivelarsi anche abbastanza complicato, soprattutto quando si tratta di capire esattamente dove ottimizzare le spese senza allocare risorse (umane e temporali) e senza avere a disposizione strumenti di gestione adeguati. Nel calcolo dei costi intervengono infatti vari elementi, e non sempre è agevole collegarli direttamente a un servizio IT oppure a un particolare centro di costo. Allo stesso modo, analizzando il cloud in termini esclusivamente economici, non sempre è lineare correlare le spese con i ricavi che provengono da determinati servizi. Una situazione simile a quella del settore privato, dove c'è una grande pressione per contenere spese e aumentare i margini di profitto, e dove ogni investimento viene fatto per aumentare la competitività. Anche nel pubblico, tuttavia, si possono applicare alcuni accorgimenti, per ottimizzare al meglio i costi dei servizi cloud.

Una professione e una disciplina: il FinOps

È proprio la pressione per ottimizzare i costi che ha fatto nascere una figura specializzata nell’analisi dei servizi cloud: l’esperto FinOps, un termine di derivazione anglosassone nato dalla contrazione delle parole finance e operations. Il FinOps è un professionista specializzato nel monitoraggio continuo dei sistemi cloud e nello sviluppo di soluzioni a misura di organizzazione, che spesso lavora con i DevOps e DevSecOps (ovvero le figure che si occupano di integrare sviluppo, sicurezza e operations) per implementare le indicazioni fornite dai responsabili di prodotto, al fine di migliorare alcuni aspetti di gestione delle spese.

Oltre che a essere una professione, con FinOps si intende anche una disciplina di amministrazione finanziaria in continua evoluzione, nata con il cloud ma che nel tempo ha ampliato il proprio raggio d’azione anche ad altri aspetti legati all’erogazione di servizi. Nelle grandi aziende, infatti, gli esperti FinOps sono anche deputati alla gestione di sistemi on-premise oppure di soluzioni ibride, dove al cloud pubblico – quello offerto pubblicamente su internet – vengono affiancate anche soluzioni private, con uno o più data center dedicati a una singola organizzazione. Da un punto di vista puramente tecnico, anche il “vecchio” data center, gestito con il modello di housing e hosting, può essere riconvertito per offrire servizi cloud privati o ibridi, anche se ricordiamo che, nel caso delle strutture di una pubblica amministrazione, i sistemi devono comunque essere in possesso dei requisiti definiti dall’Agenzia per la Cybersicurezza Nazionale.

La gestione del cloud nella Pubblica Amministrazione

Se nel privato, anche grazie al FinOps, il cloud può essere gestito in tempo reale, nel settore pubblico questa tempestività di solito è più difficile, con le pubbliche amministrazioni spesso legate a contratti di fornitura pluriennali, stesi sulla base di capitolati molto articolati e gare d’appalto che hanno come obiettivo di rafforzare la trasparenza e la correttezza dei processi amministrativi. Tuttavia anche nel pubblico si stanno affacciando modalità di acquisto e gestione di servizi sempre più agili, ed è in questo contesto che si possono implementare strategie di saving sui costi correlati ai servizi cloud. Ad esempio, nell’ambito della Strategia cloud Italia, i piani di migrazione che devono essere presentati dalle amministrazioni richiedono anche delle informazioni sul budget preventivato. Le tabelle relative ai servizi da migrare offrono una guida anche per analizzare la spesa, con il Manuale di abilitazione al cloud che contiene un capitolo dedicato anche alla gestione dei costi.

Quali sono le voci di costo dei servizi cloud e on-premise

Tra le voci che impattano maggiormente le organizzazioni, pubbliche o private, che si trovano a gestire sistemi on-premise si possono annoverare anzitutto i costi di affitto (o realizzazione) di locali specializzati – i data center – dove mantenere server e apparati di rete, i servizi di connettività alla rete, i costi del personale e della manutenzione a cui devono essere sottoposte le macchine. Voci di costo che possono essere ammortizzate negli anni ma che richiedono una costante attenzione per essere tenute sotto controllo in maniera flessibile ed efficace.

Parlando di infrastrutture cloud, invece, viene fatto riferimento tradizionalmente a tre tipologie di erogazione dei servizi: IaaS, PaaS e SaaS. Nel primo caso, con lo IaaS, viene replicato il modello del data center nel cloud in maniera più o meno virtualizzata, con la gestione della connettività e dell'hardware lasciata solitamente al Cloud Service Provider (CSP). Con la tipologia PaaS, al CSP viene affidata anche l’amministrazione del software di base (sistema operativo, servizi di middleware), mentre infine con il SaaS il CSP ha la responsabilità di condurre tutto il software e alla PA (o alle aziende) rimangono un pannello di controllo e delle API specializzate a seconda dei servizi attivati.

In base alla tipologia scelta, il controllo delle spese sarà maggiore quando parliamo di IaaS, parziale nel caso di PaaS e con scarsi margini di ottimizzazione nel SaaS, fermo restando i vincoli a cui sono sottoposti i fornitori in caso di contratto con una PA, con i requisiti ACN che prevedono, ad esempio, di ridurre il rischio lock-in delle soluzioni. Più nel dettaglio:

• Con il SaaS si negozia un servizio in base agli utenti attivi, o alla mole di dati trattati. Ci possono essere quindi sconti basati sulla quantità, ma in generale il prezzo sarà abbastanza fisso. In ogni caso è possibile comunque monitorare gli utenti attivi e i vari “piani” a loro associati.

• Nel PaaS generalmente per lo stesso servizio esistono differenti implementazioni, taglie e differenti classi di servizio e ridondanza (per esempio per il database ci possono essere varie implementazioni, che possono avere vari dimensionamenti, essere collegate a storage più o meno veloce, con diverse possibilità di gestione dei guasti). Una situazione dove il monitoraggio per ottimizzazione dei costi inizia ad avere una portata significativa.

• Nello IaaS, dove le scelte si configurano come matrici n-dimensionali, lo scenario è più complesso, e occorre essere supportati da dati e analisi puntuali per suggerire ottimizzazioni. È qui che competenze esperte possono fare la differenza in termini di ottimizzazione dei costi.

Cloud e on premise: una matrice dei costi ricorrenti

La migrazione di dati e servizi in cloud si può considerare completa solo con lo spegnimento dei server che erogavano le prestazioni on premise oppure con lo spegnimento dei contratti in essere. L’obiettivo, infatti, è di non duplicare gli sforzi, evitando di gestire due fronti allo stesso tempo (cloud e on premise), a prescindere dalla necessità di soddisfare i criteri degli Avvisi del PNRR per la migrazione in cloud.

A seconda dell’origine e della destinazione dei servizi, è possibile individuare una matrice dei costi che cessano e che si attivano, come si può vedere nella tabella seguente. È bene comunque ricordare che, nella ripartizione dei costi ricorrenti, avere un minor numero di voci di costo non significa sempre avere minori spese, ma è sicuramente indice di una riduzione della complessità di gestione dell’infrastruttura.

Servizio	On Premise	IaaS	PaaS	SaaS
Manutenzione Datacenter	✔
Manutenzione Hardware	✔
Manutenzione Rete	✔	✔
Manutenzione Sistemi Operativi	✔	✔
Manutenzione Middleware	✔	✔	✔
Manutenzione Software Applicativo	✔	✔	✔
Gestione Software Applicativo	✔	✔	✔	✔
Backup/Restore/Disaster Recovery	✔	✔
Off-Site backup	✔	✔	✔	✔
Licenze	✔	✔
Security Appliance	✔
Security as Service		✔	✔	✔
Staff per gestione Datacenter	✔
Staff per gestione Cloud		✔	✔	✔
Staff Supporto Utenti	✔	✔	✔	✔

Come scegliere tra le tipologie di servizi cloud

Nella scelta della tipologia di servizi cloud più adatti al contesto di un’organizzazione non ci sono regole a guidarci. Certamente, però, c'è un fattore di scala. Prendiamo ad esempio il servizio della posta elettronica: per un piccolo Comune, con qualche decina di caselle, non ha senso pensare a una gestione con il modello IaaS, dato che condurre un server di posta richiede competenze troppo specialistiche per essere conveniente. In questo caso la soluzione più appropriata è il SaaS. Al contrario, per un grande ente con migliaia di caselle di posta che occupano diversi tera-byte, potrebbe risultare più conveniente optare per una gestione interna.

Proviamo a tradurre la riflessione in cifre: se una casella di posta elettronica costa circa 60 euro all'anno in SaaS, 24 caselle costeranno poco meno di 1.500 euro all'anno. Se scaliamo queste cifre, ponendo l’esempio di un ente che si trova a gestire 2.400 account, il costo annuale sale a 144 mila euro l’anno, un importo sufficiente anche per valutare i vantaggi di un servizio IaaS. La posta elettronica è un servizio internet standardizzato, dove è comunque facile cambiare provider sia nel caso di un servizio on-premise sia SaaS o IaaS, senza grosse interruzioni di servizio. Diverso però è valutare l’integrazione del servizio di posta con i sistemi per la produttività individuale (calendari, editor, condivisione di file e sistemi di videoconferenza), dove l’esperienza utente ed eventuali disservizi possono influire drasticamente sull’attività degli uffici.

Come ottimizzare i costi nel cloud pubblico per i servizi IaaS e PaaS

Anche se questo è il territorio d'elezione del FinOps, è possibile provare a ottimizzare i costi di gestione dei servizi cloud pur non essendo professionisti, soprattutto quando nell’intera organizzazione aumenta la consapevolezza di quali siano le voci di costo e di quanto sia importante monitorare con attenzione l’andamento di un servizio. In generale i cloud provider mettono infatti a disposizione strumenti di reportistica e analisi dei costi più o meno sofisticati. Questi sistemi monitorano i consumi dei vari servizi e forniscono indicazioni su dove sia possibile ottimizzare, che in ogni caso possono essere vagliate anche con il riscontro di consulenti esterni. Ad esempio, una virtual machine equipaggiata con 32 giga-byte di RAM che nelle ultime 24 ore ha usato solo 12 giga-byte di RAM può essere segnalata come overprovisioned, ovvero come un servizio che impiega risorse superiori rispetto a quelle effettivamente necessarie.

Uno dei costi trasversali che si ripercuote su tutti i servizi è inoltre quello legato alla cosiddetta “zona di atterraggio” (landing zone). Di solito, specialmente nel caso di servizi gestiti da un ente pubblico, i servizi vengono migrati in cloud anche con il loro contesto, un insieme di elementi – come la configurazione di regole di accesso, sia a livello di rete che di utenza, la creazione e la verifica dei backup, la protezione da attacchi esterni – che sono comuni a tutti i servizi e che devono essere monitorati sia in fase di setup sia durante le manutenzioni.

I cloud provider offrono delle scontistiche anche molto importanti (anche oltre il 50%) se si acquistano determinati volumi per un determinato periodo (di norma 3 anni). Una volta effettuata la migrazione verso il cloud e dimensionata correttamente l'infrastruttura bisogna però valutare la convenienza di un impegno sul medio periodo. Spesso i CSP offrono anche virtual machine dalle prestazioni non garantite, con notevoli sconti, che possono essere usate per sviluppo, test, elaborazioni periodiche. Anche in questo caso è essenziale verificare se alcuni servizi possano accettare di essere gestiti con sistemi a minori prestazioni, in cambio di un vantaggio in termini di costi.

Di norma i servizi sono fatturati a consumo, con varie soglie e fasce di prezzo. Tuttavia “a consumo” è un termine molto generico: i trasferimenti sono contabilizzati in byte, ma ci sono anche servizi che sono fatturati “a chiamata”. Ad esempio, il DNS, il firewall o un sistema di rilevamento delle intrusioni (IDS), possono avere anche un contatore di chiamate, che nel caso del DNS sarà il numero di query e nel caso di un IDS potrebbe essere il numero di connessioni analizzate. I dati immagazzinati in memoria potranno costare diversamente a seconda della velocità di accesso e della ridondanza della soluzione. All’amministrazione spetta così il compito di capire se ci sono margini per ottimizzare i costi.

Ad ogni modo, il suggerimento è di fare sempre un’analisi usando il meccanismo delle etichette (tag o label), un sistema supportato da pressoché tutti i cloud provider. Il funzionamento, del resto, è semplice: si etichettano tutte le risorse utilizzate e si chiede al CSP di produrre un report di costi per etichetta. Se usate opportunamente, le etichette evidenzieranno se i costi maggiori sono nel frontend o nel backend, e se derivano da un servizio oppure da un altro, fornendo indicazioni in sede di valutazione dei costi.

Come fare attenzione ai costi nascosti

Sveliamo subito un segreto: i costi nascosti in realtà non esistono, solo che spesso si fatica a riconoscerli e inquadrarli, per questo è più semplice chiamarli “costi nascosti”. Mantenerli quindi sotto controllo, o trasformarli in opportunità, è la cosa migliore da fare.

Nel caso di migrazione totale da un sistema on-premise, si annoverano fra i costi nascosti la riconversione degli spazi del data center, la svalutazione dell'investimento in hardware, le eventuali licenze sul software che se non possono essere migrate perdono valore, la sostanziale inutilità dei contratti di manutenzione in loco in essere (che andrebbero quanto prima rescissi), la necessità di rinegoziare forniture ridondate (energia elettrica, connettività), la perdita di utilità delle competenze, del training e delle certificazioni sui sistemi on-premise (che dovrebbero essere rimpiazzate al più presto, certamente prima di iniziare una migrazione sul cloud). Ci sono poi costi legati all'indisponibilità dei servizi durante la migrazione e costi legati alla minore produttività nelle fasi immediatamente successive alla migrazione, che può essere in parte compensata dalla formazione e dalla migliore usabilità dei servizi di destinazione. In ogni caso, una migrazione in cloud rappresenta sempre una buona opportunità per dismettere servizi obsoleti e riordinare quelli esistenti, come avviene durante un trasloco.

Nel considerare l’andamento dei costi, sono inoltre da mettere in una matrice del rischio anche eventuali requisiti di legge, ad esempio se pensiamo al caso in cui un cloud provider qualificato non riesca a superare il rinnovo della certificazione. Una situazione che ha dirette conseguenze sulle pubbliche amministrazioni, costrette in auto tutela a correre ai ripari il prima possibile, sospendendo il servizio o migrando verso un provider certificato, oppure tornando a offrire il servizio da un cloud privato (che chiaramente si porterà dietro i costi del processo di certificazione).

Un altro costo da tenere sotto controllo è quello della gestione dei dati. In particolare, i cloud provider fatturano costi per il trasferimento e il loro stoccaggio che possono diventare importanti, specialmente nel caso se ne vogliano trasferire grosse quantità in poco tempo. Ci sono poi normative e raccomandazioni relative alle caratteristiche dello stoccaggio, del backup e del restore (per esempio da tenere in molteplici luoghi, offline, criptato, su media che ammettono una sola scrittura) che devono essere rispettate dal provider e verificate dall'amministrazione.

Scenari possibili: verso una combinazione delle soluzioni cloud

In linea con quanto previsto dal Piano Triennale per l’informatica nella PA e dalla Strategia cloud Italia, è possibile prevedere un futuro dell’IT né tutto nel cloud pubblico, né tutto on-premise nel cloud privato, ma sarà ibrido fra privato e pubblico, tendenzialmente multi-cloud, ovvero che si appoggia a più di un fornitore di cloud pubblico. Alcuni dati ed alcune elaborazioni saranno disponibili nel cloud, altre on-premise, a seconda della convenienza o, ad esempio, dei requisiti di sicurezza dei dati.

Già da oggi sono infatti disponibili soluzioni ibride che permettono di sfruttare al meglio quanto offerto dai due mondi (pubblico e privato). Non possiamo negare, però, che la complessità aumenta, e quindi questo approccio sarà conveniente solo per chi lavora con grandi quantità di dati e offre servizi su grande scala. In generale, per ottimizzare i costi converrà interrogare diversi fornitori, con soluzioni anche radicalmente diverse: da cloud pubblico a cloud privato, da sistemi IaaS a SaaS. Rimarrà poi in carico all’amministrazione la scelta di trovare il giusto compromesso, in un’ottica di efficienza, efficacia e soddisfazione dell’esperienza di fruizione 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

Come le PA possono sfruttare al massimo le opportunità messe a disposizione dalla migrazione di dati, servizi e sistemi applicativi

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

L'essenziale è invisibile agli occhi: si potrebbe prendere in prestito una frase de Il piccolo principe per descrivere una delle modalità di migrazione al cloud più efficaci e allo stesso tempo più trasparenti per i fruitori di servizi digitali. Il re-architect o refactoring di applicazioni permette infatti di ottimizzare in tutto o in parte l'architettura software di un'applicazione, migliorandone le performance e la qualità complessiva del sistema senza che, a livello di interfaccia, i cittadini se ne accorgano. Una modalità di migrazione individuata nell'ambito della Strategia Cloud Italia e descritta insieme ad altre strategie nel Manuale di abilitazione al cloud, che a prima vista può sembrare la più onerosa in termini di investimenti per un'Amministrazione, ma che rimane la più indicata per cogliere le opportunità del passaggio in cloud di sistemi e servizi.

In questo articolo andremo quindi a scoprire le principali caratteristiche del re-architect o refactoring di applicazioni in cloud, valutandone i punti di forza e l'opportunità, fino a individuare le figure tecniche necessarie a una migrazione di successo, senza dimenticare una serie di pratici consigli per ottimizzare le soluzioni a disposizione delle PA.

Cos'è il re-architect di applicazioni per il Cloud

Con il termine re-architect, si intende la riorganizzazione e la riscrittura di parti di un'applicazione, che apporti miglioramenti all'architettura con lo scopo di avere ricadute pratiche, per esempio migliorando le performance, la flessibilità del deployment, i tempi di backup e restore senza modificare il comportamento dell'applicazione stessa verso l'esterno.

In questo articolo i termini re-architect, re-factoring, rifattorizzazione o creazione di una nuova architettura saranno utilizzati come concetti equivalenti. Il Manuale di abilitazione al cloud li considera tutti allo stesso modo, e siccome nella nostra trattazione il refactoring è sempre finalizzato alla migrazione in cloud anche noi li tratteremo quindi come sinonimi.

In particolare, nel nostro caso, il re-architect può essere focalizzato a migliorare l'interazione con i servizi cloud¸ anche sostituendo o adattando componenti sviluppati internamente con servizi nativi cloud, tipicamente offerti come servizi Platform as a Service (PaaS), quali ad esempio bilanciatori di carico, database, sistemi di code di messaggi. Anche un refactoring interno, nell'ottica di dividere un monolito in microservizi fa parte del re-architect. Nel caso ideale, l'ente ha a disposizione il codice sorgente dell'applicazione e delle sue dipendenze, o comunque il codice è disponibile con una licenza open source che ne permetta il riutilizzo e la modifica.

Cosa non comprende

Il refactoring di norma non comprende il cambiamento di come l'applicazione si presenta al mondo esterno, per cui le eventuali API verso altri sistemi e le interfacce grafiche rimarranno invariate. Non comprende ovviamente lo sviluppo ex-novo di un applicativo di pari funzionalità o il porting totale dell'applicazione ad un nuovo linguaggio di programmazione e, a maggior ragione, non comprende lo sviluppo di un applicativo con funzionalità diverse dall'applicativo da migrare.

Questa tipologia di migrazione non comprende neanche un generico refactoring per ridurre il debito tecnico accumulato dall'applicazione. Nella maggior parte dei casi, infatti, il debito tecnico è costituito da scelte necessarie a implementare velocemente una funzionalità, senza renderla abbastanza flessibile, generica e facile da essere mantenuta. Una situazione che, a lungo termine, con lo stratificarsi dei cambiamenti, porta il debito tecnico esclusivamente ad aumentare, ma che non ha nulla a che vedere con le finalità del re-architect per il cloud.

Vantaggi per la Pubblica Amministrazione

L'adozione del cloud da parte della Pubblica Amministrazione dovrebbe portare a una riduzione dei costi, elasticità reale, facilità degli aggiornamenti, riduzione della complessità del supporto, riduzione delle attività manuali a basso valore aggiunto, adeguamento normativo in termini di sicurezza e privacy, oltre che un miglioramento dei servizi. La flessibilità e i rischi del cloud devono spingere le amministrazioni a stare al passo con i tempi, adeguandosi ai modelli agili di gestione del ciclo di vita degli applicativi. I servizi cloud prevedono di norma una fatturazione a consumo e più l'applicazione usa solo le risorse strettamente necessarie, come nel caso di un re-architect di successo, più il risparmio sarà consistente. Ovviamente c'è un compromesso fra risparmio economico, esperienza utente e tempi di attesa degli impiegati della PA che operano nell'applicazione. Il monitoraggio della latenza e dei consumi permetterà di trovare il compromesso migliore.

Come valutarne l'opportunità

Il re-architect è un processo articolato, che va preso in considerazione per applicazioni che sono centrali nella strategia dell'ente e che necessitano di miglioramenti nell'interazione con i servizi cloud, con lo scopo di garantire, ad esempio, una migliore scalabilità o una maggiore tolleranza ai guasti, ma anche il deploy multi-cloud, dove l'applicazione può essere installata su diversi cloud provider per sfruttare le peculiarità di servizi (ma anche di prezzi) diversi, o semplicemente per ridurre il lock-in.

Il refactoring va considerato come un investimento, la convenienza andrà valutata in base al piano di sviluppo e mantenimento dell'applicazione a medio/lungo termine. Il re-architect abilita l'integrazione con gli strumenti del cloud, permettendo, per esempio di usufruire dei benefici, anche in termini economici di un uso più oculato delle risorse acquistate con una formula di fatturazione a consumo, rispetto al semplice re-host, dove l'applicazione viene migrata in cloud senza essere pressoché modificata e senza le caratteristiche di scalabilità offerte dal cloud.

Come si gestisce

L'attività di refactoring per il cloud deve essere coordinata con le altre attività di sviluppo, e in molti casi, può offrire un sostanzioso vantaggio anche per le altre attività. Per esempio, l'automazione dell'installazione e della configurazione può accorciare i tempi di test delle interfacce grafiche o di test di carico. Coordinare queste attività è cruciale per ottimizzare il lavoro dei vari team che lavorano sui diversi aspetti dell'applicazione.

In generale, ci si aspetta che una robusta suite di test permetta l'avanzamento in parallelo e una facile integrazione. Al termine del processo, l'obiettivo è rendere l'applicazione più mantenibile e, sfruttando nativamente le caratteristiche del cloud, fare ad esempio in modo che sia semplice da scalare orizzontalmente. Il refactoring, visto che siamo nell'ambito di migrazione verso il cloud, può essere parzialmente orientato dall'integrazione con i servizi del cloud provider di destinazione. Su questo punto occorre stare molto attenti nella scelta dei servizi per limitare, o addirittura diminuire, il lock-in.

Il risultato ideale di un re-architect sarà un'applicazione divisa in micro-servizi, ognuno dei quali può scalare orizzontalmente, integrati con i servizi del cloud provider, suddivisi in pacchetti come immagini di container, messi in produzione a partire dal codice sorgente con una pipeline di countinuos integration (una catena di integrazioni continue), dove dal codice sorgente si producono e si testano i vari artefatti (binari, immagini di container, configurazione), e continuos delivery (dove gli artefatti vengono automaticamente messi in produzione), monitorata in tempo reale, anche per questioni legate alla sicurezza.

Il processo di refactoring, facendo leva sulla test suite, si presta naturalmente a essere un processo iterativo, dove piccoli cambiamenti sono velocemente testati e mandati in produzione. È facile che ci siano anche cambiamenti significativi, dove tornare indietro è un'opzione troppo costosa, come ad esempio la migrazione di un database, o l'aggiunta di un bilanciatore di carico, che vanno pianificati con più cura per ridurre l'impatto che possono avere in esercizio, richiedendo un fermo oppure, nei casi più gravi, causando addirittura un degrado del servizio in produzione.

Figure tecniche necessarie

Per un re-architect di successo occorre la collaborazione fra varie figure tecniche, in primo luogo, del Cloud Architect che dovrà progettare la nuova architettura. Ci sono poi una serie di figure a contorno che aiutano nella realizzazione e nel mantenimento della soluzione. I nomi di queste figure non sono ancora del tutto standardizzati e, anzi, sono in realtà in continua evoluzione.

Per esempio, si può trovare il Cloud System Engineer, che conosce le specifiche delle piattaforme cloud ma ha anche familiarità con il networking, i sistemi operativi e i linguaggi di programmazione, e che si occupa di tradurre in realtà il progetto dell'Architect. Oppure, un'altra figura chiave che si occupa del processo di automazione è conosciuta come DevSecOps, il professionista che deve occuparsi dell'integrazione nel processo di sviluppo (Dev, da development) con gli aspetti di sicurezza (Sec, da security) e funzionamento (Ops, da operations), per ridurre i tempi di aggiornamento e messa in produzione del nuovo software dentro un'infrastruttura sicura.

C'è poi una miriade di specializzazioni, sia verticali sui singoli cloud provider, sia specifici di alcune tecnologie (per esempio Kubernetes Administrator), o ancora specifici di processi (GitOps, DevOps) che completano il quadro delle professioni del Cloud. Il fatto che non esista un insieme unitario, stabile e definito degli inquadramenti professionali e di come si relazionano fra loro deve farci capire che non è tanto importante richiedere la singola certificazione del particolare vendor, ma che occorre considerare le competenze del team nel complesso, come suggerito anche nell'apposita sezione del Manuale di abilitazione al cloud.

Buone pratiche

Se durante il re-architect risultasse necessario cambiare il database e optare per la scelta di un database come servizio, ci si potrà orientare in una rosa di possibili alternative che vanno dall'acquisto di un database proprietario del cloud provider a quello di un database disponibile con licenza free software open source, sempre gestito dal cloud provider. Ovviamente il grado di lock-in è nettamente diverso: scegliere un database proprietario del cloud provider vuol dire legarsi a lui in maniera abbastanza vincolante.

Scegliere invece un database open source gestito, implica dipendere in misura minore da uno specifico cloud provider. Di norma i database open source sono offerti come servizio da vari provider ed è sempre possibile, nel caso si dovesse cambiare repentinamente provider, gestirlo in autonomia. In generale servizi disponibili come open source garantiscono il massimo della flessibilità, permettendo di scegliere sia il provider che la modalità di erogazione del servizio (self hosted vs PaaS), e permettono di avere una catena di continuos integration slegata dal provider. La parte di continuos delivery sarà invece costruita su misura per il provider di destinazione. Anche in questo caso ci sono soluzioni più o meno portabili fra provider.

Per avere il massimo della flessibilità, si può pensare di fare un refactoring che porti l'applicazione a essere nativamente multi-cloud, ovvero che possa essere messa in produzione facilmente su diversi cloud provider tramite delle ricette di deploy che partono da una base comune per poi differenziarsi ed usare gli specifici strumenti messi a disposizione da ogni singolo cloud provider.

Naturalmente supportare diversi cloud provider aumenterà la complessità del progetto e le professionalità da mettere in campo. Essere multi-cloud non è una scelta binaria. Ci sono vari gradi possibili. Si può mantenere un livello minimo di compatibilità con diversi cloud provider, integrandosi al meglio solo col fornitore principale, per essere pronti a cambiare cloud provider in caso ci siano offerte migliori o che il cloud provider non rinnovi, o perda, le qualificazioni necessarie rilasciate da ACN per offrire i suoi servizi alla Pubblica Amministrazione.

Da dove iniziare: attori e responsabilità

Generalmente i cloud provider offrono tutorial, buone pratiche, documentazione, casi di successo e figure professionali o partner che possono aiutare nel processo. L'amministrazione che vuole intraprendere un processo di re-architect di una sua applicazione può iniziare a fare un self-assesment delle competenze interne e dello stato di prontezza per il cloud (cloud readiness) dell'applicazione, per poi valutare come acquisire le nuove competenze tecniche (alcune competenze interne saranno necessarie per valutare adeguatamente le proposte progettuali che possono essere realizzate anche con l'aiuto dei cloud provider, dei loro partner o di società terze) per il nuovo ciclo di sviluppo. Sarà anche importante dividere le responsabilità tra i vari attori in campo, su questo punto si veda il l'articolo “La responsabilità ai tempi del cloud: buone pratiche per le amministrazioni”.

Il Manuale di abilitazione al cloud contiene una sezione tecnica che può essere usata come guida per iniziare un processo di assessment e di re-architect. Inizia subito a migliorare l'architettura delle tue applicazioni per migliorare la qualità complessiva dei tuoi sistemi informativi in cloud.

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

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