È difficile cogliere l'essenza parlando di DevOps? Abbiamo raccolto per te analogie chiare, frasi incisive e consigli da esperti, che ti aiuteranno a capire il nocciolo della questione anche se non sei del settore. Alla fine, un bonus: il DevOps degli impiegati di Red Hat.
Il termine DevOps è emerso 10 anni fa ed è passato da hashtag su Twitter a un potente movimento culturale nel mondo IT, una vera filosofia che incoraggia gli sviluppatori a ottenere risultati più velocemente, sperimentare e andare avanti con iterazioni. DevOps è diventato indissolubilmente legato al concetto di trasformazione digitale. Ma come spesso accade con la terminologia IT, nel corso di un decennio DevOps ha accumulato numerose definizioni, interpretazioni e fraintendimenti.
Pertanto, riguardo a DevOps si sentono spesso domande del tipo: è la stessa cosa dell'agile? O è una metodologia particolare? O è semplicemente un altro sinonimo di 'collaborazione'?
DevOps comprende molteplici concetti (consegna continua, integrazione continua, automazione, ecc.), quindi isolare l'essenza può non essere semplice, soprattutto se sei appassionato dell'argomento. Tuttavia, questa abilità è molto utile, sia che tu stia cercando di comunicare le tue idee ai superiori, sia che tu stia spiegando il tuo lavoro a familiari o amici. Quindi, per ora lasciamo da parte le sfumature terminologiche di DevOps e concentriamoci sul quadro generale.
Cos'è DevOps: 6 definizioni e analogie
Abbiamo chiesto a esperti di spiegare l'essenza di DevOps in modo semplice e conciso, affinché il suo valore fosse comprensibile a lettori di qualsiasi livello tecnico. Al termine di questi colloqui, abbiamo selezionato le analogie più illuminate e le frasi contundenti che ti aiuteranno a costruire il tuo discorso su DevOps.
1. DevOps è un movimento culturale
«DevOps è un movimento culturale in cui entrambe le parti (sviluppatori software e specialisti IT) riconoscono che il software non porta valore reale finché non viene utilizzato da qualcuno: clienti, utenti, dipendenti, non importa, - afferma Eveline Oehrlich, analista senior presso l'Istituto DevOps. - Pertanto, entrambe le parti lavorano insieme per garantire una rapida e qualitativa consegna del software».
2. DevOps è ciò che conferisce potere agli sviluppatori
«DevOps consente agli sviluppatori di avere il controllo sulle applicazioni, gestendo la loro distribuzione dall'inizio alla fine».
«Di solito si parla di DevOps come di un modo per accelerare la consegna delle applicazioni in produzione attraverso la creazione e l'implementazione di processi automatizzati», afferma Jai Schniepp, direttore delle piattaforme DevOps della compagnia assicurativa Liberty Mutual. - «Ma per me è qualcosa di molto più fondamentale. DevOps consente agli sviluppatori di detenere il controllo sulle applicazioni o su determinate parti del software, gestendo la loro distribuzione dall'inizio alla fine. DevOps elimina la confusione sulla responsabilità e guida tutti i partecipanti del processo verso la creazione di un'infrastruttura automatizzata e gestita dagli sviluppatori».
3. DevOps è collaborazione nella creazione e nella consegna delle applicazioni
«In parole povere, DevOps è un approccio alla produzione e consegna del software in cui tutti lavorano insieme», osserva Gur Staff, presidente e responsabile del settore automazione del business digitale della società BMC.
4. DevOps è una catena produttiva
«Un'assemblaggio in catena è possibile solo se tutte le parti si adattano perfettamente tra loro».
«Paragonerei DevOps a una catena di montaggio di automobili», continua Gur Staff. «L'idea è che tutte le parti devono essere progettate e realizzate in modo che possano essere assemblate senza requisiti di adattamento individuale. Un'assemblaggio in catena è possibile solo se tutte le parti si adattano perfettamente. Coloro che progettano e costruiscono il motore devono pensare a come fissarlo al telaio. Chi realizza i freni deve considerare le ruote, e così via. Allo stesso modo deve essere anche con il software.
Uno sviluppatore che crea la logica aziendale o l'interfaccia utente deve considerare il database che memorizza le informazioni dei clienti, i sistemi di sicurezza per proteggere i dati degli utenti, e come tutto questo funzionerà quando il servizio inizierà a servire un'ampia, forse anche multimilionaria, base di utenti».
«Far sì che le persone collaborino e pensino alle parti del lavoro svolto da altri, piuttosto che concentrarsi esclusivamente sulle proprie attività, è il più grande ostacolo da superare. Se ci riesci, hai ottime possibilità di realizzare una trasformazione digitale», conclude Gur Staff.
5. DevOps è la giusta combinazione di persone, processi e automazione
Jane Grohl, CEO dell'Institute for DevOps, ha proposto un'ottima analogia per spiegare il DevOps. Secondo lei, "DevOps è come una ricetta culinaria che ha tre categorie principali di ingredienti: persone, processi e automazione. La maggior parte di questi ingredienti può essere presa da altri campi e fonti: Lean, Agile, SRE, CI/CD, ITIL, leadership, cultura, strumenti. Il segreto del DevOps, come per qualsiasi buona ricetta, è come bilanciare e mescolare correttamente questi ingredienti per aumentare la velocità e l'efficacia nella creazione e distribuzione delle applicazioni."
6. DevOps è quando i programmatori lavorano come una squadra di Formula 1
"La gara non è pianificata dal via al traguardo, ma piuttosto dal traguardo all'inizio."
"Parlando di cosa aspettarsi dalla iniziativa DevOps, faccio l'esempio di un team di corsa NASCAR o Formula 1", afferma Chris Short, Chief Marketing Officer delle piattaforme cloud di Red Hat e publisher della newsletter DevOps’ish. "Il leader di un tale team ha un solo obiettivo: ottenere il miglior risultato possibile in base alle risorse della squadra e alle sfide affrontate. La gara è pianificata non dal via al traguardo, ma viceversa, partendo dal traguardo. Prima si stabilisce un obiettivo ambizioso, poi si determinano i percorsi per raggiungerlo. Successivamente, questi vengono suddivisi in compiti e delegati ai membri del team."
"Per tutta la settimana prima della corsa, il team affina il pit stop. Si dedica ad allenamenti di forza e cardio per essere in forma durante il giorno faticoso della corsa. Lavora insieme per risolvere eventuali problemi che potrebbero sorgere durante la gara. Allo stesso modo, il team di sviluppo deve allenare le competenze per il rilascio frequente di nuove versioni. Con tali competenze e un sistema di sicurezza ben collaudato, il lancio di nuove versioni in produzione avviene anche più frequentemente. Nell'ambito di questa mentalità, la crescita della velocità significa crescita della sicurezza", afferma Short.
"Non si tratta di fare le 'cose giuste', aggiunge Short, ma di eliminare il maggior numero possibile di ostacoli tra voi e il risultato desiderato. Collaborate e adattatevi in base al feedback che ricevete in tempo reale. Siate pronti per le anomalie e lavorate per migliorare la qualità per ridurre al minimo il loro impatto nel raggiungere il vostro obiettivo. Questo è ciò che ci aspetta nel mondo del DevOps."
Come scalare il DevOps: 10 consigli dagli esperti
Simple DevOps e mass DevOps sono due cose completamente diverse. Vi mostreremo come superare le barriere per passare dal primo al secondo.
Per molte organizzazioni, il cammino verso il DevOps inizia in modo facile e piacevole. Nascono piccoli team appassionati, i vecchi processi vengono sostituiti da nuovi e i primi successi non tardano ad arrivare.
Purtroppo, questo è solo un falso splendore, un'illusione di progresso, come dice Ben Grinnell, Managing Director e Head of Digital Transformation della società di consulenza North Highland. Le prime vittorie possono certamente essere incoraggianti, ma non aiutano a raggiungere l'obiettivo finale, ovvero l'adozione su vasta scala del DevOps nell'organizzazione.
È facile vedere che si forma una cultura di divisione tra 'noi' e 'loro'.
"Spesso le organizzazioni avviano progetti pionieristici credendo che apriranno la strada al DevOps su vasta scala, senza riflettere se gli altri vorranno e saranno in grado di intraprendere questo percorso", spiega Ben Grinnell. "I team per realizzare tali progetti sono solitamente composti da 'estranei' fiduciosi che hanno già fatto qualcosa di simile in altri posti, ma sono nuovi nella vostra organizzazione. Allo stesso tempo, sono incoraggiati a infrangere e demolire le regole che rimangono vincolanti per tutti gli altri. È facile vedere che si forma una cultura di divisione tra 'noi' e 'loro', che ostacola il trasferimento di conoscenze e competenze."
"E questo problema culturale è solo una delle ragioni per cui il DevOps è difficile da scalare. I team DevOps affrontano un aumento delle complessità puramente tecniche, caratteristiche delle aziende in rapida evoluzione che hanno scommesso sulle tecnologie IT", afferma Steve Newman, fondatore e presidente della società Scalyr.
Nel mondo moderno, i servizi cambiano rapidamente non appena sorge la necessità. Implementare e lanciare nuove funzionalità è certamente positivo, ma coordinare questo processo e risolvere i problemi che sorgono è una vera sfida. Steve Newman sottolinea che nelle organizzazioni in rapida crescita, gli ingegneri delle squadre cross-funzionali lottano per mantenere la possibilità di monitorare i cambiamenti e gli effetti a cascata a livello di dipendenze. Inoltre, gli ingegneri non sono affatto contenti quando vengono privati di questa possibilità, rendendo loro più difficile comprendere la natura dei problemi emergenti.
Come si possono superare le difficoltà sopra descritte e passare a un'adozione su vasta scala di DevOps in una grande organizzazione? Gli esperti invitano a essere pazienti, anche se l'obiettivo finale è accelerare il ciclo di sviluppo del software e i processi aziendali.
1. Ricordate che i cambiamenti culturali richiedono tempo
Jayne Groll, CEO del DevOps Institute: «A mio avviso, l'espansione di DevOps dovrebbe avvenire in modo graduale e iterativo, proprio come lo sviluppo agile, e dovrebbe riguardare in egual misura la cultura. In Agile e DevOps, c'è un focus su piccole squadre. Ma man mano che il numero di queste squadre cresce e si integrano, vediamo sempre più persone che adottano nuovi metodi di lavoro, e di conseguenza, si verifica una trasformazione culturale su larga scala».
2. Dedicate abbastanza tempo alla pianificazione e alla scelta della piattaforma
Eran Kinsbruner, Chief Evangelist di Perfecto: «Per far funzionare la scalabilità, le squadre DevOps devono imparare inizialmente a integrare processi, strumenti e competenze tradizionali, e poi sviluppare lentamente ogni fase di DevOps e stabilizzarla. Tutto inizia con una pianificazione attenta delle storie utente e dei flussi di creazione valore, seguita dallo sviluppo software e dal controllo delle versioni usando sviluppo trunk-based o altri approcci più adatti al branching e al merging del codice».
«Subito dopo viene la fase di integrazione e testing, dove è necessaria una piattaforma scalabile per l'automazione. È qui che le squadre DevOps devono scegliere la piattaforma giusta, che sia adeguata alle loro competenze e agli obiettivi finali del progetto.
La fase successiva è il deployment nell'ambiente di produzione, completamente automatizzato tramite strumenti di orchestrazione e container. È importante avere ambienti virtualizzati in tutte le fasi di DevOps (simulatore dell'ambiente di produzione, ambiente di controllo qualità e, ovviamente, l'ambiente di produzione) e utilizzare sempre i dati più recenti per i test, in modo da ottenere riscontri pertinenti. L'analitica deve essere intelligente e capace di gestire big data con feedback rapidi e incisivi».
3. Liberate la responsabilità dal senso di colpa
Gordon Haff, evangelista di RedHat: «Creare un sistema e un'atmosfera che permettano e incoraggino esperimenti consente di realizzare quelli che noi chiamiamo insuccessi costruttivi nello sviluppo agile del software. Ciò non significa che nessuno sia più responsabile degli errori. In realtà, è diventato anche più semplice individuare il responsabile, poiché 'essere responsabili' non significa più 'essere il colpevole del fallimento'. La natura della responsabilità cambia qualitativamente in questo senso. Quattro fattori diventano estremamente importanti: la dimensione del fallimento, gli approcci, i processi produttivi e gli incentivi». (Per ulteriori dettagli su questi fattori, potete leggere l'articolo di Gordon Haff 'Lezioni di DevOps: 4 aspetti di esperimenti sani').
4. Spianate la strada
Ben Grinnell, managing director e leader della digital transformation di North Highland: «Per raggiungere la scalabilità, consiglio di avviare un programma di 'spianamento della strada' insieme ai progetti pionieristici. L'obiettivo di questo programma è rimuovere i detriti lasciati dai pionieri di DevOps, come le regole obsolete e affini, in modo che la strada da percorrere resti libera».
«Fornite supporto organizzativo e generate impulso attraverso comunicazioni che vadano ben oltre il gruppo di pionieri, celebrando ampiamente i successi dei nuovi metodi di lavoro. Formate le persone coinvolte nella prossima ondata di progetti DevOps, che si sentono ansiose perché stanno usando DevOps per la prima volta. E ricordate, queste persone sono molto diverse dai pionieri».
5. Rendete gli strumenti più democratici
Steve Newman, fondatore e presidente di Scalyr: "Non bisogna nascondere gli strumenti alle persone; devono essere relativamente facili da imparare per chiunque sia disposto a dedicare tempo. Se la possibilità di richiedere i log è riservata solo a tre persone 'certificate' per utilizzare uno strumento, avrete sempre al massimo tre persone in grado di affrontare il problema corrispondente, anche in una grande infrastruttura informatica. In altre parole, questo crea un collo di bottiglia che può avere gravi conseguenze (per il business)."
6. Create le condizioni ideali per il lavoro del team
Tom Clark, responsabile della piattaforma comune presso ITV: "Potete fare qualsiasi cosa, ma non tutto insieme. Pertanto, ponete obiettivi ambiziosi, cominciate in piccolo e avanzate con iterazioni rapide. Col tempo, guadagnerete una reputazione come team capace, così che anche altri vorranno adottare i vostri metodi. Non cercate di costruire un team ad alta performance; piuttosto, create condizioni ideali per il lavoro delle persone, e l'efficacia arriverà di conseguenza."
7. Non dimenticate la legge di Conway e le lavagne Kanban
Logan Daigle, direttore delle operations software e della strategia DevOps di CollabNetVersionOne: "È importante essere consapevoli delle implicazioni della legge di Conway. In sintesi, questa legge afferma che i prodotti che creiamo e i processi che utilizziamo, compreso DevOps, sono organizzati in modo simile alla nostra organizzazione."
"Se c'è una scarsa integrazione all'interno dell'organizzazione e la gestione passa da una mano all'altra durante la pianificazione, creazione e distribuzione del software, l'effetto della scalabilità sarà nullo o effimero. Se invece l'organizzazione forma team cross-funzionali attorno a prodotti finanziati orientati al mercato, le probabilità di successo aumentano drasticamente."
"Un altro aspetto importante della scalabilità è visualizzare su lavagne Kanban tutto il lavoro in corso (WIP, work in progress). Quando in un'organizzazione esiste uno spazio dove le persone possono vedere queste informazioni, stimola fortemente la collaborazione, il che ha un impatto positivo sulla scalabilità."
8. Cercate le cicatrici del passato
Manuel Pais, consulente DevOps e coautore del libro 'Team Topologies': "Portare le pratiche DevOps al di fuori di Dev e Ops e tentare di applicarle ad altre funzioni non è un approccio ottimale. Questo darà un certo effetto (ad esempio, attraverso l'automazione della gestione manuale), ma si possono ottenere risultati molto maggiori partendo dalla comprensione dei processi di delivery e feedback."
"Se ci sono cicatrici nel sistema IT dell'organizzazione – procedure e meccanismi di controllo implementati a seguito di eventi passati che hanno perso rilevanza (a causa di cambiamenti in prodotti, tecnologie o processi) – è fondamentale rimuoverle o correggerle, piuttosto che automatizzare processi inefficaci o non necessari."
9. Non create varianti di DevOps
Antony Edwards, direttore della produzione di Eggplant: "DevOps è un termine molto vago, quindi ogni team finisce per avere la sua versione di DevOps. E non c'è nulla di peggio che avere 20 varianti di DevOps in un'organizzazione, che non si integrano bene tra loro. Non si può permettere che ogni team di sviluppo abbia la propria interfaccia unica tra sviluppo e gestione del prodotto. Analogamente, i prodotti non devono avere aspettative uniche riguardo al feedback durante il trasferimento nel simulatore dell'ambiente di produzione. In caso contrario, non riuscirete mai a scalare DevOps."
10. Predicate il valore di DevOps per il business
Steve Newman, fondatore e presidente di Scalyr: "Lavorate per far riconoscere il valore di DevOps. Imparate a comunicare senza timore i benefici delle vostre attività. DevOps fa risparmiare tempo e denaro (basti pensare: meno downtime, tempi di ripristino più brevi), e i team DevOps dovrebbero costantemente sottolineare (e predicare) l'importanza di queste iniziative per il successo del business. In questo modo, potrete ampliare il numero di sostenitori e accrescere l'influenza di DevOps nell'organizzazione."
BONUS
Su Il nostro DevOps arriverà il 13 settembre – sì, Red Hat, come produttore di software, ha i suoi team e pratiche DevOps.
Il nostro ingegnere Mark Birger, che si occupa dello sviluppo di servizi di automazione interna per altri gruppi all'interno dell'organizzazione, racconterà in chiaro la sua storia – come il team DevOps di Red Hat ha migrato applicazioni da ambienti virtuali gestiti da Ansible a un formato container completo sulla piattaforma OpenShift.
Ma non è tutto:
Dopo che le organizzazioni hanno spostato i carichi di lavoro nei container, i metodi tradizionali di monitoraggio delle applicazioni potrebbero non funzionare più. Nella seconda relazione, spiegheremo la nostra motivazione a cambiare il modo di registrare e mostreremo il percorso che ci ha portato a metodi moderni di registrazione e monitoraggio.
Fonte: habr.com
