Uno de los componentes más críticos e importantes hoy en día, en la era Cloud, es la Infraestructura como Código o IaC (Infrastructure as Code). En este post explicaré en rasgos generales, cómo es la gestión de las infraestructuras como código en cloud.
Hace no mucho tiempo el trabajo de un administrador de sistemas no era fácil. Había que mantener y configurar todo el hardware y software para que una aplicación pudiera funcionar correctamente. Si se rompía un servidor y había que montarlo de nuevo, había que tirar de la documentación, que resultaba que casi nunca estaba del todo actualizada y al montar el servidor de nuevo nunca se sabía con exactitud si era exactamente como estaba antes, lo cual dejaba al nuevo servidor en un estado desconocido y no probado.
Con la Infraestructura como código, se mejoran todos esos procesos y evita innumerables riesgos y posibles desastres técnicos que se puedan producir por operaciones manuales o mal documentadas.
¿Qué es exactamente la Infraestructura como Código (IaC)?
Simplificando mucho su definición, podríamos decir que el IaC significa mantener la infraestructura de forma programática eliminando así la necesidad de la configuración manual.
Ventajas de la gestión de la infraestructura como código en Cloud
IaC y DevOps
Al convertir nuestra infraestructura en código, podemos aplicarle todas las ventajas que nos ofrece el DevOps. Podemos añadir nuestro código a un repositorio Git y versionar nuestra infraestructura para así poder trabajar con un equipo para su mantenimiento. Además, podemos aplicar la mejora e integración continua para que cambios aprobados automáticamente sean desplegados.
Mayor rapidez
Otra ventaja es la rapidez con lo que podemos levantar una infraestructura. En muy poco tiempo podemos crear una infraestructura completamente operacional. Esta rapidez hace que incluso las políticas de backup deben ser revisados. Porque ¿para qué queremos tener un backup de todo si podemos recrear en cuestión de minutos la infraestructura usando nuestro IaC?.
Sin riesgos
Al automatizar la creación de recursos, el riesgo de equivocarnos en cualquier configuración se disminuye prácticamente a cero, haciendo los despliegues mucho más seguros, disminuyendo al máximo el riesgo.
Menos costes
Lógicamente la automatización para crear infraestructura lleva consigo una reducción de gastos, ya que no hace falta ingenieros que manualmente configuran y mantengan la infraestructura. Asimismo, la posibilidad de reutilizar código reduce drásticamente la creación de nuevas infraestructuras.
¿Mutable o inmutable?
Con todo estos cambios y manera de pensar se han introducido conceptos como “mutable” e “inmutable”. ¿Pero qué significan esto conceptos realmente?
Mutable quiere decir que el servidor que se monta se va cambiando con el tiempo. A lo mejor empezabas con un servidor con Linux y Tomcat 4.2, pero luego se decidió usar Nginx. Para esto se tenía que desinstalar el Tomcat e instalar el Nginx y todo esto sobre el mismo servidor. ¿Qué hay de malo en esto? Pues a la mejor en un servidor no pasa nada, pero imaginaros que lo tenemos que aplicar a 100 servidores de una granja donde todos se usan para la misma aplicación. Hay una probabilidad alta de que algo no se configure exactamente igual que los otros servidores y puede darse la situación donde no sabemos en qué estado esta cada servidor. Esto también se llama “Configuration Drift”. Esto significa que la aplicación puede empezar a generar errores de forma aleatoria y que tengamos que averiguar que servidor da realmente el problema.
Inmutable quiere dice que los servidores una vez montados no se cambian. Si tenemos actualmente un servidor Linux con Tomcat 4.2 y queremos ir a un entorno donde tenemos un servidor Linux con NGinx, lo que hacemos es montar este nuevo entorno en un servidor completamente nuevo. Una vez testado y comprobado el nuevo servidor lo reemplazamos con el antiguo y pasamos todo el tráfico al nuevo servidor.
Con la introducción de IaC estamos lentamente moviendo a un mundo donde toda la infraestructura o gran parte es inmutable, ya que montar una infraestructura con IaC es muy rápido.
¿Mascotas o ganado?
Un buen ejemplo de verlo es pensar en la infraestructura como «Mascotas o Ganado». Antes, nuestros servidores o infraestructura lo veíamos como animales domésticos a los cuales les asignábamos unos nombres bonitos y los cuidábamos con mucho mimo para que pudieran estar con nosotros el máximo tiempo posible.
Hoy en día sin embargo con la introducción de IaC y el concepto inmutable debemos empezar a pensar en nuestros servidores o infraestructura como ganado. En el ganado los animales no tienen nombre, como mucho un número y si algún animal se pone enfermo o ya no nos resulta útil lo sacrificamos y lo reemplazamos con un ejemplar nuevo.
Inconvenientes de la gestión de Infraestructura como código.
No todo son ventajas al aplicar IaC, como inconvenientes destacaría el hecho de que no existe una normativa por parte de ningún organismo para homologar la forma de crear los recursos en Cloud, además creo que dado a la diversificación de los diferentes Clouds sería actualmente imposible. De esta forma un diseño realizado para un proveedor Cloud no sería válido en otro proveedor sin hacer los cambios necesarios.
Herramientas
Actualmente existe bastantes herramientas en el mercado que nos permiten generar código IaC. Algunos son propios del proveedor de Cloud como:
- CloudFormation (AWS)
- Azure Resource Manager (Azure)
- Google Cloud Deployment Manager (Google)
Luego están las herramientas multi-cloud, es decir, son las que sirven para crear infraestructuras en diferentes proveedores desde la misma herramienta.
- Terraform
- Ansible
- Chef Puppet
- Pulami
La desventaja de casi todas estas herramientas es que usan su propio Domain Specific Language (DSL) lo cual quiere decir que tenemos que aprender un lenguaje nuevo antes de poder usar la herramienta. Esto genera una curva de aprendizaje al empezar con un proyecto. Además, suelen haber bastante limitación a nivel funcional ya que los DSL que se usan no son un lenguaje de programación en sí.
Pulami sin embargo es el primero que se ha desvinculado del DSL y permite generar la infraestructura en el lenguaje que mejor le conviene al equipo. Actualmente permite Javascript,TypeScript, Python, GO y C#. Esto incluso ha llamado la atención a Terraform que ha creado un CDK para poder generar los stacks de infraestructura lenguajes de programación.
Conclusión
La Infraestructura como Código ya es un concepto indispensable dentro del mundo Cloud y forma parte del ciclo de Devops en muchas organizaciones. Gracias a IaC nuestro concepto de como desplegar e incluso diseñar infraestructuras ha cambiado radicalmente, dándonos múltiples ventajas como acabamos de ver.
