Alla scoperta di una pratica ritenuta fondamentale nello sviluppo dei moderni applicativi
DevOps – la crasi che unisce Agile, Development & Operations in un unico termine.
DevOps, come dice la parola stessa, è una metodologia che unisce in modo sinergico processi relativi allo sviluppo software (software development, e da qui, DEV) e operations, da cui OPS.
Ci si riferisce comunemente a DevOps come a una metodologia per l’ingegneria del software, volta a integrare il lavoro dei team di sviluppo e di gestione del software, facilitando una cultura di collaborazione e di responsabilità condivisa.
Ma per meglio comprendere le caratteristiche fondanti della metodologia DevOps, e quindi i suoi vantaggi, dobbiamo prima comprendere come funzionava il mondo dello sviluppo software prima dell’avvento del DevOps.
In origine, era il team di sviluppo
Nella modalità di lavoro standard, il team di sviluppo e il team di operations lavorano nei rispettivi silos. Come una catena di montaggio: il lavoro fluisce tra i diversi team, i quali lavorano in modo asincrono e con interazioni ridotte.
Il team di sviluppo si occupa di scrittura di software, creazione di applicativi e nella realizzazione di funzionalità per rispondere ai requisiti degli utenti. Semplificando ulteriormente, il team di sviluppo è deputato alla creazione di componenti software.
Il team di operations invece è specializzato in processi, sistemi e, vedremo tra poco, attrezzature tecniche. Ha il compito di ottimizzare i processi operativi di un’azienda e in particolare renderli sicuri, efficienti, scalabili. Lo scopo ultimo è aumentare l’output funzionale diminuendo l’input in termini di energia, ore di lavoro, infrastrutture, eccetera. Semplificando ulteriormente, il team di operations è deputato alla gestione di componenti software e hardware.
Ricordiamo che, specialmente in un certo filone divulgativo classico, troviamo il team operations tradotto in italiano come “sistemisti”.
L’evoluzione delle architetture cloud porta a nuove necessità
Storicamente i ruoli operations erano incentrati sull’hardware. La responsabilità principale riguardava attività come la manutenzione dei server e la gestione di incidenti, indisponibilità delle risorse e scalabilità.
Ma, poiché i server virtuali hanno sostituito in larga misura i server fisici, i professionisti IT ora eseguono la manutenzione su di essi virtualmente, attraverso configurazioni effettuate con applicazioni web come AWS Management Console, Microsoft Azure Portal e Google Cloud Console, piuttosto che Kubernetes o Docker, solo per citare i principali.
Di conseguenza, i ruoli operativi sono diventati più incentrati sul software grazie al cloud e ai server virtuali. I tecnici operativi non configurano più reti e server fisicamente, bensì virtualmente.
Insieme a questo importante cambiamento, il software per costruire, distribuire e testare le applicazioni è diventato uno standard dell’industria del software. Testing automatici, SOA (Architettura Orientata ai Servizi), ambienti virtuali, container e gestione di container, e la sofisticazione degli attacchi informatici (cybercrime) hanno portato alla nascita di ruoli specializzati per supportare queste tecnologie.
Enter DevOps
Dopo questa breve panoramica, capiamo quindi che i team dedicati allo sviluppo dei team dedicati alla messa in produzione degli applicativi agivano separatamente, con la conseguente generazione di inefficienze a livello di comunicazione, feedback, operatività, e tempi di reazione di fronte a casi critici inevitabilmente più lunghi.
Inoltre, la conseguente virtualizzazione degli ambienti di rilascio ha reso la linea di confine tra dev e ops meno marcata, con competenze che possono essere sfruttate in modo sinergico e flussi di lavoro che possono essere gestiti in modo sincrono.
Abbiamo quindi trovato gli ingredienti principali che ci porteranno alla definizione del DevOps nella sua interezza.
L’influenza del manifesto Agile
Il manifesto agile per lo sviluppo del software vede la luce nel 2001, mentre la metodologia DevOps inizia a diffondersi intorno alla fine del 2007.
Si pone spesso a confronto Agile con DevOps, talvolta erroneamente ritenendole in antitesi, talvolta altrettanto erroneamente ritenendole metodologie sovrapposte.
La realtà è che DevOps ha certamente attinto al mindset Agile, ma estendendolo all’intero processo tecnologico, e non solo sulla parte di sviluppo software, come invece propriamente sancisce il manifesto Agile
Sebbene quindi DevOps e Agile abbiano punti di contatto e punti di differenza, l’uso combinato consente certamente di ottenere maggiore efficienza produttiva, processi più sicuri, risultati maggiormente affidabili, con un numero di risorse tendenzialmente inferiore rispetto ai processi di sviluppo e rilascio classici.
DevOps – un po’ di storia
Il concetto di DevOps inizia a emergere nell’ambiente specialistico attorno al 2007. La sua diffusione, dopo le incertezze iniziali, è rapida. Nel 2009 arrivano già i primi DevOpsDay. Possiamo dire che nel 2010 DevOps fosse già una metodologia consolidata e in via di adozione nelle migliori tech company a livello globale.
Potremmo pensare che la diffusione di questa metodologia sia stata essenzialmente merito di grandi compagnie venditrici di tecnologia come Google, oppure Microsoft, IBM o altre.
E invece la scintilla che ha dato definitivamente fuoco alle polveri è stata durante l’evento Velocity 2009, grazie a un keynote di John Allspaw e Paul Hammond, due ingegneri del servizio di photosharing Flickr.
Questo speech è tutt’oggi considerato un culto e le slide originali possono ancora essere viste su Slideshare.
Nel 2013 la pubblicazione di un libro culto, The Phoenix Project, contribuisce alla diffusione di massa della metodologia DevOps.
Nel 2020 si contavano circa 40 eventi annuali dedicati al DevOps nei soli Stati Uniti d’America.
Oggi DevOps è a tutti gli effetti uno standard metodologico sul quale si trovano innumerevoli risorse e casi di adozione di successo.
I principi fondanti del DevOps
Dal punto di vista teorico la metodologia DevOps è costruita attorno a quattro pilastri chiave:
Automazione: il ciclo di vita del software (Software Development Lifecycle) deve essere quanto più automatizzato, a partire dalla creazione del software stesso, fino alla gestione di modifiche, rilasci, upgrade, versionamento.
Collaborazione: la collaborazione e comunicazione all’interno dell’intero ciclo di vita del software deve essere costante, bidirezionale, priva di ostacoli formali, e efficace.
Miglioramento continuo: la metodologia DevOps deve garantire un continuo efficientamento delle risorse aziendali, in sostanza permettendo di fare di più con meno. L’inutilizzo di risorse allocate è considerato a tutti gli effetti uno spreco.
Hyperfocus sui bisogni degli utenti: in continuità con Agile, DevOps vuole garantire la piena soddisfazione dei bisogni degli utenti attraverso un ciclo di feedback breve, rapido, iterativo e continuo.
I vantaggi della metodologia DevOps
Possiamo riassumere i vantaggi dell’adottare la metodologia DevOps nei seguenti punti.
Reattività rispetto al mercato: grazie all’architettura a microservizi e ai rilasci continui, puoi reagire rapidamente a mutate condizioni di mercato, soddisfacendo i requisiti dei tuoi clienti con maggior rapidità.
Rilasci efficienti: la fase di messa in produzione diventa un processo deterministico (al 99%, secondo un’intervista fatta da Atlassian a un pool di oltre 500 esperti del settore). La gestione e risoluzione di bug e problematiche non causa disservizi nello stato dei tuoi applicativi.
Affidabilità: i tuoi applicativi hanno tempi di uptime decisamente migliori rispetto a uno scenario tradizionale, grazie a processi come CI/CD (integrazione e sviluppo continuo) e testing automatico, eseguito durante l’intero ciclo di vita del software.
Scalabilità: l’infrastruttura aziendale è gestita in modo efficiente, espandendosi e contraendosi a seconda delle reali necessità di business, in real-time.
Collaborazione: la collaborazione tra i team è, come abbiamo capito, cruciale per la metodologia DevOps. I principi di ownership e accountability, ossia responsabilità dei singoli e team nelle diverse fasi del processo assicura una gestione risolutiva degli incidenti senza incertezze.
Sicurezza: DevOps si focalizza sulla sicurezza dell’intero ciclo di vita del software, integrando, anche propriamente, logiche di cybersecurity (DevSecOps), migliorando quindi stabilità e sicurezza di applicativi e sistemi a fronte di minacce sempre più frequenti e sofisticate.
DevOps – quando usarlo
L’utilizzo della metodologia DevOps non ha controindicazioni, ma indubbiamente ci sono casi d’uso nei quali ne potrai beneficiare più di altri.
Azienda a silos: la tua azienda è strutturata in silos tra loro non comunicanti e avverti inefficienza e scarso trasferimento di conoscenza. L’adozione di metodologie DevOps sicuramente aiuta a rompere questo continuum e a rendere i team più collaborativi e efficaci.
Responsabilità accentrata: non vuoi più che le responsabilità dei processi siano allocate in una o poche persone chiave, ma vuoi creare un ambiente dove le responsabilità, e quindi la garanzia di successo dei processi, siano condivise tra tutto il team.
Adozione del mindset Agile: se la tua azienda sta adottando framework basati sul mindset Agile, DevOps ne è la naturale evoluzione.
Complessità della fase di sviluppo: se i tuoi prodotti sono basati su applicativi software, avrai necessità di iterare rapidamente in base alle mutate esigenze di mercato e in base a singoli casi d’uso in rapida evoluzione. DevOps ti permette di avere la necessaria rapidità per fronteggiare uno scenario in rapido cambiamento.
Complessità della fase di rilascio: se la parte di operations è diventata complessa e non riguarda più meramente tenere un sito statico in produzione, ma gestire frequenti rilasci e applicativi complessi, hai bisogno di DevOps per fronteggiare questo nuovo carico operativo.
Processi onerosi e ripetitivi: se l’overhead dei singoli processi inerenti il ciclo di vita del software è diventato importante, DevOps ti permette di adottare automatismi che ne aumentano l’efficienza e l’efficacia in modo considerevole.
Costi di gestione elevati: all’aumentare della complessità inevitabilmente vedrai un aumento di inefficienze, di spreco di risorse, e un aumento dei costi. DevOps riduce l’overlap funzionale, operativo e architetturale, aiutandoti a abbattere i costi di conseguenza.
Le figure chiave
Quali sono quindi i ruoli fondamentali per la costruzione di un DevOps team?
Vediamoli.
DevOps Evangelist: è responsabile della gestione e della realizzazione del cambiamento verso la cultura DevOps. L’Evangelista DevOps è responsabile di garantire il successo e l’implementazione di tutti i processi DevOps all’interno del team.
DevOps Engineer: è responsabile della progettazione della giusta infrastruttura necessaria ai team per costruire e consegnare continuamente i prodotti. Identifica i requisiti e i KPIs del progetto e personalizza lo stack di strumenti.
Release Manager: è responsabile dell’intero ciclo di vita del rilascio, dalla pianificazione, alla programmazione, all’automazione e alla gestione degli ambienti di consegna continua.
Cloud Architect: ha il compito di analizzare i processi di sviluppo software esistenti e creare una pipeline DevOps CI/CD ottimizzata per costruire e distribuire rapidamente il software. L’architetto analizza i processi esistenti e implementa le best practice per snellire e automatizzare i processi utilizzando gli strumenti e le tecnologie giuste.
Security Engineer: è il responsabile globale della sicurezza dell’intero ambiente DevOps e dell’integrità del dato all’interno dei singoli processi.
QA Engineer: è il responsabile per la parte di mantenimento qualitativo del software in tutte le sue fasi, quindi deputato all’organizzazione di test e automazione degli stessi.
Software developer: le responsabilità degli sviluppatori DevOps includono compiti quali l’aggiornamento del codice, l’aggiunta di nuove funzionalità e la risoluzione di bug, garantendo al contempo che l’applicazione soddisfi gli obiettivi aziendali.
DevOps – terminologia essenziale
Automazione del rilascio di applicazioni (ARA): si tratta di un processo ripetibile, verificabile e coerente di pacchettizzazione e distribuzione di un’applicazione in diversi ambienti con diverse configurazioni, e infine in produzione con un intervento umano minimo, grazie alle pipeline di Continuous Integration e Continuous Delivery.
BDD: behavior-driven development, ossia lo sviluppo guidato dal comportamento, è una metodologia di sviluppo agile del software e una terminologia DevOps in cui qualsiasi applicazione viene documentata e progettata in base al comportamento che un utente si aspetta di sperimentare quando interagisce con l’applicazione.
CALMS: un acronimo che determina l’essenza di DevOps: Cultura, Automazione, Lean, Misurazione, Condivisione (Sharing). Il modello CALMS viene utilizzato come quadro di riferimento per valutare la preparazione di un’organizzazione ad adottare una cultura DevOps.
Container: i container sono alla base della collaborazione DevOps che risolve i conflitti applicativi tra ambienti diversi.
Continuous Integration CI: è un processo di verifica dell’integrità del codice impegnato dagli sviluppatori nel repository di codice sorgente condiviso. Il codice viene integrato nel repository condiviso più volte al giorno e verificato tramite build e test automatici.
Continuous Delivery CD: un approccio di ingegneria del software con una serie di pratiche progettate per garantire che il codice possa essere distribuito in modo sicuro e rapido alla produzione in modo sostenibile, comprese le modifiche alla configurazione, le nuove funzionalità, le correzioni di bug e gli esperimenti. La CD automatizza il processo di rilascio in modo che l’applicazione possa essere distribuita in qualsiasi momento con un semplice clic di un pulsante.
Continuous Deployment: una pratica di sviluppo software per il rilascio di software in cui ogni nuovo commit di codice che supera la fase di test automatico viene rilasciato in produzione per garantire che le nuove modifiche siano visibili agli utenti finali del software.
Debito tecnico: non è altro che il costo che si deve pagare per aver scelto una scorciatoia. Per risolvere rapidamente qualcosa o per scegliere una soluzione a breve termine nonostante sia disponibile una soluzione migliore. Questo a volte porta a un ulteriore lavoro di rielaborazione; il costo implicito in questo è generalmente definito “debito tecnico”.
Event-Driven Architecture (EDA): un modello di architettura software che orchestra il comportamento di un sistema intorno al rilevamento, alla produzione e al consumo di eventi o messaggi prodotti dal sistema.
Test Automation: il processo di utilizzo di software di automazione (software specializzato) per testare l’ultima versione del software rispetto ai test unitari. Una volta che il team di sviluppo ha effettuato il commit del codice nel controllo sorgente, per garantire la qualità e l’integrità del codice, i vari casi di test unitari vengono automatizzati utilizzando vari strumenti di automazione disponibili sul mercato. I casi di test vengono quindi eseguiti sull’ultimo codice disponibile nel controllo sorgente e i risultati effettivi dei test vengono confrontati con quelli previsti.
Unit Test: la più piccola parte del codice o del modulo software, che può essere testata in modo indipendente per verificare se funziona come previsto, viene definita “Unit Testing”.
