Il lato umano di DevOps

Sei nel posto giusto?

Si, sei nel posto giusto se ti stai chiedendo:

• Cos’è DevOps?
• Qual’è il suo sistema valoriale?
• Quali sono le pratiche utilizzate?
• Perchè è così importante ora?
• Qual’è il punto di vista del Business e quale la prospettiva IT rispetto a DevOps?
• DevOps è (davvero) solo “tecnologia”?
• Come l’automazione rappresenta il fattore abilitante di una nuova cultura?

Un pò di storia…

I primi timidi tentativi di estendere i principi agili all’ambito Operation risalgono ad alcuni articoli pubblicati nei primi anni 2000 ma solo nel 2008, durante la conferenza sull’Agile che si svolgeva a Toronto, accadono due cose importanti:

• nell’agenda dell’evento viene inclusa una traccia sul tema “Infrastruttura Agile“
• viene tenuta una presentazione su “Agile infrastructure and operations: how infra-gile are you?“.

Alla conferenza Velocity nel 2009 John Allspaw e Paul Hammond tornano di nuovo sul tema con una presentazione intitolata “10+ Deploys al Day: Dev and Ops Cooperation at Flickr” che riscuote molto successo e stimola la curiosità di molti sull’argomento.

Nello stesso anno il consulente IT belga Patrick Debois organizza il primo “DevOps Day” a Gent (Belgio), una conferenza che aveva come obiettivo quello di comprendere come colmare il divario tra sviluppo ed operations grazie all’adozione degli approcci agili.

A partire dal primo del 2009, gli eventi “DevOps Days” sono diventati fenomeni virali diffusi in India, USA, Brasile, Australia, Germania e Svezia finendo per dare il nome al movimento stesso. Nasce così ufficialmente il termine DevOps, frutto della contrazione dei termini Development ed Operations.

Nel 2013 Gene Kim, pubblica il libro “The Phoenix Project” (una delle pubblicazioni più importnti sul tema) e fonda la società “IT Revolution“, che promuove la conoscenza e la diffusione di DevOps.

Cos’è DevOps?

Non trovo nulla di meglio, per descrivere DevOps, che ricorrerere alla definizione fornita dagli autori nell’introduzione del loro libro “The DevOps Handbook” (leggilo se puoi: è uno dei must-read della letteratura DevOps):

Imagine a world where product owners, Development, QA, IT Operations and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds. By working towards a common goal, they enable the fast flow of planned work into production, while achieving world-class stability, reliability, availability and security. – Gene Kim, Jez Humble, Patrick Debois, John Willis, John Allspaw

Chiudo gli occhi e immagino una IT nuova, diversa da come l’ho sperimentata tante volte in passato durante la mia carriera di consulente, una IT “rifondata” in cui persone con skill e ruoli diversi (Product Owner, Business Analyst, Architetti, DBA, Sviluppatori, Esperti di Quality Assurance, di Operation e di Sicurezza) lavorano insieme per supportarsi reciprocamente e garantire che la loro organizzazione abbia successo. Condividendo un unico obiettivo rendono possibile un flusso veloce di attività pianificate in ambiente di produzione e, contemporaneamente, garantiscono i più alti livelli di stabilità, affidabilità, disponibilità e sicurezza.

Dunque, questo è DevOps:

• non più contrapposizione ma collaborazione e supporto reciproci tra i diversi ruoli IT
• non più obiettivi diversi ma un unico obiettivo condiviso: il successo dell’organizzazione
• il “fast flow” di valore in produzione sostituisce i rilasci monolitici, con cadenze fisse, elapsed lunghissimi e un elevatissimo rischio intrinseco associato
• non si lavora più sull’urgenza dell’ultimo minuto o sull’ultima escalation ma sulle attività che abbiamo pianificato (planned work)
• non siamo più costretti a scegliere tra velocità e innovazione continua da una parte (fast flow) e stabilità, affidabilità, disponibilità e sicurezza dall’altra: dobbiamo e possiamo pretentere entrambi.

