Il fondatore e direttore di «Otomato Software», uno dei promotori e formatori della prima certificazione DevOps in Israele, Anton Weiss ha parlato lo scorso anno della teoria del caos e dei principali principi dell'ingegneria del caos, spiegando anche come dovrebbe essere strutturata l'ideale organizzazione DevOps del futuro.
Abbiamo preparato una versione testuale della presentazione.
Buongiorno!
DevOpsDays a Mosca per il secondo anno consecutivo, io sono di nuovo su questo palco, molti di voi sono di nuovo in questa sala. Cosa significa? Significa che il movimento DevOps in Russia sta crescendo, si moltiplica e soprattutto, significa che è arrivato il momento di parlare di cosa significhi DevOps nel 2018.
Alzate le mani quelli che pensano che nel 2018 DevOps sia già una professione? Ci sono. Ci sono ingegneri DevOps in sala, la cui descrizione del lavoro include ‘ingegnere DevOps’? Ci sono manager DevOps in sala? Non ci sono. Architetti DevOps? Nemmeno. Pochini. Davvero nessuno ha scritto di essere un ingegnere DevOps?
Quindi, la maggior parte di voi pensa che si tratti di un antipattern? Che una professione del genere non dovrebbe esistere? Possiamo pensare quello che vogliamo, ma mentre noi pensiamo, l'industria avanza solennemente sotto il suono delle sirene del DevOps.
Chi ha sentito parlare del nuovo tema chiamato DevDevOps? È una nuova metodologia che consente di garantire una collaborazione efficace tra sviluppatori e professionisti DevOps. In realtà non è così nuova. A giudicare da Twitter, se ne parla già da 4 anni. E l'interesse continua a crescere, quindi esiste un problema. Un problema che va risolto.
Siamo persone creative, non ci accontentiamo facilmente. Diciamo che DevOps è una parola non abbastanza esaustiva, manca di vari elementi interessanti. E ci dirigiamo nei nostri laboratori segreti per generare mutant curiosità: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logica ferrea, giusto? La nostra piattaforma di consegna non è funzionante, i nostri sistemi sono instabili e gli utenti sono insoddisfatti, non riusciamo a rilasciare il software in tempo e non rientriamo nel budget. Come risolveremo tutto questo? Inventeremo una nuova parola! Finirà con «Ops» e il problema sarà risolto.
Chiamo questo approccio — «Ops, e il problema è risolto».
Tutto ciò passa in secondo piano, se ricordiamo a noi stessi perché abbiamo inventato tutto questo. Abbiamo concepito DevOps per rendere la consegna del software e il nostro lavoro in questo processo il più fluida, indolore, efficace e, cosa più importante, piacevole possibile.
DevOps è nato dal dolore. E siamo stanchi di soffrire. Affinché tutto ciò si realizzi, ci basiamo su pratiche sempreverdi: collaborazione efficace, pratiche di flusso e, soprattutto, pensiero sistemico, perché senza di esso non esiste DevOps.
Che cos'è un sistema?
E dato che abbiamo parlato di pensiero sistemico, ricordiamo a noi stessi che cos'è un sistema.
Se sei un hacker rivoluzionario, allora per te il sistema è indiscutibilmente un male. È una nuvola che ti sovrasta e ti costringe a fare ciò che non vuoi fare.
Dal punto di vista del pensiero sistemico, un sistema è un tutto composto da parti. In questo senso, ognuno di noi è un sistema. Le organizzazioni in cui lavoriamo sono sistemi. E ciò che stiamo costruendo insieme si chiama proprio così: sistema.
Tutto ciò fa parte di un grande sistema sociotecnologico. Solo comprendendo come questo sistema sociotecnologico funzioni insieme, potremo davvero ottimizzare qualcosa.
Dal punto di vista del pensiero sistemico, un sistema ha diverse proprietà interessanti. In primo luogo, è composto da parti, il che significa che il suo comportamento dipende dal comportamento delle singole parti. Inoltre, tutte le sue parti sono interdipendenti. Pertanto, più parti ha un sistema, più difficile sarà comprenderne o prevederne il comportamento.
Dal punto di vista del comportamento, c'è un altro fatto interessante. Un sistema può fare qualcosa che nessuna delle sue singole parti può fare.
Come ha detto il dottor Russell Ackoff (uno dei fondatori del pensiero sistemico), è piuttosto facile dimostrarlo mediante un esperimento mentale. Per esempio, chi qui sa scrivere codice? Tante mani alzate e questo è normale, perché è uno dei requisiti fondamentali della nostra professione. Voi sapete scrivere, ma le vostre mani possono scrivere codice autonomamente? Ci sono persone che direbbero: «Non sono le mie mani a scrivere codice, ma il mio cervello». E il cervello può scrivere codice autonomamente? Probabilmente no.
Il cervello è una macchina straordinaria, e non sappiamo nemmeno il 10% di come funzioni, ma non può operare separatamente dal sistema che è il nostro corpo. E questo è facile da dimostrare: aprite la vostra scatola cranica, estraete il cervello e mettetelo davanti a un computer, lasciategli provare a scrivere qualcosa di semplice. «Hello, world» in Python, per esempio.
Se un sistema può fare qualcosa che nessuna delle sue parti può fare da sola, ciò significa che il suo comportamento non è definito dal comportamento delle sue parti. Ma da cosa è allora definito? È definito dalle interazioni tra queste parti. E quindi, più parti ci sono, più complesse sono le interazioni, più difficile è capire e prevedere il comportamento del sistema. E questo rende un tale sistema caotico, poiché qualsiasi, anche il più insignificante, cambiamento invisibile a occhio nudo in una qualsiasi delle parti del sistema può portare a risultati completamente imprevedibili.
Questa sensibilità alle condizioni iniziali è stata scoperta e studiata per la prima volta dal meteorologo americano Ed Lorenz. Successivamente è stata soprannominata 'effetto farfalla' e ha portato allo sviluppo di un movimento di pensiero scientifico chiamato 'teoria del caos'. Questa teoria è diventata uno dei principali spostamenti di paradigma della scienza del XX secolo.
Teoria del caos
Le persone che si occupano dello studio del caos si chiamano caosologi.
La vera ragione di questa relazione è che, lavorando con sistemi distribuiti complessi e grandi organizzazioni internazionali, a un certo punto mi sono reso conto che questo è chi sono. Sono un caosologo. È un modo astuto per dire: "Non capisco cosa stia succedendo qui e non so cosa fare al riguardo."
Penso che molti di voi si sentano così spesso, quindi anche voi siete caosologi. Vi invito a unirvi alla gilda dei caosologi. I sistemi che noi, cari colleghi caosologi, esploreremo, si chiamano "sistemi adattivi complessi."
Cosa si intende per adattività? L'adattività significa che il comportamento individuale e collettivo delle parti in un sistema adattivo cambia e si auto-organizza in risposta a eventi o sequenze di micro-eventi nel sistema. In altre parole, il sistema si adatta ai cambiamenti attraverso l'auto-organizzazione. E questa capacità di auto-organizzazione si basa sulla cooperazione volontaria, completamente decentralizzata, di agenti autonomi e liberi.
Un'altra interessante caratteristica di tali sistemi è che sono liberamente scalabili. Questo è sicuramente un aspetto di interesse per noi come ingegneri della caoticità. Dunque, se affermiamo che il comportamento di un sistema complesso è definito dall'interazione delle sue parti, cosa dovrebbe interessarci? L'interazione.
Ci sono anche altre due conclusioni interessanti.
In primo luogo, capiamo che non è possibile semplificare un sistema complesso riducendo la complessità delle sue parti. In secondo luogo, l'unico modo per semplificare un sistema complesso è semplificare le interazioni tra le sue parti.
Come interagiamo? Noi tutti siamo parti di un grande sistema informativo chiamato società umana. Interagiamo attraverso una lingua comune, se ne abbiamo una, se la troviamo.
Ma il linguaggio di per sé è un sistema adattivo complesso. Pertanto, per interagire in modo più efficace e semplice, è necessario stabilire dei protocolli. Cioè, una sequenza di simboli e azioni che renda lo scambio di informazioni tra noi più semplice, più prevedibile e più comprensibile.
Voglio dire che le tendenze verso la complessità, l'adattabilità, la decentralizzazione e il caos si possono osservare ovunque. Sia nei sistemi che stiamo costruendo, sia in quelli di cui facciamo parte.
E per non essere vago, diamo un'occhiata a come cambiano i sistemi che stiamo creando insieme.
Aspettavate questa parola, lo capisco. Siamo a una conferenza DevOps, e oggi questa parola verrà pronunciata circa centomila volte e poi ci apparirà in sogno.
I microservizi sono la prima architettura software emersa come reazione alle pratiche DevOps, concepita per rendere i nostri sistemi più flessibili, più scalabili e garantire una consegna continua. Come lo fa? Riducendo il numero di servizi, limitando i confini dei problemi che questi servizi gestiscono e accorciando i tempi di consegna. Cioè, riduciamo e semplifichiamo le parti del sistema, aumentando il loro numero; di conseguenza, la complessità delle interazioni tra queste parti aumenta, e si presentano nuove sfide che dobbiamo affrontare.
I microservizi non sono la fine, in realtà, sono già un po' superati, perché sta arrivando Serverless. Tutti i server sono andati in fumo, non ci sono più server, né sistemi operativi, solo codice eseguibile puro. Configurazioni separate, stati separati, tutto gestito da eventi. Bellezza, pulizia, silenzio, nessun evento, niente accade, tutto è in ordine.
Dove sta la complessità? La complessità, ovviamente, risiede nelle interazioni. Quanto può fare una singola funzione da sola? Come interagisce con altre funzioni? Code di messaggi, database, bilanciatori di carico. Come ricreare un evento quando si verifica un guasto? Molte domande e poche risposte.
Microservizi e Serverless sono tutto ciò che noi, informatici hipster, chiamiamo Cloud Native. Riguarda tutto il cloud. Ma in realtà, anche il cloud è limitato nella sua scalabilità. Siamo abituati a pensarlo come un sistema distribuito. Ma dove si trovano i server dei fornitori di cloud? Nei data center. Quindi abbiamo a che fare con un modello distribuito, ma in qualche modo centralizzato e molto limitato.
Oggi comprendiamo che l'internet delle cose non è solo una frase d'effetto: secondo le previsioni più modeste, nei prossimi cinque-dieci anni saremo circondati da miliardi di dispositivi connessi a internet. Una quantità enorme di dati, utili e non, verrà raccolta nel cloud e distribuita da esso.
Il cloud non ce la fa più, quindi parliamo sempre di più di ciò che viene definito "edge computing". Oppure mi piace il meraviglioso termine "fog computing". Quest'ultimo racchiude un’aura di romanticismo e mistero.
Calcolo nebbioso. Si parla di nuvole come di agglomerati centralizzati di acqua, vapore, ghiaccio e rocce. Mentre la nebbia è composta da goccioline d'acqua disperse attorno a noi nell'atmosfera.
Nella paradigma nebbiosa, gran parte del lavoro viene svolta autonomamente da queste goccioline o in collaborazione con altre goccioline. Si rivolgono al cloud soltanto quando è davvero necessario.
In altre parole, si tratta di decentralizzazione e autonomia, e come molti di voi già comprendono, non si può parlare di decentralizzazione senza menzionare la blockchain.
Ci sono quelli che credono, ed è chi ha investito in criptovalute. Ci sono quelli che ci credono, ma sono spaventati, come me, per esempio. E poi ci sono quelli che non credono. Ci sono diversi modi di vederla. C'è tecnologia, c'è una nuova cosa misteriosa, ci sono problemi. Come ogni nuova tecnologia, solleva più domande di quante ne risolva.
L'hype attorno alla blockchain è comprensibile. Anche se si ignora la febbre dell'oro, la tecnologia in sé porta straordinarie promesse per un futuro luminoso: più libertà, più autonomia, fiducia globale distribuita. Cosa si può desiderare di più?
Di conseguenza, sempre più ingegneri in tutto il mondo iniziano a sviluppare applicazioni decentralizzate. E questa è una forza dalla quale non si può semplicemente distogliere lo sguardo dicendo: «Ah, la blockchain è solo un database distribuito mal implementato». O come amano dire gli scettici: «Non ci sono applicazioni reali per la blockchain». Se ci si riflette, 150 anni fa dicevano la stessa cosa sull'elettricità. E in parte avevano ragione, perché ciò che oggi l'elettricità rende possibile, nel XIX secolo era completamente irrealizzabile.
A proposito, chi sa che logo c'è sullo schermo? È Hyperledger. Questo progetto è sviluppato sotto l'egida della Linux Foundation e comprende un insieme di tecnologie blockchain. È davvero la forza della nostra comunità open source.
Ingegneria del caos
Quindi, il sistema che stiamo sviluppando diventa sempre più complesso, sempre più caotico, sempre più adattivo. Netflix è stata pioniera nei sistemi a microservizi. Sono stati tra i primi a capirlo e hanno sviluppato un insieme di strumenti chiamato Simian Army, il più noto dei quali è . Ha definito quello che è diventato noto come .
A proposito, durante la preparazione del documento abbiamo persino tradotto questo testo in russo, quindi potete visitare il , leggete, commentate, criticatelo.
In breve, i principi dell'ingegneria del caos affermano quanto segue. I sistemi distribuiti complessi sono, per loro natura, imprevedibili, e contengono fondamentalmente degli errori. Gli errori sono inevitabili, il che significa che dobbiamo accettare questi errori e lavorare con questi sistemi in modo completamente diverso.
Dobbiamo cercare di inserire noi stessi questi errori nei nostri sistemi di produzione, per testare la nostra adattabilità, la capacità di auto-organizzazione e di sopravvivenza.
E questo cambia tutto. Non solo il modo in cui mettiamo in produzione il sistema, ma anche come li sviluppiamo e testiamo. Non esiste un processo di stabilizzazione o di congelamento del codice; al contrario, c'è un processo continuo di destabilizzazione. Cerchiamo di danneggiare il sistema e vedere se riesce a sopravvivere.
Protocolli di Integrazione di Sistemi Distribuiti
Di conseguenza, ciò richiede che anche i nostri sistemi si adattino. Per diventare più resilienti, hanno bisogno di nuovi protocolli di interazione tra le loro parti. In modo che queste parti possano accordarsi e giungere a una qualche forma di auto-organizzazione. E sorgono nuovi strumenti, nuovi protocolli, che chiamo "protocolli di interazione dei sistemi distribuiti".
Di cosa sto parlando? Innanzitutto, del progetto . Un tentativo di creare un protocollo comune per il tracciamento distribuito, uno strumento assolutamente indispensabile per il debug di sistemi distribuiti complessi.
Successivamente — . Diciamo che non possiamo prevedere cosa accadrà al sistema, il che significa che dobbiamo aumentare la sua observability, ovvero la sua capacità di essere osservato. OpenTracing appartiene alla famiglia di strumenti che forniscono visibilità sui nostri sistemi. Ma abbiamo bisogno della visibilità per determinare se il sistema si comporta come ci aspettiamo o meno. Come possiamo definire il comportamento atteso? Attraverso la definizione di una certa politica, di un insieme di regole. Il progetto Open Policy Agent si occupa di definire questo insieme di regole su un ampio spettro: dall'accesso al posizionamento delle risorse.
Come abbiamo detto, i nostri sistemi sono sempre più eventi-driven. Serverless è un ottimo esempio di sistemi guidati dagli eventi. Per poter trasmettere eventi tra i sistemi e tracciarli, abbiamo bisogno di un linguaggio comune, di un protocollo comune su come parliamo di eventi e come ce li scambiamo. Questo è l'obiettivo del progetto chiamato .
Un flusso incessante di cambiamenti, che travolge i nostri sistemi destabilizzandoli, è un flusso continuo di artefatti software. Per supportare questo costante flusso di cambiamenti, abbiamo bisogno di un protocollo comune attraverso il quale possiamo discutere cosa sia un artefatto software, come viene verificato e quale validazione ha superato. Questo è il compito del progetto chiamato . Cioè, un protocollo comune di metadati degli artefatti software.
E, infine, se vogliamo che i nostri sistemi siano completamente autonomi, adattabili e si auto-organizzino, dobbiamo consentire loro il diritto all'autoidentificazione. Il progetto chiamato si occupa proprio di questo. È anche un progetto sotto l'egida della Cloud Native Computing Foundation.
Tutti questi progetti sono giovani, hanno bisogno del nostro amore, della nostra convalida. Sono tutti codici aperti, il nostro testing, la nostra implementazione. Ci mostrano quale direzione sta prendendo la tecnologia.
Ma DevOps non è mai stato prima di tutto una questione di tecnologia, è sempre stata una questione di collaborazione tra le persone. E, di conseguenza, se vogliamo che i sistemi che sviluppiamo cambino, dobbiamo cambiare noi stessi. In realtà, stiamo già cambiando, non abbiamo particolarmente scelta.
C'è un meraviglioso libro della scrittrice britannica Rachel Botsman, in cui parla dell'evoluzione della fiducia nel corso della storia umana. Dice che inizialmente, nelle società primitive, la fiducia era locale, cioè ci fidavamo solo di coloro che conoscevamo personalmente.
Poi c'è stato un periodo molto lungo — un'epoca oscura, in cui la fiducia era centralizzata, quando abbiamo cominciato a fidarci di persone che non conoscevamo basandoci sul fatto che appartenevamo a uno stesso ente sociale o statale.
Ed ecco cosa vediamo nel nostro mondo moderno: la fiducia diventa sempre più distribuita e decentralizzata, ed è fondata sulla libertà dei flussi informativi, sulla disponibilità delle informazioni.
Se ci pensi, la disponibilità che rende possibile questa fiducia è ciò che stiamo attuando. Questo significa che deve cambiare sia il modo in cui collaboriamo che il modo in cui operiamo, poiché le organizzazioni IT centralizzate e gerarchiche del passato smettono di funzionare. Iniziano a estinguersi.
Fondamenti delle organizzazioni DevOps
L'ideale dell'organizzazione DevOps del futuro è un sistema decentralizzato e adattivo, composto da team autonomi, ognuno dei quali è formato da individui autonomi. Questi team sono sparsi in tutto il mondo e collaborano efficacemente tra loro attraverso la comunicazione asincrona e con protocolli di scambio informazioni altamente trasparenti. Molto bello, vero? Un futuro molto affascinante.
Naturalmente, tutto ciò è impossibile senza cambiamenti culturali. Dobbiamo avere leadership trasformazionale, responsabilità personale, e motivazione interna.
Questa è la base delle organizzazioni DevOps: trasparenza delle informazioni, comunicazioni asincrone, leadership trasformazionale, decentralizzazione.
Burnout
I sistemi di cui facciamo parte, e quelli che costruiamo, diventano sempre più caotici, e per noi, esseri umani, è difficile affrontare questa realtà, è difficile rinunciare all'illusione del controllo. Cerchiamo di continuarne il controllo, e questo spesso porta a un esaurimento. Lo dico per esperienza personale, anch'io ho subito questo, anch'io sono un invalidato dagli imprevisti in produzione.
L'esaurimento si verifica quando tentiamo di controllare ciò che per sua natura non può essere controllato. Quando siamo esauriti, tutto perde significato, perché perdiamo il desiderio di fare qualcosa di nuovo, ci mettiamo in una posizione difensiva e iniziamo a proteggere ciò che abbiamo.
La professione ingegneristica, come mi piace spesso ricordare, è prima di tutto una professione creativa. Se perdiamo la voglia di creare, ci riduciamo in cenere, diventiamo fuligine. Le persone si esauriscono, intere organizzazioni si esauriscono.
A mio avviso, solo accettando il potere creativo del caos, solo costruendo una collaborazione secondo i suoi principi — è questo che ci aiuterà a non perdere ciò che di buono c'è nella nostra professione.
Ciò che vi auguro è di amare il vostro lavoro e ciò che facciamo. Questo mondo è alimentato dalle informazioni, e abbiamo l'onore di nutrirlo. Dunque, esploriamo il caos, diventiamo dei chaosologi, portiamo valore e creiamo qualcosa di nuovo. E i problemi, come abbiamo già stabilito, sono inevitabili. Quando si presenteranno, diremo semplicemente «Ops!», e il problema sarà risolto.
Cosa c'è oltre Chaos Monkey?
In realtà, tutti questi strumenti sono così nuovi. Anche Netflix ha costruito strumenti per le proprie esigenze. Costruite strumenti per voi stessi. Leggete i principi dell'ingegneria del caos e seguiteli, invece di cercare altri strumenti già costruiti da qualcun altro.
Cercate di capire come i vostri sistemi si rompono, cominciate a romperli e osservate come resistono agli impatti. Questo è il primo passo. Gli strumenti possono essere ricercati. Ci sono vari progetti disponibili.
Non ho ben capito quando hai parlato del fatto che non si deve semplificare un sistema semplificando i suoi componenti, per poi passare subito ai microservizi, che invece semplificano il sistema rendendo più semplici i componenti e complicando le interazioni. Questi sono, in sostanza, due parti in contraddizione tra loro.
Esattamente, i microservizi sono un tema molto controverso. In realtà, semplificare le parti aumenta la flessibilità. Cosa ci offrono i microservizi? Ci offrono flessibilità e velocità, ma di certo non ci danno semplicità. Aumentano la complessità.
Quindi, nella filosofia del DevOps, i microservizi non sono poi così vantaggiosi?
Ogni vantaggio ha il suo rovescio. C'è un vantaggio: aumenta la flessibilità, ci permette di apportare modifiche più rapidamente, ma aumenta la complessità e, di conseguenza, la fragilità dell'intero sistema.
Dove si pone maggiore enfasi: sulla semplificazione delle interazioni o sulla semplificazione delle parti?
L'accento è indubbiamente sulla semplificazione delle interazioni, perché se guardiamo a come lavoriamo, dobbiamo concentrarci principalmente sulla semplificazione delle interazioni piuttosto che sul lavoro di ciascuno di noi singolarmente. Perché semplificare il lavoro significa trasformarci in robot. Questo funziona bene in McDonald's, dove hai istruzioni precise: metti qui l'hamburger, poi versa sopra la salsa. Nella nostra attività creativa, invece, non funziona affatto.
È vero che tutto ciò che hai raccontato vive in un mondo senza concorrenza, dove il caos è così gentile e non ci sono contraddizioni all'interno di questo caos, nessuno vuole mangiare o uccidere nessuno? Come dovrebbero convivere concorrenza e DevOps?
Beh, dipende da quale concorrenza stiamo parlando. Quella sul posto di lavoro o quella tra le aziende?
Riguardo alla concorrenza dei servizi, che esistono poiché i servizi non sono solo diverse aziende. Stiamo creando un nuovo tipo di ambiente informativo, e nessun ambiente può esistere senza concorrenza. La concorrenza è ovunque.
Prendiamo Netflix come modello di riferimento. Perché l'hanno creato? Perché avevano bisogno di essere competitivi. Questa flessibilità e velocità sono proprio i requisiti competitivi, e portano caos nei nostri sistemi. Il caos non è qualcosa che facciamo coscientemente perché lo desideriamo, ma è ciò che accade perché il mondo lo richiede. Dobbiamo semplicemente adattarci. E il caos è proprio il risultato della concorrenza.
Questo significa che il caos è l'assenza di obiettivi, giusto? O sono quegli obiettivi che non vogliamo vedere? Noi siamo nel nostro mondo e non comprendiamo gli obiettivi degli altri. La concorrenza, in realtà, si basa sul fatto che abbiamo obiettivi chiari e sappiamo dove arriveremo in ogni momento successivo. Questa, dal mio punto di vista, è l'essenza del DevOps.
È un altro punto di vista sulla questione. Penso che il nostro obiettivo comune sia uno: sopravvivere e farlo con
il massimo piacere. E l'obiettivo competitivo di qualsiasi organizzazione è lo stesso. La sopravvivenza avviene spesso in una lotta competitiva, non possiamo farci nulla.
Quest'anno la conferenza si terrà il 7 dicembre al «Tecnopoli». Fino all'11 novembre accettiamo proposte per le relazioni. se volete partecipare come relatori.
Le registrazioni per i partecipanti sono aperte, il biglietto costa 7000 rubli. Unisciti a noi!
Fonte: habr.com
