Incontro DevOps 2019

Anche quest'anno c'è stato Incontro DevOps, l'appuntamento Bolognese dedicato alla pratica DevOps. Riporto alcuni appunti che ho preso durante la conferenza.

Negli anni passati si è sviluppato molto entusiasmo intorno a questo argomento, insieme ad altri che nella pratica sono spesso associati: architettura a microservizi, continuous integration, test automatizzati. Il graal di ogni azienda che fa software è azzerare il tempo che passa tra la scrittura del codice e il momento in cui il codice è andato in produzione (ma si può poi dire di aver scritto codice, se questo codice non sta girando in produzione?).

Rispetto agli anni passati si respirava una maggiore maturità. Gli stessi DevOppers induriti da un altro anno di battaglie. Questa nuova consapevolezza è rappresentata dal nuovo logo: il Cinghiocervo, una chimera metà cinghiale e metà cervo che rappresenta la dualità Developer/Operator ("decidete voi chi dei due ha le corna").

Tutto il primo talk che ho seguito sulla migrazione di Wikimedia ai microservizi è stato un avvertimento a valutare bene le proprie esigenze prima di adottare questa architettura. I microservizi portano con se una complessità di cui la maggior parte delle aziende può fare a meno.

Da questo talk mi porto via la citazione di
Choose Boring Technology (anche qui), che non conoscevo, e un'idea interessante per debuggare architetture a microservizi: lo Unified Request ID. Facendo un po' di ricerca su Google mi sembra un'idea originale, per quanto probabilmente banale dopo che qualcuno ti ci ha fatto pensare. Sostanzialmente si tratta di assegnare un ID unico a ogni richiesta o transazione in ingresso e passare questo ID in tutto lo stack dei microservizi, aggiungendolo nei log. In questo modo si ha una correlazione esatta del giro che ha fatto la richiesta.

Su un argomento simile, in un talk del pomeriggio sulla risposta agli incidenti nelle architetture a microservizi, Serhat Can ha citato alcuni software di tracing per le applicazioni distribuite. Non ne conoscevo neanche uno, quindi ne ho appuntati alcuni: Open Tracing, ZipKin, AWS X-Ray.

Senza i giganti del Cloud il movimento DevOps non sarebbe altrettando diffuso, perché il Cloud ha eliminato la necessità di avere sistemisti: tolti sistemisti basta mettere gli Ops a contatto con il contagioso entusiasmo dei Devs per rimuovere qualunque remora ad andare in produzione. Un'intera sala era dedicata agli sponsor (Pivotal, AWS, OVH). Ho seguito un po' ma non l'ho trovato molto interessante: nuovi prodotti più sofisticati e costosi.

La sensazione è che ci sia molta attenzione per gli strumenti e poco per le pratiche di sviluppo. Da questo punto di vista è stata fantastica la presentazione di Andrea Francia (da non perdere quella dell'anno scorso in cui ha riproposto Kata in Bash): ha dato un senso profondo alla metrica del code coverage in un esempio di refactoring di codice legacy per renderlo testabile. Mi incuriosisce il suo applicare il concetto di Kata alla programmazione, ma non so se ci sia una pratica affermata.

Agile 42 ha presentato un case study di organizzazione di diversi team. Mi ha colpito la contrapposizione tra DevOps team e Scrum team, come se i due team avessere bisogno di metodi di pianificazione differenti: lo Scrum non va bene per il DevOps? In quale dei due contesti impiegano Kanban?
Interessante l'uso di pilots, o "safe to fail experimentation", o "complexity experimentation". Mi sembra in qualche modo collegato a "Plan to Throw One Away" di The Mythical Man-Month. A un certo punto ha citato STATIK, ma non sono riusciuto a trovare riferimenti.

L'ultimo talk che ho seguito era sull'uso di Jupyter come runbook. L'aspetto interessante della soluzione è che Jupyter veniva eseguito su un server anziché in locale, in questo modo tutti gli Ops hanno accesso agli stessi runbook. Le modifiche effettuate runtime sono considerate prove a perdere e ogni giorno vengono ripristinati i runbook versionati. L'ho trovato interessante come approccio per documentare e condividere i passi più comuni di debug di una architettura a microservices. In più è stato anche citato papermill per eseguire i runbook in cron e salvare i risultati.

Cover image curious by Rasto Rejko on 500px.com