DevOps (abbreviazione di sviluppo e operazioni), è una buzzword di cui si sente molto parlare di questi tempi nel mondo IT enterprise. Tutti ne parlano ma pochi sanno realmente cosa essa sia. In termini generali, DevOps è un approccio basato sui principi lean e agile in cui business owners, sviluppatori, amministratori di sistema e dipartimento di qualità del software collaborano per rilasciare software in maniera continua, consentendo alle aziende di cogliere più rapidamente le opportunità di mercato e
ridurre i tempi per avere il feedback dai clienti. Nel mondo enterprise siamo spesso in presenza di applicazioni molto complesse con vari moduli che interaggiscono, varie basi dati e client eteregenei (desktop, mobile,ecc..) e sicuramente un approccio di tipo DevOps aiuta a semplificare la gestione di queste infrastutture.

Cosa è DevOps ?

DevOps è meglio definita come una filosofia o ideologia. Non è un titolo di lavoro, né un set di strumenti specifici e nemmeno un mercato.
Abbracciare una filosofia DevOps significa adottare una ideologia che promuove la collaborazione tra il team di sviluppo (Dev) e gli amministratori dei sistemi (Ops). Obiettivo comune di DevOps è quello di rimuovere gli attriti, i rischi, e gli altri vincoli per consentire una più veloce produzione di applicazioni da rilasciare in produzione, più veloce a volte anche di quanto il business stesso richieda.
La maggior parte delle aziende che implementano i metodi DevOps oggi hanno ancora un team di sviluppo e un team operativo sul posto. Si può pensare  DevOps come i processi e le persone che costruiscono i ponti tra queste squadre per migliorare il business e migliorare la user experience. Vari strumenti e piattaforme facilitano il lavoro di DevOps, ma questi non servovo a definirlo.
Non esistono attualmente regole codificate o manuali per DevOps, ma solo linee guida generalmente accettata. Detto questo, l’adozione e l’attuazione di DevOps variano notevolmente da un’organizzazione all’altra.

Perchè adottare DevOps ?

DevOps è stato originariamente considerato una metodologia adottata solo nelle grandi aziende basate sul Web (Netflix, Google ™, etc.) e start-up. All’interno della comunità DevOps, questi tipi di organizzazioni sono spesso indicate come “cloud-natives,” “born in the cloud,” or “unicorns.”.
Ma negli utltimi tempi, anche le grandi imprese “tradizionali” stanno adottando in una qualche maniera principi DevOps per diventare sempre più agili e rispondere meglio alle esigenze del mercato attuale ed essere competitive.

Le aziende si trovano a dover creare nuove applicazioni o servizi innovativi per soddisfare alcune esigenze di business. Si può decidere di affrontare problemi di business interni (come ad esempio la creazione di un migliore Customer Relationship Management System) oppure decidere di creare soluzioni atte ad aiutare i loro clienti o gli utenti finali (ad esempio, fornendo una nuova applicazione mobile), ma non sempre le aziende riescono nello scopo e i fallimenti sono spesso legati alle sfide che devono affrontare per lo sviluppo del software e il delivery portando inevitabilmente  a perdere occasioni di business.

Questo problema è ulteriormente amplificato da un grande cambiamento nei tipi di applicazioni che le imprese sono tenute a fornire:

✓ Systems of record: sono le applicazioni software “tradizionali” grandi sistemi che funzionano come sistemi di registrazione, che contengono enormi quantità di dati e/o transazioni e sono progettati per essere altamente affidabili e stabili. Pochè queste applicazioni non hanno bisogno di cambiare spesso, le aziende possono soddisfare i loro clienti e le loro esigenze di business fornendo solo uno o due grandi nuove release all’anno.

✓ Systems of engagement: Con l’avvento delle comunicazioni mobili e l’evoluzione delle applicazioni web, i systems of record sono stati affiancati dai systems of engagement, con i quali i clienti possono accedere direttamente e utilizzare il business. Tali applicazioni devono essere facili da utilizzare, ad alte prestazioni, e, richiedono tempi rapidi di sviluppo per adattarsi velocemente ai cambiamenti delle esigenze dei clienti e l’evoluzione del mercato.

