El Caos del Éxito en IaC

Cuando empiezas con Infraestructura como Código (IaC) en Azure usando Terraform o Bicep, todo es mágico. Un par de archivos .tf y de repente tienes una red, una base de datos y un App Service. Pero el éxito trae crecimiento, y el crecimiento trae complejidad.

Pasan los meses, el equipo crece, y ese repositorio mágico de Terraform se ha convertido en un monstruo de 5.000 líneas. Los despliegues (terraform apply) tardan 45 minutos. Nadie se atreve a tocar nada por miedo a destruir producción, y los conflictos de Git en los archivos de estado son el pan de cada día.

Aquí es donde entra el Tech Lead. Tu misión ya no es escribir el módulo perfecto para desplegar un clúster de AKS, sino construir un sistema que permita a 20 ingenieros desplegar infraestructura simultáneamente sin pisarse.

1. Modularización: Cortando el Monolito

El error número uno en equipos que escalan su IaC es tratar la infraestructura de toda la empresa como una gran y única aplicación.

La Estrategia de Módulos

Como Tech Lead, debes guiar al equipo hacia una arquitectura modular. No me refiero solo a usar module {} en Terraform, sino a separar lógicamente los entornos y los dominios de vida:

1. Fundational (Core): Redes (VNets, ExpressRoute), firewalls, Log Analytics workspaces. Cambian raramente.
2. Shared Services: Active Directory (Entra ID), clústeres base de Kubernetes, Azure Container Registries. Cambian moderadamente.
3. Application (Workloads): Bases de datos específicas de una app, Web Apps, Serverless functions. Cambian a diario.

Cada una de estas capas debe tener su propio estado de Terraform (State File). Si un desarrollador rompe la configuración del App Service de su equipo (Workload), no debería haber riesgo alguno físico ni de tiempos de ejecución sobre la red troncal de la empresa (Core).

2. El Proceso de Revisión: Pull Requests de Infraestructura

El código de infraestructura es código, y como tal, requiere revisión por pares (Peer Review). Sin embargo, revisar IaC es distinto a revisar C# o Python.

¿Qué buscar en una PR de Terraform/Bicep?

• Planes visibles: El pipeline de Integración Continua (CI) debe ejecutar automáticamente un terraform plan y publicar el resultado como un comentario en la Pull Request. Nadie debería aprobar código sin ver exactamente qué va a crear, modificar o destruir.
• Idempotencia: ¿Si ejecuto esto dos veces, intentará recrear algo?
• Hardcoding: Elimina cadenas de texto “quemadas” en el código. Exige el uso de variables, data sources y naming conventions dinámicas.
• Análisis Estático de Seguridad: Integra herramientas como Checkov o tfsec en el pipeline para bloquear automáticamente PRs que intenten, por ejemplo, desplegar un Storage Account con acceso público a internet.

# Fragmento de Azure Pipeline para Terraform Plan
jobs:
- job: TerraformPlan
  steps:
  - task: TerraformTaskV4@4
    inputs:
      provider: 'azurerm'
      command: 'plan'
      commandOptions: '-out=tfplan'
      environmentServiceNameAzureRM: 'My-Azure-Service-Connection'

3. Gestión del Estado (The State File)

El archivo de estado es la única fuente de verdad de tu infraestructura. Perderlo o corromperlo es un evento de nivel de desastre.

Como líder técnico, debes garantizar que las bases están cubiertas:

1. Backend Remoto Seguro: Nunca en local. En Azure, esto significa un Azure Storage Account.
2. Bloqueo de Estado (State Locking): Absolutamente crítico. Azure Storage soporta bloqueos nativos (Leases) para evitar que dos pipelines ejecuten un apply al mismo tiempo.
3. Control de Accesos (RBAC): No todos los desarrolladores necesitan leer el archivo de estado (que puede contener contraseñas o claves primarias en texto plano). Limita el acceso a este Storage Account de forma estricta.

4. Pruebas: Confía, pero verifica

“Testear infraestructura no es posible” es un mito que el Tech Lead debe desterrar.

• Validación temprana: terraform validate y terraform fmt deben ser pre-commit hooks obligatorios.
• Pruebas de Integración: Herramientas como Terratest (en Go) permiten levantar infraestructura temporal, realizar peticiones HTTP (por ejemplo, comprobar si el Application Gateway responde 200 OK) y destruirla.
• Policy as Code: Integra OPA (Open Policy Agent) o Azure Policy Enforcements a nivel de CI/CD para que el código ni siquiera llegue a desplegarse si viola las reglas de la empresa.

Conclusión

Escalar Infraestructura como Código no es un problema de conocer más sintaxis de HCL o Bicep. Es un desafío de ingeniería de software clásico: acoplamiento, cohesión, despliegue continuo y trabajo en equipo.

El Tech Lead exitoso en este ámbito es el que construye barreras de seguridad invisibles automatizadas en los pipelines, permite autonomía mediante la modularización y trata el código de infraestructura con el mismo rigor (o más) que el código de aplicación de producción.