\ /
sorint.lab  sorintians  cloud  Database  Microservices  Sircle 

Infocert come Sun Wukong

Dovendo scegliere un termine che oggi possa identificare l'informatica contemporanea tra il più ampio pubblico, non ci sono dubbi che questo termine sia l'inglesissima parola "cloud". L'aspettativa che si è creata intorno a questo sostantivo, soprattutto "ai tempi del COVID19" (locuzione quest'ultima oramai troppo spesso abusata, ndr), mostra aspetti di particolare interesse in quanto il vocabolo di per sé presenta molteplici facce a seconda del suo interlocutore. Questo evidentemente è dovuto in parte alla sua origine straniera, che chiaramente lo rende meno pregnante nell'uditorio italiano anche più istruito, ed in parte alla sua totale aspecificità, tutte caratteristiche che secondariamente contribuiscono inoltre ad alimentare una certa esterofilia di cui il settore informatico (italiano) è già ampiamente impregnato.

Gli aspetti che però per noi sono di maggiore interesse, si riferiscono in particolare alla semantica tecnico-commerciale che ha assunto nel gergo aziendale e che è connessa al concetto di "public cloud". Più precisamente siamo interessati alla sua capacità di disaccoppiare, almeno teoricamente (ed entro certi limiti), l'azienda proprietaria dell'infrastruttura (hardware e software) e che si cura della sua gestione e manutenzione, da quella che si occupa della progettazione e realizzazione dei servizi che di quella infrastruttura faranno uso, promettendo in questo modo di migliorare i livelli funzionali e rendere più efficienti tutti i processi aziendali "tecnologico-dipendenti". La forza di questa particolare idea ha così conferito alla parola "cloud" una evidente capacità di penetrazione nei diversi livelli e comparti di quelle aziende che primariamente erogano servizi a privati o imprese, che stanno così dispensando notevoli risorse in questa nuova "corsa all'oro".

La scelta strategica di adottare "soluzioni (public) cloud" si presenta per loro quindi (quasi) obbligata, e si ritrovano immerse in un mercato, quello del "cloud" appunto, che freneticamente presenta nuovi attori e propone nuove offerte e nuovi servizi. La conseguente ubriacatura indotta da questa smania, è un seria fonte di rischio durante le fasi più operative del percorso di adozione di questo nuovo modello di erogazione dei servizi. Il suo piano di attuazione assume quindi diverse declinazioni, che richiedono una valutazione attenta dei risultati attesi e delle relative metriche di valutazione. In questo contesto lo spostamento, la riorganizzazione e la dismissione delle componenti informatiche, siano esse hardware o software, la formazione e riqualificazione del personale, il rispetto normativo e giurisprudenziale assumono un ruolo centrale nella definizione della tattica.

Infocert, evidentemente anch'essa soggetta alle forze di trazione esercitate da questo nuovo paradigma, nel piano più complessivo di riorganizzazione dei servizi, e sotto la spinta interna di due anime, la prima che promuoveva e promuove una decisa migrazione dei servizi su public cloud, ed una seconda più reazionaria, meno incline ad un abbandono completo del "precedente" modello operativo, ha deciso di valutare se, quanti e quali dei loro servizi fossero candidabili ad una collocazione presso un cloud provider, valutando Amazon quale miglior soluzione per le loro esigenze. La possibilità di una completa transizione verso il public cloud, seppur tecnicamente percorribile con i tempi necessari, molto spesso deve scontrarsi con esigenze diverse che ne condizionano talvolta drasticamente il percorso, e come per Infocert richiede quindi soluzioni più articolate.

Viste le difficoltà emerse nello scandagliare i possibili scenari tecnici, nel definire e valutare le problematiche tecnico-funzionali, e consci delle complessità che un cambiamento di questo tipo richiede, l'azienda sceglie di proseguire nell'adottare questo "nuovo" modello coadiuvata da Sorint nella fase di definizione, coordinamento e supervisione tecnica al progetto. Il coinvolgimento inizia nel Luglio del 2019 con una programmazione dei lavori molto stringente che aveva come termine ultimo il 31 Dicembre dello stesso anno, data che evidentemente non è poi stata rispettata.