DevOps è un movimento culturale che promuove la collaborazione e la comunicazione, non solo tra Sviluppo (DEV) ed Operation (OPS), ma tra tutti gli attori coinvolti nello sviluppo di valore, con l’obiettivo di accorciare il ciclo di vita end-to-end dei Servizi IT, garantendo riduzione del time-to-market, qualità più alta, soddisfazione del cliente e stretto allineamento con gli obiettivi di business.

The Wall of Confusion

DevOps nasce come risposta alla crescente consapevolezza che esiste uno scollamento profondo tra ciò tradizionalmente chiamiamo DEV e ciò che tradizionalmente conosciamo come OPS.

Questa dicotomia si manifesta spesso come una situazione di conflitto che genera inefficienza:

• Sviluppo (DEV) è, per sua stessa natura, sottoposto alle pressioni del business che spinge per una continua innovazione (nuove piattaforme SW per rispondere alle esigenze di mercato e clienti, nuovi change, etc.)
• Operation (OPS), per contro, ha l’obiettivo e la responsabilità di garantire e mantenere la stabilità dei sistemi (sicurezza, disponibilità, affidabilità etc.)
• Un muro di confusione si erge, tra DEV ed OPS, a causa di questi obiettivi contrastanti
• Presto il conflitto diventa cronico generando una spirale discendente che crea tempi di immissione sul mercato sempre più lunghi, cicli di sviluppo eterni, un numero sempre crescente di incident ed interruzioni del servizio, la crescita esponenziale del debito tecnico e una qualità generalmente ridotta, un cliente insoddisfatto che guarda alla concorrenza

E’ vero, le aziende non sono tutte uguali:

• alcune sono soggette a controlli normativi e policy stringenti che non consentono loro di correre rischi (e gli impediscono quindi di innovare rapidamente come vorrebbero)
• altre invece (le startup ad esempio) manifestano un’alta propensione al rischio perchè per loro la capacità di innovare e di posizionarsi come leader di mercato sono valori cruciali e vitali, più importanti di qualsiasi rischio potenziale

Ma indipendentemente dalla tolleranza al rischio di un’organizzazione, la stabilità è un valore imprescindibile ma lo è anche la capacità di innovare. Un sbilanciamento estremo su uno dei due poli non è più pensabile. Non è più possibile scegliere tra stabilità ed innovazione: il business vuole entrambi!

DevOps rompe il tradizionale “triangolo di ferro” in cui l’alta velocità si paga sempre con una scarsa qualità del nostro software e l’alta qualità si ottiene solo a scapito di velocità ed innovazione. Con DevOps possiamo avere tutto, software stabile e di alta qualità, con costi ridotti e con un time-to-market (o meglio con un time-to-value) sempre più ridotto e compatibile con le richieste del mercato. E, in ultimo ma non da ultimo, con una dose extra di soddisfazione da parte dei nostri clienti.

IT’s Silo culture

Quando i silos IT diventano dei “feudi impenetrabili”, forzando stereotipi e incomprensioni tra DEV, OPS e tutti i team IT coinvolti, l’impatto negativo sull’efficacia e la velocità del flusso di lavoro e sulla nostra capacità di generare valore e innovazione è ineluttabile.

La cultura dei silos è il sintomo tangibile della totale assenza di trust: più diminuisce la fiducia più si è costretti a normare, rendendo lenti e burocratici i nostri processi con un impatto culturale negativo sulla capacità di interagire e collaborare.

Ma non basta. Gli effetti disastrosi si riverberano anche sui nostri sistemi e sulle nostre architetture che diventano sempre più fragili e inutilmente complesse.

Come ci ricorda la legge di Conway siamo destinati a costruire architetture software che ci somigliano: teniamolo ben presente quando scegliamo il nostro modello organizzativo.

Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations…The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon. – Melvin Conway, 1967

Cosa NON E’ DevOps?

DevOps:

• NON E’ un titolo o un ruolo specifico
• NON E’ un team dedicato
• NON E’ un tool
• NON E‘ solo cultura
• NON E‘ solo tecnologia
• NON E‘ anarchia
• NON E’ una ricettina facile e preconfezionata che va bene per tutto

e, sopratutto

• NON E’ il lavoro di una singola persona ma il lavoro di tutti!

