Gestionar infraestructura en múltiples nubes es más difícil de lo que parece. Terminas con dos consolas de facturación, dos conjuntos de primitivas IAM, dos CLIs y el riesgo constante de desviación de configuración entre entornos. Terraform no elimina esa complejidad, pero te da un solo lugar donde definir todo y un único flujo de trabajo para aplicarlo.

¿Por Qué Usar Terraform para Despliegues Multi-Nube?

Las herramientas de Infraestructura como Código te permiten definir la infraestructura en archivos versionados en lugar de hacer clic en una consola. Terraform es una elección sólida para configuraciones multi-nube por varias razones concretas:

  1. Ecosistema de Providers: Los plugins de provider de Terraform soportan GCP, AWS, Azure y docenas más. Puedes gestionar recursos de distintas nubes en el mismo proyecto.

  2. Gestión de Estado: Terraform rastrea el estado real de los recursos en un archivo de estado. Cuando ejecutas terraform apply, reconcilia la configuración deseada con lo que existe actualmente, haciendo las actualizaciones predecibles.

  3. Reutilización de Código: Los módulos te permiten encapsular definiciones de recursos y reutilizarlos en distintos entornos y providers. Esto es especialmente útil cuando las configuraciones de GCP y AWS comparten una estructura común.

  4. Control de Versiones: Los archivos de Terraform son código, por lo que van a Git. Tienes historial, blame, pull requests y rollbacks para tu infraestructura.

  5. Flujo de Trabajo Uniforme: En lugar de alternar entre gcloud, aws y scripts personalizados, ejecutas terraform plan y terraform apply para ambas nubes. Esa consistencia importa cuando incorporas ingenieros nuevos o depuras a las 3 de la madrugada.

Beneficios del Multi-Nube con Google Cloud y AWS

Operar en ambos providers ofrece ventajas reales:

  1. Redundancia: Si un provider sufre una interrupción, las cargas de trabajo pueden migrar al otro sin partir de cero.

  2. Optimización de Costos: Los providers tienen precios distintos para sus servicios. Ejecutar cómputo en el más económico para una región o tipo de carga de trabajo determinado suma con el tiempo.

  3. Acceso a Servicios Únicos: AWS Lambda tiene un sólido ecosistema serverless. GKE es una de las mejores ofertas de Kubernetes gestionado. Una configuración multi-nube te permite usar la mejor herramienta para cada trabajo.

  4. Migración Gradual: Muchos equipos usan la multi-nube durante una migración, ejecutando parte de la carga de trabajo en cada provider mientras hacen la transición. Terraform gestiona ambos lados desde una única fuente de verdad.

Preparando el Entorno de Terraform

Antes de escribir cualquier configuración, ten las herramientas listas.

1. Instalar Terraform

Descarga e instala el binario más reciente de Terraform desde el sitio oficial de HashiCorp. Verifica la instalación:

terraform -version

2. Configurar las CLIs de Nube

Necesitas el Google Cloud SDK (gcloud) y la AWS CLI para autenticarte y gestionar recursos.

  • Google Cloud SDK: Autentícate ejecutando gcloud init o gcloud auth login.
  • AWS CLI: Autentícate con aws configure para configurar tu access key, secret key y región por defecto.

3. Configurar Cuentas de Servicio y Claves de Acceso

Para producción, usa credenciales dedicadas en lugar de tu cuenta personal:

  • Google Cloud: Crea una cuenta de servicio con los roles necesarios (por ejemplo, admin de cómputo, admin de almacenamiento). Descarga el archivo de clave JSON y referencíalo en tu configuración de Terraform o establécelo como variable de entorno.
  • AWS: Genera una access key y secret key con permisos limitados, siguiendo los principios de menor privilegio.

Estructurando el Proyecto Terraform

Un proyecto multi-nube típico podría verse así:

.
├── modules
│   ├── gcp
│   │   └── compute_instance
│   └── aws
│       └── ec2_instance
├── environments
│   ├── dev
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── prod
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
├── provider.tf
├── versions.tf
└── README.md

Archivos clave:

  • versions.tf fija la versión de Terraform y de los providers para mantener consistencia entre entornos.
  • provider.tf configura los providers de GCP y AWS con el proyecto, la región y los detalles de credenciales.
  • main.tf referencia módulos o define recursos de forma inline.
  • variables.tf declara variables, manteniendo los valores sensibles fuera del control de versiones mediante terraform.tfvars.
  • modules/ contiene configuraciones reutilizables, cada una con su propio main.tf, variables.tf y outputs.tf.

Esta estructura modular te permite probar en staging y promover a producción con confianza.

Configurando los Providers

Declarar ambos providers en un único archivo de configuración es sencillo:

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
  credentials = file(var.gcp_credentials_file)
}

provider "aws" {
  region = var.aws_region
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

En producción, usa variables de entorno (GOOGLE_APPLICATION_CREDENTIALS, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) en lugar de incrustar credenciales en el código. Para configuraciones más avanzadas, considera AWS assume roles o GCP Workload Identity.

Aprovisionando Recursos en Google Cloud

Con el provider de GCP configurado, puedes aprovisionar instancias de Compute Engine, buckets de Cloud Storage, bases de datos de Firestore y más. Aquí tienes una instancia básica de Compute Engine:

resource "google_compute_instance" "web_server" {
  name         = "terraform-gcp-instance"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }

  metadata = {
    ssh-keys = "terraform:YOUR_PUBLIC_SSH_KEY"
  }
}