Infocert eroga servizi collegati alla gestione dell'identità digitale e più in generale ai sistemi di certificazione delle procedure ad essa connessi, quali i sistemi di firma digitale della documentazione e quelli di posta certificata; servizi che nel loro caso sono rivolti al mercato B2B. Le caratteristiche specifiche di questo tipo di settore ponevano diverse difficoltà normative, alcune di queste legate alla collocazione dei dati ed alla loro accessibilità, a cui occorreva rispondere con una strategia ibrida, in cui una parte dei servizi potevano essere collocati esternamente sull'infrastruttura di Amazon, ed un'altra richiedeva un approccio più "tradizionale" (seppur comunque innovativo) che invece utilizzasse esclusivamente l'infrastruttura già disponibile presso i loro centri di elaborazione dati. L'azienda possiede primariamente due centri elaborativi, il principale dei quali si trova a Padova da dove vengono attualmente erogati tutti i servizi, mentre il suo subalterno è a Modena, e normalmente è inattivo fungendo da sito per il "Disaster Recovery".

Il disaccoppiamento nella collocazione delle applicazioni software ha richiesto quindi una omogeneizzazione del livello di servizio delle due infrastrutture, quella Amazon e quella Infocert, che consentisse inoltre anche di rispondere alle nuove esigenze contrattuali molto serrate che si andavano delineando nella proposta commerciale di Infocert. Le esigenze descritte hanno rivisto i ruoli di questi due siti, che sono stati parificati, "attivando" il sito di Modena e permettendogli in questo modo l'erogazione dei servizi assieme a quello di Padova, almeno per quelle applicazioni oggetto di migrazione in questa prima fase. Inoltre sono state introdotte nuove tecnologie software ed adottati nuovi paradigmi di sviluppo per la produzione delle applicazioni che saranno ospitate sul "nuova" impianto.

L'infrastruttura Infocert emersa con il disegno del nuovo modello, sebbene considerata una soluzione "multi zona" su singola regione, nella realtà e nell'inconsapevolezza generale, ha assunto una topologia multi regione con le sue proprie difficoltà, che differivano da quelle attese. Inoltre anche le esigenze normative, che non avevano consentito l'abbandono completo dell'infrastruttura aziendale, vincolando ad una netta distinzione tra i servizi erogati tramite Amazon e rimasti sull'impianto interno, riducevano di fatto per questi ultimi la numerosità dei siti a due, numero evidentemente inadeguato alle esigenze di distribuzione ed esecuzione geografica. Inoltre occorreva non dimenticare anche tutti le applicazioni che pur non essendo direttamente coinvolte da questo progetto, avrebbero usufruito dei "nuovi" servizi pur continuando ad adottare il modello di erogazione precedente, e sarebbero quindi state eseguite esclusivamente a Padova salvo disastri. In questo contesto ad esempio ha ricoperto un aspetto importante la gestione della geolocalizzazione operativa dei diversi servizi che tra loro interagiscono.

Sul piano tecnico è stato deciso di abbandonare il database relazionale Oracle per approdare su quello NoSQL Mongodb, la cui scelta, fatta come spesso capita nell'impeto iniziale e probabilmente in una fase prematura del progetto, ha richiesto alcuni adattamenti in corso di adozione, e successivamente una indagine che fortunatamente si è conclusa positivamente, sulla possibilità di utilizzo dell'infrastruttura Amazon per la collocazione dei dati. Mongodb, in virtù della sua capacità di gestire la replica delle informazioni, ha in parte risolto alcuni dei classici problemi sulle modalità di copia e accesso ai dati, ma aggiungeva esigenze più vincolanti in merito a numero e posizione delle copie. La sua configurazione che richiede un numero dispari di copie appunto, mal si adattava al numero dei siti Infocert disponibili. Sulla base dei requisiti in essere quindi è stato suggerito di sfruttare alcune sue particolarità nel tentativo di aggirare questa prima esigenza. Per questo motivo la configurazione prevedeva inizialmente, come suggerito da Mongodb Inc. anche per ovviare alle disposizioni su posizionamento ed accedibilità delle informazioni, di utilizzare i due siti Infocert per ospitare le istanze con i dati, mentre quello di Amazon per ospitare il nodo "arbitro", che diversamente dagli altri, non immagazzina alcuna informazione. Questo però confliggeva con un'altra esigenza più spiccatamente "applicativa", quella di poter garantire una stringente coerenza dei dati sui due siti di Padova ed Modena, che aveva richiesto l'adozione di una politica di scrittura delle informazioni sul database definita "a maggioranza", e con la quale in alcune condizioni potevano evidentemente porsi gravi problemi di totale incapacità ad erogare i servizi. Il nodo "arbitro" è stato quindi sostituito con un nodo dati grazie anche all'introduzione di sistemi di crittografia delle informazioni, che hanno in parte mitigato la presenza di quei dati su un sito non sotto il completo controllo aziendale.

