O que é Infra as Code

Primero de todo, ¿sabes qué es Infra as Code?

Bueno, el uso de la computación, de hecho, se ha vuelto más popular cada año. Cada vez más empresas utilizan la nube para alojar los más diversos tipos de aplicaciones. Seguramente ya debes haber escuchado hablar de DevOps y SRE, áreas que se complementan y se comunican, y entre las muchas tareas que un equipo así puede tener está el mantenimiento de un ambiente en la nube.

Ahora, piensa en cuánto tiempo se sobrecarga al equipo responsable de cuidar los recursos en la nube.

Cada vez que se inicia un nuevo proyecto, el equipo necesita: definir los recursos, definir los parámetros de cada recurso, crear todos los recursos y replicar los recursos para N ambientes. Si algo sale mal en el camino, el trabajo es mayor. Es necesario eliminar el recurso y rehacerlo. Lo mismo es válido durante el desarrollo donde nuevos recursos pueden ser necesarios.

En principio, el proceso de creación y mantenimiento de una infraestructura puede ser muy doloroso si se hace de forma totalmente manual. Basándose en esto, surgió un nuevo concepto para automatizar esta tarea y traer algunos beneficios.

Este concepto se llama Infrastructure as Code (IaC).

¿Qué es Infrastructure as Code (IaC) al fin y al cabo?

Infra as Code utiliza un lenguaje de alto nivel (generalmente siguiendo el estándar .json o .yaml) para describir las características de cada recurso que queremos crear en nuestra nube. Estos archivos suelen llamarse templates.

Notar el cambio: en lugar de crear la infraestructura de forma totalmente manual, ahora tienes un script informando cuáles son los recursos y parámetros necesarios para crear ese ambiente.

La parte interesante es que, como ahora tenemos la información en un archivo, el mismo puede ser versionado en un repositorio git por ejemplo, permitiendo algunas visiones que antes no eran posibles: historial de cambios de esa infraestructura y posibilidad de asignar un grupo de personas para revisar los cambios sin tener que seguir un proceso manual.

**¿Qué otras ventajas proporciona Infrastructure as Code (IaC)?**

Estandarización de ambientes y parametrización

¿Recuerdas que antes, en un proceso manual, era necesario repetir todos los pasos para N ambientes de esa aplicación que fueran a ser creados?

Llevando esta configuración a un script, es posible parametrizarlo de manera que, al cambiar algunas entradas, sea posible replicar ambientes de forma sencilla.

Por ejemplo, imagina que necesitas crear un ambiente de desarrollo y uno de producción. Puedes utilizar el mismo script y cambiar algunos parámetros como la cantidad de procesadores del servidor para atender la especificidad de cada ambiente.

La diversión se vuelve aún más interesante con la posibilidad de utilizar condiciones para la creación de recursos. ¿Necesitas crear un recurso adicional si es en producción? No hay problema: basta con colocar una condición para crear ese recurso solo si el parámetro de ambiente es producción.

Configuración de reglas

¿Necesitas evitar que tu equipo cree ciertos tipos de recursos? ¡Está bien!

Con Infra as Code es posible colocar reglas de validación automática en el ambiente, ya sea a través de pipelines o la propia capacidad de la herramienta que estás usando. De forma automática, tu template puede ser validado para que siga los estándares del proyecto.

Historial y versionado

Como ya mencionamos, la utilización de Infra as Code permite versionar los archivos utilizando una herramienta como git, permitiendo mantener un historial de cambios de ese template.

Es posible localizar la fecha y hora de cuando un determinado template fue modificado, lo que puede ayudar mucho en troubleshooting cuando los recursos provisionados no actúan de la forma esperada. ¿Por qué antes funcionaba y ahora no? ¿Qué cambió en la infraestructura de ese recurso? Ahora con Infra as Code es posible tener pistas y visibilidad de los cambios de los recursos.

Agilidad en el proceso

Así como un desarrollador puede reutilizar código en su aplicación, lo mismo se puede hacer con scripts.

Una vez que desarrollas scripts para algún tipo de recurso, puedes reutilizar el código y agilizar la creación de nuevos entornos utilizando scripts creados anteriormente.

**Entendí el concepto. ¿Pero qué herramientas permiten el uso de Infra as Code?**

Vamos a conocer un poco sobre las herramientas más utilizadas:

Terraform: Terraform es una de las herramientas más populares en Infra as Code precisamente por ser agnóstica de nube. ¿Qué significa eso? Que el template creado por terraform puede ser utilizado para crear entornos tanto en AWS como en Google u otros proveedores que Terraform soporte. Este formato es interesante porque tu aplicación no queda “vendor locked”, es decir, no queda atada al proveedor de nube.

Herramientas de los proveedores de nube:

Estas tres herramientas son los servicios propios de cada uno de los proveedores para aprovisionar los recursos en sus nubes. La ventaja de utilizarlos es que, al ser servicios nativos, pueden integrarse fácilmente a otros servicios del proveedor de nube.

Ansible

Ansible es la herramienta de Red Hat y tiene enfoque en orquestación y automatización de deploys de múltiples máquinas y entornos complejos. También es posible automatizar la propia configuración de las máquinas como instalación de paquetes y actualizaciones de software.

Puppet y Chef

Puppet y Chef son dos herramientas similares, con un enfoque mayor en configuración del sistema. Con ambas herramientas puedes automatizar procesos de configuración, mantenimiento y actualización de servidores utilizando Infra as Code.

O sea, independientemente de la herramienta, tu equipo ganará agilidad y productividad al automatizar tareas que antes eran manuales.

Impacto de Infra as Code en el mercado

Utilizar Infra as Code va de acuerdo con temas que la Gartner lista como tendencias.

Las aplicaciones Cloud Native, es decir, que nacieron en la nube, son cada vez más comunes hoy en día y aceleran el proceso de creación de MVPs y Go To Market. Infra as Code agiliza la creación de recursos nativos en la nube haciendo aún más productivo el desarrollo del producto, con enfoque total en la creación de la aplicación.

Hyperautomation también es una tendencia donde las empresas buscan automatizar la mayor cantidad de procesos en TI posible. Infra as Code es una de las herramientas que puede auxiliar en este proceso.

La cultura de Infra as Code ya forma parte de la cultura de Zappts, donde los proyectos Cloud Native con infraestructura creada por nosotros siempre contemplan la utilización de templates de infraestructura. De esta forma, aprovechando el beneficio de reutilización de scripts, Zappts mantiene un repositorio público con templates en Cloud Formation. En este repositorio encontramos diversos patrones de template utilizables.

Además, el repositorio también cuenta con una documentación muy buena explicando cómo utilizar algunos ejemplos e incluso algunas propiedades específicas de Cloud Formation. Consulta el repositorio: https://github.com/zappts/zappts_cfn_templates.

Un ejemplo: Cloud Formation

Cloud Formation es una de las herramientas más populares de Infra as Code, como ya mencionamos.

Mucho por el éxito del proveedor de nube detrás de él, AWS.

Entonces, vamos a entender mejor cómo funciona Infra as Code en la práctica aprendiendo algunos conceptos de Cloud Formation.

Estructura de Cloud Formation:

Un documento de Cloud Formation puede estar estructurado en .yaml o .json. En este ejemplo veremos una estructura en .yaml.

En principio, Cloud Formation tiene su estructura dividida en:

Encabezado

Indica la versión del formato que estás usando y también una descripción general del template.

Cloud Formation permite la aplicación de transformaciones: es decir, es posible cambiar la sintaxis de Cloud Formation mediante el uso de macros. Este concepto es más avanzado y no se tratará aquí, sin embargo, es importante saber que una de las transformaciones más utilizadas es la del Serverless Framework, que simplifica la sintaxe de algunos recursos Serverless.

Si aún no conoces el concepto de Serverless, puedes saber más revisando nuestro artículo.

Parameters

Los parameters, como el nombre sugiere, son los parámetros para definir las características de los recursos de ese template.

Por ejemplo, podemos definir por parámetro la capacidad de procesamiento de una máquina descrita en un template.

De esta forma, tenemos la información de la capacidad de procesamiento necesaria en el momento de deploy del template.

Conditions

Utilizamos esta propiedad para definir condiciones de creación de determinados recursos o qué valor utilizar para las propiedades del recurso. Por lo tanto, es posible combinar conditions y utilizar AND y OR para condiciones más complejas.

Un ejemplo muy interesante es: activar la copia de seguridad automática de una tabla solo si el ambiente es producción. Observa que aquí estamos usando ambos los conceptos de parameters y conditions.

En este caso, especifico el parameters ambiente para definir si es un template para desarrollo o producción y la condition para determinar si creo una copia de seguridad automática o no.

