DevOps: tentare una definizione

Negli ultimi anni le pratiche DevOps si sono diffuse causando una “rivoluzione gentile” nell’ambito dello sviluppo e della gestione del software. Le tecnologie, gli strumenti, le pratiche connesse all’area DevOps non sono più materia esoterica per pochi interessati, ma sono note, almeno a grandi linee, a coloro che devono occuparsi seriamente dell’IT nelle aziende.

I risultati e i miglioramenti tangibili apportati da tale approccio, che è anzitutto metodologico, prima ancora che tecnologico, sono stati sicuramente la ragione migliore per convincere certi scettici.

Parafrasando uno dei film culto degli anni Novanta (“Cos’è… cos’è; che fa di un uomo un uomo, signor Lebowski?”) vorrei parlare dei principi base per definire i caratteri distintivi dell’area DevOps, le caratteristiche e le competenze che deve possedere un professionista che operi in quest’area. In breve “Cos’è che fa di un DevOps un DevOps, signor Lebowski?”.

Cercherò di concentrarmi su alcuni dei principi che negli ultmi cinque anni ho potuto assimilare nell’ambito del mio cammino professionale e riassumerò una serie di riflessioni in alcuni paragrafi, senza pretesa di concludere con questo elenco la discussione, ma solo come stimolo per la riflessione e un miglioramento continuo. Quindi, quali sono le caratteristiche di un buon DevOps?

Essere una BaaS (Buzzword as a Service)

Diciamolo subito: gli ambiti innovativi forniscono tanti stereotipi ed esagerazioni quando ci si trovi a cavallo tra vera innovazione e buzzword sopravvalutata. All’inizio DevOps era sicuramente una buzzword, ma ora non lo è più. O meglio, può esserlo ancora per chi legge solo i blog o scorre distrattamente i tweet.

Ma non è una buzzword se si sono toccati con mano i benefici e i risultati di questo approccio. Nei contesti dove c’è stata una vera rivoluzione, la parola “DevOps” descrive perfettamente figure professionali che svolgono attività di collegamento tra i gruppi di sviluppo e le operation. Queste attività si individuano nella forma di integrazioni di sistemi, sviluppo di piccoli tool e… pubbliche relazioni perché spesso danno supporto agli altri.

I Devops seguono tutta la catena di montaggio partendo dal codice fino al delivery e monitoring delle applicazioni. Sono sistemisti che scrivono del buon codice, o programmatori che si muovono agili sulla shell. Giocano con molte tecnologie e spesso fanno “ricerca” nel senso che devono trovare la soluzione tecnica più giusta e adatta andandosela a cercare perché, non è già preconfezionata, scoprendo così quanto è in grado di risolvere la situazione.

Stare attenti a quando si dice “Alla vecchia maniera”

Nell’IT non è previsto l’utilizzo di espressioni quali “Ai miei tempi” o “Come si faceva un tempo”. Un paio di scarpe — o un altro prodotto artigianale — fatto alla vecchia maniera è resistente e di qualità, ma un sistema fatto così, pur essendo stabile, verrebbe inevitabilmente visto come “anziano”. Saggio, magari, in quanto anziano; ma con la barba bianca e lunga al posto dei baffetti hipster…

Anche qui occorre trovare un equilibrio tra innovazione per il solo gusto di “fare qualcosa di nuovo” e reale necessità di adottare nuove soluzioni. Di fatto, nel mondo IT, ogni anno assitiamo all’avvento di nuove tecnologie — software e hardware — e di nuove metodologie.

Molte delle cose fatte un tempo funzionano egregiamente anche oggi e comunque le usiamo volentieri: “Bash Rocks!”. Ma è innegabile che sistemi costruiti come quelli di dieci anni fa appaiono superati e soprattutto non invogliano l’organizzazione a perseguire una strada come quella di DevOps. Insomma, per molti il nuovo ha un valore, di per sé. Non entro nel merito della correttezza di tale giudizio, ma è innegabile che in molti contesti ciò accade.

E a volte il cambiamento è fortemente consigliato. Ad esempio, non è possibile sostituire un configuration management tool come Chef o Puppet con dello shell scripting. Concetti come idempotenza e auto-discovery richiedono comunque un effort nella loro realizzazione. È meglio quindi usare strumenti supportati da una community, piuttosto che scrivere componenti, per quanto validi, di cui poche persone mantengono la memoria storica.

Essere preparato su Git

Non può mancare una conoscenza approfondita di Git. Servirà quando uno sviluppatore ti chiederà aiuto o quando prenderai in giro il tuo amico perchè lavora dove ancora distribuiscono il codice e le nuove release su aeroplanini di carta: sull’ala destra c’è il messaggio di commit e su quella sinistra la versione; se l’aeroplanino ritorna indietro per via di forti correnti contrarie, hai fatto rollback…

Il pattern di “Infrastructure as Code” non può mancare, e quindi serve “versionare”. È importante sapere che lavoriamo in un ambiente deterministico e che possiamo pilotare piattaforme tramite codice.

