Cosa significa DevOps?

L’acronimo DevOps è l’unione di due parole chiave nello sviluppo di applicazioni business e nella gestione di sistemi informativi: ‘Development’ e ‘Operation’ e coinvolge quindi, in una organizzazione, chi è deputato allo sviluppo delle applicazioni e chi è invece incaricato di gestirle in un ambiente tendenzialmente produttivo. Tra i due gruppi di lavoro (Development e Operation) esiste, tradizionalmente, da sempre una sorta di conflitto dovuto ai diversi obiettivi da soddisfare:

• I team di sviluppo devono creare applicazioni seguendo le indicazioni del business nel modo più veloce possibile, arrivare rapidamente in ambiente produttivo e ridurre al minimo il tempo del time to market;
• I team di operation devono gestire le applicazioni in produzione, che in sintesi si traduce nell’obiettivo di rendere l’ambiente produttivo il più stabile e sicuro possibile, evitando impatti negativi legati al deploy di applicazioni non sufficientemente stabili o performanti.

A causa di questi obiettivi parzialmente in conflitto tra questi due gruppi di lavoro si è sempre avuta una sorta di “diffidenza” reciproca. L’approccio DevOps spinge invece questi due gruppi di lavoro a cooperare per rendere il processo di deploy veloce, ma al contempo sicuro. Questa operazione è realizzabile attraverso l’adozione di automatismi, che garantiscano da un lato la velocità di esecuzione di alcune operazioni, dall’altro che le stesse operazioni siano fatte in sicurezza e con elevata qualità.

Strutture organizzative per il DevOps

In questo contesto è interessante riprendere alcune riflessioni sulle strutture organizzative adottate in ottica DevOps, contenute nella ricerca 2018 State of DevOps Report   promossa da Puppet e Splunk.

Nello studio vengono infatti classificate le organizzazioni (che sviluppano e gestiscono applicazioni di business per la propria azienda) in 5 raggruppamenti, non necessariamente disgiunti, sulla base delle modalità di collaborazione tra i team di sviluppo e operation:

• Cross Functional Team: è il modello secondo cui le organizzazioni IT hanno dei team dedicati per servizi o applicazioni specifiche, composti da rappresentanti di tutte le discipline responsabili dello sviluppo e dell’implementazione di un servizio (analisti aziendali, sviluppatori, ingegneri di qualità, operatori, sicurezza, ecc.). Questi team hanno pieno controllo e autosufficienza del software: lo scrivono, lo testano e lo distribuiscono. Questa modalità di organizzazione rappresenta ancora oggi una realtà abbastanza importante (il 57% delle aziende intervistate nel Report utilizza questa struttura).
• Team dedicati al DevOps: questa tipologia di struttura organizzativa prevede dei Team con competenze diversificate, che si occupano del tema del DevOps in maniera complessiva (51% delle aziende), con l’obbiettivo di implementare soprattutto gli automatismi, a cominciare da quelli che riguardano la distribuzione del software.
• Team “collaborativi”: organizzazioni che hanno un team “operation” centralizzato e gruppi di lavoro dedicati allo sviluppo delle applicazioni (58% delle aziende); è il modello più ricorrente, almeno in Italia, dove il grado di efficienza dipende esclusivamente da quanto i team collaborino tra di loro senza innalzare quei “muri di confusione” teorizzati da Lee Thomson, uno dei maggiori “guru” su questo tema.
• Site Reliability Engineering (SRE): è una disciplina che incorpora aspetti dell’ingegneria del software e li applica a problemi di infrastruttura e delle “operation”. È quella meno adottata (riguarda il 29% delle aziende) ma è in forte espansione. Gli obiettivi principali sono la creazione di sistemi scalabili ed altamente affidabili. Secondo Ben Treynor, fondatore del Team di affidabilità del sito di Google, SRE è “ciò che accade quando a un ingegnere del software viene affidato il compito di gestire la produzione”.
• Service team providing DevOps capabilities: sono team di servizio che forniscono al sistema delle capacità di DevOps, Tool o funzionalità (36% delle aziende) senza avere avuto uno specifico mandato sul tema, né aver costituito funzioni aziendali dedicate.

Le 5 fasi verso il DevOps

Volendo schematizzare il processo che porta all’adozione della metodologia DevOps si potrebbe differenziare in cinque tappe fondamentali:

1. La prima è quella della normalizzazione dello “stack tecnologico”, quindi di una riduzione della complessità in termini di utilizzo di strumenti, sia per lo sviluppo, che per la gestione. La maggior parte delle organizzazioni che utilizzano un’ampia gamma di tecnologie devono gestire un elevato grado di complessità, che si traduce spesso in scarsa capacità di automazione. Non sorprende quindi che il primo passo in una trasformazione DevOps si focalizzi sulla riduzione delle tecnologie in gioco.
2. Segue la standardizzazione e riduzione della variabilità che ha come obiettivo quello di permettere l’implementazione delle pratiche DevOps. Al raggiungimento di questa seconda fase le organizzazioni dovrebbero aver già avviato il processo di standardizzazione di un insieme di tecnologie, separato le configurazioni delle applicazioni dai dati, adottato un processo coerente per l’infrastruttura di test e un modello di condivisione del codice sorgente.
3. Estendere le practice DevOps: se le fasi 1 e 2 riducono la complessità dello stack tecnologico in modo che i team possano ottenere risultati ripetibili con varianza limitata, la fase 3 si dovrebbe focalizzare sull’espansione delle pratiche DevOps in gruppi di lavoro che vanno oltre la divisione ICT. In questa fase le pratiche DevOps si estendono infatti oltre i team di sviluppo (Dev) e operation (Ops). Al crescere della collaborazione le organizzazioni si focalizzano sui miglioramenti relativi al service management, sulla riduzione dei tempi di attesa e sulla minimizzazione dei processi di approvazione, coinvolgendo aree diverse dei dipartimenti tecnologici.
4. Automazione dell’infrastruttura di Delivery: la vera chiave di volta del DevOps. Per ottenere velocità e sicurezza nella fase di deploy di applicazioni assolutamente stabili e non pericolose l’unica possibilità è quella di avere una fortissima implementazione di automatismi, che garantiscano da un lato la trasformazione automatica e dall’altro controlli di qualità su quanto viene sviluppato.
5. Fornire capacità self-service è l’ultimo e più ambizioso stadio dove si perviene ad una quasi totale capacità di automazione. Si garantisce ai gruppi applicativi autonomia in tutto il processo di deploy, attraverso funzioni vere e proprie di self-service. Per passare alla fase 5, un’organizzazione deve avere più dipartimenti impegnati a fornire funzionalità IT all’azienda (e non considerare l’IT come un centro di costo che esegue ordini di lavoro).

Cosa si intende per modalità Self-service?

Per modalità Self-service si fa riferimento ad azioni fatte in totale autonomia da un gruppo di lavoro senza avere il bisogno che un altro gruppo le prosegua per completarle. Con l’implementazione di tale modalità la parte di operation quasi “scompare”, per concentrarsi sulle attività di controllo e monitoraggio. Tutto il processo è automatizzato e il team di sviluppo può portare le proprie modifiche in produzione (quindi fare il deploy) in maniera totalmente automatica.

In generale le organizzazioni si trovano oggi all’interno di quella che viene definita media intensità evolutiva: si posizionano infatti più o meno a metà del percorso che porta al completamento di un’implementazione DevOps. In effetti la percezione che abbiamo come Gruppo RES, anche sulla base del confronto diretto con i nostri clienti, è che il processo di adozione del DevOps abbia raggiunto un buon grado di automazione sotto molti aspetti, anche grazie alle nostre tecnologie. Si è però ancora abbastanza lontani dall’aver completato l’intero processo.

Il Gruppo RES e il DevOps

Dagli anni ‘90 RES propone sul mercato una serie di strumenti, che vanno sotto il nome di RES Suite, che lavorano nell’ambito della System e IT Governance, in particolare proprio nel campo dell’automazione e della cooperazione tra settori diversi dell’IT.  Le soluzioni RES hanno una forte connotazione e aderenza al modello DevOps perché consentono di rimuovere alcuni dei limiti sopra descritti.

Con la nuova Versione 6, che verrà rilasciata nel 2020, RES vuole valorizzare e rafforzare l’apporto dei prodotti RES Suite alle tematiche DevOps, in particolare: JADe, DDL-Changer, Planning, UpTown, Docet, BatchWatch e Daisy.