Infraestructura como código: por dónde empieza de verdad un equipo de ingeniería

El síntoma aparece antes que el incidente

Un equipo suele descubrir que necesita infraestructura como código siempre de la misma forma: alguien se va de vacaciones y nadie más sabe recrear exactamente ese entorno de staging. O una instancia cae, y el restore "manual, como siempre se hizo" se come toda la tarde porque dos configuraciones de la consola habían divergido sin que nadie lo notara.

Ninguno de los dos casos es realmente sobre automatización. Es sobre un entorno que solo existe en la cabeza de una persona, o disperso en notas que nadie vuelve a mirar hasta que las necesita con urgencia.

Qué cambia cuando el entorno se vuelve un archivo

Infraestructura como código, en la práctica, significa algo simple: la configuración de servidores, redes, bases de datos y permisos pasa a vivir en un archivo versionado, no en un clic que alguien recuerda haber hecho una vez. Terraform, Pulumi o el equivalente del proveedor no son lo importante: son solo la herramienta que lee ese archivo y aplica la diferencia entre lo que está descrito y lo que realmente existe.

Eso cambia la pregunta que el equipo se hace después de un incidente. En vez de "¿quién recuerda cómo se armó esto?", la pregunta pasa a ser "¿qué dice el archivo que debería existir acá?". La segunda pregunta tiene respuesta en segundos. La primera, solo a veces, y no siempre de la persona correcta.

La decisión que más dudas genera: un módulo o varios, desde el día uno

Acá va una opinión que vale la pena defender, porque la tentación del equipo siempre va en sentido contrario: empezá con un único módulo, para un solo entorno, sin abstraer para reutilización multi-cuenta desde el primer día. Modularizar demasiado pronto asume que ya sabés qué variaciones se van a repetir, y normalmente no lo sabés, porque todavía no existen dos entornos reales para comparar.

El costo de empezar simple es duplicar algo de código cuando aparezca el segundo entorno. El costo de modularizar temprano es mantener una abstracción genérica que nadie tiene la certeza de que esté bien, porque solo se probó contra un caso. Entre los dos, el primero sale más barato de corregir después: es refactorización. El segundo, si la abstracción se equivocó, es reescritura.

La regla práctica: esperá a que el patrón se repita en al menos dos entornos reales antes de extraer un módulo. Antes de eso, la duplicación visible es preferible a la abstracción especulativa.

Dónde el estado de Terraform se vuelve riesgo, no herramienta

El archivo .tfstate guarda la relación entre lo que describe el código y lo que realmente existe en la nube. Perderlo, o dejar que dos personas apliquen cambios al mismo tiempo sin un lock, no es un detalle operativo. Es la forma más común en que un entorno entero termina desincronizado de lo que el código dice que debería ser.

Un backend remoto con lock (S3 con DynamoDB, o el equivalente del proveedor elegido) resuelve la mayor parte de esto. El error común es tratarlo como configuración para "cuando el proyecto crezca". Es exactamente al revés: cuanto más chico el equipo, menor la chance de que alguien note la divergencia a tiempo.

Una hoja de ruta para las primeras semanas

Antes de escribir la primera línea, mapeá lo que ya existe hoy, de preferencia con terraform import sobre un recurso real, no recreándolo desde cero. Después, elegí el entorno de menor riesgo (staging, no producción) como primer objetivo. Solo después de un ciclo completo de plan y apply sin sorpresas en ese entorno vale la pena pensar en producción.

Documentá las decisiones que no son obvias directo en el código, como comentario cerca del recurso, no en una wiki aparte que nadie va a mantener actualizada. Y tratá el primer apply como un evento acompañado, no como una tarea que se dispara y se olvida.

Cuándo todavía no vale la pena

Si la infraestructura de hoy es chica y estable, y el equipo es una o dos personas que ya conocen el entorno de memoria, el retorno de adoptar infraestructura como código ahora puede ser menor que el costo de aprender la herramienta. Empieza a valer la pena en cuanto aparece el segundo entorno, o cuando la única persona que lo conocía se va de vacaciones y alguien más necesita tocarlo.

Dónde entra Diglion

Cuando se llega a ese punto (el entorno creció más allá de lo que una persona recrea de memoria), el trabajo real es decidir qué describir primero y con qué nivel de abstracción, no solo instalar la herramienta. Diglion ayuda a equipos de ingeniería a tomar esa decisión a partir de lo que ya existe, en vez de reescribir infraestructura estable solo para parecer moderna.