Poiché i systems of engagement sono utilizzati direttamente dai clienti, c’è bisogno di porre particolare attenzione alla user experience (UX), alla velocità di delivery e agilità – in altre parole, un approccio DevOps.

I systems of engagement sono spesso legati ai system of record e questo comporta che cambiamenti rapidi ai primi comporta cambiamenti altrettanto rapidi ai secondi. Quindi in generale possiamo dire che qualsiasi tipo di sistema che necessita delivery rapidi ed è sogetto ad innovazioni richiede DevOps. Tali innovazioni sono guidati principalmente dalle tendenze tecnologiche emergenti come il cloud computing, le applicazioni mobile, Big Data, e social media, che possono influenzare tutti i tipi di sistemi.

Falsi miti su DevOps

Il movimento DevOps è giovane e ancora emergente, in particolare tra le imprese e come ogni nuovo movimento o tendenza, ha attirato miti e falsità. Alcuni di questi miti possono avere avuto origine in aziende o progetti che hanno provato senza successo ad adottare DevOps. Cosa c’è di vero in una situazione, tuttavia, può non essere necessariamente vero in altre. Vediamo di seguito  alcuni miti comuni circa DevOps – e i fatti

• DevOps è un titolo di lavoro?
  La risposta in breve è: “No”, DevOps coinvolge la collaborazione tra vari gruppi, chi usa DevOps
  può lavorare in una serie di settori diversi. Infatti, DevOps è adottato e guidato da professionisti ed evangelisti che detengono una varietà di titoli di lavoro. Ci sono comunque aziende che assegnato titoli relativi al DevOps come ad esempio DevOps Engineer, DevOps Security Engineer, e altri.
  
• Quali sono gli skills degli operatori DevOps?
  Gli evangelisti ed operatori di metodi DevOps sono in genere analisti, sviluppatori e architetti senior e più in generale professionisti con una vasta comprensione di varie discipline. Sulla base della crescente complessità dei sistemi questi professionisti, hanno abbracciato una mentalità di miglioramento continuo al fine di ottimizzare i processi e i sistemi. Nella loro intima essenza, le persone che  adottano metodologie DevOps sono risolutori di problemi che vogliono trovare la soluzione il più velocemente possibile pur mantendendo standard di elevata qualità.
• No Cloud = No DevOps                                                                                                                    Quando si pensa di DevOps, spesso si pensa al Cloud per la sua capacità di fornire rapidamente le infrastrutture che servono a sviluppatori e tester senza aspettare giorni o settimane. Tuttavia, usare il Cloud non implica necessariamente adottare pratiche DevOps e viceversa. In un azienda si può adottare DevOps anche su infrastrutture interne se il processo di lavoro è ben organizzato ed ottimizzato.
  
•  DevOps non è per i grandi Sistemi complessi
  I sistemi complessi richiedono la disciplina e la collaborazione che DevOps fornisce. Tali sistemi hanno in genere vari moduli software che comunicano  e/o vari componenti hardware, ognuno dei quali ha un proprio cicli di delivery e scadenze. DevOps facilita il coordinamento di questi cicli di delivery e la pianificazione dei rilasci a livello di sistema.
• DevOps riguarda solo il miglioramento della comunicazione e della collaborazione Alcuni membri della comunità DevOps hanno coniato umoristicamente termini come ChatOps (squadre che comunicano solo attraverso strumenti di comunicazione come Email o Chat) e HugOps  (DevOps che si concentrano solo sulla collaborazione e la comunicazione).
  Questi termini derivano dall’idea sbagliata che la comunicazione e la collaborazione da sole risolvano tutti i problemi. DevOps dipende dalla comunicazione, ma una migliore comunicazione accoppiata con  processi dispendiosi non portano ai risultati che DevOps si propone di ottenere.

 Come funziona DevOps ?

Il movimento DevOps ha prodotto diversi principi che si sono evoluti nel tempo e sono ancora in evoluzione. Diverse soluzioni sono state proposte ed adottate con le proprie varianti, ma alcuni principi diciamo che sono comunemente riconosciuti e adottati e sono i seguenti:

✓ Sviluppare e testare in ambienti simili a quelli di produzione
✓ Distribuire con processi automatici, ripetibili e affidabili
✓ Monitorare e convalidare la qualità operativa
✓ Amplificare e accelerare il ritorno di feedback da parte degli utenti

