Cloud First,strategia e framework metodologico per la migrazione al cloud della PA

Nel PNRR  ci sono ingenti risorse per la digitalizzazione della PA e parte di queste (1 miliardo circa) verranno impiegate per la realizzazione di servizi in cloud e la razionalizzazione dei data center pubblici. L’ Operazione Cloud First, nelle intenzioni del ministero dell’Innovazione tecnologica e del Dipartimento per la trasformazione digitale, è la condizione per raggiungere 3 obiettivi strategici principali:

-       aumentare la qualità dei servizi offerti in termini di sicurezza, resilienza, continuità

-      accelerare la piena interoperabilità tra enti pubblici e le loro basi informative, così da assicurare che le amministrazioni possano “incrociare” le informazioni sui cittadini e averle sempre disponibili in modo immediato

-      conseguire un risparmio consistente di spesa derivante dal consolidamento dei data center e dalla migrazione dei servizi verso tecnologie cloud

IL PIANO TRIENNALE PER L'INFORMATICA PUBBLICA 2019-2022

Infrastrutture, Piattaforme (Identità digitale, SPID, Pago PA), Dati e Servizi Digitali sono i 4 componenti fondamentali del piano triennale per l'Informatica Pubblica, con 2 elementi di sistema, l’interoperabilità dei sistemi e la sicurezza informatica by design.

Fonte: Osservatorio Politecnico, Agenda Digitale

Nel piano Triennale vengono indicati alcuni principi fondamentali per la migrazione al cloud ed il consolidamento dei data Center della PA:

 1)   Cloud First: le PA devono, in via prioritaria, adottare il paradigma cloud (in

particolare i servizi SaaS) prima di qualsiasi altra opzione tecnologica per la definizione di nuovi progetti e per la progettazione dei nuovi servizi nell’ambito di nuove iniziative da avviare.

 2)   Modello Cloud della PA : il modello strategico si compone di infrastrutture, servizi e provider qualificati da AgID

 3)   Cloud Enablement Program: il programma abilita le amministrazioni pubbliche a migrare il proprio patrimonio IT esistente (infrastrutture e applicazioni) utilizzando infrastrutture e servizi cloud all’interno del modello Cloud della PA. Nell’ambito del programma è stato definito un framework, costituito dall’insieme di unità organizzative (unità di controllo, unità di esecuzione e centri di competenza), risorse, strategie operative e il Cloud Enablement Kit

TIPOLOGIA E MODELLI DI IMPLEMENTAZIONE DEL CLOUD COMPUTING

Possiamo immaginare i servizi in cloud come un piramide costituita da 3 elementi fondamentali, Infrastracture as a Service (IaaS), Platform as a Service (Paas), Software as a Service (Saas)

Vediamoli in dettaglio:

-      Infrastracture as a Service: il modello di servizio  costituisce la base per l’implementazione della tecnologia cloud. Attraverso un provider IaaS (es: Google Compute Engine, AWS EC2, Azure Instance) si ottiene l’accesso on-demand via internet alle risorse IT principali, compresi i computer (hardware virtuale o dedicato), il networking e l’archiviazione.

