¿Qué es Infrastructure as Code? Guía visual para principiantes

Una vez pasé un viernes entero haciendo clic en la consola de AWS para montar un entorno de producción. VPC, subredes, grupos de seguridad, una instancia RDS, un balanceador de carga, dos EC2. Cuatro horas de trabajo. Me sentí orgulloso. Documentado: nada.

Tres semanas después, el cliente pidió un entorno de staging idéntico. Abrí la consola y me di cuenta de que había olvidado la mitad de los parámetros. Los rangos CIDR de las subredes? Desaparecidos. Las reglas de seguridad? Algo recordaba. El parameter group de RDS? Ni idea.

Así que pasé otras cuatro horas reconstruyendo todo, adivinando la mitad de la configuración. El entorno de staging quedó “más o menos” como producción. Ya te imaginas cómo terminó la historia.

Antes y después: manual vs código

Esto es lo que parece gestionar infraestructura sin IaC:

1. Abrir la consola cloud
2. Navegar por quince pantallas
3. Elegir configuraciones de memoria (o desde una página wiki medio desactualizada)
4. Esperar no haber olvidado ninguna regla de seguridad
5. Repetir para cada entorno, cada vez
6. Rezar para que nadie cambie algo manualmente sin avisar

Y esto es lo mismo con Infrastructure as Code:

1. Escribir un archivo de configuración describiendo lo que quieres
2. Ejecutar un comando
3. Tu entorno completo aparece, idéntico cada vez
4. Guardar el archivo en Git como cualquier otro código
5. Revisar cambios en pull requests antes de que lleguen a producción
6. Dormir tranquilo

Eso es todo. Describes tu infraestructura en archivos de texto y una herramienta la construye por ti. Misma entrada, misma salida, siempre.

Qué es realmente Infrastructure as Code

Infrastructure as Code significa gestionar servidores, redes, bases de datos y recursos cloud mediante archivos de configuración legibles por máquina, en lugar de procesos manuales. En vez de hacer clic en botones de una consola web, escribes código que describe el estado deseado de tu infraestructura.

La palabra clave ahí es estado. No escribes “crea un servidor”. Escribes “debe haber un servidor con estas propiedades”. La herramienta se encarga de los pasos. Si el servidor ya existe y coincide, no hace nada. Si algo se desvió, lo corrige.

Esto se llama configuración declarativa — describes el qué, no el cómo. Es la diferencia entre decirle al GPS “llévame al aeropuerto” y dar indicaciones giro a giro de memoria.

También existe el enfoque imperativo, donde escribes instrucciones paso a paso. Ansible se inclina hacia este lado. Ambos funcionan. El declarativo tiende a ser más fácil de razonar a gran escala.

Por qué importa todo esto? Tres razones:

Reproducibilidad. Mismo código, misma infraestructura. Dev, staging, producción — todos idénticos. Se acabó el “funciona en mi máquina”, pero para servidores.

Control de versiones. Tu infraestructura vive en Git. Puedes ver quién cambió qué, cuándo y por qué. Puedes revertir. Puedes revisar cambios antes de que pasen a producción.

Velocidad. Levantar un nuevo entorno pasa de “un día haciendo clic” a “ejecuta este comando”. Tirarlo abajo es igual de rápido. Eso cambia por completo la forma de pensar sobre infraestructura.

Las grandes herramientas (y para qué sirve cada una)

Cuatro nombres dominan este espacio. No todos hacen lo mismo, aunque constantemente se meten en el mismo saco.

Terraform

La herramienta IaC de propósito general más popular. Creada por HashiCorp. Funciona con AWS, Azure, GCP y cientos de otros proveedores. Escribes archivos .tf en un lenguaje llamado HCL (HashiCorp Configuration Language), y Terraform determina cómo crear, actualizar o destruir recursos.

Terraform es declarativo y cloud-agnóstico. Ese segundo punto importa — puedes gestionar AWS, Cloudflare y Datadog desde la misma base de código.

Ideal para: aprovisionar infraestructura cloud. Servidores, redes, bases de datos, DNS, CDN. La parte estructural.

Ansible

Creado por Red Hat. Ansible es principalmente una herramienta de gestión de configuración y automatización. Se conecta a tus servidores por SSH y ejecuta tareas en orden. No necesita ningún agente en las máquinas destino.

Ansible usa playbooks en YAML y se inclina hacia lo imperativo — defines pasos, no solo estados finales. Es excelente para instalar software, configurar servicios, desplegar aplicaciones.

Ideal para: configurar servidores después de que existen. Instalar paquetes, parametrizar servicios, ejecutar despliegues.

AWS CloudFormation

La herramienta IaC nativa de AWS. Templates en JSON o YAML que describen recursos de AWS. Integración profunda con cada servicio de AWS, frecuentemente soportando nuevas funcionalidades desde el primer día.

El problema: solo funciona con AWS. Si estás completamente en AWS y planeas quedarte, CloudFormation es sólido. Si podrías usar múltiples nubes, vas a chocar contra un muro.

Ideal para: equipos 100% AWS que quieren integración nativa con el ecosistema.

Pulumi

El retador más reciente. En lugar de un lenguaje dedicado, escribes IaC en lenguajes de programación reales — TypeScript, Python, Go, C#. El mismo modelo declarativo que Terraform por debajo, pero con todo el poder de un lenguaje de programación.

Ideal para: equipos que quieren bucles, condicionales y abstracciones sin aprender HCL. También genial si tu equipo ya vive en TypeScript o Python.