Nella figura sotto un comune ciclo di processi nella metodologia DevOps:

All’interno di una tipica organizzazione IT, il campo di applicazione di DevOps si estende su quattro aree funzionali:

1. Continuous integration e testing
2. Continuous delivery e deployment
3. Continuous operations
4. Continuous assessment

Vediamoli uno per uno:

Continuous integration e testing

Continuous integration (CI) è una pratica di sviluppo che richiede agli sviluppatori di integrare il loro codice  diverse volte al giorno mediate l’uso di un repository condiviso (SVN, GIT,…). Ogni check-in viene poi verificato da un sistema di build automatico consentendo ai programmatori di rilevare eventuali problemi nelle prime fasi del ciclo. CI è la pratica di automatizzare e integrare test funzionali e non funzionali (Prestazioni, sicurezza, ecc),  nella catena di distribuzione del software, eseguendo questi test in maniera automatica ogni volta che c’è una modifica nel codice. Ci possono essere dei test più importanti di altri a cui viene data una maggiore priorità oppure è possibile eseguire ogni volta l’intera suite di test. CI può essere utilizzata come una naturale estenzione dello sviluppo test-driven.

Continuous delivery e deployment

Continuos Delivery (CD) è una disciplina il cui  obiettivo è quello di buildare il software in modo che possa essere rilasciato in produzione in qualsiasi momento, ed essere quindi sempre production-ready. CD si realizza automatizzando il flusso di distribuzione del software dallo svilippo alla produzione. Gli elementi chiave di CD comprendono la standardizzazione della configurazione delle infrastrutture, e la gestione
dei dettagli di configurazione seguendo la stessa disciplina applicata alla gestione del codice sorgente. Altri elementi comprendono l’automatizzazione della distribuzione del software da parte del team di sviluppo su specifici ambienti (sviluppo, collaudo, produzione) con relativi test automatici per rilevare subito eventuali problemi. Tipicamente gli ambienti “intermedi” sono simili a quello di produzione in modo tale da essere certi che il software funzionerà anche in produzione. Continuos Deployment può essere vista come una forma estrema di CD in cui ogni singola modifica che passa con successo i test viene automaticamente distribuita in produzione.

Nella figura sotto una tipica delivery pipeline dallo sviluppo fino alla produzione:

Continuous operations

E’ la pratica di gestire le modifiche software o hardware in modi tali che non siano lesive per gli utenti finali: l’applicazione di patch o la manutenzione dei server non devono impedire agli utenti di utilizzare il software che possono ad esempio ultilizzare la versione precedente nel software, fino a quando la nuova
versione è stata testata e implementata con successo.

Continuous assessment

Vuol dire valutare continuamente l’applicazione basandosi su tre tipi di feedback:

• Feedback loops – si implementa col continuo monitoraggio della disponibilità, della salute e delle prestazioni dell’applicazione, ma anche registrando l’esperienza degli utenti in tutto il ciclo di vita
portandone a conoscenza i team di competenza. In questo modo è possibile un ottimizzazione continua dell’applicazione ed un aumento della soddisfazione d’uso (UX) degli utenti finali.
• Planning prioritization – Quando i team ricevono i feedback a questi viene data una priorità siano essi richieste di nuove caratteristiche o funzioni e o bug-fixing, in base alle esigenze di business
e le richieste degli utenti finali.
• Portfolio investment – Quando i team ricevono i feedback  il gruppo di pianificazione darà una priorità anche in termini di investimenti necessari. 

Conclusioni

Il movimento Devops è ancora nella sua infanzia, ma c’è molto movimento intorno ad esso – ci sono convegni, mailing list, canali IRC e blog. Credo di poter affermare con un buon grado di certezza che non è una moda passeggera, ma siamo davanti ad una rivoluzione nel settore del software – un cambiamento di paradigma in cui gli sviluppatori e amministratori di sistema iniziano a lavorare insieme, a formarsi  l’un l’altro, e in ultima analisi, ad offuscare la linea di confine tra i due ruoli – benvenuti nel mondo della Devop.

Risorse

Per approfondire l’argomento DevOps si consigliano le seguenti risorse:

• continuousdelivery.com
• devops.com
• arresteddevops.com