Resources

Son los recursos propiamente dichos.

Cada recurso tiene sus propias propiedades. Podemos visualizar estas propiedades en la documentación de Cloud Formation.

Así, la documentación es fundamental para saber qué atributos colocar en cada propiedad y cómo crear cada recurso.

Outputs

Los outputs son una herramienta de Cloud Formation utilizada para exportar valores de propiedades de los recursos y hacerlos visibles globalmente para otros templates.

Por ejemplo, imagina que tienes un template solo para crear tablas de la base de datos DynamoDB. DynamoDB tiene una propiedad llamada Stream, que sirve para transmitir los cambios ocurridos en esa tabla.

De esta forma, ese stream puede activar una función lambda para realizar algún procesamiento reaccionando a este evento.

Ahora, supongamos que quieras vincular el stream de esa tabla a una lambda que está en otro template. La lambda requiere que pases el identificador del stream (también conocido como ARN – Amazon Resource Name) en una de las propiedades, sin embargo, este nombre no está disponible hasta que crees el template.

Así, para ejemplos como este, puedes exportar este nombre como un output del template y utilizar la variable exportada en otro.

Es importante utilizar el recurso de Outputs con cuidado porque atan templates.

Esto significa que no puedes eliminar un recurso si está siendo referenciado por otro recurso. Por eso, solo úsalo en casos extremadamente necesarios.

Funciones Intrínsecas

Las funciones intrínsecas son funciones built-in de Cloud Formation. Estas funciones permiten referenciar propiedades de recursos, es decir, sus valores, que aún no están disponibles de hecho hasta crear el template.

A continuación, ¿conocemos algunas de ellas?

La Ref se utiliza para referenciar el valor lógico del recurso. Entonces, generalmente representa el id, nombre o identificador único del recurso.

El GetAtt nos permite acceder a algunos otros atributos del recurso que no están definidos en la Ref. Así, cada recurso tiene su propio conjunto de atributos disponibles para acceso.

Ya el Sub permite utilizar los nombres de variables (los parameters) dentro de los recursos. De esta forma, Cloud Formation reconoce que el nombre debe ser reemplazado por la variable informada en el parameter.

Finalmente, puedes consultar la documentación de cada una de ellas aquí.

¡Ahora, veamos un ejemplo práctico de la aplicación de estos conceptos! Vamos al caso de uso:

Necesitamos crear una tabla de DynamoDB (base de datos no relacional de AWS) con el nombre ‘{ambiente}_mensajes’. La clave primaria de esta tabla es el ID de los mensajes. La tabla debe ser creada para todos los ambientes y, para producción, debe tener la copia de seguridad (point in time recovery) habilitada. Además, la tabla debe poseer un stream (evento de cuando un elemento es insertado, modificado o eliminado) y este stream debe ser utilizado por funciones ya existentes que están en otro template.

Así, observa cómo quedaría el template de este ejemplo:

Entonces, piensa qué interesante: Con pocas modificaciones tendrías nuevos templates para otros tipos de tablas de DynamoDB. Como resultado, ¡esa es la magia y el beneficio de utilizar Infra as Code!

Cómo facilitarlo aún más:

¿Tienes una infraestructura y te gustaría automatizarla y empezar a generar scripts? ¿Te gustaría crear una infraestructura en la nube pero te parece crear scripts complicado? Zappts puede ayudarte con nuestro producto de Infra as Code.

Nuestra plataforma lee tus recursos en la nube y genera un script listo para ti. Además, si deseas un proceso desde cero, también ofrecemos ese apoyo.

¡Ven a conocer nuestro producto! Habla con un especialista.

Sobre Zappts

Fundada en 2014 por Rodrigo Bornholdt y Pablo Augusto, Zappts acelera la transformación digital de grandes marcas con equipos de alto rendimiento. Con enfoque en el desarrollo de software, especialmente en Front-end, UX Design, Quality Assurance y Gestión de Ambientes Cloud, opera en la planificación, gestión y operación de servicios de desarrollo de soluciones digitales corporativas, gestión de ambientes y transferencia de conocimiento a través de la tecnología de la información. Referencia en la creación de experiencias digitales para los usuarios, además de desarrollar soluciones innovadoras y rápidas, la empresa opera en un modelo 100% remoto, con equipos distribuidos en más de 17 estados de Brasil.

Qué es Infra as Code