Come fare DevOps: primo step, la chiarezza

Da qualche tempo si ritiene che l’approccio tradizionale “a cascata” per lo sviluppo e l’implementazione di applicazioni in azienda non sia adatto a conseguire l’elasticità operativa che oggi tutte le imprese cercano.

Questo modello prevede una distinzione netta tra i team di sviluppo e quelli delle operations, ossia coloro che gestiscono l’IT aziendale. Ad esempio, nella creazione di una nuova applicazione gli sviluppatori ne recepiscono le specifiche, scrivono codice, testano le varie versioni del software e poi rilasciano quella definitiva. A questo punto le operations la implementano e, se tutto va bene, badano in seguito alla sua manutenzione.

Un approccio rigido, si ritiene oggi, e DevOps si presenta come la risposta alla scelta di evitare questa rigidità.

Dalla rigidità alla flessibilità

La rigidità del modello a cascata è legata in primo luogo alla separazione delle varie classi di attività e delle persone che le portano avanti. È una distinzione storica e che ha le sue ragioni perché i compiti di analisi, sviluppo, implementazione e manutenzione sono diversi e richiedono skill differenti.

Ma specie nelle grandi imprese è diventata spesso una separazione quasi burocratica che rallenta tutto il ciclo di sviluppo. Ad esempio, il rilascio nell’ambiente di produzione di un nuovo software solo alla fine del ciclo di sviluppo evidenzia tardi eventuali problemi che negli ambienti di test non si potevano verificare. Così bisogna ritornare a macinare codice intervenendo su un prodotto finito e non su uno ancora in evoluzione.

Cicli di sviluppo più brevi

L’approccio DevOps fa in modo che la parte di sviluppo (development) e le operations interagiscano molto più strettamente – da qui l’acronimo DevOps – per lavorare tutti meglio. In realtà l’approccio concettualmente non è nuovo: è una estensione del modello di sviluppo “agile” e si può considerare più in generale come ispirato dai modelli “lean” nati per i processi produttivi del manufacturing. L’idea infatti è generale: un flusso produttivo (in questo caso dallo sviluppo alla gestione del software) si può rendere più efficiente con una maggiore integrazione dei vari elementi della sua catena.

L’approccio DevOps abbandona lo sviluppo monolitico e sequenziale e adotta cicli molto più brevi e frequenti di sviluppo e implementazione, anche delle versioni preliminari del software o del servizio su cui si sta lavorando. In sintesi e semplificando, il team di sviluppo crea una successione frequente di versioni sempre più complete del software o del servizio, mettendole di volta in volta in un ambiente di (quasi) produzione e recependo immediatamente le segnalazioni e i feedback del team di operations.

I vantaggi di DevOps

I vantaggi del modello DevOps sono diversi. Innanzitutto avere feedback pratici sin dalle prime fasi di sviluppo permette di capire subito in che direzione muoversi. Dato poi che l’iterazione tra le varie versioni è veloce, la quantità di codice su cui intervenire per correggere errori e ottimizzare il risultato è minore. Per questo motivo le versioni dei software sono anche generalmente più stabili e con meno bug, dato che i nuovi elementi introdotti di volta in volta sono contenuti.

Nel complesso tutto questo porta a una riduzione dei tempi di rilascio definitivo, a una riduzione anche dei costi di sviluppo (che si stima intorno al 20 percento) e a risultati più soddisfacenti in termini di qualità del prodotto.

È tutto così ovviamente positivo che viene da chiedersi perché non ci si è pensato prima. Ma DevOps è figlio dei suoi tempi e non potrebbe essere altrimenti. Concettualmente non sarebbe possibile se non si fossero assimilati prima i modelli di sviluppo agile e di Continuous Delivery, tecnicamente sarebbe molto più complesso da realizzare senza la presenza di piattaforme relativamente recenti.

Ad esempio quelle di virtualizzazione e containerizzazione, come Docker, che facilitano e velocizzano le fasi di implementazione e test in ambienti controllati ma realistici. E le piattaforme di orchestration come Jenkins, che permettono di automatizzare e integrare potenzialmente tutti i passi del processo di sviluppo-test-rilascio.

Semplicità apparente

L’idea è evidentemente buona, gli strumenti ci sono, eppure l’adozione del modello DevOps resta un problema per molte imprese, indipendentemente dalla loro dimensione. Non è strano e si capisce perché, se ci si astrae dalle sigle e dagli acronimi e si guarda al ciclo di vita del software per quello che è: un processo articolato e complesso che comprende aspetti sì tecnologici ma anche organizzativi e strategici.

Il primo ostacolo per molte imprese è che DevOps innanzitutto è un cambiamento culturale che deve interessare sviluppatori e operations. I primi devono imparare qualcosa di IT management e i secondi qualcosa dello sviluppo, tutti devono imparare a collaborare insieme e a “vivere” un modello fatto di esperimenti e test frequenti e anche insuccessi (seppure parziali) frequenti.

Nelle organizzazioni “a silo” in cui sviluppo e operations sono storicamente separati, è tutt’altro che banale. E per questo ci deve essere un impegno chiaro non solo della parte IT e delle operations ma proprio del top management.

Secondo punto chiave: DevOps non è una ricetta univoca. Non si “fa DevOps” semplicemente perché si usano le piattaforme che vanno per la maggiore nelle presentazioni tecniche. Bisogna partire considerando i propri processi di sviluppo e gestione e capendo in che modo possono essere ottimizzati grazie al modello DevOps. Può darsi che gli strumenti più di tendenza siano quelli adatti, può anche darsi che altri siano più efficaci. Di solito, avvisano gli esperti di settore, conviene farsi aiutare in questa fase di auto-valutazione, come si farebbe per l’ottimizzazione di qualsiasi processo.

Se non si tengono presenti questi punti il rischio è andare alla ricerca della “soluzione DevOps” che si ritiene adatta alle proprie caratteristiche e adottarla come se fosse un nuovo ambiente di sviluppo chiavi in mano. In questo modo l’approccio porta più problemi che soluzioni. E di sicuro nessuno dei suoi vantaggi.