Cuándo usar qué

Este es un modelo mental que me ha funcionado bien:

• Necesitas crear recursos cloud (servidores, bases de datos, redes)? Terraform o CloudFormation.
• Necesitas configurar lo que hay en esos servidores (instalar software, editar archivos de configuración)? Ansible.
• Solo AWS con integración nativa? CloudFormation.
• Quieres usar un lenguaje de programación real? Pulumi.
• Estás empezando y quieres el mercado laboral más grande? Terraform. Sin duda.

Muchos equipos usan Terraform y Ansible juntos — Terraform crea la infraestructura, Ansible la configura. Son complementarios, no competidores.

Si todavía estás construyendo tus bases en cloud, nuestra guía para aprender cloud computing desde cero cubre los conceptos fundamentales que vas a querer dominar antes de meterte de lleno en herramientas IaC.

Tu primer archivo Terraform

Aquí tienes una configuración Terraform completa que crea un bucket S3 en AWS. Es prácticamente lo más simple que puede ser el IaC:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "mi_primer_bucket" {
  bucket = "mi-primer-bucket-iac-12345"

  tags = {
    Environment = "learning"
    ManagedBy   = "terraform"
  }
}

Qué está pasando aquí:

• El bloque terraform dice “necesito el provider de AWS.”
• El bloque provider dice “conéctate a AWS en us-east-1.”
• El bloque resource dice “debe haber un bucket S3 con este nombre y estos tags.”

Para ejecutarlo:

terraform init      # Descargar el provider de AWS
terraform plan      # Previsualizar qué se va a crear
terraform apply     # Crear los recursos de verdad

terraform plan es tu red de seguridad. Te muestra exactamente qué va a pasar antes de que nada cambie. Acostúmbrate a leer la salida del plan. Cada vez. Sin excepción.

Cuando termines de experimentar:

terraform destroy   # Eliminar todo lo que Terraform creó

Eso es IaC de verdad. Quince líneas, un comando, y tienes infraestructura versionada, reproducible y eliminable. Intenta hacer eso haciendo clic por la consola.

Errores comunes de principiantes

Los he cometido todos. Algunos más de una vez.

No usar state remoto. Terraform almacena su estado en un archivo local por defecto. Está bien para aprender. En equipo, es un desastre — dos personas ejecutando Terraform al mismo tiempo van a corromper el state. Usa un backend S3 (o equivalente) desde el inicio de cualquier proyecto real.

Poner todo hardcodeado. Tu primer instinto va a ser poner valores directamente en los bloques resource. Nombres de región, tamaños de instancia, nombres de bucket. Usa variables en su lugar. Tu yo del futuro te lo va a agradecer cuando necesites la misma config para tres entornos.

Saltarse terraform plan. Ejecutar apply sin leer el plan es como hacer push a main sin leer el diff. Funciona bien hasta que no funciona, y cuando no funciona, generalmente es algo que se destruye.

Intentar aprender todo a la vez. IaC tiene una superficie de aprendizaje grande. No intentes aprender Terraform, Ansible, Docker, Kubernetes y CI/CD simultáneamente. Elige una herramienta, construye algo real con ella y después amplía. Quince minutos al día le ganan a una maratón de fin de semana — escribimos sobre por qué.

Modificar la infraestructura manualmente después de desplegarla con código. Esto se llama “drift”, y es el equivalente IaC de editar bases de datos de producción directamente. La herramienta cree que la infraestructura está en un estado; la realidad dice otra cosa. Todo se rompe en el siguiente apply. Si está gestionado por código, solo cámbialo mediante código.

FAQ

Necesito saber programar para aprender Infrastructure as Code?

No realmente. El HCL de Terraform se parece más a un formato de configuración que a un lenguaje de programación. Si sabes escribir JSON o YAML, puedes escribir HCL. Ansible usa YAML, que es todavía más simple. No necesitas saber Python o JavaScript para empezar. Eso sí, entender conceptos básicos como variables, bucles y condicionales ayuda cuando las configuraciones crecen.

Terraform es gratis?

El CLI de Terraform es open-source y gratuito. Puedes usarlo para todo lo descrito en este artículo sin pagar nada. HashiCorp ofrece Terraform Cloud con funcionalidades de equipo (state remoto, colaboración, políticas), que tiene un plan gratuito y planes de pago. La mayoría de individuos y equipos pequeños se las arreglan perfectamente con el CLI y un backend S3 para el state.

Debería aprender Terraform o Ansible primero?

Terraform, si te estás metiendo en infraestructura cloud. Resuelve el problema más fundamental — crear los recursos. Ansible es más útil una vez que tienes servidores que configurar. Si tu trabajo es sobre todo “montar entornos AWS”, Terraform es la respuesta. Si es más bien “desplegar y configurar aplicaciones en servidores existentes”, empieza por Ansible.

Cuánto tiempo se tarda en ser productivo con IaC?

Puedes crear recursos cloud reales con Terraform en una tarde. Sentirte cómodo toma de dos a cuatro semanas de práctica regular. Sentirte seguro con módulos, gestión del state y configuraciones multi-entorno lleva unos meses. La curva de aprendizaje está cargada al principio — la primera semana es la más difícil. Después, es principalmente aprender nuevos tipos de recursos, que siguen los mismos patrones que ya conoces.

Listo para construir habilidades cloud reales desde cero? Empieza con SkillRealm Learn —>