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