--- title: "Infrastructure as Code con Terraform: de hacer click en consolas a gestionar infra como código" description: "Aprendé qué es Infrastructure as Code, por qué Terraform es la herramienta líder y cómo funciona su ciclo de trabajo con providers, modules, state y CI/CD. Por el equipo CloudOps de Devlights." url: "https://www.devlights.com/es/blog/terraform-infrastructure-as-code" language: es published: 2026-10-23T13:00:00.000Z updated: 2026-10-28T22:29:56.057Z type: devtalk authors: ["Horacio Zini"] category: "DevTalks" tags: ["Terraform", "Infrastructure as Code", "IaC", "CloudOps", "DevOps", "AWS", "HCL", "Cloud", "CI/CD", "HashiCorp"] --- # Infrastructure as Code con Terraform: de hacer click en consolas a gestionar infra como código > Infrastructure as Code es la práctica de gestionar infraestructura cloud con código declarativo en lugar de interfaces manuales. Terraform es la herramienta líder: cloud-agnostic, con un ecosistema enorme y un modelo predecible y versionable. [YouTube](https://www.youtube.com/watch?v=0DDfpg9hsrQ) > **TL;DR** > > Infrastructure as Code (IaC) es la práctica de provisionar y gestionar infraestructura cloud mediante código declarativo en lugar de interfaces manuales. Terraform es la herramienta líder del espacio: cloud-agnostic, con un ecosistema enorme y un modelo de trabajo predecible y versionable. Si tu equipo todavía gestiona infra haciendo clicks en consolas, esto es para vos. ## De los clicks al código: ¿por qué importa el salto? Cuando los equipos empiezan a trabajar con cloud, el camino natural es la consola web. Es visual, inmediata y no requiere conocimiento previo. Funciona bien para explorar, para aprender, para un recurso puntual. El problema llega cuando ese mismo enfoque escala: múltiples entornos, múltiples regiones, múltiples servicios que dependen entre sí. En ese contexto, la consola se convierte en un cuello de botella. Los cambios son manuales, difíciles de reproducir, imposibles de versionar y propensos a errores humanos. La respuesta de la industria a ese problema tiene nombre: **Infrastructure as Code**. ## ¿Qué es Infrastructure as Code? IaC es la práctica de **provisionar y gestionar infraestructura mediante código declarativo** en lugar de procesos manuales. En lugar de describir *cómo* crear un recurso paso a paso, describís *qué* querés que exista, y la herramienta se encarga del resto. Tres propiedades definen bien el concepto: **Predecible.** El mismo código produce siempre el mismo resultado. No hay ambigüedad sobre qué va a crear ni cómo va a quedar configurado. **Idempotente.** Aplicar la misma configuración dos veces tiene el mismo efecto que aplicarla una. Si el recurso ya existe con la configuración correcta, no se toca. **Versionable.** El código de infraestructura vive en un repositorio junto al código de la aplicación. Tenés historial de cambios, podés hacer code review, podés hacer rollback. ### Las alternativas antes de IaC Antes de que IaC se adoptara de forma masiva, los equipos gestionaban la nube principalmente a través de tres interfaces: **CLI**: control total y scripteable, pero requiere conocimiento profundo y los scripts son difíciles de mantener a escala. **SDK**: integración directa desde el código de la aplicación, útil para casos puntuales pero no pensado para gestionar infraestructura completa. **GUI (consola web)**: la más accesible visualmente, pero manual por definición. No escala, no se puede versionar, no se puede automatizar. Cada una tiene su lugar. Pero para gestionar entornos cloud completos en equipos, ninguna de las tres es suficiente sola. ## ¿Por qué Terraform? Existen varias herramientas de IaC: AWS CloudFormation, Azure ARM Templates, GCP Deployment Manager, Pulumi. Terraform se destaca por una razón central: es **cloud-agnostic**. Mientras que CloudFormation solo funciona con AWS, ARM solo con Azure y Deployment Manager solo con GCP, Terraform gestiona recursos en cualquier provider con la misma herramienta y el mismo lenguaje. AWS, Azure, GCP, Kubernetes, Datadog, GitHub, si existe una API, probablemente existe un provider de Terraform para ella. Algunos datos de contexto: - Creada por **HashiCorp** en **2014**, versión estable v1.0 en 2021 - Ecosistema con **miles de providers y módulos** en el Terraform Registry - **Adquirida por IBM en 2025**, lo que refuerza su continuidad y soporte empresarial a largo plazo ## HCL: el lenguaje detrás de Terraform Terraform usa **HCL (HashiCorp Configuration Language)**, un lenguaje declarativo diseñado para ser legible por humanos y expresivo sin ser un lenguaje de programación general. Un ejemplo básico: crear un bucket S3 en AWS. ``` provider "aws" { region = "us-east-1" } resource "aws_s3_bucket" "data_lake_raw" { bucket = "devlights-datalake-raw" tags = { Environment = "production" Team = "cloudops" } } resource "aws_s3_bucket_versioning" "raw_versioning" { bucket = aws_s3_bucket.data_lake_raw.id versioning_configuration { status = "Enabled" } } ``` Lo que hace este código: declara que querés un bucket S3 con ese nombre, esas etiquetas y versionado habilitado. Terraform se encarga de crearlo, y si ya existe con esa configuración, no hace nada. ## Los dos pilares del ecosistema: Providers y Modules ### Providers Los providers son **plugins escritos en Go** que le permiten a Terraform comunicarse con APIs externas. Sin un provider, Terraform no puede gestionar nada. Cada provider expone un conjunto de recursos y data sources que podés usar en tu código. ``` terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } kubernetes = { source = "hashicorp/kubernetes" version = "~> 2.0" } } } ``` ### Modules Los módulos son **paquetes HCL reutilizables** que agrupan recursos relacionados. En lugar de definir una VPC de AWS desde cero cada vez, usás (o creás) un módulo que encapsula toda esa lógica y la exponés con variables de configuración. ``` module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "5.0.0" name = "devlights-vpc" cidr = "10.0.0.0/16" azs = ["us-east-1a", "us-east-1b"] private_subnets = ["10.0.1.0/24", "10.0.2.0/24"] public_subnets = ["10.0.101.0/24", "10.0.102.0/24"] } ``` Los módulos son lo que hace que la infra sea reutilizable entre proyectos y equipos. ## El State: la fuente de verdad Uno de los conceptos más importantes (y más mal entendidos) de Terraform es el **state**. El archivo `terraform.tfstate` es el **puente entre tu código HCL y los recursos reales en la nube**. Es un JSON que registra qué recursos gestiona Terraform, cuál es su configuración actual y cuál es su ID en el provider. Por qué importa entenderlo bien: **Backend remoto.** En proyectos de equipo, el state nunca debería vivir localmente. Se almacena en un backend remoto, S3, Google Cloud Storage, Azure Blob, para que todos los miembros del equipo trabajen contra el mismo estado. ``` terraform { backend "s3" { bucket = "devlights-terraform-state" key = "cloudops/pipeline/terraform.tfstate" region = "us-east-1" encrypt = true dynamodb_table = "terraform-state-lock" } } ``` **Locking.** Para evitar que dos ejecuciones simultáneas corrompan el state, Terraform puede usar DynamoDB (en AWS) u otros mecanismos para adquirir un lock exclusivo antes de modificarlo. **Drift.** El drift es la divergencia entre lo que dice el state y lo que existe realmente en la nube. Puede ocurrir cuando alguien hace un cambio manual en la consola sin pasar por Terraform. El comando `terraform plan` detecta este drift y lo refleja como diferencia a resolver. ## El ciclo de vida: 4 comandos para gobernar tu infra Terraform tiene un flujo de trabajo bien definido que se repite en cada cambio de infraestructura: ``` terraform init ``` Inicializa el workspace: descarga los providers declarados, instala los módulos referenciados y configura el backend. Es el primer comando que se corre en cualquier proyecto nuevo o al clonar uno existente. ``` terraform init ``` ``` terraform validate ``` Valida la sintaxis del código HCL y verifica la consistencia interna de la configuración. No hace llamadas a la API del provider. Útil para correr en CI antes de cualquier otra cosa. ``` terraform validate ``` ``` terraform plan ``` El comando más importante del ciclo. Muestra **exactamente qué va a cambiar** antes de tocar nada: qué recursos se van a crear, modificar o destruir, y cuáles van a quedar igual. ``` terraform plan # Ejemplo de output: # + aws_s3_bucket.data_lake_curated will be created # ~ aws_glue_crawler.iot_raw will be updated in-place # - aws_lambda_function.legacy_processor will be destroyed # # Plan: 1 to add, 1 to change, 1 to destroy. ``` Revisar el plan antes de aplicar es el equivalente al code review en infraestructura. ``` terraform apply ``` Ejecuta los cambios del plan y actualiza el state con el resultado. Pide confirmación explícita antes de proceder (o podés pasarle `-auto-approve` en pipelines de CI/CD). ``` terraform apply ``` ``` terraform destroy ``` Elimina todos los recursos gestionados por la configuración. Útil para limpiar entornos temporales, pero hay que usarlo con cuidado en la producción. ## Integración con CI/CD El verdadero poder de Terraform se libera cuando se integra en un pipeline de CI/CD. El flujo típico: 1. Un developer abre un PR con cambios de infraestructura. 2. El pipeline corre `terraform validate` y `terraform plan` automáticamente. 3. El output del plan se comenta en el PR para revisión. 4. Al mergear a main, el pipeline corre `terraform apply` automáticamente. Herramientas como Atlantis, Terraform Cloud o GitHub Actions permiten implementar este flujo con configuración mínima. ## Conclusión El salto de "hacer clicks en la consola" a gestionar infraestructura como código no es solo una mejora técnica. Es un cambio de modelo que afecta directamente la confiabilidad, la velocidad y la capacidad de escalar de un equipo de tecnología. Terraform, en particular, resuelve bien el problema porque no te ata a un solo provider, tiene un ecosistema maduro y sigue un modelo mental simple: declarás lo que querés, Terraform calcula la diferencia con lo que existe y aplica solo lo necesario. En equipos que trabajan con múltiples entornos cloud, como el CloudOps Team de Devlights, la diferencia entre infra gestionada con IaC e infra gestionada manualmente es la diferencia entre poder operar con confianza y estar siempre apagando incendios. Si tu equipo está evaluando adoptar Terraform o necesita ayuda para estructurar su infra como código de forma escalable, en Devlights tenemos experiencia concreta en ese camino. [Hablemos](https://www.devlights.com/es/contact).