La discusión más larga y estéril que tuve con un compañero no fue sobre código de aplicación. Fue sobre por qué el entorno de pruebas se comportaba distinto al de producción. Él juraba que había desplegado igual. Yo juraba que la configuración era otra. Los dos teníamos razón, y ese era justamente el problema: nadie sabía cuál era la verdad porque la infraestructura vivía en la cabeza de cada uno.
Adoptar infraestructura como código no fue una decisión de arquitectura elegante. Fue rendirnos ante la evidencia de que la memoria humana es un pésimo sistema de versiones.
Empezamos pequeño, a propósito. Nada de "vamos a codificar toda la nube en un trimestre". Cogimos un solo entorno, el de pruebas, y lo describimos en archivos de Terraform. Red, base de datos, permisos, todo. La primera vez que destruimos ese entorno y lo levantamos idéntico desde cero, en el equipo hubo un silencio de esos que valen más que cualquier presentación.
Lo que más me sorprendió fue el efecto en las conversaciones. Antes, cuando alguien pedía un recurso nuevo, era una charla vaga por chat. Después, era un pull request. Podíamos discutir sobre líneas concretas, ver el impacto, dejar constancia de por qué se tomó una decisión. La infraestructura pasó a tener historia, y con ella, contexto para quien llegara nuevo.
También cometimos errores sanos. Aprendimos a separar el estado por entornos para no pisarnos, a no meter secretos en el código, y a que un plan antes de un apply no es burocracia, es respeto por quien duerme tranquilo esa noche.
Mi consejo para un equipo que empieza: no busquen la abstracción perfecta desde el día uno. Busquen que dos personas, mirando el mismo repositorio, puedan estar de acuerdo sobre qué existe y por qué. El resto es refinamiento.
La discusión de "en mi máquina funciona" no desapareció por arte de magia. Desapareció porque dejamos de tener máquinas distintas en la cabeza y empezamos a tener una sola descripción, compartida y revisable, de la realidad.
– Sergey Shinder
Top comments (0)