Intervista

Change Management nell’era dell’IT ibrida e multicloud. Sinthera: "È tempo di gestire l'on-premise come i grandi cloud provider"

Per poter gestire l’IT aziendale nell’era dell’hybrid multicloud occorre utilizzare gli stessi metodi di delivery infrastrutturale e applicativo che sono oggi impiegati ad esempio da Google e Amazon. Ne parliamo con Paolo Marco Salvatore, CTO di Sinthera

03 Giu 2020

Redazione

Qual è il cambiamento più significativo richiesto all’IT aziendale dall’utilizzo dei servizi di cloud ibrido e multicloud? Per Paolo Marco Salvatore, CTO di Sinthera, la risposta è semplice: «Consiste nell’adozione di modalità di gestione dell’on-premise analoghe a quelle adottate su grande scala dai grandi cloud provider, come Amazon o Google».

Paolo Marco Salvatore

CTO di Sinthera

La crescente complessità degli ambienti d’impresa non può essere affrontata senza spingere l’acceleratore sull’automazione, sull’esempio di chi oggi fa business con servizi cloud.

Come? «Abbiamo visto l’applicazione di modalità agili nello sviluppo, di DevOps, di pratiche focalizzate per l’automazione delle operation e dei deploy del software – continua Salvatore -. Un percorso che prosegue con GitOps, un approccio che mette insieme il provisioning delle infrastrutture con il deploy delle applicazioni».

L’automazione del provisioning infrastrutturale con GitOps

GitOps offre un modo per implementare il Continuous Deploy (CD) attraverso Git (un tool molto noto tra chi sviluppa applicazioni native per il cloud), ma valido anche con altri strumenti. È un modo per sfruttare le moderne infrastrutture data center virtualizzate, e in particolare kubernetes, sfruttandone il modello dichiarativo per risorse “software defined”. L’idea è usare il repository di Git per contenere non solo i progetti e il codice applicativo, ma anche tutte le prescrizioni relative alle infrastrutture, reti e storage.

Mentre nei processi tradizionali, il trasferimento dei requisiti d’infrastruttura dipende dalla comunicazione tra team diversi (sviluppo e operation), spesso divisi anche nel linguaggio e nelle competenze, con GitOps codice, configurazioni di sistema, modalità di monitoraggio e altri aspetti viaggiano e si aggiornano insieme. «Nei processi di Continuous Integration e Continuous Deploy con modalità DevOps – spiega Salvatore -, ogni volta che lo sviluppatore lancia il commit, si avvia in automatico il build dell’eseguibile, che passati test funzionali, di qualità e gradimento degli utenti, può andare in produzione».

Come si gestiscono gli aggiornamenti

La nuova prassi vuole che i requisiti infrastrutturali vengano gestiti su piattaforme come Git, «attraverso interfacce di programmazione per ogni oggetto o servizio – precisa Salvatore -, quindi rimediando ai configuration drift attraverso definizioni a più alto livello dello stato funzionale richiesto, quindi usando tool come Terraform o Ansible per allineare l’infrastruttura, rimediando alle differenze rilevate».

Con GitOps, i deploy seguono modalità specifiche. Se si ha bisogno di aggiornare una piattaforma, si istanzia nuovo codice e nuove risorse sull’infrastruttura, in parallelo alla precedente. Se il nuovo ambiente soddisfa i requisiti, allora si trasferiscono gli utenti e si butta via la versione precedente. «Questo è l’approccio adottato dai grandi cloud provider – precisa Salvatore – che non fa perdere tempo nell’allineare l’infrastruttura e nel tracciare le modifiche per gli eventuali rollback».

Come realizzare il cambiamento

Come si realizza il salto di qualità verso il deploy automatizzato? Salvatore cita l’esperienza di Sinthera con un cliente impegnato a ridisegnare le applicazioni con cui i clienti interagiscono con la banca. «C’era l’esigenza di adottare un nuovo framework di sviluppo, ma anche di rivedere le modalità d’interazione tra i membri del team e adottare un nuovo approccio al project management con il DevOps».

Per cambiare l’IT, «serve individuare scopi delimitati e chiari – precisa Salvatore -. Il problema più grande è creare il team, quindi fare formazione in modo continuo, tenendo in considerazione che le persone devono poter ottemperare anche alla loro mansione primaria aziendale. In modo graduale, in 3 anni il cliente è stato messo in grado di trarre beneficio dal cambiamento».

Le nuove architetture cloud con software a microservizi non risolvono tutti i problemi: «Con le architetture distribuite non sempre è possibile bilanciare i parametri di velocità, costo e qualità richiesti – spiega Salvatore -. Il valore che portiamo è l’esperienza, la capacità di ridurre i rischi e velocizzare il cambiamento».

L’approccio iniziale ai progetti d’innovazione inizia, per Sinthera, con un discovery workshop di 3 giorni rivolto agli analisti software, sviluppatori e responsabili IT del cliente. «Partiamo dalle basi, container e kubernetes – spiega Salvatore -. Poi trattiamo tool come Terraform e Ansible, le pratiche di DevOps, continuous integration, continuous development, e altre. Una volta che le persone hanno acquisito conoscenza e terminologia comuni, diventa possibile discutere e condividere gli obiettivi del cambiamento».

@RIPRODUZIONE RISERVATA

Articolo 1 di 3