Por que os livros são tão predominantes na comunidade DevOps?

Vi vários blogs que sigo recomendando mais e mais livros ao longo do tempo.

Gosto de ler ficção e não tenho aversão a livros, mas onde um post de blog pode ser atualizado / reescrito quando a tecnologia se move nesses livros que normalmente são de ~ 20 a 30 libras.

Existe alguma qualidade específica nos títulos relacionados ao DevOps que está faltando no mundo on-line ou todos estão menos eu doidos?

Na maioria dos casos, os livros recomendados não são sobre tecnologia. Enquanto a tecnologia muda, os princípios fundamentais por trás das organizações, como pensamento sistêmico, liderança, senso comum, etc ... não mudam com tanta frequência.

Livros como The Goal e mesmo o The DevOps Handbook não mencionam muita tecnologia em suas páginas, mas sim maneiras de gerenciar o trabalho realizado por pessoas.

Muitos problemas estão relacionados à tecnologia, tópicos como microsserviços, arquitetura de sistemas em larga escala, infraestrutura como código, etc ... não se referem a uma ferramenta e / ou tecnologia específica, mas a um tópico de arquitetura. Um campo de conhecimento que as pessoas que constroem grandes sistemas precisam conhecer para construir o sistema corretamente. Esse conhecimento é raro e é ótimo que os livros sejam escritos sobre esses assuntos - apenas desconsidere as ferramentas mencionadas ou traduza em sua nova reencarnação.

Um dos melhores livros sobre criação de software de qualidade (imho) é Desenvolvimento, Princípios, Padrões e Práticas de Software Ágil . E embora a linguagem usada neste livro (Java) tenha evoluído bastante, os exemplos fornecidos no livro são atemporais e podem ser facilmente traduzidos para qualquer outro idioma de sua escolha.

Alguns dos problemas que o movimento DevOps tenta resolver estão envolvidos em maneiras comuns de gerenciar o trabalho em organizações que simplesmente não fazem sentido. Como Eliyahu Goldratt costumava dizer (autor de The Goal ) "O senso comum não é muito comum".

Esses livros ensinam princípios de pensar corretamente sobre problemas e relacionamentos humanos em um ambiente de sistema, para que todo o sistema seja aprimorado. As lições são antigas e, infelizmente, raramente existem pessoas que trabalham no campo que realmente as aprenderam.

Naturalmente, também existem autores que escreveram livros sobre essa e aquela ferramenta tecnológica fizz-bang que são novos e relevantes para o campo, como AWS ou Docker ou Jenkins ou o que quer e apenas querem aumentar suas vendas de livros ... mas eu tento excluir esses tipos de postagens de blog da minha resposta.

Isso é um sinal da crescente maturidade da engenharia de infraestrutura como campo ou profissão. Se você considerar alguma das formas mais tradicionais de engenharia, como mecânica, civil ou elétrica, a maior parte do conhecimento é em formato de livro em papel, é assim que é ensinado, os engenheiros praticantes consultam os livros de referência. Isso ocorre porque, quando os princípios subjacentes são entendidos e codificados, os detalhes da implementação são específicos apenas para um aplicativo ou instalação em particular. Você pode considerar qualquer artefato de engenharia - um arranha-céu ou ponte, um motor a jato, um porta-aviões. Extremamente sofisticado, exigindo grande habilidade de construção, mas construído usando princípios gerais que agora são entendidos, muda apenas ao longo de décadas e seria facilmente compreensível para um engenheiro de décadas atrás.

Tornando-o mais específico para o DevOps - realmente não importa se você implementa o gerenciamento de configurações com o CFEngine, Chef, Puppet ou qualquer outra coisa, os princípios do gerenciamento de configurações são bem compreendidos agora que podem ser anotados e aplicados a qualquer ferramenta real.