La mayoría de las organizaciones han adoptado herramientas de automatización de infraestructuras de TI y plataformas de infraestructura dinámica tales como nubes privadas o públicas. Sin embargo, solo la tecnología no es suficiente para ayudar a que TI responda de manera rápida y confiable a las oportunidades y desafíos cambiantes. En el peor de los casos, puede llevar a una situación de "aprendiz de brujo", donde la capacidad de activar rápidamente una nueva infraestructura, conduce a una expansión de sistemas mal mantenidos.
La Infraestructura como Código es un enfoque para administrar la infraestructura que aprovecha las prácticas ágiles de ingeniería de software. Compañías como Netflix, Facebook y Etsy han sido pioneras en una nueva generación de principios y prácticas para la gestión del cambio en TI. Los equipos de TI que han adoptado estas ideas, descubren que no solo pueden realizar cambios con mucha más frecuencia que con antiguas formas de trabajo, sino que también pueden aumentar la confiabilidad, seguridad y calidad de sus servicios de TI.
Pero la habilidad de activar nuevas máquinas virtuales (VMs) en minutos requería mejorar la automatización de éste proceso. Las plantillas de imágenes de servidor y la clonación nos ayudó a superar ese bache. Pero luego, nos enfrentamos a un nuevo problema. Debido a que podíamos crear nuevas máquinas virtuales sin esfuerzo, asumiendo una capacidad general suficiente, nos encontramos con un portafolio de servidores cada vez mayor. La necesidad de mantener actualizados un número creciente y cambiante de servidores actualizados, evitó que las nuevas herramientas generen configuraciones a la deriva.
La esencia de la Infraestructura como Código es tratar la configuración de los sistemas de la misma manera en que se trata el código fuente del software. Los sistemas de gestión de código fuente, el desarrollo guiado por pruebas (TDD), la integración continua (CI), la refactorización y otras prácticas de XP son especialmente útiles para garantizar que los cambios en la infraestructura sean probados, repetibles y transparentes.
El problema es que algunos de estos conjuntos de herramientas están diseñados para soportar infraestructura como código. Sí, éstas automatizan las cosas. Una vez que utilizas la GUI para crear un template de un servidor, puedes crear instancias idénticas del contenido. Pero cuando regresas y haces cambios en la plantilla, no tienes un registro del cambio que se pueda rastrear y entender fácilmente. No puedes activar las pruebas automáticas para cada cambio utilizando herramientas de validación de múltiples proveedores, proyectos de código abierto y grupos internos.
En resumen, en lugar de utilizar una gestión de cambios continua e intensiva, te encuentras estancado con el manual de la vieja escuela sobre la gestión de cambios: “lo haríamos más a fondo si tuviéramos tiempo”.Resultados
La característica definitoria de nuestro movimiento más allá de la “Edad del Hierro” y de la “Edad de la nube” es que la infraestructura ahora puede tratarse como un software. Aprovechamos al máximo este cambio cuando llevamos también prácticas efectivas de desarrollo de software, y sacamos provecho del creciente ecosistema de herramientas diseñadas para apoyar el cambio.
Una copia anterior de este artículo originalmente apareció en el Blog de Kief’s.
Traducción realizada por: Gonzalo Martinez y Miguel Hernandez
La Infraestructura como Código es un enfoque para administrar la infraestructura que aprovecha las prácticas ágiles de ingeniería de software. Compañías como Netflix, Facebook y Etsy han sido pioneras en una nueva generación de principios y prácticas para la gestión del cambio en TI. Los equipos de TI que han adoptado estas ideas, descubren que no solo pueden realizar cambios con mucha más frecuencia que con antiguas formas de trabajo, sino que también pueden aumentar la confiabilidad, seguridad y calidad de sus servicios de TI.
De vuelta a la Edad del Hierro...
La Virtualización y Cloud (Infraestructura como Servicio, en particular) ha forzado la necesidad de automatización de algún tipo. En los viejos tiempos, en la "Edad de Hierro" de TI, el crecimiento de la infraestructura estaba limitada por el ciclo de compra de hardware. Ya que la llegada de un nuevo servidor tardaba semanas, había poca presión para instalarle un sistema operativo. Colocábamos un disco en el servidor y seguíamos una lista de verificación. Unos días más tarde estaba listo para usar.Pero la habilidad de activar nuevas máquinas virtuales (VMs) en minutos requería mejorar la automatización de éste proceso. Las plantillas de imágenes de servidor y la clonación nos ayudó a superar ese bache. Pero luego, nos enfrentamos a un nuevo problema. Debido a que podíamos crear nuevas máquinas virtuales sin esfuerzo, asumiendo una capacidad general suficiente, nos encontramos con un portafolio de servidores cada vez mayor. La necesidad de mantener actualizados un número creciente y cambiante de servidores actualizados, evitó que las nuevas herramientas generen configuraciones a la deriva.
Nace la Infraestructura como Código
CFengine, Puppet y Chef establecieron una nueva categoría de herramienta de automatización de infraestructura que fue rápidamente adoptada por organizaciones ágiles que aprovechaban al máximo la nube de IaaS a medida que ésta surgía. Estas organizaciones, cuya TI se construyó normalmente alrededor de la mentalidad de Agile y Lean, desarrollaron prácticas de "Infraestructura como Código" para administrar su infraestructura automatizada.La esencia de la Infraestructura como Código es tratar la configuración de los sistemas de la misma manera en que se trata el código fuente del software. Los sistemas de gestión de código fuente, el desarrollo guiado por pruebas (TDD), la integración continua (CI), la refactorización y otras prácticas de XP son especialmente útiles para garantizar que los cambios en la infraestructura sean probados, repetibles y transparentes.
Se unen los proveedores empresariales
A medida que organizaciones más tradicionales han adoptado la virtualización, generalmente en la infraestructura interna en lugar de nubes públicas, éstas han sentido la misma necesidad de automatización para administrar sus sistemas. Pero, aunque algunas han explorado los conjuntos de herramientas utilizados por los primeros usuarios, muchas recurren a los proveedores tradicionales de los llamados conjuntos de herramientas de gestión empresarial, quienes se han movido para adaptar y cambiar el nombre de su software para así detectar las últimas oleadas de la industria ("¡Ahora con DevOps!" )El problema es que algunos de estos conjuntos de herramientas están diseñados para soportar infraestructura como código. Sí, éstas automatizan las cosas. Una vez que utilizas la GUI para crear un template de un servidor, puedes crear instancias idénticas del contenido. Pero cuando regresas y haces cambios en la plantilla, no tienes un registro del cambio que se pueda rastrear y entender fácilmente. No puedes activar las pruebas automáticas para cada cambio utilizando herramientas de validación de múltiples proveedores, proyectos de código abierto y grupos internos.
En resumen, en lugar de utilizar una gestión de cambios continua e intensiva, te encuentras estancado con el manual de la vieja escuela sobre la gestión de cambios: “lo haríamos más a fondo si tuviéramos tiempo”.
Aquí está la diferencia
La automatización de la infraestructura hace posible realizar acciones repetidamente, en un gran número de nodos. La infraestructura como código utiliza técnicas, prácticas y herramientas de desarrollo de software para garantizar que esas acciones se pongan a prueba exhaustivamente antes de aplicarse a los sistemas críticos del negocio.Qué exigir de tus herramientas
Aquí hay algunas pautas para elegir las herramientas que administren la configuración que soporta la Infraestructura como Código:- Las definiciones que se usan para crear y actualizar las configuraciones del sistema deben ser externalizables en un formato que se pueda almacenar en sistemas de control de versiones disponibles como Git, Subversion o Perforce. Esto permite la adopción de una amplia variedad de herramientas para administrar, validar y probar el código fuente del software, en lugar de encerrarlo en un conjunto de herramientas de un solo proveedor. También otorga un historial de cada cambio, junto con quién lo hizo, (con suerte) el por qué y la capacidad para retroceder los cambios.
- Debería ser posible validar definiciones en varios niveles de granularidad, para que pueda aplicar una variación de la pirámide de prueba. Sintaxis rápida y validaciones del estilo de código, seguidos de la ejecución de unidades individuales de configuración, seguidas de la creación de instancias de máquinas virtuales que pueden validarse, etc. Esto ofrece los beneficios de una retroalimentación rápida y la correción de cambios, siendo la base para la integración continua y la construcción de un pipeline de entrega continua.
Resultados
La característica definitoria de nuestro movimiento más allá de la “Edad del Hierro” y de la “Edad de la nube” es que la infraestructura ahora puede tratarse como un software. Aprovechamos al máximo este cambio cuando llevamos también prácticas efectivas de desarrollo de software, y sacamos provecho del creciente ecosistema de herramientas diseñadas para apoyar el cambio.Una copia anterior de este artículo originalmente apareció en el Blog de Kief’s.
Traducción realizada por: Gonzalo Martinez y Miguel Hernandez
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.