Questo a dispetto dei numerosi annunci di ricerca di personale che popolano i nostri social (la ricerca di DevOps Engineers va per la maggiore) e nonostante molte aziende creino dei team DevOps dedicati.

Queste interpretazioni di DevOps ne snaturano lo spirito, che è quello di migliorare la comunicazione e la collaborazione, e finiscono solo per creare nuovi silos!

DevOps tra miti ed anti-pattern

Sfatiamo alcuni falsi miti che circondano DevOps ma che non gli appartengono e ne violano lo spirito e le intenzioni:

1DevOps vuol dire caos: No, DevOps non è il far west e i tecnici non sono dei moderni fuorilegge! Auto organizzazione non fa rima con anarchia ma con responsabilità!

2DevOps significa fare a meno di Operations (NoOps): il termine NoOps è stato coniato da Adrian Cockcroft, Direttore della Cloud Systems Architecture di Netflix, per descrivere l’organizzazione IT della sua azienda, caratterizzata da un settore Operation piuttosto esiguo, anche in virtu del massiccio ricorso ad architetture in cloud (per cui molte delle funzioni svolte dagli specialist di IT Operation erano di fatto state dismesse e passate al service provider).

Sebbene l’articolo di Cockcroft abbia generato a suo tempo un grande dibattito, il concetto NoOps sta per lo più scomparendo.

Nonostante molte organizzazioni abbiano tentato di dismettere completamente Ops, nell’illusione di sostituire le persone con l”automazione, ci si sta sempre più rendendo conto che i ruoli di Operation sono ancora necessari.

Semmai il punto focale è capire come Ops debba essere reinterpretato ed evoluto rispetto ai nuovi scenari, a come sia necessario ampliare le sue responsabilità ben oltre il tradizionale confine della sola distribuzione del software.

Leggi qui per approfondire.

3DevOps non può essere applicato ai sistemi legacy: DevOps può essere applicato a qualsiasi scenario e forse proprio in contesti legacy evidenzia al massimo il suo valore.

4Se alcuni servizi sono in outsourcing non possiamo adottare DevOps: i servizi in outsourcing non sono una controindicazione per DevOps a patto, ovviamente, che nostri i partner ne condividano lo spirito e gli approcci

5Dobbiamo automatizzare tutto! Certo l’automazione ha un ruolo centrale in DevOps e andrebbe introdotta laddove possibile. Tuttavia va automatizzato solo ciò che ha senso. E’ l’automazione ad essere al nostro servizio non noi al servizio dell’automazione

6DevOps è adatto solo alle startup: in organizzazioni grandi e complesse la transizione a DevOps è sicuramente più lunga e impegnativa ma sono proprio queste organizzazioni a tranne il giovamento maggiore

7DevOps sostituisce l’Agile: DevOps integra, amplia e estende l’agilità anche ad Operation. Non esiste una contrapposizione tra approcci agili e DevOps che, al contrario, condividono molte pratiche e, sicuramente, lo stesso mindset

8DevOps è incompatibile con ITIL: DevOps si erge sulle spalle dei giganti che l’hanno preceduto e ITIL è uno di questi. DevOps non reinventa i processi ITSM/ITIL ma si poggia su di loro cercando di infondere l’agile thinking anche alla gestione dei servizi IT

9DevOps è incompatibile con l’Information Security & Compliance: esattamente il contrario. DevOps ha l’obiettivo di costruire un mindset in cui «tutti sono responsabili della sicurezza».
La disciplina DevSecOps incorpora la “Sicurezza come Codice” (Security as Code) e il paradigna dello “shifting left” ci permette di anticipare il prima possibile (spostando a sinistra ciò che normalmente avviene a destra della fase di sviluppo) test di sicurezza “continui” nella nostra pipeline di distribuzione. La sicurezza è parte dello sviluppo non il mestiere di qualcun’altro (“Built-In Securety”)!

10DevOps è solo ‘Infrastructure as code’ o ‘Automation’: falso. DevOps è prima di tutto un movimento culturale che “usa” la tecnologia come fattore abilitante.

Perchè DevOps proprio ora?

