Nel 2019 l'approccio
DevOps compie dieci anni. Anche se la ricorrenza, come
molti anniversari nel mondo delle tecnologie, è più che altro simbolica. Secondo gli annali dell'IT il termine DevOps è stato effettivamente
usato per la prima volta nel 2009, ma va ricordato che esso indica un approccio allo sviluppo e all'implementazione delle applicazioni, non una specifica tecnologia, una lista di regole ferree o un singolo strumento.
DevOps non nasce dal nulla e non vive da solo. Non esisterebbe senza l'affermazione delle logiche di sviluppo Agile e non avrebbe importanza se, parallelamente alla sua nascita, non fosse stata in atto una
profonda rivisitazione dello sviluppo software.
Il termine DevOps è l'acronimo di
development e
operations, perché in estrema sintesi l'obiettivo della metodologia è fare in modo che i team di sviluppo e quelli che si occupano del buon funzionamento dei sistemi
operino in maniera sinergica e coordinata quando si tratta di portare in produzione, negli ambienti IT aziendali, nuove applicazioni o servizi.
Sembra una idea banale, in realtà IT e operations una decina di anni fa vivevano spesso come separati in casa: poche interazioni, quelle poche legate a qualche problema da risolvere.
La constatazione di fondo, da cui correttamente DevOps parte, è che sviluppatori e team di operations
hanno esigenze ideali contrastanti: i primi devono innovare modificando frequentemente le applicazioni e i servizi che girano sull'infrastruttura IT aziendale, i secondi vogliono che questa sia stabile per garantirne la massima operatività. È sempre stato così, i contrasti e gli attriti
si sono fatti più evidenti quando ai team di sviluppo è stato chiesto di lavorare in maniera
sempre più veloce.
Tra Agile e DevOps
È qui che DevOps mostra il suo legame intrinseco con i concetti precedenti di sviluppo Agile. Questi hanno giustamente portato le aziende ad
abbandonare lo sviluppo tradizionale e hanno favorito l'adozione di cicli di sviluppo brevi, l'apertura al cambiamento frequente, l'attenzione al miglioramento continuo, l'importanza del feedback degli utenti finali. Ma in questa evoluzione molte aziende hanno puntato dritte sui vantaggi -
più funzioni e applicazioni, più spesso - senza considerare che qualsiasi attività di sviluppo non può essere del tutto priva di vincoli.
DevOps aiuta a mettere ordine in questo scompenso, prima ancora di andare a colmare il gap tra sviluppo ed operations, con alcune linee guida per la parte di sviluppo e test. Attenzione, però:
DevOps non è un "nuovo Agile". I principi dello sviluppo Agile valgono comunque, con o senza DevOps, e riguardano soprattutto il lavoro dei team di sviluppo, il concetto della qualità del software, l'attenzione al software funzionale. DevOps ha
una visione più concreta, operativa e quasi "strumentale", di tutto il flusso sviluppo-implementazione-operations.
Lato sviluppo in sé, infatti, uno degli elementi chiave di DevOps è
il concetto di Continuous Integration, o integrazione continua. Come teoria è uno dei principi del modello Agile: non puntare su grandi aggiornamenti applicativi che richiedono settimane o mesi ma su
innovazioni incrementali molto più contenute e frequenti. Queste possono essere testate velocemente e
portate in produzione quasi subito, ricevendo un feedback immediato sulla loro funzionalità reale.
Il modello DevOps porta questa visione sul piano della concretezza, indicando in che modo muoversi (ma non ci sono tavole della legge, perché non esiste "la" formalizzazione di DevOps) e spingendo per l'utilizzo di strumenti che
automatizzano e controllano le varie fasi dello sviluppo. Ad esempio
git e GitHub per gestire cicli di sviluppo collaborativo, non lineare e distribuito: ogni sviluppatore interviene sulla sua parte di codice, introduce le sue modifiche e resta sempre aggiornato su quelle degli altri. L'obiettivo è ridurre al minimo il rischio di produrre codice errato per un
disallineamento tra i singoli sviluppatori o i gruppi di sviluppo. O che un errore si scopra tardi e per questo si debba scartare tutto un corposo aggiornamento applicativo.
Il
test del nuovo codice è un altro elemento importante di DevOps. Idealmente ogni modifica alle applicazioni o ai moduli di codice deve essere testata in ambienti simili a quelli reali ma sicuri, comunque non in produzione. L'obiettivo non è solo bloccare il codice evidentemente errato ma anche
valutare il suo livello di rischio: un modulo software anche funzionante e formalmente corretto potrebbe comunque
introdurre vulnerabilità, a seconda delle sue possibili interazioni con altri elementi dell'ambiente di produzione.
DevOps: arriviamo alle operations
L'approccio DevOps arriva a toccare direttamente la parte delle operations portando a una formalizzazione dei passi da seguire per
implementare in produzione il nuovo codice. Si suppone che la parte di Continuous Integration e testing abbia portato a codice corretto, ma questo non basta.
Uno dei principali punti di contrasto tra sviluppatori e operations è tradizionalmente lo spuntare in produzione di servizi, applicazioni e relative risorse di cui lo staff IT non sa niente o quasi. Non è una questione di shadow IT ma di
stabilità stessa dei sistemi: anche nei migliori ambienti IT risorse e applicazioni devono attivarsi - a maggior ragione oggi, negli ambienti di cloud computing - in maniera sicura. Questo ovviamente
contrasta con la volontà di avere il massimo di quella "agility" di cui oggi parlano tutti, ma i controlli ci vogliono.
Nel modello DevOps questo contrasto viene superato con una collaborazione fattiva tra le parti - un elemento concettuale e culturale, ma dove si trova
la vera carica innovativa di DevOps - e operativamente con strumenti di
Continuous Delivery e anche di
Continuous Deployment.
La
Continuous Delivery è il complemento della Continuous Integration: "riceve" il nuovo codice impacchettato nella maniera più opportuna (ad esempio
in un container); configura, attiva e/o rilancia le risorse che lo devono eseguire; effettua altri
test di funzionamento oltre a quelli degli sviluppatori; in caso di problemi ripristina tutto allo stato precedente alla ricezione del nuovo codice. Se è previsto che le modifiche
passino direttamente in produzione una volta verificato il loro buon funzionamento, la Continuous Delivery diventa anche Continuous Deployment.
L'approccio DevOps prevede poi che la collaborazione tra sviluppatori e operations continui
anche dopo il deployment. Controllando la corretta (o meno) esecuzione delle nuove applicazioni e dei nuovi servizi, le operations possono dare agli sviluppatori informazioni importanti per le attività successive di creazione del codice.
DevOps: a chi interessa
Nonostante il mantra secondo cui ogni azienda è (o diventerà) una software house, il dibattito inaugurato da DevOps
non ha interessato tutti subito. E nemmeno, nonostante l'onnipresenza del termine, interessa tutti adesso. Però tocca
potenzialmente molti.
Ottimizzare al massimo il percorso che va dalla creazione di un nuovo servizio o applicazione alla sua esecuzione e chiuderlo in un ciclo ideale interessava, dieci anni fa,
i cloud provider, le aziende di fascia enterprise e i fornitori di servizi online (di qualsiasi tipo: dalle applicazioni in SaaS agli ecommerce fino ai social network). Oggi le realtà interessate sono molte di più, perché la
digitalizzazione in generale ha messo un numero molto elevato di imprese nelle condizioni - e anche nella necessità - di migliorare frequentemente i "tasselli" applicativi su cui si basano i propri processi.
Quindi, tanto per fare qualche esempio, DevOps interessa
i retailer che vogliono sviluppare sempre nuovi servizi digitali ai clienti per aumentarne il coinvolgimento,
le banche che cercano di restare al passo con le esigenze dei clienti, le
software house propriamente dette, gli
operatori di telecomunicazioni che stanno "cloudificando" le loro piattaforme... In estrema sintesi, tutte le imprese che hanno scelto la digitalizzazione come modo per poter
cambiare in meglio i propri processi ogni volta che è necessario.
Un dato di fatto ormai poco confutabile è che
le metodologie DevOps portano vantaggi a chi le adotta. Ci sono
molte analisi che hanno cercato di quantificarli, tra i vari loro risultati è interessante notare una netta accelerazione della
frequenza di delivery di nuovo codice, che arriva ad essere di più volte al giorno. Non tutte le aziende hanno bisogno di operare così frequentemente, ma anche in implementazioni più conservative DevOps riduce notevolmente il tasso di errori del nuovo codice in delivery e il tempo necessario a recuperare da situazioni di errore.
DevOps: i punti deboli
Di suo, DevOps ha un solo importante punto critico, per chi lo approccia:
non è una lista formalizzata e univoca di cose da fare. Il concetto di fondo è chiaro - coinvolgere sia sviluppatori sia operations in tutto il ciclo di vita di una applicazione/servizio - ma concretizzarlo oggi vuol dire mettere insieme concetti di sviluppo, test, integration, deployment,
automazione, orchestration, infrastructure-as-code e via dicendo.
DevOps è quindi una di quelle discipline per cui non è praticabile l'idea di trovare il (malcapitato) "esperto" aziendale a cui affidare il compito di creare il ponte tra sviluppo e operations.
Ci vuole impegno da parte di tutte le figure coinvolte e anche del management. Impegno che certamente arriva una volta quantificati i vantaggi di DevOps, ma che prima non è scontato.
La genericità di DevOps riguarda anche gli strumenti da adottare.
Non esiste una piattaforma DevOps formale ma un insieme di tool mirati alle varie componenti dell'approccio - alcuni dei quali sono diventati ormai standard di mercato - e tra cui scegliere quelli più opportuni. In generale la cosiddetta
DevOps toolchain può essere molto articolata, con prodotti tanto
open source quanto commerciali, e nuovi moduli software interessanti in logica DevOps nascono frequentemente.
Infine, un punto critico che si constata in molti flussi DevOps è una relativa
poca attenzione alle fasi di test, nella parte di integration come in quella di deployment. Questo deriva sia da una poca predisposizione "storica" delle aziende ad eseguire test estesi del codice e delle applicazioni, sia dal fatto - peraltro collegato a questa poca predisposizione - che
le soluzioni di test automatizzato non si sono granché evolute negli ultimi anni. O perlomeno non quanto il resto degli ambiti toccati da DevOps.
Questo rappresenta
un problema e una mancata opportunità. Il problema è che per le specifiche implementazioni di DevOps aumenta la probabilità di avere codice errato oppure applicazioni malfunzionanti, vanificando parte dei benefici stessi di DevOps. L'opportunità mancata è che inserire una mole cospicua di test e controlli di sicurezza nei flussi DevOps, spaziando dai test funzionali all'analisi delle vulnerabilità, aiuterebbe a
concretizzare i principi di security by design che gli esperti
richiedono. Tanto che l'idea del
DevSecOps si è già abbastanza diffusa.