Oggi parliamo di un tema ancora “giovane” nell’ambito della nostra metodologia di Sviluppo & Deploy preferita e che è soggetto a tutti i problemi della “nomenclatura” corretta di una professione informatica “cutting hedge” (avete presente?), a cui si aggiunge spesso una parziale comprensione dei concetti base della metodologia stessa.
Se preferite il video alla carta stampata, trovate il mio seminario sul tema qui, altrimenti…
Parliamo dei
Mestieri del DevOps
Essendo in territorio ad alto rischio “fuffologico” e non avendo la pretesa di conoscere tutti i nuovi modi di chiamare figure professionali che, in parte, hanno già qualche anno, attribuirò a tali professionalità un nome che mi sembra ragionevolmente accettato e diffuso, spiegandone il significato che vi attribuisco e lasciando a chi legge il compito di ri-mapparlo con quello che gli sembra più calzante.
Ovviamente se mi segnalate in tanti un errore o un’omissione evidente, sarà mia cura provvedere alla correzione.
L’elenco è ordinato secondo un grado crescente di “tecnologicità”, cominciamo dall’alto della “catena alimentare” organizzativa per arrivare a coloro che operano fisicamente sui sistemi per far girare il fumo del DevOps, cercando di tradurre in pratica quello che i “pensatori” in cima alla piramide hanno ipotizzato, aggiungendo anche alcune figure (non tutte) normalmente già presenti in un team applicativo, ma “aumentate” da una corretta mentalità DevOps.
Ovviamente, per coloro che volessero seguire la strada professionale del DevOps, valgono le considerazioni sulla cultura e sull’atteggiamento mentale già espresse.
DevOps Evangelist
Chi è: Il DevOps Evangelist è tipicamente un consulente direzionale, che ha una lunga e concreta esperienza di progetti di sviluppo software su varie tecnologie e una buona conoscenza/esperienza delle problematiche legate all’esercizio delle applicazioni. Si tiene aggiornato sulle nuove tendenze tecnologiche, sia di sviluppo che di operation, per capire come si possano integrare nella “big picture DevOps” dell’azienda. Deve avere una visione d’insieme sia del percorso End to End della messa in produzione di un’applicazione che di tutto ciò che è necessario per mantenerne il funzionamento efficace. Deve conoscere i processi dell’azienda e capire come questi debbano essere modificati per accogliere al meglio la metodologia, senza renderli eccessivamente “spiazzanti” per il personale dell’azienda stessa. Deve essere un buon comunicatore e riuscire a far percepire il valore aggiunto del cambio di paradigma prima che questo venga implementato, rendendo al contempo evidenti i costi e gli ostacoli da affrontare per la corretta adozione nell’ambito aziendale.
Deve essere in grado di realizzare un vero e proprio cambio culturale nell’organizzazione aziendale, può essere un consulente esterno, tipicamente coinvolto nella fase di analisi e startup del DevOps in un’organizzazione, o una figura interna all’azienda, che ha “preso a cuore” il problema della comunicazione inter-gruppi e della velocità di “messa a terra” delle applicazioni e ha i mezzi metodologici e di competenza per provare a risolverlo.
E’ la persona che da l’imprinting del DevOps in un’azienda, l’idea di base che da la forma al tutto e che rimarrà, nel bene e nel male, fino al successivo “ciclo metodologico”.
A chi o cosa serve: A quelle aziende che approcciano per la prima volta al DevOps o devono rifondare le proprie software factory ed i propri gruppi di esercizio per migliorarne l’efficacia e ridurre i tempi di messa in produzione delle applicazioni.
DevOps Architect
Chi è: Il DevOps Architect è colui che “disegna” e cuce addosso all’environment aziendale il lifecycle di un’applicazione (vi ricordate la figura?), secondo la metodologia DevOps. Si preoccupa di “stare al passo” con gli strumenti ed i tool che implementano il DevOps, senza innamorarsi di una soluzione ma , selezionando quelli più adeguati ad aumentare l’efficacia dei processi, definiti e disegnati insieme all’Evangelist.
Deve necessariamente avere un’ottima conoscenza delle Architetture Software, per supportare i responsabili di sviluppo nella corretta progettazione delle applicazioni nei nuovi ambienti ad “alta volatilità e scalabilità” sul cloud, in modo da identificare i corretti pattern di supporto e monitoraggio della fase di esercizio delle applicazioni stesse, pattern che dovrà poi essere in grado di trasferire ai gruppi di operation.
A chi o cosa serve: Alle aziende che hanno la necessità di rivedere (e manutenere) il ciclo di vita delle applicazioni in ottica DevOps, rinnovando o adeguando il parco applicativo a supporto della produzione del software. In particolare può essere necessario a quelle aziende che applicano (correttamente) paradigmi architetturali diversi a seconda della tipologia delle applicazioni realizzate, con stream di produzione differenti che devono essere mantenuti contemporaneamente “in linea” con strumenti e processi agili ed efficaci.
DevOps Engineer
Chi è: E’ realmente il “meccanico del DevOps”, colui che fisicamente mette in linea “le pensate” delle figure precedenti sugli strumenti selezionati, configurandoli e mantenendoli in efficienza e operando in continuous improvement in termini di funzionalità e sicurezza. E’ colui che garantisce che tutto il lavoro fatto dai team di sviluppo e operation venga agevolato (e non ostacolato) dagli strumenti a supporto. E’ il custode dei sistemi che “aiutano i sistemi”.
A chi o cosa serve: E’ una figura necessaria alle organizzazioni che vogliono assicurarsi che il controllo sui sistemi a supporto venga effettuato “a prescindere” dal carico di lavoro e dalla pianificazione del personale di operation, dedicandovi quindi personale specifico.
Full Stack Developer
Chi è: E’ lo sviluppatore che ha la reale visione End to End di un’applicazione, capace di progettarne e realizzarne ogni sua componente architetturale, dal Database fino all’interfaccia utente, e che si preoccupa “by design” delle implicazioni e dei possibili problemi di funzionamento in esercizio di ogni singola componente. Lavora con l’obiettivo di creare un prodotto, non di partecipare ad un progetto, tenendo sempre conto delle implicazioni di carico, efficienza e qualità del codice sviluppato, senza adagiarsi sulla “potenza di fuoco” che i sistemi attuali possono garantire. Anche lui si tiene sempre aggiornato, per sfruttare le nuove features e i miglioramenti disponibili nelle nuove release delle tecnologie e dei linguaggi di adozione.
A chi o cosa serve: La vera domanda da porsi è: a chi non servirebbe uno così?
Application Reliability Engineer
Chi è: E’ il custode dei sistemi, colui che ha ben chiaro in mente che la Reliability è l’unica caratteristica realmente importante, la persona che capisce più di ogni altra che non importa quante features possa avere il proprio prodotto:
“se il sito è giù, la gente va altrove”.
Deve essere in grado di recepire le indicazioni di funzionamento dell’applicazione da parte dello sviluppo, mediarle con le esigenze di corretta gestione dei propri sistemi e “portare a casa” un altro giorno senza azzerare il contatore degli incidenti. Deve comprendere come sfruttare le nuove capability di scaling e distribuzione dell’applicazione del cloud “lasciando fare” ai sistemi preposti ma mantenendo sempre il controllo e la vigilanza attiva su quelli che possono sembrare problemi minori. Deve avere l’autorevolezza necessaria a “fermare gli sviluppi” quando l’Error budget va sotto soglia e deve invece riuscire a “cavalcare l’onda” del continuous delivery, senza vederlo come un’affronto personale, quando invece ci sono le condizioni per farlo.
A chi o cosa serve: Sicuramente serve a Google, visto che se si ha il dubbio che internet sia giù è la prima cosa che si prova (ergo Google è costretta ad avere SLA migliori di internet stessa), ma ritengo che qualsiasi azienda che si ponga l’obiettivo di mantenere alta l’immagine di efficienza delle proprie applicazioni debba averne uno.
Lascio per ultima la prima figura che è stata individuata in letteratura quando si è cominciato a parlare di DevOps, il…
DevOps Officer
Chi è: Il DevOps Officer è, semplicemente, colui che riesce a far parlare tra loro (senza litigare) Sviluppatori e Sistemisti. Ne ho già ampiamente accennato quando ho parlato di Leadership del DevOps, in questa sede voglio solo ricordare che il perfetto DevOps Officer è colui che “fa un piano di scale invece che mandare una email”, che ha perfettamente chiaro che Sviluppatori e Sistemisti, per loro natura, parlano due linguaggi diversi ed è quindi necessario uno sforzo di adattamento di entrambe le “specie”, possibilmente con qualche contaminazione reciproca, per permetterne l’intesa. E’ una persona che non “fa il Tecnico” ma sa di esserlo, e molto bravo anche, la cui competenza viene riconosciuta e vista come un supporto e non come un’ingerenza.
A chi o cosa serve: E’ il cuore di un’organizzazione che “innesta” il DevOps in modo non nativo ma vuole cominciare al far fluire le informazioni e far parlare in modo costruttivo i gruppi di lavoro, avvicinandoli progressivamente al nuovo modo di lavorare come un’unica squadra.
Un’ultima nota a margine….
La numerosità delle professionalità DevOps presente in un’azienda è direttamente proporzionale alle dimensioni e alla struttura organizzativa interna dell’azienda stessa, quindi non è infrequente che alcune delle figure professionali appena descritte possano “collidere” su una stessa persona nelle realtà più piccole, così come è probabile che la figura del DevOps Officer sia presente (leggi necessaria) in quelle realtà che provengono da modalità lavorative più tradizionali, che si trovino, con l’avvento delle nuove tecnologie, a dover fare i conti con un’accelerazione della delivery e con il solito problema della cattiva comunicazione tra i gruppi.
Alla prossima.