I servizi collegati ad applicazioni già esistenti sono stati in tutto o in parte nuovamente scritti. Per alcuni di questi si è semplicemente proceduto ad un adattamento tecnologico anche (e non solo) in conseguenza dell'atterraggio su Mongodb; per altre diversamente la traduzione è stata più profonda ed ha coinciso con l'adozione almeno (o meglio sarebbe scrivere solo) formalmente di un modello basato sui microservizi. Per queste ultime in particolare, la cui logica di business è stata sezionata e ripartita su diverse componenti direttamente comunicanti tra loro, comunicazione che si è assommata a quella già presente e richiesta tra i diversi servizi, si è reso necessario verificare i flussi operativi e garantire la coerenza comportamentale in risposta ad anomalie o disservizi infrastrutturali, al fine di consentirne la piena operatività, pur in presenza di una fase di disservizio necessaria ma transitoria, che però sarebbe dovuta essere minimizzata e contenuta all'interno degli stringenti accordi contrattuali con i clienti.

La doppia anima di questo nuovo modello composto di infrastruttura e servizi, ed il rispetto dei livelli di servizio da garantire poneva un problema di auto adattamento del sistema nel suo complesso di componenti applicative ed infrastrutturali. Occorreva che i diversi elementi dell'infrastruttura dialogassero tra di loro per rilevare e reagire opportunamente alle mutazioni delle condizioni ambientali. Questo si è tradotto da un lato nella definizione di una modalità di interscambio di informazioni in merito allo stato operativo delle applicazioni, modalità che fosse anche consultabile dalle componenti infrastrutturali, e dall'altro nella creazione di regole di risposta ai diversi scenari di anomalia previsti anche se non auspicati. In conseguenza di questo ad esempio è emersa la necessità di alcune funzionalità di controllo specifiche su alcuni dispositivi di rete, non sempre disponibili su quelli già presenti in Infocert, ma la concomitante dismissione di alcuni di questi apparati già in essere, quali i bilanciatori, ha consentito una valutazione più contestuale dei nuovi prodotti da acquistare ed una scelta più mirata.

La fase che potremmo definire finale, ha previsto la verifica di quanto disegnato attraverso la stesura di un piano di test. La proposta strategica condivisa con ed accettata da Infocert, è stata in questo caso la verifica non tanto o non solo del comportamento dell'architettura nel suo complesso, ma anche di valutare l'influenza di questo comportamento sui diversi servizi durante la piena operatività. Occorreva quindi predisporre un ambiente per la simulazione delle richieste, stimare quali sarebbero stati i carichi attesi in piena operatività, analizzare i flussi connessi ai diversi casi d'uso applicativi per comprendere da dove generare il carico simulato, ed infine su tutte queste informazioni dimensionare l'ambiente di simulazione. Contestualmente sono stati identificati possibili anomalie e fallimenti, per i quali sono state quindi definite le modalità di simulazione. I test in alcuni casi hanno fatto emergere bug su librerie o framework adottati sconosciuti agli stessi produttori, in altri consentito di correggere alcuni errori nello sviluppo del software, in altri ancora mostrato i limiti nelle capacità di alcuni apparati di crittografia.

Giovanni Senatore Pioneer - Sircle Academia

comments powered by Disqus