Pourquoi les livres sont-ils si répandus dans la communauté DevOps?

17

J'ai vu pas mal de blogs que je suis et qui recommandent de plus en plus de livres au fil du temps.

J'aime lire de la fiction et je n'ai aucune aversion pour les livres, mais où un article de blog peut être mis à jour / réécrit lorsque la technologie évolue sur ces livres qui sont normalement ~ 20-30 £.

Y a-t-il une qualité particulière aux titres liés à DevOps qui fait défaut dans le monde en ligne ou tout le monde sauf moi est fou?

culture

— Briansbum
source

1

Le sujet DevOps est hautement subjectif et fluide. Ce qui donne beaucoup plus de possibilités d'écriture de livres que d'autres domaines plus établis. Beaucoup de ces références sont de la publicité ordinaire, cela ne signifie pas nécessairement qu'elles sont vraiment des références à lire absolument dans le domaine (même si elles sont explicitement appelées comme ça).

— Dan Cornilescu

En général, vous ne savez pas si c'est de l'huile de serpent après l'avoir achetée.

— corsiKa

2

Les tâches DevOps commencent avant que les moniteurs soient allumés :-)

— mcalex

15

Dans la plupart des cas, les livres recommandés ne concernent pas la technologie. Alors que la technologie change, les principes fondamentaux des organisations comme la pensée systémique, le leadership, le bon sens, etc. ne changent pas aussi souvent.

Des livres comme The Goal et même The DevOps Handbook ne mentionnent pas beaucoup de technologie sur leurs pages mais plutôt des façons de gérer le travail effectué par les gens.

De nombreux problèmes sont liés à la technologie, des sujets tels que les microservices, l'architecture de systèmes à grande échelle, l'infrastructure en tant que code, etc ... ceux-ci ne parlent pas d'un outil et / ou d'une technologie spécifique mais plutôt d'un sujet architectural. Un domaine de connaissances que les personnes qui construisent de grands systèmes doivent connaître afin de construire le système correctement. Cette connaissance est rare et ses grands livres sont écrits sur ces sujets - il suffit de ne pas tenir compte des outils mentionnés ou de les traduire dans leur nouvelle réincarnation.

L'un des meilleurs livres sur la création de logiciels de qualité (imho) est le développement de logiciels agiles, les principes, les modèles et les pratiques . Et tandis que le langage utilisé dans ce livre (Java) a beaucoup évolué, les exemples fournis dans le livre sont intemporels et peuvent être facilement traduits dans n'importe quel autre langage de choix.

Certains des problèmes que le mouvement DevOps essaie de résoudre sont liés à des façons courantes de gérer le travail dans des organisations qui n'ont tout simplement aucun sens. Comme Eliyahu Goldratt l'a souvent dit (auteur de The Goal ) "Le bon sens n'est pas très courant".

Ces livres enseignent les principes d'une réflexion correcte sur les problèmes et les relations humaines dans un contexte de système afin que l'ensemble du système soit amélioré. Les leçons sont anciennes et, malheureusement, il n'y a que rarement des personnes qui travaillent dans le domaine qui les ont réellement apprises.

Naturellement, il y a aussi des auteurs qui ont écrit des livres sur tel ou tel outil technologique fizz-bang qui est nouveau et pertinent pour le domaine, comme AWS ou Docker ou Jenkins ou autre et je veux juste pousser leurs ventes de livres ... mais j'essaie et exclure ces types de billets de blog de ma réponse.

— Evgeny
source

Cette citation était à l'origine Voltaire, je n'ai jamais entendu parler de ce Goldratt

— Gaius

@Gaius Goldratt citait de nombreuses personnes intelligentes.

— Evgeny

4

C'est un signe de la maturité croissante de l'ingénierie des infrastructures en tant que domaine ou profession. Si vous considérez l'une des formes d'ingénierie les plus traditionnelles telles que la mécanique, le génie civil ou l'électricité, la majeure partie des connaissances est sous forme de livre papier, c'est ainsi qu'elle est enseignée, les ingénieurs praticiens consultent des livres de référence. En effet, une fois les principes sous-jacents compris et codifiés, les détails de mise en œuvre ne sont spécifiques qu'à une application ou une installation particulière. Vous pouvez considérer tout artefact d'ingénierie - un gratte-ciel ou un pont, un moteur à réaction, un porte-avions. Énormément sophistiqué, nécessitant une grande habileté à construire, mais construit en utilisant des principes généraux qui maintenant sont compris, ne changent qu'au fil des décennies et seraient facilement compréhensibles par un ingénieur d'il y a des décennies.

Rendre plus spécifique DevOps - peu importe si vous implémentez la gestion de la configuration avec CFEngine, Chef, Puppet ou toute autre chose, les principes de la gestion de la configuration sont suffisamment bien compris maintenant qu'ils peuvent être écrits et appliqués à n'importe quel outil réel.

— Gaius
source