VUCA è la nostra nuova normalità. La Velocità, l’Incertezza, la Complessità e l’Ambiguità del mondo che viviamo stanno rendendo via via più urgente l’adozione di approcci e strumenti che ci garantiscano velocità e flessibilità:

• Internet ha abbattuto le barriere all’ingresso nel mercato: le grandi aziende hanno ora come concorrenti startup giovani e agili
• in un clima così fortemente competitivo, “soddisfare il cliente” non è abbastanza: bisogna coinvolgerlo, sedurlo, deliziarlo, fiderizzarlo
• Il cliente vuole valore, non prodotti o servizi. Il time-to-market è un concetto obsoleto: ridurre il time-to-value è la nostra nuova sfida
• Lo sviluppo agile sostituisce i tradizionali approcci waterfall, rigidi, pesanti e burocratici, rendendo veloce, flessibile e adattivo il processo di sviluppo: Operation deve adeguarsi a questo nuovo modello di sviluppo
• L’adozione di soluzioni cloud abilita una gestione flessibile, elastica delle nostre infrastrutture, impensabile fino a qualche anno fa, riducendo al contempo costi e rischi collegati
• L’IT non può più operare in una cultura a silos se vuole essere e mantenersi agile
• I consumatori hanno sviluppato una mentalità da “App”: siamo ormai abituati alla tecnologia subito disponibile, spesso in modalità “self-service”, di qualità ed a costi accessibili. I tempi biblici con cui si rendeva disponibile un prodotto/servizio in passato sono incompatibili con la sensibilità e le esigenze attuali
• Le aziende devono essere guidate da fatti, non da opinioni (Data Driven Organizaton). L’enorme mole di dati ora disponibile (Big Data, Intelligenza Artificiale, Machine Learning, IoT) deve essere sfruttata in modo intelligente per indicarci una direzione (Advanced Analytics, Business Intelligence)
• Nel mercato attuale ogni azienda è una tech company (anche se non lo sa o non ne è consapevole!). I modelli di business moderni sfruttano il canale Internet e la tecnologia: non sarebbero proponibili diversamente. Se non ci credi, prova ad immaginare una azienda di successo (Amazon, ING Bank, Netflix, Yoox, etc.) attuale privata del suo IT! L’IT non ha più bisogno di allinearsi o integrarsi con il business, l’IT è il business.

DevOps applica il System Thinking all’intero sprettro dei processi IT

Molte organizzazioni IT hanno messo in campo diverse iniziative per migliorare la velocità, l’affidabilità e la qualità dei propri sistemi:

• l’introduzione di modelli di sviluppo agile
• il ricorso ad infrastrutture in cloud
• l’utilizzo spinto delle tecnologie per l’automazione dei processi IT
• l’adozione di framework IT standard come ITSM/ITIL per governare i processi IT
• le buone pratiche di cybersecurity
• lo sfruttamento della grande mole di dati oggi disponibile (IoT, Analytics, Big Data, etc.).

Tuttavia queste iniziative, seppur efficaci singolarmente, non sono di solito il frutto di una strategia condivisa tra i vari settori IT (Sviluppo, Quality Assurance, Operation, etc.): si tratta quasi sempre di iniziative isolate, verticali, tutte interne ad una singola linea o dipartimento IT e che quindi non hanno contribuito al miglioramento delle performance generali del flusso end-to-end.

Gli approcci di analisi tradizionali cercano di comprendere un sistema trattandolo, con un approccio meccanicistico,  come semplice “somma delle parti“. Ma un sistema complesso è simile ad un organismo vivente: non è possibile prevedere in modo deterministico il suo comportamento senza tener conto che questo dipende da innummerevoli variabili a loro volta influenzate dal modo in cui le singole parti interagiscono le une con le altre.

Un sistema complesso può essere compreso solo a posteriori, osservandolo a mano a mano che il suo comportamento “emerge”: l’unico approccio possibile è ottenerne e misurarne i feedback in modo “empirico“.

Il System Thinking è un approccio olistico all’analisi che si concentra sul modo in cui le parti costitutive di un sistema complesso si collegano e sul modo in cui i sistemi funzionano nel tempo e nel contesto di sistemi più grandi.

DevOps Goals

In sintesi questi sono gli obiettivi ambiziosi di DevOps:

