Terraform que tu equipo pueda mantener.

Cualquiera escribe Terraform que funciona un viernes. La disciplina está en escribir Terraform que tu equipo pueda seguir cambiando el lunes, y durante dos años de lunes después de ese.

Todo código de Terraform cuenta dos historias. Una es la infraestructura que levanta. La otra es si alguien en el equipo todavía se anima a correr terraform apply sin contener la respiración. La mayoría de los equipos optimiza la primera historia y hereda, en silencio, la segunda.

La infraestructura como código ganó la discusión hace años, casi todo equipo serio de cloud la escribe hoy. En la encuesta State of IaC de Firefly, cerca del 89% de los equipos la adoptó, pero solo el 6% tiene su infraestructura totalmente bajo código; la mayoría codificó apenas una fracción de lo que realmente corre. Esa brecha lo dice todo. Adoptarla nunca fue lo difícil. Lo difícil aparece después: la primera vez que alguien tiene que cambiar un módulo que no escribió, contra un estado en el que no confía del todo, en un plan que no termina de entender. Ese momento es donde la mayoría de la IaC deja de rendir, en silencio.

El motivo casi siempre es el mismo. El código se escribió para aplicarse una vez, no para convivir con él. Funciona, salió a producción, y cada atajo que se tomó para llegar ahí se convirtió en un impuesto que paga el que viene después, casi siempre bajo presión, casi siempre en producción.

El código de infraestructura se lee, y se teme, mucho más de lo que se escribe.

Copiar y pegar es un préstamo

La forma más rápida de agregar un segundo entorno es copiar el primero. La más rápida de agregar un tercero es copiar el segundo. Se siente productivo, y por una semana lo es. Después un security group necesita cambiar, y ahora tiene que cambiar en nueve lugares que ya se separaron entre sí. La duplicación no es un problema de estilo; es un préstamo que sacás contra cada edición futura, y el interés se acumula con cada entorno que agregás. Los módulos existen para pagar ese préstamo, para plegar la repetición en un solo lugar que valga la pena hacer bien, de modo que un cambio sea un cambio, no una excavación arqueológica.

El estado es el sistema

El verdadero producto de Terraform no son tus archivos .tf, es el estado. El estado es el mapa entre tu código y el mundo real, y en el momento en que dos personas aplican sobre él sin lock, o alguien edita un recurso a mano, el mapa deja de coincidir con el territorio. Tratá al estado como producción, porque lo es: remoto, con lock, versionado, con backup y con dueño. La corrupción de estado, el drift y las fallas de lock son, de forma consistente, los principales dolores que reportan los equipos una vez que pasan los cincuenta ingenieros, el tamaño en que los hábitos informales dejan de escalar. El drift, la distancia entre lo que dice el código y lo que realmente corre en la nube, no es un caso borde. Menos de un tercio de las organizaciones lo monitorea de forma continua; el resto se entera cuando algo se rompe. Y no sale gratis: la investigación de DORA vincula el drift de configuración frecuente con tasas de fallo de cambios cerca de 2,3 veces más altas. El drift es el resultado por defecto de cada arreglo manual que nadie anotó.

Lo aburrido es una feature

El Terraform mantenible es implacablemente aburrido. Nombres consistentes, módulos chicos con un radio de impacto claro, un plan que un revisor pueda leer de verdad, y convenciones que alguien nuevo absorba en una tarde. La viveza, dynamic blocks anidados tres niveles, el módulo que hace todo, se lee hermoso para quien lo escribió y como una nota de secuestro para todos los demás. Nada de esto es preferencia estética. Los equipos que pasan su Terraform por revisión de pares reportan cerca de un tercio menos de problemas de calidad, y los que versionan sus módulos de forma deliberada ven caer las fallas de despliegue en los meses siguientes. El objetivo no es código elegante. Es un terraform plan que diga la verdad con la claridad suficiente para que aprobarlo no requiera fe.

Escribir Terraform es fácil; casi cualquiera hace que la nube haga algo hoy. Construir infraestructura que un equipo pueda cambiar sin riesgo dentro de dos años, después de que los autores originales se fueron, después de que los requerimientos cambiaron dos veces, es lo más difícil y lo más valioso. La primera versión impresiona en una demo. La segunda sigue en pie cuando el equipo se triplicó y nadie recuerda por qué existe un recurso.

Escribí la infraestructura que tu equipo pueda cambiar sin titubear. Es la única versión que sobrevive a la gente que la escribió.