¿Qué es Infrastructure as Code, y por qué importa la infraestructura inmutable?

#Infraestructura como Código es lo que convierte a "¿cómo se configuró este servidor?" en una pregunta respondible

Infrastructure as Code (IaC) significa que tus servidores, redes, balanceadores de carga y registros DNS están definidos en archivos de configuración versionados —Terraform, Pulumi, CloudFormation, Bicep— y se crean o modifican corriendo esa configuración a través de una herramienta automatizada, nunca con un humano haciendo clic en la consola de la nube o entrando por SSH a correr un comando puntual. El archivo de configuración es la fuente de verdad; la infraestructura corriendo es solo su representación actual y descartable. Ese único cambio de enfoque transforma casi todo en cómo un equipo opera su infraestructura.

#Lo que realmente ganás al tratar la infraestructura como código

• Reproducibilidad — levantar un segundo ambiente idéntico (un staging que realmente coincide con producción, o recuperación ante desastres en una región nueva) es correr la misma configuración de nuevo, no hacer ingeniería inversa de lo que alguien hizo a mano hace dieciocho meses.
• Revisión y trazabilidad — un cambio de infraestructura pasa por un pull request como el código de aplicación: un diff, un revisor, un historial de commits que dice quién cambió qué y por qué, en vez de una acción de consola registrada (con suerte) en una entrada de CloudTrail que nadie lee hasta que un incidente los obliga.
• Detección de drift — correr terraform plan te muestra exactamente dónde la realidad se desvió de la configuración declarada, algo que de otro modo es invisible hasta que algo se rompe.
• Recuperación ante desastres más rápida y segura — si una región desaparece, IaC es la diferencia entre "correr apply contra una región nueva" y "esperar que alguien recuerde los pasos manuales".

#Un ejemplo real de Terraform

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

  backend "s3" {
    bucket         = "acme-terraform-state"
    key            = "prod/api/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "acme-terraform-locks"
    encrypt        = true
  }
}

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

resource "aws_launch_template" "api" {
  name_prefix   = "api-"
  image_id      = var.api_ami_id   # una AMI dorada horneada por CI en cada merge a main
  instance_type = "t3.medium"

  lifecycle {
    create_before_destroy = true   # nunca mutar una plantilla en uso in situ
  }
}

resource "aws_autoscaling_group" "api" {
  name                = "api-asg"
  desired_capacity    = 3
  min_size            = 2
  max_size            = 6
  vpc_zone_identifier = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.api.id
    version = "$Latest"
  }

  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 50
    }
  }

  tag {
    key                 = "Name"
    value               = "api"
    propagate_at_launch = true
  }
}

Dos detalles acá cargan con toda la lección. Primero, el backend "s3" con una dynamodb_table no es decoración — el archivo de estado de Terraform es el mapa de "qué existe y qué cree Terraform que tiene forma", y si dos personas corren apply desde sus propias laptops con estado local, tarde o temprano van a corromperse los cambios mutuamente o a duplicar recursos. Un backend remoto con una tabla de locks hace que apply sea mutuamente excluyente para todo el equipo. Segundo, el instance_refresh del autoscaling group es el patrón de infraestructura inmutable resumido en un bloque: cuando cambia api_ami_id, Terraform no parchea las instancias en ejecución — despliega instancias completamente nuevas construidas desde la AMI nueva, reemplazando las viejas un porcentaje controlado a la vez, y nunca toca el disco de una instancia viva.

#Infraestructura mutable vs. inmutable

El modelo viejo —entrar por SSH a un servidor en ejecución, hacer apt upgrade, editar un archivo de configuración a mano, reiniciar un servicio— es infraestructura mutable. Cada servidor que fue parcheado una cantidad de veces ligeramente distinta, por una secuencia de personas ligeramente distinta, va derivando lentamente hacia un "copo de nieve": una máquina que nadie puede reproducir exactamente, cuya configuración vive en parte en una herramienta de gestión de configuración, en parte en el historial de shell de alguien, y en parte en la memoria de nadie.

La infraestructura inmutable convierte lo opuesto en regla: una vez que una instancia (o una imagen de contenedor) está corriendo, nunca se modifica. Un cambio de código o configuración significa construir una imagen o AMI nueva, y reemplazar por completo la instancia en ejecución en vez de parchearla in situ. Si algo anda mal en una instancia corriendo, no la depurás en vivo — la terminás y dejás que el autoscaling group (o Kubernetes?) arranque una nueva desde la imagen conocida como buena. Esto convierte "¿está bien configurado este servidor?" de una investigación en una tautología: está corriendo la imagen, así que sí, por definición.

#Por qué esto importa más allá de la prolijidad

La inmutabilidad no es solo una preferencia estética — elimina toda una categoría de incidentes de producción que existen únicamente porque era posible arreglar algo in situ. El drift de configuración, "funciona en la máquina que lleva 400 días encendida", y los hotfixes manuales que nunca volvieron al control de versiones son todos síntomas de infraestructura mutable. La infraestructura inmutable obliga a que cada cambio pase por el mismo camino revisado, versionado y reproducible — exactamente el mismo argumento que CI/CD para el código de aplicación, aplicado una capa más abajo.