Cuando abres Slack por la mañana, los servidores que te responden no fueron creados a mano en una consola. Fueron descritos en archivos de texto, revisados en una solicitud de fusión, luego construidos por Terraform. Lo mismo ocurre en GitHub, en Decathlon, y en miles de equipos más pequeños. Aquí tienes cuatro hechos públicos, verificables, con su fuente.
| Quién | Qué hacen con Terraform | Fuente |
|---|---|---|
| Slack | Una sola sintaxis para AWS, DigitalOcean, NS1 y Google Cloud. Cerca de 1 400 archivos de state, cada uno bajo la responsabilidad del equipo dueño del servicio. State almacenado en S3 con versionado, bloqueado por DynamoDB. Una herramienta interna publica el terraform plan en cada pull request antes de la fusión. | How We Use Terraform At Slack, publicación de ingeniería de Slack, 25 de octubre de 2022 |
| GitHub | «Casi todos nuestros hosts, incluyendo los del centro de datos, son gestionados por Terraform y construidos de la misma manera, ya sea en Azure, AWS u otra plataforma.» Prototipar un nuevo servicio tomaba varios días; con Terraform, menos de una hora. | Caso de estudio HashiCorp — GitHub, declaraciones de Aaron Brown, ingeniero de infraestructura |
| Decathlon | Antes: más de una semana para obtener una infraestructura, el tiempo de pasar por varios equipos y una CMDB. Después: «lo que tomaba más de una semana ahora se hace en menos de 30 minutos», y cada marca construye lo que necesita, por sí sola. | Caso de estudio HashiCorp — Decathlon, declaraciones de Kévin Defives, ingeniero de sistemas de información |
| Toda la comunidad | El Terraform Registry cuenta más de 7 200 providers (los plugins que hablan con las API) y más de 24 000 módulos reutilizables. Solo el provider de AWS superó 5 mil millones de descargas: ocho años para el primer mil millones, dos años para los cuatro siguientes. | Terraform Registry (contador de la API del Registry, medido el 15 de septiembre de 2026) · HashiCorp, 24 de noviembre de 2025 |
Lo que estos equipos tienen en común: siempre tienen una consola cloud, y la usan para mirar. Pero la fuente de verdad, lo que dice qué debe existir, es el código. Nadie crea un servidor haciendo clic. Es exactamente lo que vas a hacer en este curso, a pequeña escala: primero un archivo de texto en tu máquina, luego un bucket S3, luego cuatro plataformas a la vez.
Seis palabras aparecerán en cada lección. Se dan aquí con la definición que HashiCorp les da, traducida, y el enlace a la página oficial.
| Término | Qué es | Referencia oficial |
|---|---|---|
| Infrastructure as Code (IaC) | Gestionar la infraestructura en uno o varios archivos en lugar de configurarla a mano en una interfaz. Máquinas virtuales, grupos de seguridad, interfaces de red, buckets, repositorios Git: todo lo que tiene una API puede describirse en un archivo. | Glosario Terraform — Infrastructure as Code |
| Declarativo (contra imperativo) | Un archivo declarativo describe el resultado esperado: «este bucket debe existir, con estas etiquetas». Un script imperativo describe los pasos: «llama a create-bucket, luego a put-bucket-tagging…». Los archivos de Terraform son declarativos: no escribes los pasos, Terraform los deduce. | What is Terraform — configuración declarativa |
| Idempotencia | Relanzar la misma operación varias veces da el mismo resultado que una sola vez. Si la infraestructura ya corresponde al código, terraform plan anuncia que no se necesita ninguna acción (No changes. Your infrastructure matches the configuration.) y apply no toca nada. Un script que encadena llamadas create-…, al relanzarse, falla sobre lo que ya existe o crea un duplicado. | Referencia de terraform plan |
| Deriva (drift) | La diferencia entre lo que el state cree y lo que realmente existe, porque alguien modificó un recurso fuera de Terraform (en la consola, con un script, a mano). Terraform la detecta en el momento del plan, releyendo la infraestructura real. | Tutorial — Manage resource drift |
| State | El archivo (terraform.tfstate) donde Terraform anota qué bloque del código corresponde a qué objeto real (con su identificador, sus atributos). Sin él, Terraform no sabría que un bucket que ya existe es «el suyo» y lo recrearía. Es sensible: puede contener contraseñas y direcciones. | Terraform state |
| Provider | Un plugin que conoce la API de una plataforma (AWS, Azure, Google Cloud, GitHub, o incluso el disco local) y expone sus objetos como tipos de recursos. Terraform los descarga en terraform init. Es el provider quien hace las llamadas de API, no Terraform en sí. | Providers |
Imagina un arquitecto a cargo de un edificio. Tiene tres cosas a la mano.
.tf.Cada vez que se le pide intervenir, el arquitecto hace lo mismo. Relee el plano. Abre su registro. Va a ver el edificio. Luego compara los tres y escribe un presupuesto de obras: falta este muro, hay que construirlo; esta puerta no está en el plano, hay que quitarla; esta ventana está en el lugar correcto, no se toca. El presupuesto lo firma el cliente, y solo después los gremios (los providers) ejecutan cada línea. Ni más ni menos que el presupuesto.
Esta imagen vuelve a aparecer en todo el curso. Cuando una lección hable del plano, del registro y del edificio, habla del código, del state y de la infraestructura real.
La diferencia esencial entre «el plano» y
terraform plan. En la imagen, el plano es el dibujo del arquitecto, es decir, tu código. El comandoterraform plan, en cambio, produce el presupuesto de obras: la lista de lo que va a cambiar para que el edificio se ajuste al plano. Dos sentidos para una misma palabra. En el curso, se escribe «el plano (el código)» o «el presupuesto (la salida deterraform plan)» cuando hay riesgo de confusión.
Puedes crear un bucket S3 de tres maneras sin Terraform: haciendo clic, lanzando un script, o siguiendo un procedimiento escrito. Cada una tiene su lugar. Ninguna hace el trabajo del arquitecto.
| Método | Lo que hace bien | Lo que no hace |
|---|---|---|
| La consola (AWS, Azure, GCP en el navegador) | Explorar, entender un servicio, mirar un objeto preciso, resolver problemas rápido. | Reproducir de forma idéntica. Dos personas que hacen clic «igual» obtienen dos resultados distintos. Sin historial legible de quién cambió qué. Nada que revisar antes de validar. |
Un script bash o PowerShell (aws ec2 run-instances …, aws s3api create-bucket …) | Repetir una creación de forma idéntica, encadenarla en un pipeline. | Saber qué existe ya. Relanzado una segunda vez, intenta recrear y se detiene con un error, o crea un duplicado. No compara nada, no detecta que una regla fue cambiada a mano, y no sabe destruir lo que creó sin un segundo script escrito a mano. |
| Un runbook (procedimiento escrito, capturas de pantalla) | Transmitir una intención, formar a alguien, dejar constancia de la decisión. | Probar que la infraestructura todavía corresponde al texto. Al día siguiente de una modificación en la consola, el runbook queda falso y nadie lo sabe. |
Terraform hace lo que estos tres métodos no hacen, y lo hace en este orden: lee lo existente, compara con el código, anuncia lo que va a cambiar, aplica solo lo que falta, anota lo que hizo en el state, y sabe destruir todo de forma limpia con terraform destroy. Cada proyecto del curso termina con esta destrucción: nada queda activo, nada queda facturado.
Imagina que una empresa debe lanzar una aplicación web. Quizá haya que crear:
Puedes crear todo a mano en una consola AWS, Azure o Google Cloud. Funciona para una primera prueba. Se vuelve frágil en cuanto el entorno crece.
Relee la tabla de ejemplos reales: Decathlon describe el costo del método manual (más de una semana, varios equipos y una CMDB que llenar para un solo servidor), GitHub responde a la dificultad 1 (hosts construidos «de la misma manera» en todas partes), Slack a la dificultad 5 (el presupuesto revisado en el pull request antes de cualquier fusión).
La Infrastructure as Code, abreviada IaC, consiste en describir la infraestructura en archivos tratados como código. HashiCorp define Terraform como una herramienta de IaC que permite definir recursos cloud y on-premise en archivos de configuración legibles, que puedes versionar, reutilizar y compartir. Referencia oficial — Introducción a Terraform
En lugar de escribir un largo procedimiento como «haz clic aquí, elige esta región, crea luego esta red», describes el estado deseado:
resource "aws_s3_bucket" "documents" {
bucket = "entreprise-documents-exemple"
}Este bloque no describe cada llamada de API. Dice: «este bucket debe existir con esta configuración». Es el plano del arquitecto. Terraform determina luego las obras necesarias.
El mismo código sirve para crear un entorno de desarrollo, de prueba o de producción. Los valores que cambian se colocan en variables en lugar de copiarse a mano.
terraform plan presenta las creaciones, modificaciones y destrucciones previstas: es el presupuesto de obras. El equipo revisa la intención antes de que Terraform toque la infraestructura. Los símbolos están fijados por la documentación oficial. Referencia oficial — terraform plan
+ creación
~ modificación en el lugar
-/+ reemplazo (destruir, luego recrear)
- destrucciónAtención: un plan reduce el riesgo, no garantiza la ausencia de impacto. Una modificación de red, de base de datos o de identidad sigue siendo peligrosa y debe examinarse línea por línea.
Los archivos .tf viven en Git. Cada cambio está asociado a una rama, una solicitud de fusión, una revisión y un autor. Es lo que hace Slack: el presupuesto se publica en el pull request, y nadie fusiona sin haberlo leído.
Una organización encapsula sus reglas en módulos reutilizables: cifrado obligatorio, etiquetas de costos, registros activados, red aprobada y versiones controladas. Los módulos permiten reutilizar colecciones configurables de recursos. Referencia oficial — Módulos de Terraform
Terraform no sirve solo para crear. Compara la configuración, el state y la infraestructura real para determinar qué añadir, modificar o eliminar. Es el gesto del arquitecto: releer el plano, abrir el registro, ir a ver el edificio.
Terraform exige una inversión inicial: aprender HCL, escribir los módulos, asegurar el state y construir una cadena de aprobación. Esta inversión se vuelve rentable en cuanto el equipo debe repetir, auditar o hacer evolucionar la infraestructura.
Ejemplo: una empresa tiene 30 aplicaciones y cuatro entornos por aplicación. A mano, son 120 entornos que mantener. Módulos comunes permiten describir el modelo una vez y proporcionar los valores propios de cada aplicación.
Terraform automatiza una intención. Si el código pide una mala arquitectura, Terraform reproduce esa mala arquitectura muy eficazmente, y en todas partes. Siempre hay que:
El arquitecto no construye lo que quiere. Construye lo que está dibujado. Si el dibujo es malo, el edificio también lo será.
Lee el esquema de izquierda a derecha. El plano y el registro entran donde el arquitecto. Él va a ver el edificio. Produce un presupuesto. Tú lo firmas. Los gremios ejecutan, y el arquitecto actualiza su registro. En la siguiente vuelta, si nada cambió, el presupuesto está vacío: No changes.
terraform plan antes de una puesta en producción?