Perché i libri sono così diffusi nella comunità DevOps?

Ho visto alcuni dei blog che seguo raccomandando sempre più libri nel tempo.

Mi piace leggere la narrativa e non ho avversione per i libri, ma dove un blogpost può essere aggiornato / riscritto quando la tecnologia si sposta su questi libri che normalmente non sono ~ £ 20-30.

C'è una qualità particolare nei titoli relativi a DevOps che manca nel mondo online o sono tutti tranne me pazzi?

Nella maggior parte dei casi, i libri consigliati non riguardano la tecnologia. Mentre la tecnologia cambia, i principi fondamentali alla base di organizzazioni come il pensiero di sistema, la leadership, il buon senso, ecc ... non cambiano altrettanto spesso.

Libri come The Goal e persino The DevOps Handbook non menzionano molta tecnologia sulle loro pagine ma piuttosto modi per gestire il lavoro svolto dalle persone.

Molti problemi sono legati alla tecnologia, argomenti come microservizi, architettura di sistemi su larga scala, infrastruttura come codice, ecc ... questi non parlano di uno strumento e / o tecnologia specifici ma piuttosto di un argomento architettonico. Un campo di conoscenza che le persone che costruiscono sistemi di grandi dimensioni devono conoscere per costruire correttamente il sistema. Questa conoscenza è rara ed è grandioso che i libri siano scritti su questi argomenti: basta ignorare gli strumenti menzionati o tradurli nella loro nuova reincarnazione.

Uno dei libri migliori sulla creazione di software di qualità (imho) è Agile Software Development, Principles, Patterns and Practices . E mentre il linguaggio usato in questo libro (Java) si è spostato abbastanza, gli esempi forniti nel libro sono senza tempo e possono essere facilmente tradotti in qualsiasi altra lingua preferita.

Alcuni dei problemi che il movimento DevOps cerca di risolvere sono legati a modi comuni in cui il lavoro è gestito in organizzazioni che non hanno alcun senso. Come diceva spesso Eliyahu Goldratt (autore di The Goal ) "Il senso comune non è molto comune".

Questi libri insegnano i principi del pensare correttamente ai problemi e alle relazioni umane in un'impostazione del sistema in modo da migliorare l'intero sistema. Le lezioni sono vecchie e, sfortunatamente, solo raramente ci sono persone che lavorano sul campo che le hanno effettivamente imparate.

Naturalmente, ci sono anche autori che hanno scritto libri su tali e tali strumenti tecnologici frizzanti che sono nuovi e rilevanti per il campo, come AWS o Docker o Jenkins o qualsiasi altra cosa e vogliono solo spingere le loro vendite di libri ... ma provo e escludo questo tipo di post dal blog dalla mia risposta.

Questo è un segno della crescente maturità dell'ingegneria delle infrastrutture come campo o professione. Se si considera una delle forme più tradizionali di ingegneria come meccanica, civile o elettrica, la maggior parte della conoscenza è la forma del libro di carta, cioè come viene insegnata, gli ingegneri praticanti consultano i libri di consultazione. Questo perché una volta compresi e codificati i principi sottostanti, i dettagli dell'implementazione sono specifici solo per una particolare applicazione o installazione. Puoi prendere in considerazione qualsiasi artefatto ingegneristico: un grattacielo o un ponte, un motore a reazione, una portaerei. Enormemente sofisticato, che richiede una grande abilità per costruire, ma costruito usando principi generali che ora sono compresi, cambiano solo nel corso di decenni e sarebbero facilmente comprensibili per un ingegnere decenni fa.

Rendendolo più specifico per DevOps: non importa davvero se si implementa la gestione della configurazione con CFEngine, Chef, Puppet o qualsiasi altra cosa, i principi della gestione della configurazione sono ben compresi ora che possono essere scritti e applicati a qualsiasi strumento reale.