“Un gran poder conlleva una gran responsabilidad”. – Franklin D. Roosevelt… y el tío Ben, en Spiderman.
El concepto de Infraestructura como Código va más allá de definir la infraestructura desde archivos de configuraciones; implica también implementar buenas prácticas de desarrollo de software, tales como: versionamiento, pruebas unitarias y de integración, sistemas auto documentados, entre otros. Incluso, sugiere preferir siempre cambios pequeños, tal y como lo recomiendan las metodologías ágiles. Pero, ¿Por qué? ¿Por qué no simplemente escribir la definiciones de infraestructura? ¿Qué beneficio nos trae el hecho de implementar buenas prácticas? ¿Acaso no es solo crear infraestructura y… ya?.
Independientemente de cómo creemos la infraestructura, no debemos perder de vista que tenemos que mantener los sistemas siempre disponibles. Cuando desarrollamos software, previo a poner las aplicaciones disponibles al usuario final, nos aseguramos que todo funcione correctamente para garantizar que las aplicaciones en producción estén siempre disponibles: agregamos a nuestro código pruebas unitarias, creamos ambientes de pruebas donde desplegamos nuestras aplicaciones para correr pruebas de integración y de funcionalidad. Sin embargo, la infraestructura es lo que soporta estas aplicaciones; por lo tanto, aunque las aplicaciones funcionen correctamente, si alguna pieza de infraestructura no tiene los requerimientos necesarios o falla, la aplicación no estará disponible. Es por esto que es importante tratar la infraestructura como tratamos a las aplicaciones. Es aquí donde cobra sentido el aprovechar todas las buenas prácticas del desarrollo de software para crear infraestructura.
Todos los proveedores de nube, independientemente si es privada o pública, nos proveen una interfaz que puede ser visual o a través de la línea de comandos; desde esta interfaz podemos crear nuestra infraestructura y hacer pruebas o chequeos manuales para garantizar que tenga las especificaciones requeridas por la aplicación, las cuales pueden ser de capacidad de cómputo o de configuraciones. El problema es que esto no escala. ¿Qué pasa si queremos repetir esta infraestructura? ¿Qué pasa si tenemos que hacer un cambio?.
En realidad, con este enfoque, no existe una fuente de verdad desde la cual nosotros podamos definir ya sea declarativamente o imperativamente lo que estamos creando, mientras que si tenemos nuestra infraestructura como Código, tenemos un fuente de verdad, la cual podemos repetir n veces. Además, es posible utilizar un control de versiones, en primer lugar para garantizar que esta fuente de verdad persista y sobre todo para tener visibilidad y trazabilidad de nuestra infraestructura a través del tiempo. Esto nos da la habilidad de crear sistemas con infraestructura consistente, también nos permite crear infraestructura desechable porque sabemos que desde nuestros archivos de definición la podemos reproducir fácilmente. Pero aún hay mas: según el libro Infrastructure as Code de Kief Morris, “la infraestructura como código es un enfoque para la automatización de infraestructura” que se basa en las prácticas del desarrollo de software como lo he mencionado previamente. Tener nuestra infraestructura definida en código y versionada nos permite fácilmente ejecutar pruebas de forma automatizada desde servidores de Integración Continua o Despliegue continuo ( CI/CD por sus siglas en inglés) y, si los resultados de estas pruebas son satisfactorios, crear la infraestructura sin intervención humana.
Sabemos que las pruebas son parte fundamental para garantizar que las aplicaciones y ahora también la infraestructura cumpla con los requerimientos necesarios, pero cuando hablamos de automatización esto cobra más relevancia. Recordemos que cuando hablamos de automatización estamos anulando la intervención humana; por lo tanto, los set de pruebas que ejecutemos tienen que ser lo más completo y explícitos posibles. Debemos probar desde la creación hasta la configuración de la infraestructura. La mayoría de herramientas para definir infraestructura como código cuentan con frameworks que permiten escribir estas pruebas.
Regularmente las herramientas en el mercado para implementar Infraestructura como código son DSL (Declarative Scripting Languages) por lo que es más sencillo de aprender que un lenguaje de propósito general. Además existen herramientas para diferentes enfoques como:
- Definición de infraestructura
- Crear plantillas de servidores
- Configuración de servidores
- Ejecución de comandos de forma remota.
¿Qué estás esperando? Si quieres empezar a implementar este enfoque, te dejo una guía de consideraciones para ir por el camino correcto.
- Definir qué enfoque deseas utilizar
Es posible utilizar más de un enfoque, puesto a que todo depende de que tanto quieras automatizar. Puedes empezar, por ejemplo, creando plantillas de servidores, luego definir infraestructura a partir de las plantillas y por último utilizar una herramienta para configurar los servidores. Es decir, provisionar la infraestructura con las dependencias y paquetes necesarios para una aplicación en específico. - Seleccionar las herramientas adecuadas
Hay dos factores muy importantes a tomar en cuenta en la selección de una herramienta. La primera es la calidad de la documentación y la segunda es la comunidad. Estos factores son importantes porque son los que te sacarán de apuros cuando te encuentres en un problema. Ambos son factores genéricos que aplican para cualquier herramienta. Adicional a eso debes asegurarte que las herramientas tengan soporte para el o los proveedores de nube en los que tengas definida tu infraestructura. - Definir un plan de pruebas
Es importante que definas todos los aspectos que deseas probar de tu infraestructura, de tal forma que la cobertura de pruebas dentro del código sea lo más alta posible. - Garantizar la seguridad en el almacenamiento y transmisión de datos
Regularmente estas herramientas se conectan a los proveedores de nube a través de internet y muchas veces se maneja información sensible como claves de acceso o contraseñas por lo que es importante tomar en cuenta la seguridad cuando implementes este tipo de herramientas.
¡Que comience el juego!
¿Has escuchado de DevOps? Supongo que sí, es un tema muy popular en estos días. Básicamente es una Cultura que dicta varios principios en pro de un solo objetivo: Hacer que la entrega de software sea mucho más eficiente. Uno de sus principios básicos es la automatización. Definitivamente implementar Infraestructura como Código es algo fundamental dentro de la cultura DevOps. Además de que nos permite crear flujos de entrega continua de infraestructura, nos garantiza la consistencia de los servidores. Es de conocimiento público que los servidores suelen ser piezas muy frágiles y muchas veces hacen fallar a las aplicaciones, lo que ha genera conflicto entre las personas de Operaciones de TI y los desarrolladores, lo cual a su vez hace más grande el silo entre ambos equipos. Sin embargo, como he mencionado anteriormente, implementar Infraestructura como Código nos permite crear infraestructura repetible, desechable y consistente. Este es un punto clave para las personas de Operaciones de TI ya que genera confianza a los desarrolladores. Así, ambos equipos colaboran de una mejor manera para la entrega de software al usuario final. Y una entrega impecable, como vimos previamente, es el objetivo primordial de DevOps.
No esperes más… ¡A codificar tu infraestructura!
2 Comments
Yolanda es muy interesante lo que explicas.
Yo soy de Operaciones desde hace años y se de las diferencias entre los desarrolladores de Aplicaciones (Dev) y sus “buenos” amigos de Infraestructura.
Mas, tu das por supuesto en tu disertación que en el ambiente (corporativo) las “aplicaciones” están bien diseñadas y bien escritas, que (por omisión y contraste) el tema a resolver es el la Infraestructura. ¿Pero realmente es todos los casos las cosas son así?
Hace poco un Usuario me preguntaba: “si se pierde mi información en la nube *de Azure Microsoft se hace responsable?.
¿Qué responderle?? ¿Si hay brechas de seguridad (en la App) ?, si no se actualiza?, si tiene fallas y lo único que hace es responsabilizar a sus colegas de Operaciones?
Tal vez llegó el momento que también en el desarrollo de aplicaciones se piense en una automatización suponga se consideren los fallos en las malas prácticas de (¿algunos?) desarrolladores
Concuerdo completamente contigo, la calidad en el software se debería buscar tanto en el código que escribimos para las aplicaciones como para el código que escribimos para infraestructura, Mi punto va mas orientado a que todas esas buenas practicas del desarrollo de software que actualmente hace mas énfasis en código para aplicaciones (se implementen o no, hay muy buenas practicas y principios), son completamente validas cuando escribimos código para infraestructura.