Personaliza los tipos de máquina, imágenes y scripts de inicio en esta configuración.

Aprovisionando Recursos en AWS

Los recursos de AWS conviven en el mismo proyecto junto a los recursos de GCP. Para una instancia EC2:

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"

  tags = {
    Name = "terraform-aws-instance"
  }
}

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

El mismo enfoque basado en código se extiende a S3, RDS, Elastic Load Balancers y la mayoría de los demás servicios de AWS.

Gestionando el Estado

La gestión de estado multi-nube requiere planificación previa.

  1. Almacenamiento Remoto de Estado: Los archivos de estado locales son arriesgados en entornos de equipo. Usa Amazon S3 con DynamoDB para el bloqueo de estado, o Google Cloud Storage con el bloqueo basado en la API de GCP. Esto evita que aplicaciones concurrentes corrompan el estado.

  2. Estados Separados por Entorno: Mantén archivos de estado distintos para dev, staging y prod. Un cambio en dev nunca debe afectar el estado de prod.

  3. Cifrado y Control de Acceso: Los archivos de estado suelen contener IDs de recursos y configuración de red. Aplica políticas de bucket en S3 o ACLs en GCS para restringir el acceso.

Buenas Prácticas para Despliegues Multi-Nube

  1. Usa Módulos y el Principio DRY: Encapsula definiciones de recursos de GCP y AWS en módulos reutilizables. Copiar y pegar bloques de recursos es como empieza la desviación de configuración.

  2. Aprovecha los Workspaces: Los workspaces de Terraform mantienen estados separados para distintos entornos, lo cual es más rápido de arrancar que directorios separados en proyectos pequeños.

  3. Prueba en Entornos Inferiores: Aplica cambios en dev o staging antes de producción. Verifica que tus planes realmente hacen lo que esperas.

  4. Automatiza con CI/CD: Ejecuta terraform plan en cada pull request y terraform apply al hacer merge. GitHub Actions, GitLab CI y Jenkins soportan esto.

  5. Etiqueta y Rotula los Recursos: Etiqueta todo en AWS y rotula todo en GCP. La atribución de costos y el seguimiento de propiedad se vuelven imposibles sin un etiquetado consistente.

  6. Monitorea y Observa: Usa Cloud Monitoring en GCP y CloudWatch en AWS para hacer seguimiento del uso de recursos, el rendimiento y los logs en ambos providers.

Manejando Escenarios Multi-Nube Complejos

A medida que las configuraciones crecen, algunos patrones avanzados se vuelven relevantes:

  • Kubernetes Híbrido: Gestiona definiciones de clústeres GKE y EKS con Terraform más módulos Helm para unificar flujos de trabajo basados en contenedores entre providers.

  • Arquitecturas Serverless: GCP Cloud Functions y AWS Lambda pueden aprovisionarse en paralelo. La cobertura de Terraform se extiende a servicios serverless, por lo que las configuraciones de funciones conviven junto a tu infraestructura principal.

  • Replicación en la Capa de Datos: Sincronizar datos entre Google Cloud Storage y Amazon S3 para disponibilidad requiere Terraform más soluciones de replicación nativas de la nube o servicios de terceros.

  • Red y Seguridad: Las VPCs en ambas nubes necesitan una coordinación cuidadosa. Declara roles IAM, políticas y cuentas de servicio en Terraform para estandarizar la configuración de seguridad entre providers.

Superando Problemas Comunes

  1. Particularidades por Provider: Cada provider tiene comportamientos únicos y limitaciones ocasionales. Lee la documentación del provider y revisa los módulos de la comunidad antes de construir algo desde cero.

  2. Gestión de Credenciales: Administrar credenciales para dos providers de nube puede volverse complicado. HashiCorp Vault o AWS Secrets Manager centraliza los secretos y reduce el riesgo de que las credenciales se filtren al código.

  3. Colisiones de Nombres de Recursos: Algunos nombres deben ser globalmente únicos, otros solo dentro de una región. Establece convenciones de nomenclatura desde el principio para evitar conflictos.

  4. Sobrecostos: Terraform puede aprovisionar recursos rápidamente, y olvidar destruir entornos de prueba en dos providers de nube genera facturas inesperadas. Etiqueta los recursos efímeros y configura alertas de facturación.

  5. Consistencia en los Patrones de Infraestructura: Resiste la tentación de gestionar recursos de GCP y AWS con estilos completamente distintos. Un enfoque uniforme permite a los ingenieros cambiar entre entornos sin tener que reaprender las convenciones.

Mirando Hacia Adelante

El ecosistema de providers de Terraform y los propios proveedores de nube evolucionan rápidamente. Las habilidades esenciales —escribir configuraciones modulares, gestionar el estado con cuidado, integrar con CI/CD y hacer seguimiento de costos entre providers— seguirán siendo relevantes independientemente de los servicios específicos que estés usando.

La multi-nube es cada vez más el estándar para organizaciones con requisitos serios de confiabilidad o cargas de trabajo que se benefician de las fortalezas de distintos providers. Terraform es actualmente la herramienta más práctica para gestionar esa complejidad desde una única base de código, y la inversión en IaC limpio y bien organizado ahora rinde dividendos cuando la infraestructura necesita cambiar.