Vorrei parlare dei principi base del Devops che negli ultimi 5 anni ho potuto assimilare lungo il cammino.
Questo perchè dovevo preparare delle noiosissime slide. Mi serviva uno scopo, e un post sul blog ci sta tutto.
Inoltre, ho preso il dominio ziopinguino.it e sto pensando di migrare tutto il blog lì…
Quali sono i caratteri distintivi dell’area Devops?
Quali sono gli stereotipi e le considerazioni ricorrenti tipiche degli ambiti innovativi a cavallo tra buzzword e vera innovazione?
Cos’è che fa di un devops un devops, signor Lebowski?
Essere una BaaS? Buzzword as a service?
Lo era sicuramente all’inizio una buzzword, ma ora non più.
Lo è se si legge solo nei blog di Devops, se non si è potuto toccarne con mano i benefici e i risultati.
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 (quando dai supporto…).
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 trovano la parola chiave corretta su Google che gli risolve la giornata.
Stare attento a quando dici “alla vecchia maniera”?
Nell’IT non è previsto l’utilizzo di espressioni come “ai tempi miei” o “come si faceva un tempo”.
Un paio di scarpe fatto alla vecchia maniera è resistente e di qualità, ma un sistema fatto così, pur essendo stabile, verrebbe inevitabilmente visto come “anziano”.
Saggio in quanto anziano, ma con la barba bianca e lunga al posto dei baffetti hipster.
Non entro in merito sulla correttezza di tale giudizio, ma è innegabile dire che in molti contesti ciò accade.
Molte delle cose fatte un tempo funzionano egregiamente anche oggi e comunque le usiamo volentieri.
Dirò solo una cosa “Bash Rocks!”.
A volte però 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. E’ meglio quindi usare strumenti supportati da una community, piuttosto che scrivere componenti 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”.
E’ importante sapere che lavoriamo in un ambiente deterministico e che possiamo pilotare piattaforme tramite codice.
Così “ciao ciao” documentazione, si legga il playbook di Ansible o il cookbook Chef (tutto questo in mondo immaginario…il “documentone” verrà sempre chiesto, però ultimamente sono sceso a compromessi per cui anche un bel markdown fatto bene può andare)
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 perchè le abbiamo sviluppate noi. Questo è poco Devops, perchè diventa comunque un silos. Un “agile silos”.
Scegliere i tool con senso critico?
Il landscape dei tool Devops è enorme.
E’ costellato di programmi che fanno a volte la stessa cosa e che competono a suon di stellette su github e loghi accattivanti.
Alcuni di essi sono veramente utili ed è divertente contribuire alle loro community. Altri vengono proposti “a cazzo di cane” in conversazioni di gruppo dove il tema parrebbe essere “spariamo a nomi a caso”.
Una specie di cyber flusso di coscienza << kubernetes! Prometheus!! Openshift!! Spark!! Mesos! Puppy Linux!! >>
Comunque… un Devops, come sceglie i tool da usare nell’opensource?
Evitare sicuramente di giudicare solo in base alla popolarità.
Se tale software viene utilizzato e contemporaneamente lo si reputa mediocre, si dovrebbe contribuire con quello che pensiamo possa portare un miglioramento.
L’opensource del resto è un qualcosa di tutti, potrebbe in un futuro prossimo diventare un bene di tutti. Forse il paragone è esagerato, ma migliorare il software contruibuendo è come pulire una strada per il bene della comunità, perchè hai necessità di percorrerla e se la percorri imprecando sembri un predicatore matto.
Condividere il knowledge, abbattere i silos e fare team?
Assolutamente si. Senza questi tre elementi probabilmente il mio lavoro sarebbe molto noioso. Sono punti fondamentali.
Mi viene in mente un modo di dire che ho coniato qualche minuto fa per cui non ne certifico la concretezza e neanche un senso logico: se detieni l’ownership di una procedura noiosa, non detieni l’ownership del tempo lavorativo mentre la fai.
Intendo che se ci è richiesto di intervenire solo perchè conosciamo una procedura che noi e solo pochi eletti siamo in grado di eseguire siamo distanti anni luce dalle metodologie Devops.
Non siamo owner 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.
E’ compito di un Devops, a mio parere, arrivare al risultato scegliendo la soluzione più smart possibile.
Ecco tutto questo però dimenticatelo il venerdì pomeriggio… ben venga il noioso, il ripetivo e pure il “se funziona non lo toccare”.
E pure il “eh vecchio mio, mi ricordo quando mettevamo il notepad in cluster…”.
