DevOps Engineer: attività e competenze

In quest’articolo parliamo di alcuni profili professionali nuovi, sempre più diffusi: i “DevOps”.

Una delle sfide importanti per le società di selezione specializzate nell’Information Technology è quella di rimanere sempre al passo con l’evoluzione tecnologica, per saper interpretare al meglio le necessità del cliente, spesso formulate da manager tecnici piuttosto che dai referenti delle risorse umane.

E vogliamo provare a spiegare chi sono in parole semplici, cercando di non deludere Einstein che diceva: “Se non lo sai spiegare in modo semplice, non l’hai capito abbastanza bene”.

Affronteremo la tematica in modo alquanto semplificato, senza entrare in dettagli troppo specifici. Non ce ne vogliano quindi gli specialisti del settore se trattiamo l’argomento in modo non proprio accademico.

Come funzionavano le cose prima?

Fino a qualche lustro fa, la realizzazione di un software ed il successivo rilascio agli utenti erano organizzati in fasi ben distinte, di seguito sintetizzate e semplificate, proprio per tener fede al nostro intento di essere semplici:

• Analisi. L’analista funzionale e poi l’analista tecnico si occupavano di progettare il software, partendo dai requisiti raccolti dal “business”, preoccupandosi di disegnare la struttura dei database, degli algoritmi e dell’interfaccia utente (flussi ed organizzazione delle schermate).
• Sviluppo. Un team di programmatori, spesso coadiuvati da un architetto informatico, si occupava di implementare quanto stabilito in fase di analisi, cercando di attenersi quanto più possibile alle “specifiche”.
• Test. Un team di “testers” si occupava di verificare la qualità del software, intercettando per tempo eventuali bugs o malfunzionamenti che non sarebbero stati per niente graditi dagli utenti in fase di utilizzo.
• Operations (oppure produzione oppure esercizio). Il software testato, ovvero un suo aggiornamento, veniva infine installato nei server di produzione da un team cosiddetto di “esercizio” o “operations”, per essere utilizzato dagli utenti finali. I server erano “fisici”, quindi prima di rilasciare un software occorreva anche acquistare i server necessari, con dispendio di tempo e denaro.

Queste fasi, tutte insieme, dall’idea iniziale alla sua realizzazione, prendono il nome di “ciclo di vita” del software.

Le fasi erano sequenziali e l’intero processo vedeva coinvolte molte risorse, talvolta decine tra analisti e sviluppatori. Un aggiornamento di un software era pensato in modo tale da comprendere molti requisiti e gli aggiornamenti erano abbastanza rari (intervalli nell’ordine di mesi o, nei casi migliori, settimane). Il processo garantiva un’ottima qualità finale, perché tutto era pensato e ben ragionato prima del passaggio in produzione.

Ma perché tutto ciò non andava bene??? Semplice, non era compatibile con la velocità richiesta dal mercato, soprattutto per le aziende che erogano servizi web.

Occorreva trovare un modo più efficace per ridurre i tempi di rilascio degli aggiornamenti, cercando un adeguato compromesso con la qualità finale del software.

Benvenuta DevOps!

Il signor Patrick Debois nel 2009 inizio a parlare, nei suoi illuminati workshops, di DevOps, parola composta dai termini “Development” (=Sviluppo) e “Operations” (=Esercizio o produzione).

Proprio così, una nuova metodologia che prevedeva una maggiore integrazione e collaborazione tra i diversi team coinvolti nei progetti di realizzazione software, tutti quelli che abbiamo menzionato prima (analisti, sviluppatori, tester, tecnici di esercizio, …), finalizzata ad accelerare i cicli di aggiornamento del software, garantendo comunque una qualità finale più che accettabile.

Le aziende che hanno adottato un modello organizzativo DevOps favoriscono moltissimo il dialogo tra i diversi team coinvolti nel ciclo di vita del software, anzi spesso si avvalgono di figure trasversali il cui compito è quello di facilitare i vari passaggi, ottimizzando tempi e risorse.

Ma, in pratica, in cosa consiste la metodologia devops?

DevOps è un modello organizzativo che mira ad integrare al meglio i team di sviluppo e di operations, automatizzando l’infrastruttura, i workflow e la misurazione delle performance dei sistemi.

Con l’obiettivo di accorciare il più possibile i tempi di rilascio delle modifiche software, i team DevOps adottano diverse strategie, tra le quali evidenziamo:

• Utilizzo della metodologia “agile” per lo sviluppo. Piuttosto che progettare sulla carta e poi realizzare il software, in cascata, si creano dei piccoli team che, in modo iterativo, raffinano delle versioni intermedie del software, consultandosi direttamente con i referenti di business.
• Suddividere una piattaforma software in tanti moduli indipendenti. In questo modo è possibile gestire il rilascio di una quota parte del software e non di tutto il sistema contemporaneamente, riducendo così il perimetro su cui si lavora. Si tratta delle cosiddette architetture a “microservizi”.
• Infrastruttura virtualizzata/cloud. L’offerta “cloud” sul mercato è aumentata a dismisura negli ultimi anni, e con essa le possibilità di rilasciare in produzione un determinato software. Possiamo, ad esempio:
  • creare un server “virtuale”, cioè ospitato su un server fisico del quale magari non conosciamo neanche le caratteristiche o, talvolta, la precisa ubicazione geografica
  • creare un intero insieme di server (un coseddetto “ambiente”) lanciando una serie di comandi (più comandi insieme formano uno “script”). E’ la tecnologia dei software defined data center
  • oppure, addirittura, impacchettare il software in porzioni di server che possono viaggiare da un ambiente ad un altro, senza preoccuparsi più del sistema operativo (esempi di tali tecnologie sono i “containers“, su tecnologie come Kubernetes/Docker)

Insomma, utilizzare al massimo le tecnologie ed ottimizzare le metodologie per permettere di accorciare il più possibile i tempi di rilascio, per arrivare sul mercato prima dei competitors o per soddisfare in tempi record una necessità di un cliente.

In una frase: diminuire il “time to market”.

Il regista

La velocità, però, è insidiosa e la fretta è nemica della qualità. Allora è bene incrementare il livello di coordinamento delle risorse impegnate in un contesto DevOps, magari attraverso figure specifiche, quali i DevOps Engineer, che agiscono come una sorta di controllore di volo, coordinando le molte modifiche software in fase di implementazione in modo tale che non accadano disastri, in piena sicurezza.

I profili

Spesso siamo ingaggiati per ricerche di personale da impiegare in organizzazioni DevOps. Prima di cercare le singole skill, è quindi bene capire qual è l’organizzazione nella quale la risorsa dovrà inserirsi e capire bene quale sarà il suo compito (sviluppo? operations? coordinamento? figura cross?).

Le figure che spesso i nostri clienti ci richiedono riguardano tutti gli ambiti: sviluppo, operations o coordinamento. E spesso siamo noi di EgoValeo a consigliare al meglio il tipo di profilo da inserire, confrontandoci con direttamente con le figure tecniche. E questo sappiamo farlo particolarmente bene!