Come avvicinarsi al DevOps, tra falsi miti e vantaggi reali

Di DevOps si parla da anni, ma esiste ancora confusione intorno al significato di questa sigla (che rappresenta il connubio tra development e operations) e a ciò che comporta per le aziende che l’adottano. Tra dubbi e false certezze, il DevOps deve ancora affermarsi pienamente sul mercato e per una adozione consapevole e di successo potrebbe essere opportuno l’ingaggio di un mediatore, un system integrator, un consulente tecnologico. Ne abbiamo parlato con Mirko Gubian, Global Demand Senior Manager di Axiante, società che ama definirsi come “Business Innovator Integrator” al fianco delle aziende clienti.

Intorno al concetto di DevOps esistono ancora dei dubbi o preconcetti? 

La prima cosa che facciamo parlando di DevOps  è rimuovere un mito. Spesso si pensa che siano concetti o tecnologie a uso e consumo e a vantaggio solo di chi mette le mani nel codice e programma, ma non è così. Il DevOps non è una tecnologia, non è un insieme di tool specifici e non rappresenta solo un vantaggio per gli sviluppatori o per il team informatico: al contrario, è una cultura, è un processo, e porta vantaggi all’intera azienda. Nelle aziende non sono gli sviluppatori a decidere quali nuove funzionalità inserire in un’applicazione, solitamente sono i manager Line of Business a chiedere che vengano rese disponibili determinate funzionalità o modifiche. E con il DevOps tutto questo si può gestire meglio.

Quali sono i principali vantaggi?

Il vantaggio fondamentale è la flessibilità, e si tratta di una flessibilità di cui beneficia l’azienda, il business, e non il team degli sviluppatori. Il DevOps permette di accorciare il time-to-market, di tagliare i tempi dal momento in cui una nuova applicazione (o una funzionalità interna all’applicazione esistente) viene richiesta a quando viene sviluppata, testata e poi messa in produzione. Il DevOps quindi è un abilitatore, perché consente di modernizzare un’applicazione in tempi rapidi e con maggiore agilità, e dunque di reagire più rapidamente alle esigenze del mercato. Ci sono poi anche dei benefici economici, perché modernizzare un’applicazione riduce il Total Cost of Ownership dell’applicazione stessa ed evita alle aziende di dover spendere soldi per la manutenzione di tecnologie obsolete.

E la sicurezza?

Questo è un punto fondamentale, tant’è che se sarebbe più corretto parlare di DevSecOps, incorporando anche l’elemento della security, anche se la sigla DevOps è quella che si è affermata nel lessico dei vendor e delle aziende. Terminologia a parte, il modo in cui la sicurezza è integrata nel ciclo di sviluppo è totalmente cambiato. Nell’approccio tradizionale si parte dalla scrittura del codice, poi si crea un ambiente integrato per il testing e successivamente l’applicazione viene spostata in un ambiente di quality assurance e infine messa in produzione. Le verifiche di sicurezza arrivano alla fine.

Nel DevOps (o DevSecOps), al contrario, ogni volta che uno sviluppatore apporta una modifica e la inserisce nel  repository del codice, automaticamente essa viene testata nel flusso di lavoro. Lo sviluppatore può sapere immediatamente se tale modifica si integra con il codice progresso o se ha creato dei problemi. Inoltre nel DevOps i test eseguiti misurano non solo le performance ma anche la sicurezza. In sintesi, quelle che prima erano fasi distinte e sequenziali ora avvengono ogni volta che viene apportata una modifica di codice.

Mirko Gubian, global demand senior manager di Axiante

Come ci si avvicina al DevOps? Da dove si parte?

Innanzitutto bisogna ricordarsi che non stiamo parlando solo di tecnologia. Il primo passo non è decidere quali tool usare. Il primo passo è mettere allo stesso tavolo i team di sviluppo e di operations, cioè il personale deputato allo sviluppo delle applicazioni e coloro che si occupano della gestione. Storicamente questi due ruoli sono stati misurati in maniera diversa: dal team di sviluppo ci si aspettava efficienza e velocità, mentre alle operations si chiedeva che le applicazioni funzionassero in modo continuativo, senza problemi di sicurezza o interruzioni. Dunque è importante spiegare alle aziende che bisogna lavorare con un solo team e misurarlo con parametri unici.

Una volta messi allo stesso tavolo diversi punti di vista e funzioni, bisogna definire il processo da seguire, la pipe, i criteri di sviluppo, test, quality assurance. Solo dopo si possono scegliere i tool tecnologici da usare.

Quindi, per un’azienda che si approccia per la prima volta al DevOps, è bene investire innanzitutto sulle persone, sulla cultura del personale e sulla formazione dei team che rompono le barriere dipartimentali tra Dev e Ops. È importante che i team non vedano il DevOpS come un’imposizione ma come un vantaggio. C’è poi da fare un investimento sul disegno delle applicazioni. Di contro, il costo effettivo di realizzazione delle iniziative DevOps è molto contenuto (anche per la disponibilità di molti strumenti open-source) a fronte di ritorni sull’investimento notevoli.  Mediamente, in sei mesi un’azienda può partire da zero e arrivare ad avere un processo DevOps funzionante. Se però l’azienda è agile o di medie dimensioni allora possono bastare anche due o tre mesi.

Come aiutate le aziende clienti a trarre vantaggio dal DevOps?

Innanzitutto cerchiamo di supportarle con la giusta formazione, sia culturale sia tecnica. Sul primo aspetto, abbiamo alle spalle la nostra stessa esperienza di passaggio al DevOps e cerchiamo di portarla anche ai nostri clienti. Inoltre i nostri tecnici, una volta definito il processo, possono individuare con i tecnici dell’azienda l'infrastruttura informatica e gli strumenti da utilizzare, e possono offrire formazione e affiancamento tecnico. In effetti in Axiante spendiamo molto tempo a formare i nostri clienti, perché riteniamo sia giusto lasciare alle aziende il controllo sulle proprie iniziative di trasformazione tecnologica.

Spesso molti clienti hanno paura a buttarsi in queste iniziative perché temono di dipendere poi dal fornitore che realizza il progetto, dai suoi tempi e dalle richieste. La pensiamo diversamente: se si vuole essere promotori di cambiamento allora bisogna lasciare il controllo a chi quel cambiamento deve realizzarlo. Ciò significa formare il cliente e renderlo più indipendente. Questo non ci spaventa, ma anzi è utile al cambiamento e ci dà anche l’opportunità di instaurare un rapporto diverso e di lunga durata con il cliente, che ci percepisce come un partner per la trasformazione.