Questo significa anche salutare la documentazione tradizionale: si legga il playbook di Ansible o il cookbook Chef per rendersene conto. Chiaramente, stiamo parlando di uno scenario perfetto… Il “documentone” verrà sempre chiesto; però devo anche dire che negli ultimi tempi sono riuscito più volte a tovare un dignitoso compromesso per cui anche un bel markdown fatto bene può bastare.

Ho imparato che tutto il lavoro svolto deve essere portabile. Un modulo Puppet o un cookbook Chef deve essere chiaro e leggibile. Sembra scontato ma non lo è. Spesso automatismi e meccanismi agili all’interno delle nostre infrastrutture risiedono solo nella nostra conoscenza: quelle infrastrutture le abbiamo sviluppate noi e ci risultanto pertanto familiari. Tutto ciò è poco DevOps, perchè diventa comunque un silos: un “agile silos” ma sempre un silos…

Scegliere i tool con senso critico

Il panorama dei tool DevOps è davvero ampio ed è costellato però anche di programmi che fanno la stessa cosa e che competono a suon di stellette su github e loghi accattivanti. Alcuni di essi sono veramente utili ed è gratificante contribuire alle community che li sostengono; altri vengono proposti in conversazioni di gruppo a tema “spariamo a nomi a caso” solo per fare la figura di quello che conosce tutte le novità. Ne nasce una sorta di cyber “flusso di coscienza” del tipo: “kubernetes! Prometheus! Openshift! Spark! Mesos! Puppy Linux!”…

Ma nel concreto, come fa un DevOps a scegliere i tool da usare, tra i molti prodotti open source presenti in questo panorama?

Occorre giudizio e misura, il che porta a evitare di giudicare solo in base alla popolarità. La popolarità ha sicuramente delle ragioni e una base, ma non deve essere l’unico criterio su cui basare l’adozione di un tool. Se tale software viene utilizzato estensivamente e, contemporaneamente, lo si reputa mediocre, si dovrebbe contribuire con ciò che pensiamo possa portare un miglioramento, nell’ottica del paradigma dell’open source.

L’open source del resto è un qualcosa di tutti e potrebbe in un futuro prossimo diventare un “bene comune”. Forse il paragone è esagerato, ma migliorare il software contruibuendo alla comunità che lo sviluppa e mantiene equivale a pulire una strada per il bene della comunità che la abita. Hai la necessità di percorrerla e devi impegnarti a renderla vivibile: se ti limiti a imprecare, non stai facendo nulla per migliorarla.

Condividere la conoscenza, abbattere i silos e fare team

Assolutamente sì. Sono punti fondamentali: senza questi tre elementi probabilmente il lavoro del DevOps sarebbe molto noioso.

La condivisione di conoscenza stimola la crescita di tutti coloro che partecipano al processo, facilita lo svolgimento delle operazioni, migliora la qualità delle soluzioni che si adottano. Detenere l’ownership di una procedura noiosa e complicata non è un gran valore, da custodire gelosamente… anzi, finisce per far perdere valore al tempo lavorativo che si impiega nel farla.

Intendo dire che, se ci è richiesto di intervenire solo perché noi e pochissimi altri “eletti” siamo in grado di eseguire una determinata procedura complicata, siamo distanti anni luce dalle metodologie DevOps. Non siamo noi i “proprietari” di quel tempo che impieghiamo a concludere il task perché qualcuno prima di noi ha deciso quanto sarebbe dovuto durare scrivendo passo passo un documento procedurale.

È compito di un Devops, a mio parere, arrivare al risultato scegliendo la soluzione più smart possibile. E in questo senso intendo che sia una soluzione efficace, efficiente, comprensibile, condivisa e facilmente modificabile/migliorabile. Per questo la condivisione della conoscenza nel team e l’abbattimento delle barriere fra dipartimenti sono valori importantissimi: non è questione di “siamo tutti più buoni”, ma è questione di “facciamo insieme le cose meglio, con soddisfazione da parte di tutti”.

Poi… che c’entra… al venerdì pomeriggio, ben venga pure il noioso, il ripetivo e il classicissimo “Se funziona non lo toccare!”. E, a questo punto, anche il “Eh vecchio mio, mi ricordo quando mettevamo il notepad in cluster…”. Ma sono eccezioni, perché DevOps è altro.

Conclusioni

L’abbiamo detto: non pretendiamo con queste brevi note di aver trattato esaustivamente il corpo delle competenze tecniche e attitudinali di un professionista che si muove nell’ambito DevOps. Ci piaceva però stimolare la riflessione e contribuire alla discussione con qualche considerazione maturata “nelle trincee”.

Le tecnologie e i tool si evolvono con una velocità notevole, a volte spiazzante. Ma l’approccio e la forma mentale di un DevOps sono elementi fondamentali e meno soggetti alla rapida obsolescenza di qualsiasi tecnologia.