ITIL e DevOps: nemici o modelli complementari?

Sempre più spesso sentiamo parlare di DevOps, la metodologia di sviluppo del software che punta alla comunicazione, collaborazione e integrazione tra sviluppatori sviluppatori software e professionisti di operations IT. Ma qual è la “reale” relazione con ITIL?

Abbiamo deciso di spiegarvi, prendendo come riferimento il blog post Axelos di Dave Blodgett, quali sono le innovazioni apportate da DevOps e perché ITIL è e continuerà ad essere il riferimento per la gestione dei servizi IT.

Ecco quali sono le caratteristiche innovative di DevOps:

• Gli sviluppatori non sono più al di fuori della gestione operativa. Con DevOps, gli sviluppatori e i sistemisti in esercizio diventano integrati in un unico, coeso team di sviluppo (development – Dev) ed esercizio (operatons – Ops)
• i “laboratori” DevOps ben implementati fanno grande uso di infrastructure as a code (IaC), ovvero di metodi automatici per configurare e implementare l’infrastruttura. L’avvento dei servizi di public cloud ha reso meno rilevante il ruolo di un sottoinsieme di gestori delle infrastrutture dedicate in quei “laboratori” che hanno già completato la trasformazione in ambienti di public cloud. Tuttavia, ciò NON elimina il bisogno di ingegneri “infrastrutturali” che costruiscano e gestiscano il cloud sottostante e le interfacce API, o di ingegneri che creino e gestiscano infrastrutture cloud
• DevOps ci spinge verso un unico codice di riferimento che comprende software, middleware, ed ambiente operativo. DevOps fa convergere quelli che storicamente erano sistemi diversi, in termini di modalità di gestione, ciclo di rilascio o modello di controllo. Con DevOps più discipline lavorano insieme, in un modello di delivery perfettamente integrato, per aggiungere valore al cliente.
• È una questione di velocità/time to market – DevOps combina Integrazione Continua (Continuous Integration – CI) ed Erogazione Continua (Continuous Delivery – CD), e proprio CI/CD migliorano la velocità nel soddisfare le esigenze dei nostri clienti.

DevOps è nato dalla necessità delle startup che operavano sui servizi di public cloud.
Di solito la maggior parte delle risorse economiche che le startup hanno viene investito per creare le funzionalità che saranno poi utilizzare dagli utenti e, visto che agli sviluppatori era ovviamente richiesto di realizzare quelle tecnologie che rappresentano il “core” del business, si è pensato di  rendere gli sviluppatori anche responsabili della gestione dell’infrastruttura e non solo della creazione del codice.

Ma ecco una verità: in DevOps non viene data la “licenza” di eliminare i criteri di trasparenza e controllo, specialmente in grandi società (società regolamentate). Sembra sia diffusa l’idea che essere un “laboratorio” DevOps esenti l’organizzazione dal bisogno di essere conforme a standard normativi tipici del settore o che elimini la necessità di implementare procedure di Change Management, o di mantenere un sistema di Configuration Management, o di avere un meccanismo formale per tracciare e eliminare incidenti ricorrenti, ecc.

MODELLI COMPLEMENTARI

In realtà, ITIL e DevOps sono perfettamente complementari. Infatti, erano presenti delle disposizioni in ottica DevOps sin dalla edizione ITIL v3 (edizione 2007) – anche se quelle non erano state pensate esplicitamente per DevOps.

Perché è così importante avere processi maturi? “Laboratori” meno controllati funzionano bene nelle startup, dove il lavoro richiesto per tracciare gli asset e le relative relazioni è più gestibile, mentre la necessità di processi più maturi emerge in organizzazioni più complesse.

Tenete sempre a mente una cosa importante mentre utilizzate DevOps o lo integrate più profondamente all’interno della vostra organizzazione: i processi previsti nel modello ITIL dovranno comunque essere implementati. Avrete sempre la necessità di risolvere ciò che non funziona (incident management), di scoprire la causa degli incidenti più frequenti (problem management); così come quello di conoscere quali sono gli elementi della configurazione (configuration item – CI) e quali sono le relazioni tra di loro (configuration management).

DevOps è un elemento importante, ma si tratta di un metodo per mettere in pratica le cose e non si  sostituisce ad un modello di gestione dei servizi informatici. ITIL è e continuerà ad essere il riferimento per la gestione dei servizi IT – e non è assolutamente in pericolo.

Vuoi saperne di più su DevOps? Segui il link DevOps: cos’è

Vuoi conoscere quali sono gli errori più comuni nell’implementazione di ITIL (e come evitarli)? Scarica gratuitamente l’articolo round up dei nostri tre esperti 

Vuoi leggere il post originale? Leggi ITIL® and DevOps – arch-enemies or complementary models? sul blog Axelos