• Rilasci più piccoli e più frequenti con coerenza e velocità garantite dall’automazione
• Riduzione dell’effort e dei rischi associati al rilascio
• Riduzione dei costi di sviluppo e dei ritardi causati dai frequenti rework
• Aumento della qualità del nostro software
• L’abbattimento dei “Silos” organizzativi e la promozione di una cultura della comunicazione e della collaborazione.

DevOps Values

DevOps è, prima di tutto, un movimento culturale basato su interazioni umane e tecniche finalizzate a  migliorare relazioni e risultati.

Dopo i primi DevOps Days con sede negli Stati Uniti, a Mountainview, nel 2010 John Willis e Damon Edwards coniano l’acronimo CAMS, acronimo di Culture, Automation, Misurement e Sharing, con cui volevano sintetizzare i 4 valori portanti di DevOps.

Solo più tardi, Jez Humble ha aggiunto la L, di Lean, per formare CALMS a testimonianza di quanto il sistema valoriale di DevOps sia figlio della cultura e del mindset Lean:

CCULTURE: si riferisce agli aspetti umani e di processo connessi a DevOps ed alla necessità inderogabile di migliorare la comunicazione e la collaborazione. Senza il giusto mindset qualsiasi tentativo di automazione si ridurrà ad un puro esercizio tecnologico

AAUTOMATION: strumenti come le piattaforme di release management, test automation, configuration management e monitoring & control rendono possibile l’automazione di processi ripetitivi e proni all’errore. Sono importantissimi perchè rappresentano la tecnologia abilitante della cultura DevOps

LLEAN: massimizzare il valore per il cliente, minimizzando gli sprechi e migliorando il flusso è il primo mantra di Lean, il suo pilastro portante e la sua eredità per DevOps

MMEASURING: ciò che non può esser misurato non può essere migliorato! Una implementazione efficace di DevOps implica necessariamente la misurazione di ogni aspetto per poterlo migliorare

SSHARING: la condivisione è il feedback loop di ritorno del ciclo CAMLS, alla base di una cultura dove le persone condividono idee e problemi, fattore critico che abilita la comunicazione e la collaboorazione aiutando le organizzazioni a crescere e migliorarsi

L’Automazione è essenziale (anche se non è tutto)

DevOps is not about automation, just as astronomy is not about telescopes. – Christopher Little

Dunque DevOps non è solo tecnologia o automazione ma nemmeno solo cultura: l’Organizational Agility si ottiene solo quando cultura organizzativa, processi ed automation sono allineati.

L’automazione e la tecnologia:

• Sono gli accelleratori che abilitano DevOps
• Ci aiutano ad essere “more continuous”.

Pratiche DevOps

Diverse sono le pratiche DevOps cruciali per rendere più “continuous” il nostro flusso di lavoro e più stabili, sicuri e resilienti i nostri sistemi:

• Continuous Testing, Integration, Delivery & Deployment

Continuos Testing	Continuous Integration (CI)	Continuous Delivery (CD)	Continuous Deploy
Processo di esecuzione di test automatizzati come parte integrante della pipeline di distribuzione, allo scopo di ottenere un feedback immediato sui potenziali rischi associati al rilascio in produzione di un componente software	Pratica di sviluppo che richiede agli sviluppatori di integrare il software eseguendo il commit del codice (in modalità master/trunk) in un repository condiviso almeno quotidianamente (e idealmente ad ogni change). Ogni check-in è convalidato da: una build automatizzata Unit, Integration e Acceptance test automatizzati	Pratica che garantisce che il software si trovi sempre in uno stato potenzialmente rilasciabile durante tutto il suo ciclo di vita	Facciamo un ulteriore passo in avanti rispetto al Continuous Delivery estendendo l‘automatismo fino al rilascio in produzione vero e proprio (passiamo da un trigger manuale ad un trigger automatico)

• Site Reliability & Resilience Engineering (SRE)

La disciplina che incorpora concetti e pratiche propri dell’ingegneria del software (DEV) nel contesto infrastrutturale (OPS) con l’obiettivo di creare sistemi software altamente scalabili e affidabili.

• DevSecOps

