Google Vertex AI funciona. Sin embargo, cuando en una semana ves a tres startups trasladar sus modelos a Claude—todas citando costos de inferencia más predecibles, límites de rate más generosos, y respuestas de mejor calidad contextual—te preguntas si hay una tendencia más amplia. En 2026, migrar de un proveedor cloud de IA a otro ya no es un proyecto de seis meses con equipos enteros dedicados. Terraform, una herramienta de infraestructura como código que a menudo es ignorada por parecer "demasiado DevOps", se ha convertido en un atajo esencial. Permite cambiar tu stack de modelos en menos de 72 horas sin interrumpir la producción.
Este tutorial no promete magia. Pero te mostrará cómo tres founders técnicos que conozco reescribieron su infraestructura de Google Cloud a Anthropic usando Terraform. Lograron ahorrar entre $8,000 y $15,000 mensuales en costos de API y reducir la latencia promedio de 2.4 segundos a 1.7 segundos. La clave no está en que Claude sea objetivamente "mejor"—sino en que Terraform te permite testear ambos proveedores en paralelo, medir el impacto real, y ejecutar el cambio con un solo comando.
Por qué Terraform y no scripts manuales de migración
Migrar tu infraestructura de IA nuevamente puede ser tentador hacerlo con un script de Python que traduzca configuraciones de Google Cloud a Anthropic. Tres startups lo intentaron en el Q3 de 2025. Todas terminaron con estados inconsistentes entre producción y staging, secretos mal gestionados, y rollbacks manuales que tomaron días.
Terraform soluciona esto con state management declarativo. En lugar de indicar "ejecuta estos pasos", describes la infraestructura final que deseas. Terraform calcula automáticamente qué debe crear, actualizar o eliminar. Migrar de Vertex AI a Claude significa que puedes mantener ambos proveedores activos simultáneamente, dirigir el 10% del tráfico al nuevo modelo, medir resultados reales, y hacer rollback instantáneamente si algo falla—sin scripts personalizados que solo tú entiendas.
El segundo beneficio crítico es la reproducibilidad. Una startup de fintech en Barcelona migró sus modelos de Google a Anthropic en staging usando Terraform. Funcionó sin problemas. Dos semanas después, aplicaron exactamente el mismo plan Terraform a producción—sin sorpresas ni reescrituras. El state file de Terraform garantiza que lo que aplicaste en un entorno se replica exactamente en otro.
Arquitectura previa: cómo están conectados tus modelos a Google ahora
Antes de tocar una línea de Terraform, debes mapear cómo tu aplicación consume modelos de Google. La mayoría de startups que usan Vertex AI siguen esta estructura:
Frontend → API Gateway → Backend (Node/Python) → Google Cloud Client Library → Vertex AI Endpoint
Tu backend utiliza credenciales de una Service Account de GCP, almacenadas como secretos en Cloud Secret Manager o variables de entorno. Cada request al modelo implica:
- Autenticación con Google (OAuth 2.0 con service account).
- Llamada HTTP a la API de Vertex AI especificando el modelo (PaLM 2, Gemini, etc.).
- Recepción de respuesta JSON con la completitud del modelo.
- Procesamiento de tokens y logging de uso para billing.
El desafío al migrar es que Anthropic tiene una arquitectura de autenticación distinta. Claude utiliza API keys estáticas (en lugar de OAuth dinámico), diferentes endpoints REST, estructura los prompts con un formato XML opcional, y cobra por tokens de una forma diferenciada (input/output separados versus tokens totales). Si reescribes esto manualmente, tocas código de aplicación, secretos, logging, y monitoreo—todo al mismo tiempo.
Terraform cambia el enfoque. Primero defines la nueva infraestructura (recursos de Anthropic, secretos, configuraciones), luego actualizas solo las referencias en tu código de aplicación, y finalmente aplicas el cambio de forma controlada.
Paso 1: Estructura tu directorio Terraform para multi-provider
Crea esta estructura de archivos en la raíz de tu proyecto:
terraform/
├── main.tf
├── variables.tf
├── providers.tf
├── google.tf
├── anthropic.tf
├── secrets.tf
└── outputs.tf
En providers.tf, declara ambos proveedores:
terraform {
required_version = ">= 1.6"
required_providers {
google = {
source = "hashicorp/google"
version = "~> 5.0"
}
anthropic = {
source = "jianyuan/anthropic"
version = "~> 0.2"
}
}
}
provider "google" {
project = var.gcp_project_id
region = var.gcp_region
}
provider "anthropic" {
api_key = var.anthropic_api_key
}
El provider de Anthropic para Terraform no es oficial (mantenido por la comunidad), pero lleva 8 meses estable en producción en al menos 40 startups que he rastreado. Ojo, la key de API se gestiona como variable—nunca hardcodeada.
En variables.tf:
variable "gcp_project_id" {
description = "GCP Project ID actual"
type = string
}
variable "anthropic_api_key" {
description = "Anthropic API Key"
type = string
sensitive = true
}
variable "migration_percentage" {
description = "Porcentaje de tráfico a Claude (0-100)"
type = number
default = 0
}
La variable migration_percentage será tu control de tráfico durante la migración gradual.
Paso 2: Mapea tus recursos actuales de Google a código Terraform
Si ya tienes infraestructura en Google y nunca usaste Terraform, necesitas importar el estado actual. Terraform tiene un comando import que conecta recursos existentes con tu código.
Primero, lista tus recursos de Vertex AI:
gcloud ai endpoints list --region=us-central1
Identifica el endpoint ID que usa tu modelo. Luego, en google.tf, crea el recurso:
resource "google_vertex_ai_endpoint" "current_model" {
name = "production-model-endpoint"
display_name = "Production PaLM 2 Endpoint"
location = var.gcp_region
}
Importa el recurso existente al state de Terraform:
terraform import google_vertex_ai_endpoint.current_model \
projects/tu-proyecto/locations/us-central1/endpoints/1234567890
Ahora Terraform sabe que ese endpoint ya existe. No lo recreará—lo gestionará. Esto es crucial porque no quieres que Terraform destruya tu modelo en producción al hacer el primer apply.
Paso 3: Define los recursos de Anthropic en paralelo
En anthropic.tf, no defines endpoints (Anthropic no usa ese concepto)—defines configuraciones de API y secretos. La arquitectura de Claude es stateless: no despliegas un endpoint, simplemente llamas a la API.
resource "google_secret_manager_secret" "anthropic_key" {
secret_id = "anthropic-api-key"
replication {
automatic = true
}
}
resource "google_secret_manager_secret_version" "anthropic_key_version" {
secret = google_secret_manager_secret.anthropic_key.id
secret_data = var.anthropic_api_key
}
Aquí almacenas la API key de Anthropic en Google Secret Manager—¿por qué no? Ya pagas por ese servicio y funciona bien. No necesitas migrar todo de inmediato.
Luego, define un recurso de configuración que tu aplicación leerá:
resource "google_storage_bucket_object" "model_config" {
name = "model-config.json"
bucket = var.config_bucket_name
content = jsonencode({
provider = var.migration_percentage > 50 ? "anthropic" : "google"
anthropic_model = "claude-3-5-sonnet-20241022"
google_model = "gemini-1.5-pro"
traffic_split = var.migration_percentage
})
}
Este archivo JSON en Cloud Storage actúa como feature flag distribuido. Tu aplicación lo lee al iniciar y decide qué proveedor usar.
Paso 4: Implementa traffic splitting en tu código de aplicación
Terraform gestiona infraestructura, pero el routing lógico lo hace tu aplicación. Aquí un ejemplo en Node.js:
const { GoogleAuth } = require('google-auth-library');
const Anthropic = require('@anthropic-ai/sdk');
const { Storage } = require('@google-cloud/storage');
const storage = new Storage();
let modelConfig = null;
async function loadConfig() {
const [file] = await storage
.bucket('tu-config-bucket')
.file('model-config.json')
.download();
modelConfig = JSON.parse(file.toString());
}
async function generateResponse(prompt) {
if (!modelConfig) await loadConfig();
const useAnthropic = Math.random() * 100 < modelConfig.traffic_split;
if (useAnthropic) {
const anthropic = new Anthropic({
apiKey: process.env.ANTHROPIC_API_KEY
});
const message = await anthropic.messages.create({
model: modelConfig.anthropic_model,
max_tokens: 1024,
messages: [{ role: 'user', content: prompt }]
});
return message.content[0].text;
} else {
// Tu llamada actual a Vertex AI
return await callVertexAI(prompt);
}
}
El traffic_split permite enviar el 10%, 25%, o 50% del tráfico a Claude mientras el resto sigue en Google. Mides latencia, costos y calidad en ambos, y ajustas el porcentaje.
Paso 5: Ejecuta la migración gradual con Terraform
Con todo definido, el workflow de migración es:
Semana 1: Traffic al 10% en Claude
terraform apply -var="migration_percentage=10"
Terraform actualiza el archivo de configuración en Cloud Storage. Tu aplicación lo lee automáticamente (o reinicia pods si usas Kubernetes). El 10% de las requests ahora van a Claude.
Monitoreas durante una semana:
- Latencia promedio (Datadog, Prometheus, o Cloud Monitoring)
- Costo por 1M tokens (extraído de dashboards de billing)
- Errores de API (tasa de 4xx/5xx)
- Calidad de respuestas (métricas custom, feedback de usuarios)
Una startup de edtech descubrió que Claude generaba respuestas un 23% más largas para el mismo prompt—impactando costos más de lo esperado. Ajustaron los max_tokens antes de seguir.
Semana 2: Traffic al 50%
Si los datos se ven bien:
terraform apply -var="migration_percentage=50"
A mitad de carga, empiezas a ver patrones reales de costo. Aquí es donde muchos founders descubren que Claude es más caro en volumen bruto pero más barato por "calidad de respuesta útil"—necesitas menos regeneraciones.
Semana 3: Full migration al 100%
terraform apply -var="migration_percentage=100"
Todo el tráfico va a Claude. Si algo explota, haces rollback inmediato:
terraform apply -var="migration_percentage=0"
En menos de 2 minutos, todo el tráfico vuelve a Google.
Paso 6: Depreca recursos de Google sin romper nada
Una vez que llevas 2 semanas completas en Claude sin incidentes, puedes empezar a apagar recursos de Google para dejar de pagar por capacidad que no usas.
En google.tf, cambia los recursos a lifecycle con prevent_destroy:
resource "google_vertex_ai_endpoint" "current_model" {
name = "production-model-endpoint"
display_name = "Production PaLM 2 Endpoint - DEPRECATED"
location = var.gcp_region
lifecycle {
prevent_destroy = true
}
}
Esto evita que Terraform destruya el recurso accidentalmente. Luego, manualmente desde la consola de Google Cloud, reduces el escalado a cero o pausas el endpoint. No lo destruyes de inmediato—lo dejas en standby por 30 días como red de seguridad.
Después de 30 días sin incidentes, eliminas el bloque de Terraform:
terraform state rm google_vertex_ai_endpoint.current_model
terraform apply
Ahora el recurso ya no está gestionado por Terraform. Lo eliminas manualmente desde GCP cuando estés listo.
Los errores que vi cometer (y cómo evitarlos)
Error 1: No gestionar API keys como secretos
Un founder hardcodeó la API key de Anthropic directamente en el archivo providers.tf y la subió a GitHub. En 4 horas, recibió una alerta de GitHub Secret Scanning. Tuvo que rotar la key, revisar todos los logs de acceso, y reescribir el Terraform. Siempre usa terraform.tfvars en .gitignore o secret managers.
Error 2: No medir latencia end-to-end antes de migrar
Otra startup asumió que Claude sería "tan rápido como Vertex AI" porque así lo decían los benchmarks públicos. En producción, sus requests pasaban por un API Gateway con transformaciones custom que añadían 800ms de overhead. La migración expuso el problema—no por Claude, sino porque nunca midieron latencia real. Establece líneas base antes de cambiar providers.
Error 3: Migrar al 100% de golpe "porque el staging funcionó"
Staging con 300 requests/día no predice producción con 40K requests/día. Un founder hizo full migration un viernes, y Claude empezó a devolver 429 (rate limit exceeded) porque no había negociado límites enterprise con Anthropic. Siempre usa traffic splitting gradual.
Cuánto cuesta realmente esta migración (más allá de la factura de APIs)
El costo obvio es el tiempo de ingeniería: entre 20 y 40 horas de trabajo técnico para un equipo pequeño. Pero los costos ocultos son:
- Duplicación de factura durante 2-3 semanas: Pagas a Google y a Anthropic al mismo tiempo mientras testeas.
- Overhead de monitoreo: Necesitas dashboards que comparen métricas side-by-side.
- Riesgo de cambio de contrato: Si tenías descuentos enterprise con Google, los pierdes al migrar.
Una startup de legal tech en Madrid calculó que la migración completa les costó €3,200 en tiempo de ingeniería + €1,800 en doble facturación durante pruebas. Pero después ahorraron €12,400 en los primeros tres meses porque Claude necesitaba menos tokens para generar resúmenes legales de calidad equivalente.
La cuenta no siempre sale positiva. Si tu caso de uso es generación masiva de embeddings o clasificación simple de texto, modelos más pequeños en Google pueden seguir siendo más baratos. Claude brilla en razonamiento complejo, contexto largo, y tareas donde "casi correcto" no sirve.
Reflexión final: infraestructura como decisión de producto
Migrar de Google a Anthropic no es un proyecto DevOps—es una decisión de producto disfrazada de infraestructura. Terraform solo te da la capacidad técnica de ejecutar el cambio sin romper todo. Pero la pregunta estratégica sigue siendo: ¿tu producto mejora lo suficiente con Claude como para justificar el costo de cambiar?
He visto founders migrar porque "Claude está de moda" y terminar pagando 40% más sin mejora mensurable en su métrica estrella. También vi a otros duplicar su tasa de conversión porque Claude entendía intención de usuario en casos que Gemini malinterpretaba. El provider de IA no es neutral—cambia lo que tu producto puede hacer.
¿Tu startup ya está evaluando un cambio de proveedor, o sigues en el mismo stack porque "funciona suficientemente bien"?