¿Por qué los libros son tan frecuentes en la comunidad DevOps?

He visto bastantes de los blogs que sigo recomendando más y más libros con el tiempo.

Disfruto leyendo ficción y no tengo aversión a los libros, pero cuando una publicación de blog puede actualizarse / reescribirse cuando la tecnología avanza en estos libros, que normalmente no cuestan entre 20 y 30 libras.

¿Existe una cualidad particular en los títulos relacionados con DevOps que falta en el mundo en línea o todos menos yo?

En la mayoría de los casos, los libros recomendados no son sobre tecnología. Si bien la tecnología cambia, los principios fundamentales detrás de las organizaciones, como el pensamiento sistémico, el liderazgo, el sentido común, etc., no cambian con tanta frecuencia.

Libros como The Goal e incluso The DevOps Handbook no mencionan mucha tecnología en sus páginas, sino formas de gestionar el trabajo que realizan las personas.

Muchos problemas están relacionados con la tecnología, temas como microservicios, arquitectura de sistemas a gran escala, infraestructura como código, etc., no se trata de una herramienta o tecnología específica, sino más bien de un tema arquitectónico. Un campo de conocimiento que las personas que construyen sistemas grandes necesitan conocer para construir el sistema correctamente. Este conocimiento es raro, y es genial que los libros estén escritos sobre estos temas, simplemente ignore las herramientas mencionadas o traduzca a su nueva reencarnación.

Uno de los mejores libros sobre la creación de software de calidad (en mi humilde opinión) es Desarrollo, principios, patrones y prácticas de software ágil . Y aunque el lenguaje utilizado en este libro (Java) se ha movido bastante, los ejemplos proporcionados en el libro son eternos y se pueden traducir fácilmente a cualquier otro idioma de elección.

Algunos de los problemas que el movimiento DevOps intenta resolver están relacionados con formas comunes en que el trabajo se gestiona en organizaciones que simplemente no tiene ningún sentido. Como a menudo decía Eliyahu Goldratt (autor de The Goal ) "El sentido común no es muy común".

Estos libros enseñan los principios de pensar correctamente sobre los problemas y las relaciones humanas en un entorno de sistema para mejorar todo el sistema. Las lecciones son viejas y, desafortunadamente, rara vez hay personas que trabajan en el campo que realmente las aprendieron.

Naturalmente, también hay autores que escribieron libros sobre tal y tal herramienta tecnológica que es nueva y relevante para el campo, como AWS o Docker o Jenkins o lo que sea y solo quieren impulsar sus ventas de libros ... pero intento excluir este tipo de publicaciones de blog de mi respuesta.

Esta es una señal de la creciente madurez de la ingeniería de infraestructura como campo o profesión. Si considera alguna de las formas más tradicionales de ingeniería, como mecánica, civil o eléctrica, la mayor parte del conocimiento es en forma de libro de papel, así es como se enseña, los ingenieros en ejercicio consultan libros de referencia. Esto se debe a que una vez que los principios subyacentes se entienden y codifican, los detalles de la implementación son específicos solo de una aplicación o instalación en particular. Puede considerar cualquier artefacto de ingeniería: un rascacielos o un puente, un motor a reacción, un portaaviones. Enormemente sofisticado, que requiere una gran habilidad para construir, pero construido utilizando principios generales que ahora se entienden, cambian solo a lo largo de décadas y serían fácilmente comprensibles para un ingeniero desde hace décadas.

Haciéndolo más específico de DevOps: realmente no importa si implementa la administración de configuración con CFEngine, Chef, Puppet o cualquier otra cosa, los principios de administración de configuración se comprenden lo suficiente ahora que pueden escribirse y aplicarse a cualquier herramienta real.