DevOps: quale futuro e da dove cominciare

Il futuro del DevOps

Per qualche strano motivo nell’ultimo periodo tutti mi fanno domande sul futuro.

Che futuro c’è per il DevOps?

E’ una moda momentanea o è qui per restare?

Perché un’organizzazione dovrebbe investire nel DevOps?

Cosa dovrebbe fare qualcuno che si sta avvicinando a questo lavoro per essere preparato alle sue evoluzioni future?

Sono tutte domande lecite, ma il problema del futuro è che è in continuo mutamento, quindi, a meno che non disponiate o vi facciate prestare un mezzo Tempo e Relativa Dimensione nello Spazio, qualsiasi previsione che vada oltre qualche mese è una mera ipotesi; qualsiasi idea che possiate avere di questo lavoro da qui a tre anni è speculazione pura, perché se c’è una cosa che le speculazioni sul futuro ci hanno insegnato, è che è maledettamente difficile che si avverino.

Quindi potrei sottolineare l’ovvio come fanno i grandi e blasonati analisti, facendo auto-avverare le proprie previsioni, oppure scrivere una cosa ragionevole a caso, aspettare che il tempo passi e poi modificare questo post per inserirvi quello che è realmente accaduto, come il Minamor di 1984, solo per poter dire: “Ve l’avevo detto!”.

L’ultima cosa probabilmente la farò comunque, ma questo post lo userò per cercare di spiegare, più che il futuro del DevOps, come attrezzarsi per esso, perché nella  situazione di continua e velocissima evoluzione tecnologica in cui ci troviamo, piuttosto che provare ad anticipare le mode penso sia più utile “cavalcarle” oppure, per dirla come uno degli speaker di un evento a cui ho partecipato di recente (sì, confermo che c’era anche Aranzulla):

Quando sei continuamente sommerso da informazioni tecniche hai bisogno di capisaldi, di valori di base.

Quali sono i tools (come dicono quelli bravi), gli strumenti base di cui secondo me si dovrebbe attrezzare qualcuno che si approccia al DevOps, per essere competitivo ed efficace velocemente e per poter “gestire” anche gli scossoni della propria macchina del tempo che, come quella di tutti, va solo in una direzione (in avanti) e spesso prende bivi inaspettati?

Della Cultura abbiamo già parlato, della Leadership anche, della parte tecnologica ne parleremo probabilmente quando tratteremo gli altri “sapori” del nostro buon whiskey, quindi quello che rimane è:

L’Approccio

L’approccio che chiunque ha alla metodologia DevOps (vogliamo chiamarla così?) è come l’imprinting di un pulcino, difficilmente nel corso della vostra carriera di “DevOppers” vi scosterete da quello che vedrete e assimilerete la prima volta che starete cercando informazioni e farete le prime esperienze sull’argomento.

Il problema dell’imprinting però è che oltre una buona dose di informazioni, a seconda del momento storico in cui si fa, lascia anche parecchie cattive abitudini.

Vi faccio un esempio personale, io il mio imprinting sul DevOps l’ho avuto praticamente quando ho cominciato a lavorare, solo che ancora non si chiamava così, un po’ come quando ho cominciato a fare Le Rich Internet application con javascript asincrono (e poi l’hanno chiamato Ajax), oppure quando facevo le architetture basate sui servizi (e poi hanno chiamato la cosa SOA).

Dicevo…

Ho cominciato a nuotare nello stagno DevOps quando mi dovevo smazzare sia i problemi del Dev che quelli dell’Ops, crescendo professionalmente questa cosa mi ha “forgiato” nel carattere e mi ha fatto mantenere sempre una visione “end to end”, per cui ho cercato sempre di mantenere la vicinanza dei due mondi e di trasmettere questa cosa anche ai miei gruppi di lavoro, sia che fossero della parrocchia Dev sia che fossero di quella Ops.

Ciò ovviamente è bene, perché quando poi “è arrivata” la codifica metodologica di quello che facevo, mi ci sono ritrovato comodo comodo. Il problema però è che cominciando così presto ho preso l’abitudine allo smanettamento, al risolvermi i problemi da solo, bypassando spesso le comodità e le facility che ormai hanno gli strumenti moderni di gestione del Software.

La cosa si è tradotta, di recente, con il perdere mezza domenica a incaponirmi per cercare di far capire “da sotto” al servizio SaaS WordPress che ho sul Provider che vendeva solo libri su cui vive questo blog, quando sono passato da http a https (mi ha detto la mia SEO Officer di farlo, e non posso contraddirla perché è anche mia moglie), che la nuova url delle immagini doveva avere il nuovo prefisso e non il vecchio http, quando invece bastava cercare e attivare uno dei tanti plug-in nati a questo scopo, cosa che poi mi ha rubato solo 5 minuti di tempo.

Tutto questo per dire che l’idea generale di qualcuno che si avvicina al DevOps non può fermarsi (accomodarsi) a quella che ha sullo sviluppo software e sui sistemi quando ha cominciato, ma deve sempre tenere presente l’evoluzione continua a cui questi temi sono soggetti; deve quindi avere un approccio evolutivo, adeguando costantemente il proprio modo di pensare e operare al meglio che possa offrire il mercato tecno-metodologico in quel momento, senza inseguire mode, ma tenendo sempre presenti i valori base di cui abbiamo già parlato fino alla noia.

Questo è il senso di quel “Evolutionary Architect” che leggete accanto al mio nome nel profilo LinkedIn ed è quello che consiglio a tutti coloro che vogliono cominciare questo mestiere.

Legarsi a una tecnologia (o a un insieme di esse) rischia di rendervi rapidamente obsoleti, legarsi a dei buoni valori di base vi manterrà sempre “moderni” e vi consentirà di “annusare” il futuro prima degli altri.

Ovvero, come diceva Machiavelli:

“Far tesoro della conoscenza da me imparata con una lunga riflessione sugli avvenimenti moderni e una continua lezione da parte di quelli antichi”.

Alla prossima.