-      Platform-as-a-service ( PaaS): ovvero piattaforma distribuita come servizio. Si tratta di servizi cloud che forniscono strumenti e ambienti per lo sviluppo, il test, la distribuzione e la gestione di applicazioni software, attraverso strumenti specifici forniti dal provider stesso e pannelli di configurazione fruibili via browser web. Una soluzione PaaS è progettata per consentire agli sviluppatori di progettare e creare concentrandosi sulle funzionalità dell’applicativo, lasciando al fornitore del servizio aspetti come la configurazione, la gestione dell’ambiente di esecuzione dell’archiviazione o dei database. Esempi di provider e servizi di Paas sono Google App Engine, AWS Beanstalk, Azure App Service, Heroku.

 -      Software-as-a-service (SaaS), ovvero software come servizio. Si tratta di un metodo per la distribuzione di applicativi software tramite internet, su richiesta e in genere in base a una sottoscrizione / abbonamento mensile. Nel caso di una soluzione SaaS, i provider di servizi cloud ospitano e gestiscono il software e l’infrastruttura sottostante e si occupano delle attività di manutenzione, come gli aggiornamenti. Gli utenti si connettono all’applicazione tramite internet e possono accedervi da diverse tipologie di dispositivi (desktop, mobile, tablet. A differenza del modello ASP (Application Service Provisioning), dove i fornitori installano un’istanza di applicazione per ogni cliente personalizzandole a seconda delle richieste di ognuno, nel SaaS si fa uso di applicazioni  c.d “multi-tenants”, cioè noleggiabili da più utenti contemporaneamente, con codice non customizzabile ma uguale per tutti e personalizzazione funzionale. Un approccio, quest’ultimo, che garantisce il raggiungimento più facile di economie di scala da parte del fornitore. Esempi di SaaS sono Microsoft Office 365, tutte le app di Google, iCloud

 Vi sono inoltre diversi modelli di dispiegamento ed implementazione dei servizi:

-      Cloud pubblico: offerti da fornitori che mettono a disposizione dei propri utenti/clienti la potenza di calcolo e/o di memorizzazione dei loro data center. Il tipo di servizi cloud che vengono offerti dal fornitore (IaaS, PaaS, SaaS) dipende dalla politica del fornitore stesso, così come il prezzo e la tariffazione. Uno dei maggiori vantaggi del cloud pubblico per il cliente consiste nel fatto che può richiedere l’utilizzo dei servizi cloud di cui necessita nel momento in cui effettivamente ne ha bisogno (pay-per-use), e solo per il tempo che gli sono necessari. In questo modo, si possono ridurre notevolmente gli investimenti in infrastrutture IT e ottimizzare l’utilizzo delle risorse interne che le gestiscono, oltre a trarre vantaggio dai già citati benefici.

 -      Cloud privato: installato dall’utente nel suo data center per suo utilizzo esclusivo. I servizi vengono forniti da elaboratori che si trovano interamente nel dominio del cliente che detiene controllo e totale responsabilità della gestione delle macchine sulle quali vengono conservati i dati e vengono eseguiti i suoi processi, assieme agli aspetti relativi alla sicurezza dei dati. Oltre allo scenario in cui si possiede interamente l’infrastruttura sui propri data center, un altro scenario possibile è invece quello in cui l’utente installa il proprio cloud privato nel data center di un terzo soggetto (tipicamente un fornitore di servizi cloud), in cui dispone di macchine dedicate. In questo caso, l’utente ha il controllo delle macchine anche se non risiedono nel suo dominio, e può configurarle secondo le proprie necessità.

 -      Cloud ibrido: combinazione del modello pubblico e di quello privato, ovvero un modello in cui l’utente utilizza risorse sia del suo cloud privato che di un cloud pubblico. Ad esempio, un utente che dispone di un cloud privato, può utilizzare le risorse di un cloud pubblico per gestire improvvisi picchi di lavoro che non possono essere soddisfatti facendo ricorso unicamente alle risorse disponibili nel cloud privato. Tuttavia questo modello

IL MODELLO DI RESPONSABILITA' CONDIVISA (SHARED RESPONSIBILITY MODEL)

Quando si considerano e si valutano i servizi cloud pubblici, è fondamentale comprendere il modello di responsabilità condivisa tra utente e service provider (Shared Responsibility Model), quali attività vengono gestite dal provider di servizi cloud e quali attività vengono gestite dall'utente. Le responsabilità del carico di lavoro variano a seconda delle diverse tipologie di servizi in cloud acquistati, Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS). Nella chart qui sotto potete vedere in rosso le responsabilità del Provider, mentre in celeste quelle dell’utente / cliente.

Nello IaaS il provider gestisce server,s torage, networking, virtualizzazione, mentre il cliente si occupa di tutto il resto (sistemi operativi, middleware, runtime, dati e applicazioni).

Nel PaaS, il cliente si occupa solo della gestione dei dati e delle applicazioni, mentre nel Saas è tutto a carico del provider (pensiamo ad applicazioni di CRM come Salesforce per intenderci, o a servizi di e-mail)

IL FRAMEWORK METODOLOGICO PER LA MIGRAZIONE AL CLOUD DELLA PA

Per iniziare un precorso di migrazione e identificare gli applicativi da cui iniziare, pianificarne ed eseguirne la migrazione, suggerisco un framework metodologico articolato in più fasi

1.    MAPPING DEGLI APPLICATIVI

 Evidentemente, il primo step  consiste nell’identificare una lista degli applicativi attualmente in uso, sia quelli utilizzati abitualmente che quelli con accessi saltuari o legati a specifiche necessità. L’obiettivo è di avere una visione d’insieme degli applicativi e i rispettivi servizi che l’amministrazione gestisce. Si fa un assessment degli applicativi, approfondendo gli aspetti e le caratteristiche tecnologiche e non. L’obiettivo è di raccogliere ad un sufficiente livello di dettaglio le informazioni necessarie a supportare un processo decisionale informato sulle possibili strategie di migrazione da applicare.

Fonte: Cloud Enablement Kit Agid

2. PRIORITIZZAZIONE

 Vengono identificati gli applicativi candidati ad essere migrati nell’immediato e nel medio lungo periodo, classificandoli secondo un sistema a quattro livelli. Si tiene conto del valore generato dalla migrazione, valutando il rischio potenziale e le difficoltà dell’operazione:

 -      Livello 1 (Opportunity): Gli applicativi che si consiglia di approfondire per primi sono quelli che hanno maggiori opportunità di trarre vantaggio dal cloud (soprattutto in termini di costi). Le domande da porsi per identificarli sono diverse (es: la licenza è in scadenza, si può risparmiare sulle infrastrutture, c’è una soluzione di disaster recovery e quanto costa?, quali applicativi richiedono risorse hw aggiuntive?, etc.)

 -      Livello 2 (Minimize risk):  il secondo livello si concentra sul rischio. Quali applicazioni si possono spostare con un rischio relativamente basso per la continuità del servizio? Le domande da porsi sono ad esempio: “Qual è la criticità di questa applicazione per l’organizzazione?  Qual è il livello dell’ambiente di questa applicazione ( produzione, staging, test, sviluppo)? Quante dipendenze e/o integrazioni non interoperabili ha questa applicazione? Quali sono le considerazioni sui dati per questa app? Sono aggiornati di frequente?”

-      Livello 3 (Easyness of Migration): la facilità di migrazione riguarda il modo in cui il trasferimento dell’applicazione verso il cloud sarà privo di attriti. Alcune buone domande da porsi includono:  “Come è stata sviluppata questa applicazione (make or buy)?  Quanto è nuova questa applicazione? Questa applicazione è strettamente dipendente da uno specifico sistema operativo o è flessibile?”

 -      Livello 4 (Other Apps):  Il quarto ed ultimo livello di questo framework raccoglie tutti quegli applicativi che non hanno un evidente beneficio dalla migrazione al cloud, rappresentano un rischio significativo nella migrazione, sono molto personalizzati, hanno una complessità specifica nella migrazione.

3. STRATEGIA DI MIGRAZIONE

 Ci sono 6 tipiche strategie di migrazione possibili da valutare attraverso un’approfondita analisi costi benefici:

-      Lift & Shift:  consiste nel prendere (Lift) l’intero servizio, compreso di infrastruttura, architettura, dati e traffico e spostarlo su un hosting cloud (Shift) senza modifiche al core dell’applicativo. Spesso il re-host è una strategia che permette di fare un primo step verso il cloud valutando poi successivamente ulteriori miglioramenti all’applicativo che permettano di sfruttare ulteriormente i vantaggi del cloud.

-      Re-platform:  La strategia di Re-platform, oltre a trasferire un applicativo sul cloud come nel re-host, sostituisce nel processo di migrazione alcune componenti per meglio sfruttare le specificità della piattaforma di destinazione (utilizzando servizi PaaS). Esempi di sostituzione sono la sostituzione dei load balancer, database management, ambienti di runtime.

-      Retain: La strategia di conservazione o retain consiste nel prendere la decisione consapevole di non migrare in cloud un determinato applicativo e di mantenerlo attivo sulla propria infrastruttura on-premise definendo una nuova data in cui rivalutare i fattori che hanno portato a questa decisione. E nel caso non fossero più attuali, procedere con la migrazione in cloud dell’applicativo.

 -      Retire:  La strategia di smantellamento o retire consiste nell’identificare gli applicativi che non sono più utili e possono essere "spenti", per focalizzare l’attenzione sulle risorse che sono maggiormente utilizzate. Sono da considerarsi come “non più in uso” anche quegli applicativi il cui beneficio per l’amministrazione pubblica è inferiore ai costi complessivi di mantenimento, ed il cui utilizzo è limitato ad un insieme predefinito e ricorrente di funzionalità con bassa frequenza.

 -      Re-purchase: La strategia di re-purchase consiste nel rimpiazzare un applicativo installato e gestito on-premise con la controparte SaaS.  Esempi di servizi che è possibile migrare su SaaS sono laPosta elettronica, File Server per la condivisione dei file, ERP, CMS, Collaborazione e produttività, etc.

-      Refactoring:  La strategia ha come obiettivo quello di ripensare significativamente l’architettura core di un applicativo in ottica cloud, con un processo di redesign iterativo ed incrementale (agile) che mira ad adottare appieno i servizi cloud-native offerti dai cloud service provider, per massimizzare i benefici che ne derivano. Pensiamo all’utilizzo di API Gateway, alla creazione di layer di orchestrazione e integrazione alla realizzazione di applicazioni con logica di micro-servizi.

4. IMPLEMENTAZIONE

E’ la fase durante la quale si esegue l’effettiva migrazione degli applicativi a più alta priorità.  Sviluppatori, sistemisti e tester devono adottare un approccio operativo conforme alle pratiche DevOps  per garantire comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle operations.  Tutte le fasi di un piano di migrazione devono essere iterative ed incrementali rispetto ad un insieme prioritizzato di azioni che si vogliono intraprendere sia nel caso si stia definendo il piano di migrazione degli applicativi, sia nel caso

5. FORMAZIONE DELLE COMPETENZE

Uno dei fattori cruciali per il successo di un processo di migrazione (oltre ovviamente alla definizione di un piano strategico ed operativo per la migrazione al cloud) sono gli hard & soft skills dei funzionari pubblici. E' fondamentale formare il personale dirigente ed operativo per colmare il gap di  competenze necessaria alla migrazione, coprendo non solo l’ambito tecnologico, ma tutti quelli che possono essere necessari per il successo del (Devops, Cloud, Security Agile Project Management & Development, Problem Solving).