Con il precedente post, abbiamo iniziato il nostro nuovo viaggio nel mondo DevOps, sfatando sin da subito alcuni falsi miti. Cerchiamo ora di capire, in modo semplice e diretto, cos’è DevOps e perché se ne parla tanto. 
DevOps
Personalmente, amo molto l’affermazione di Jim Stoneham di Opsmatic: We transformed from a team of employees to a team of owners.
Ecco, proprio questo è il punto: non si tratta di ragionare in termini di sviluppo o di operation, ma in termini di Valore prodotto per il cliente, andando a ridurre il Lead-Time, e creando un circolo virtuoso in cui il cliente si fida ed è soddosfatto della capacità dell’azienda di rispondere alle proprie esigenze. In tale ottica, tutti diventano responsabili in prima persona del successo dell’intero Value Stream.
Ma perché è così importante, anzi fondamentale, arrivare ad un’integrazione automatizzata delle attività di sviluppo e di quelle sistemistiche a supporto del prodotto? Ebbene, facciamo un esempio tipo che ricalca un comune modello organizzativo di un’azienda IT, o una divisione IT:
Il Team di Sviluppo realizza la nuova soluzione o una nuova feature, casomai lo fa con un approccio Agile/Lean volto alla qualità e all’ottenimento di un prodotto che rispecchia quanto desiderato dal cliente. Quando il Product Owner decide che è arrivato il momento di consegnare la soluzione nelle mani del cliente, è necessario pianificare la messa in esercizio con il Team di Operations che deve configurare i vari ambienti necessari, se non lo ha già fatto in precedenza. Pronti gli ambienti, il Team di Operations schedula il rilascio in produzione, effettua il deploy…. ma qualcosa non funziona cosa dovrebbe!
Cos’è accaduto? Gli ambienti di sviluppo e produzione non sono allineati tra loro? La soluzione presenta qualche bug? Chi deve intervenire? Chi coordinata queste attività di verifica risoluzione incrociata?
Ecco, qui troviamo il nocciolo della questione: i due team asseriscono, separatamente, di aver completato correttamente quanto dovevano e non si capisce chi deve fare cosa. Intanto il Lead-Time (o Time to Market se preferite) si allunga, si crea caos e il cliente vede ritardarsi la disponibilità della nuova soluzione, cominciando ad innervosirsi non poco. Attenzione: per il cliente è indifferente che il problema sia nel codice o negli ambienti di esercizio perché lui non riesce ad utilizzare il prodotto, per cui il Valore di quello che faticosamente è stato realizzato è zero!
Da questi elementi nasce la filosofia DevOps, che punta all’integrazione delle attività dei Dev e degli Ops al fine di aumentare la produttività complessiva grazie all’automatizzazione della gestione dell’infrastruttura, dello sviluppo del codice e del continuo monitoraggio delle applicazioni. Viene così condivisa la responsabilità del deployment, inteso come momento di reale completamento della realizzazione di una nuova soluzione, automatizzando quanto più aspetti possibili.
Si tratta di estendere molto di quanto appreso e adottato con successo nel mondo Dev con Agile/Lean all’intera catena IT, ripensando all’idea del deploy Big-Bang, ovvero effettuo il deploy solo quando ho tutto pronto e funzionante sugli ambienti di QA, in favore di un approccio di Continuous Deployment, in cui i deploy avvengono frequentemente (anche più volte al giorno) rilasciando soluzioni incrementali in produzione.
Continuous Deployment
Va da sé, che per poter raggiungere tale obiettivo, l’automatizzazione è uno dei pilastri portanti: dalla configurazione delle macchine tramite script, al testing, al rollback, tutto deve essere automatizzato il più possibile.
Nonostante, ad oggi, non ci sia una definizione univoca di quelli che sono i principi portanti, e chissà se la avremo in futuro, si è comunque concordi nell’individuarne 5 che non possono non essere adottati in un ambiente DevOps:
- Culture – Let yourself Fail, il fallimento deve essere alla base del processo di apprendimento. In un mondo complesso come quello odierno, l’unico modo per migliorarsi costantemente è quello di testare le proprie assunzione, valutare il risultato e agire di conseguenza;
- Automation – Focus on your business, l’automatizzazione dei processi ripetitivi, oltre a ridurre drasticamente l’errore umano, consente di dedicare il proprio tempo ad aspetti più importanti, focalizzandosi sugli obiettivi di business e sulla propria vita personale. Inoltre, grazie all’automatizzazione, è possibile creare ambienti auto consistenti, in grado di tollerare il turn-over di risorse umane;
- Lean – Cut down on waste, i principi Lean sono alla base di tutte le attività di ottimizzazione dei processi. L’abbattimento degli sprechi (waste) consente di ottimizzare le performance generali, riducendo i costi ed il Time-to-Market, e favorendo il focus sulla responsabilità e sul miglioramento della qualità del lavoro;
- Metrics – Audience analysis, Lean Startup e Customer Development insegnano: l’attività fondamentale per ogni azienda è conoscere i propri clienti. Solo conoscendo chi sono i nostri cliente, attuali e potenziali, possiamo attuare le giuste scelte tecnologiche in funzione delle loro reali esigenze. Avere strumenti automatizzati che analizzano tali informazioni, consente di rispondere rapidamente alle mutate esigenze e rafforzare il rapporto di fiducia tra azienda e cliente;
- Sharing – Sharing data, condividere le informazioni è fondamentale. Per fare ciò bisogna abbattere la burocrazia e le barriere che non portano ad avere un rapido e completo accesso a tutte le informazioni, di qualsiasi dipartimento. Tutto ciò non è solo un discorso di strumenti, ma di forte integrazione e collaborazione di tutti all’interno della struttura, indipendente dalla mansione e dal ruolo.
Come si intuisce, il cammino verso il mondo DevOps è complesso, perché fatto da un mix di relazioni e strumenti di automazione, ma come tutte le cose, questo lo rende più attraente e, soprattutto, chi lo ha già iniziato può testimoniare gli enormi vantaggi che ne derivano.
