Este es un gran libro “definitivo” sobre el concepto de Infraestructura como Código (IaC). IaC es un conjunto de principios y patrones para administrar la infraestructura en la nube. Por lo general, soy escéptico con respecto a los libros que tienen nombres de mercado que suenan como SEO, pero este libro es una muy buena descripción (el autor menciona que muchas de estas ideas están dispersas en blogs, charlas, artículos o cabezas de personas, y su objetivo es unirlos a todos, y creo que hace un gran trabajo). Se centra más en principios generales e ideas que en herramientas, pero tiene algunos ejemplos ilustrativos.
El libro está dividido en tres secciones, Fundamentos, Patrones y Prácticas. Pasaré más tiempo resumiendo la Parte I, y en particular, el primer capítulo, ya que es allí donde se cubren los principios de alto nivel, para darle una visión general, pero si lo encuentra interesante, ¡realmente debería comprar el libro!
En la Parte I (Fundamentos) , Morris se enfoca en los principios centrales detrás de IaC. Se puede ver que IaC ha surgido del movimiento DevOps y del cambio a la nube y X-as-a-Service. Básicamente, el argumento es que la barrera de aprovisionamiento de nueva infraestructura se ha reducido tan rápidamente, pero los principios detrás de la administración de la infraestructura no se han mantenido. IaC es un enfoque para resolver estos problemas, abordando la automatización de la infraestructura utilizando prácticas del desarrollo de software. En otras palabras, la infraestructura debe tratarse como si fuera software y datos, aplicando principios como el control de versiones, las pruebas automatizadas y la integración y entrega continuas.
El Capítulo 1 comienza explorando algunos de los problemas que pueden ocurrir para las organizaciones que no aplican los principios adecuados. Algunos de estos problemas incluyen cosas como Server Sprawl (gran número de servidores que no están bien mantenidos), Configuration Drift (inconsistencias desconocidas en los servidores debido a arreglos y ajustes manuales) y Snowflake Servers (servidores “especiales” que no pueden ser fácilmente replicable) Las implicaciones son la infraestructura frágil y el miedo a la automatización, que se alimentan entre sí en un ciclo (la infraestructura frágil conduce al miedo a la automatización, lo que solo conduce a una infraestructura más frágil).
- Si estás atrapado en una isla y solo puedes leer un libro por el resto de tu vida, ¿cuál elegirías? ¿Por qué?
- ¿Qué libros debo leer para mejorar mi inteligencia?
- ¿Cuáles son los mejores libros sobre arquitectura naval?
- ¿Qué libro o serie de libros de Stephen King debería leer primero?
- ¿Cuál es el libro más satisfactorio que has leído?
Además, Morris presenta los principios básicos detrás de Infraestructura como código. En primer lugar, los sistemas deben ser fácilmente reproducibles. Segundo, los sistemas deben ser desechables (“los servidores deben ser como el ganado, no las mascotas”). Luego, deben ser consistentes (en particular, los sistemas que brindan un servicio similar deben ser casi idénticos). Además, cualquier acción llevada a cabo en la infraestructura debe ser fácil, barata y repetible para adaptarse a los diseños cambiantes.
La sección final del capítulo presenta prácticas de alto nivel para lograr estos principios. En primer lugar, IaC aboga por el uso de archivos de definición para definir la infraestructura y la configuración; de aquí proviene el nombre “Infraestructura como código”. Muchas de las otras prácticas solo se pueden habilitar a través de este uso declarativo de dichos archivos. Por ejemplo, estos archivos se auto documentan, aliviando la carga de mantener documentación separada. Además, esos archivos se pueden registrar en un sistema de control de versiones, que brinda beneficios adicionales como la trazabilidad, reversibilidad / reversiones, visibilidad y capacidad de acción (a su vez, la capacidad de acción puede permitir cosas como pruebas e implementación automatizadas). Finalmente, los cambios deben hacerse en pequeños incrementos en lugar de grandes lotes, y los servicios deben estar continuamente disponibles a través de los cambios.
Los cuatro capítulos restantes de la Parte I intentan dividir el panorama de las herramientas de infraestructura en varias áreas (aunque a menudo se solapan y algunas herramientas pueden proporcionar utilidad en más de un área). El Capítulo 2 discutió las Plataformas de Infraestructura Dinámica, o servicios que proporcionan cómputo, almacenamiento y / o redes. La infraestructura dinámica debe ser programable (en lugar de solo proporcionar una IU) y aprovisionarse en un método a pedido / de autoservicio (en lugar de requerir tickets y, por lo tanto, tiempo para cumplir). El capítulo también analiza diferentes tipos de plataformas de infraestructura dinámica (pública, privada, comunitaria y nubes de metal desnudo), y las compensaciones para elegir entre ellas (cosas como seguridad y legalidad, capacidad variable, costo y portabilidad).
El Capítulo 3 explica las herramientas de definición de infraestructura para administrar la infraestructura dinámica de manera coherente con los principios descritos en el capítulo 1. Por ejemplo, dichas herramientas deberían poder ejecutarse sin mensajes interactivos durante la ejecución, y deberían ser idempotentes. Una conclusión clave aquí es que hay herramientas que están diseñadas con los principios de IaC en mente (por ejemplo, Terraform, que utiliza archivos de configuración declarativos). Otras herramientas son, por defecto, más procesales, pero podrían usarse de manera IaC, solo requiere más disciplina.
El Capítulo 4 discutió las herramientas de configuración del servidor. Entonces, ¿cuál es la diferencia entre definir la infraestructura y configurarla? Para citar el libro: “Una herramienta de definición de infraestructura creará servidores pero no es responsable de lo que hay en el servidor mismo. Por lo tanto, la herramienta de definición declara que hay dos servidores web, pero no instala el software del servidor web o los archivos de configuración en ellos ”. Este último es el trabajo de las herramientas de configuración, como Ansible, Chef o Puppet. El capítulo analiza las compensaciones de dos enfoques que pueden tomar estas herramientas: pull (modelo de agente) versus push (modelo SSH). También hay una discusión sobre el enfoque del contenedor (Docker) para configurar tiempos de ejecución.
Finalmente, el Capítulo 5 incluye una gran discusión sobre las herramientas que son útiles en un entorno de infraestructura dinámica y las formas de elegir la herramienta adecuada. Esto incluye monitoreo (alertas, métricas, registro), herramientas de descubrimiento de servicios, administración de procesos distribuidos (también conocida como orquestación) e implementación.
La Parte II (Patrones) analiza las mejores prácticas y antipatrones para infraestructura en mucha más profundidad. El Capítulo 6 trata los patrones para el aprovisionamiento de servidores y, además, tiene algunas secciones interesantes sobre la “anatomía” y el “ciclo de vida” de un servidor típico. El Capítulo 7 analiza las plantillas e imágenes del servidor, y tiene una discusión interesante sobre las compensaciones entre los elementos de “horneado” en una plantilla y el aprovisionamiento en el momento de la creación del servidor. El Capítulo 8 discute formas de mantener los servidores actualizados y administrarlos para evitar inconsistencias, con algunos patrones interesantes como sincronización continua, servidores inmutables y servidores Phoenix. Finalmente, el Capítulo 9 cubre patrones más avanzados para reducir la complejidad al administrar configuraciones más grandes con varios tipos de infraestructura.
La sección final, Parte III (Prácticas) , aplica los principios y patrones a través de más técnicas prácticas. Por ejemplo, el Capítulo 10 discute algunas prácticas de ingeniería de software que se pueden aplicar a la infraestructura, como el uso de un sistema de control de versiones e implementación de integración y entrega continuas, el Capítulo 11 cubre estrategias de prueba y el Capítulo 12 integra ambos aprendizajes en un “Canal de Gestión de Cambio” o “Aprovisionamiento continuo”. El Capítulo 13 analiza los “flujos de trabajo”, lo que esencialmente significa tratar de automatizar todo y evitar cambios manuales o ad-hoc. También discute consejos sobre la organización de bases de código. El Capítulo 14 cubre el logro de la “continuidad”, que es básicamente un término general que el libro usa para la confiabilidad (por ejemplo, cambios de tiempo de inactividad cero), disponibilidad / consistencia de datos, recuperación y seguridad. Finalmente, el Capítulo 15 discute las técnicas de organización para implementar los principios del libro, como cómo pasar de una arquitectura más antigua, cómo medir la efectividad y cómo estructurar mejor los equipos y las responsabilidades.
Vale la pena señalar que la Parte III (aparte de los capítulos 14 y 15) me pareció demasiado “idealógica”. Las discusiones en el resto del libro presentaron principios o patrones con compensaciones, pero cuáles de esos funcionan como prácticas para un equipo en particular pueden variar. Y aunque Morris había intentado intencionalmente ser independiente de las herramientas, también significa que los capítulos tampoco proporcionan tanto valor práctico. Todavía son muy informativos, solo siento que si estuviera aplicando el resto del libro, podría tomar las prácticas en la última sección con un grano de sal.
De lo contrario, este fue un libro bastante impresionante, ya sea que esté construyendo, operando o utilizando infraestructura en la nube. Dado que también proviene de ThoughtWorks, muchas de las ideas aquí son consistentes con otras ideas y libros de ThoughtWorks sobre arquitectura, como Evolutionary Architecture y Building Microservices.