DevOps è una di quelle tendenze che, nel mondo dell’IT, riveste un consenso unanime: la grande differenza rispetto alla tradizionale modalità di sviluppo software è rappresentata dalla possibilità di accelerare notevolmente lo sviluppo delle applicazioni. Nell’approccio dell’era pre DevOps le aziende avevano infatti a che fare con un notevole disallineamento tra sviluppatori, team operativo e produzione, che tendevano a procedere su binari separati. Con conseguenze negative sui costi dello sviluppo software, sui tempi della pianificazione e, in fin dei conti, sulla stessa reputazione di un’organizzazione.
Un problema che si è recentemente aggravato con l’evoluzione tecnologica attuale, che ha portato alla nascita di un’economia sostanzialmente software defined: le aziende di tutti i settori produttivi interagiscono con i propri clienti o partner tramite prodotti software sotto forma di applicazioni o servizi online, che possono essere utilizzati in molti dispositivi differenti. I software sono ormai costantemente impiegati per migliorare l’efficienza operativa della produzione, della logistica e delle comunicazioni; le stesse infrastrutture hardware IT sono sempre più software defined, cioè gestite e potenziate per mezzo di speciali software. Dunque le aziende hanno un’estrema necessità di avere a che fare con software e applicazioni che siano il più frequentemente possibile aggiornatati ed efficienti, in modo da mantenere ai più elevati standard la propria catena produttiva. Ma come è stato caratterizzato, sino a non molto tempo fa, lo sviluppo del software? In passato, la delivery del software avveniva in modo relativamente semplice. Tutti i requisiti erano definiti con il cliente prima della fase di coding e del testing di Quality and Assurance (Q&A). Il team responsabile delle Operation a un certo punto interveniva e distribuiva tutto. In modo semplice, limpido e perfettamente ordinato. Una procedura che, però, comportava inevitabilmente tempistiche molto lunghe, incompatibili con le esigenze del business moderno, dove le priorità cambiano di continuo.
Indice degli argomenti
Cos’è e cosa significa la metodologia DevOps (developement operations)
Questa situazione sta rendendo vincente il paradigma DevOps, un termine che nasce dall’unione delle parole dev (sviluppo) e ops (operazioni): secondo la definizione di AWS, nel DevOps “ I team dedicati a sviluppo e produzione non agiscono più separatamente. In alcuni casi, al contrario, i due team vengono fusi in un’unità in cui i tecnici sono attivi lungo tutto il ciclo di vita dell’applicazione, da sviluppo e testing a distribuzione e produzione, e acquisiscono una serie di competenze non limitate da una singola funzione. In alcuni modelli DevOps, anche i team dedicati a controllo della qualità e sicurezza spesso sono coinvolti più direttamente nelle fasi di sviluppo e gestione in tutto il ciclo di vita dell’applicazione. Quando in un team di DevOps la sicurezza è il punto focale di tutti, a volte prende il nome di DevSecOps”.
Vantaggi del DevOps per le aziende e il business
In buona sostanza, le aziende che sposano una strategia DevOps hanno la possibilità di effettuare test e implementare nuove funzionalità e applicazioni molto più rapidamente rispetto alle modalità di sviluppo tradizionali, senza contare il fatto che gli stessi sviluppatori, lavorando in prima linea sulla programmazione, sono stimolati a scrivere codici di qualità superiore. In particolare, I processi che in passato potevano risultare manuali e lenti per i team di sviluppo, come l’aggiornamento di codice o il provisioning di un nuovo ambiente, possono essere ora eseguiti rapidamente e in modo continuativo grazie agli strumenti e alle procedure DevOps. È inoltre più facile rispettare gli standard per la sicurezza e l’affidabilità perché questi elementi sono direttamente incorporati nel processo.utti lavorano in un ambiente incentrato sulle competenze in cui determinati dipartimenti o settori non desiderano condividere informazioni tra loro nella stessa azienda, il che probabilmente porta all’inefficienza di un’organizzazione.
DevOps VS non DevOps: le differenze
Una grande differenza tra DevOps e non DevOps, spesso non adeguatamente sottolineata, può essere identificata nell’aspetto dimensionale. I team DevOps si caratterizzano per un lavoro su piccoli lotti di codice, in modo da rendere possibile il testing e rilascio continuo e, al contempo, ridurre al minimo i rischi. Al contrario gli sviluppatori tradizionali sono abituati a lavorare su enormi porzioni di codice, in maniera tale da rispettare le date di rilascio stabilite in fase di programmazione, fattore che espone inevitabilmente a un rallentamento della produttività e a un possibile aumento dei costi. Inoltre, nel mondo non DevOps ogni professionista tende a lavorare con altri che condividono le proprie competenze o attività. Si tratta di una modalità che non facilita la condivisione di informazioni tra i diversi dipartimenti aziendali, provocando inevitabilmente inefficienze all’interno di un’organizzazione.
DevOps: Integrazione e distribuzione continua
Altre due caratteristiche fondamentali di un sistema di sviluppo DevOps sono l’integrazione continua (CI) e l‘erogazione continua e/o la distribuzione continua (CD). CI significa che nel processo di sviluppo i test su una porzione di codice sono continui e automatici, mentre CD sta a indicare che il processo di messa in produzione del codice validato dopo il dovuto collaudo diventa automatica. Sono proprio queste due caratteristiche che rendono possibile l’accelerazione dei tempi di rilascio. In passato, ad esempio, molte aziende mettevano in produzione il nuovo codice a date prestabilite, con tempistiche magari mensili. Ma la velocità attuale del business ha reso questo modello per cicli di rilascio del tutto obsoleto; DevOps, invece, punta proprio ad automatizzare il ciclo di rilascio per renderlo il più possibile immediato.
Come lavorano i team di DevOps
Oltre al cambiamento delle modalità di lavoro da svolgere, DevOps determina inevitabilmente anche un cambiamento del tipo di lavoro da svolgere, nota un’azienda esperta di questo settore come Red Hat. “La metodologia DevOps non permette semplicemente di accelerare la creazione delle solite, vecchie applicazioni monolitiche, ma si prefigge di creare nuove tipologie di software, che rispondono più efficacemente all’esigenza di delivery continua. Proprio per questo, per la realizzazione del software i team DevOps spesso utilizzano un’architettura a microservizi e collegano tali servizi fra loro attraverso le API. I team possono accelerare la delivery concentrandosi sulla creazione di funzionalità più limitate (..)”.
DevOps: più attenzione alla sicurezza
L’aumento della velocità reso possibile dall’adozione del modello DevOps non significa però un minore controllo sulla conformità di controllo e applicazioni, tutt’altro. Il vero vantaggio derivante dall’adozione di questo paradigma è proprio che l’aspetto sicurezza non è più affidato a un team separato, ma entra immediatamente a far parte del modello di sviluppo del software stesso e della sua relativa fase di test. Si tratta della cosiddetta Security By Design, un principio che è stato adottato da numerosi vendor del mercato, come ad esempio Trend Micro. Dal momento che il DevOps rende possibile ai team di sviluppo lavorare per microservizi, ossia per piccole parti di applicazione che possono essere modificate in maniera molto veloce. Il risultato indiretto è a tutto favore della sicurezza: ogni team ha di avere meno codice da analizzare e maggiori possibilità di rimediare a eventuali errori o a vulnerabilità. Che in ogni caso, data la possibilità di aggiornamento rapido e continuo resi possibili da DevOps, possono essere risolti in maniera molto più tempestiva.
DevOps: boom atteso entro 5 anni
Ma quanto è diffuso attualmente il modello DevOps? Secondo i dati di una recente ricerca pubblicata da Fujitsu, entro il prossimo quinquennio le aziende si aspettano notevoli passi avanti nel completamento della diffusione di DevOps. In particolare, questa metodologia viene considerata dalla maggior parte delle aziende coinvolte nello studio come un approccio prezioso per affrontare il cambiamento continuo necessario per raggiungere un superiore grado di flessibilità a fronte di costi decrescenti. D’altra parte, le percentuali che scaturiscono dal report indicano come molta strada rimanga ancora da fare: solo meno di metà degli intervistati (45%) giudica attualmente DevOps come ‘stabilito’ (25%) o ‘completamente stabilito’ (20%). Solo un’azienda su quattro ha completato un progetto DevOps pilota e il 22% lo sta realizzando o pianificando. D’altra parte, appena l’8% del campione non possiede alcun piano per esplorare DevOps. Nonostante solo il 20% delle aziende disponga attualmente di processi DevOps maturi, i responsabili decisionali IT si attendono importanti cambiamenti. I risultati del sondaggio Fujitsu State of Orchestration 2018/19 evidenziano come quasi otto intervistati su dieci (78%) si aspettino che le aziende ricorrano a DevOps per erogare applicazioni e servizi su scala entro i prossimi cinque anni. Le principali ragione per perseguire un modello DevOps, emerge dal report Fujitsu, sono quelle di poter gestire meglio i cambiamenti e i miglioramenti continui (42%), diventare più rapidi e capaci di supportare i cambiamenti business (37%), e abbattere i costi (36%).
DevOps: i vantaggi per gli ISV
L’avvento del modello DevOps ha ovviamente rimescolato le carte nel mondo del software, a tutto vantaggio dei piccoli produttori software, i cosiddetti ISV (Indipendent Software vendor). Che ora, oltre alla loro rodata flessibilità organizzativa, possono contare su una flessibilità tecnica senza precedenti. Il maggiore beneficio per gli ISV, in particolare, risiede nella stretta integrazione esistente tra DevOps e cloud, che consentono di abbattere molte delle barriere IT tipiche della vecchia era del software. In poche parole, molti ambienti di test e provisioning, necessari al moderno sviluppo software, risiedono nei servizi cloud offerti dai principali provider globali. Che possono quindi essere utilizzati, in modalità pay per use, dagli sviluppatori degli ISV per rilasciare più rapidamente applicazioni o aggiornamenti. La modalità cloud, tra l’altro, rende possibile ampliare a dismisura la collaborazione, particolare non di poco conto se si tiene conto che i team di sviluppo sono spesso sparsi per il mondo, così come i clienti finali. Tutto questo consente agli produttori di progettare, assemblare e testare piccoli pezzi di funzionalità più velocemente rispetto al passato e in maniera più efficace.
Come fare DevOps: gli step da seguire
Da un punto di vista teorico, la strategia DevOps non può non fare riferimento alla metodologia Agile, e cioé a quella summa di principi derivati dal “Manifesto Agile” che nel 2001 ha definito un modello di sviluppo focalizzato sull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente (early delivery – frequent delivery), software funzionante e di qualità. Rispetto ai metodi tradizionali a cascata o ad altri processi software, le pratiche Agile presuppongono la formazione di team di sviluppo piccoli, cross-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo. Se si vuole mettere in piedi un IT shop di successo, il primo passo è dunque quello di scegliere una metodologia Agile intuitiva, con dei framework di sviluppo come Scrum (che enfatizza tutti gli aspetti di gestione di progetto legati a contesti in cui è difficile pianificare in anticipo) o KanBan (che aiuta a visualizzare e rendere esplicito il flusso di lavoro per riconoscere prima le opportunità di miglioramento, limitando il work in progress). Questi framework sono importanti perché aiutano i team di sviluppo a definire rapidamente gli obiettivi e le priorità, ad assegnare i compiti e a identificare dove possono verificarsi problemi nello sviluppo di un processo.
DevOps: le possibili criticità
Nonostante tutti i vantaggi promessi dal modello DevOps, come peraltro ha messo in luce la ricerca Fujitsu citata in precedenza, tale paradigma è ancora lontano dalla completa affermazione. E anche le storie di successo commerciale ancora non abbondano. Il problema, come ha messo in luce un report di Micro Focus, è probabilmente costituito dal carattere immateriale dei DevOps. È infatti difficile capire se un’organizzazione è riuscita a realizzare il DevOps. Non esistono infatti riconoscimenti formali o certificati da esibire o che attestino inequivocabilmente di aver seguito le metodologie descritte in precedenza. Anzi spesso capita che un’azienda dichiari di aver adottato la metodologia DevOps, quando in realtà nella sua filiera di produzione sono stati integrati appena un paio di processi. Inoltre, il livello di immediatezza e collaborazione nell’IT promosso da DevOps può essere utile a livello teorico, ma non è affatto semplice da implementare. Soprattutto per ragioni di carattere culturale: DevOps richiede infatti un livello preliminare di agilità (grande o piccolo, in base alle preferenze) che per molti reparti IT aziendali è ancora parecchio lontano. Secondo una ricerca condotta nel 2018 per CA Technologies da Freeform Dynamics, il gap di competenze digitali rimane un ostacolo di primo piano: circa l’82% delle organizzazioni italiane concorda nel ritenere difficile reperire personale con competenze DevOps; il 72% incontra difficoltà nell’individuare professionisti con skill in materia di Agile e il 67% trova a fatica risorse con esperienza di lavoro in team multidisciplinari. Inoltre la persistenza di architetture di tipo legacy in azienda può senza dubbio rappresentare un freno alla piena realizzazione del modello DevOps.
DevOps, serve una maggiore collaborazione tra IT e sviluppo software
Uno dei requisiti fondamentali per la fruttuosa conclusione dei progetti di DevOPs è la proficua collaborazione e comunicazione tra il dipartimento di IT security e quello dedicato allo sviluppo software. Lo conferma una recente ricerca di Trend Micro, condotta su 1.310 decisori IT in tutto il mondo: il 74% degli intervistati (77% in Italia) dichiara che le iniziative DevOps sono diventate più importanti nel corso dell’ultimo anno, ma l’89% (91% in Italia) afferma che i dipartimenti di IT security e software development hanno necessità di lavorare più a stretto contatto. Il 77% (84% in Italia) ritiene che lo stesso debba avvenire tra gli sviluppatori, la security e le operation, mentre il 34% (21% in Italia) attribuisce ai silos la difficoltà nel creare una cultura DevOps all’interno dell’organizzazione. Per raggiungere questi obiettivi occorre lavorare in direzione di un’integrazione maggiore tra i team (61% – 70% in Italia), nonchè nel fissare obiettivi comuni (58% – 56% in Italia) e condividere esperienze formative (50% – 48% in Italia).
DevOps, necessario mettere in sicurezza l’open source
Uno delle caratteristiche chiave del DevOps è data dall’impiego dell’open source: la maggiore velocità nello sviluppo delle applicazioni e la rapidità e l’efficienza si possono ottenere anche attraverso lo sfruttamento del codice open source. Secondo Gartner oltre il 95% delle organizzazioni IT di tutto il mondo utilizza software Open-Source all’interno di carichi di lavoro IT mission critical, in maniera consapevole o inconsapevole. Questo utilizzo continuo di codici open source può però comportare dei rischi per la sicurezza informatica: secondo un’altra ricerca, questa volta condotta da Snyk,le vulnerabilità nelle librerie open source sono raddoppiate negli ultimi due anni e stanno crescendo rapidamente. Sul mercato si stanno perciò affermando soluzioni che sono in grado di aiutare le aziende a identificare le vulnerabilità dell’open sourcee a mitigare e prevenire i rischi, così da mettere al sicuro il processo di sviluppo software DevOps.
La flessibilità aziendale grazie al DevOps
Il paradigma DevOps ha un ruolo in primo piano anche per garantire ai clienti una maggiore rapidità nelle risposte, miglior qualità nelle applicazioni e prodotti e servizi più sicuri. In parole povere, si consentirebbe una maggiore flessibilità di reazione anche nelle aziende di maggiore dimensione, solitamente ingessate da pesanti procedure. Aziende che devono soddisfare richieste frequenti e sostanziose di servizi digitali, stanno risolvendo tale esigenze implementando il modello DevOps, passando da cicli di rilascio del software ogni tre mesi, a ritmi settimanali o addirittura quotidiani o addirittura orarie (ma questo riguarda solo il 15% delle aziende europee). Un processo che viaggia in parallelo e contribuisce alla trasformazione digitale, dove l’IT diventa il vero carburante per il business aziendale. Diventa fondamentale quindi fare evolvere le applicazioni aziendali verso la metodologia DevOps,