disciplica che ha lo scopo di costruire un mindset in cui «tutti sono responsabili della sicurezza» e in cui la sicurezza diventa parte integrante del processo di sviluppo attraverso l’implementazione di test di sicurezza anticipati e “continui” in tutta la pipeline di distribuzione.

• Kanban

Pratica della Lean Production che ci consente di gestire il nostro flusso di lavoro con un ritmo sostenibile, implementando un approccio “Pull” che adatta la quantità di lavoro gestita alla nostra reale capacità produttiva limitando il Work-in-Progress (WIP).

• Infrastructure as Code (IaC)

la pratica di instanziare, configurare e gestire i component infrastruturali tramite codice (script) e non attraverso configurazioni manuali. Ci consente di agire sulle infrastrutture in modo più veloce e flessibile e di incorporare la configurazione dell’infrastruttura nei processi automatizzati di DevOps.

La IaC ci consente di avere accesso a capacità e risorse infrastrutturali in modalità automatica e quando ne abbiamo bisogno (self-service e on-demand) senza richiedere l’interazione umana con il fornitore di servizi.

Naturalmente questa pratica è strettamente dipendente dall’adozione di architetture in Cloud e dalle tecnologie di virtualizzazione degli ambienti.

Le tecnologie che abilitano DevOps

Molte delle pratiche DevOps sono attuabili solo grazie a nuovi paradigmi tecnologici oggi disponibili:

CLOUD	VIRTUALIZATION	MICROSERVICES	CONTAINERS
L’utilizzo di server remoti ospitati su Internet per le nostre applicazioni anziché di architetture tradizionali con server locali in un data center privato.	La possibilità di astrarre le componenti hardware degli elaboratori al fine di renderle disponibili al software in forma di risorsa virtuale. Ci consente, non solo di ottimizzare i costi delle risorse hardware, ma anche di introdurre il livello di astrazione necessario a disaccoppiare il codice eseguibile delle nostre applicazioni dal software di base sottostante.	Un’architettura software composta da piccoli componenti, autoconsistenti ed indipendenti, che interagiscono via API che possono essere aggiornati senza impattare sull’intero sistema (comportamento noto come “loose coupling”).	Un modo per impacchettare il software in una immagine, autonoma ed eseguibile (una sorta di virtualizzazione leggera) che include tutto ciò che è necessario per la sua esecuzione (codice, runtime, librerie di sistema, configurazione, etc.). I Container disaccoppiano le applicazione dall’infrastruttura host sottostante e rendono semplice il deploy nei differenti cloud o sistemi operativi per una maggiore scalabilità.

Il volto agile di DEV

E’ possibile introdurre DevOps in un contesto dove lo sviluppo (DEV) è basato su un modello Waterfall tradizionale?

Tecnicamente parlando la risposta è si ma in questo modo DevOps viene ridotto ad un puro esercizio tecnologico: nessun impatto positivo sulla cadenza e velocità del ciclo di vita del software, nessun beneficio derivante dalla riduzione del lead time per il cliente (il tempo totale he un cliente attende da quando la sua idea viene tradotta in valore utilizzabile), nessuno dei veri obiettivi di DevOps viene colto.

L’adozione di approcci agili (Scrum, Kanban, etc.) lato DEV è il presupposto imprescindibile per introdurre DevOps con successo nei nostri processi IT.

Le nostre fonti

• Agile infrastructure and operations: how infra-gile are you?
• 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
• ‘NoOps’ Debate Grows Heated
• The Phoenix Project
• The DevOps Handbook

Lasciaci un commento

• Cosa ne pensi di DevOps?
• Lo stai già adottando nella tua organizzazione o ne hai solo sentito parlare?
• Quanto è lontana la tua idea di DevOps rispetto a quello che hai letto?
• In una iniziativa di trasformazione DevOps quanto pesano secondo te gli aspetti culturali rispetto a quelli legati alla tecnologia?

Perchè non ci scrivi cosa ne pensi lasciandoci un tuo commento?

Se ti piacerebbe approfondire puoi dare un’occhiata ad uno dei nostri corsi DevOps online o in aula/virtual room.

A presto!

Stay agile! 🏄‍♀️