8 Configuración como código
Configuración como código es una práctica que permite almacenar la configuración de una aplicación en archivos de código fuente, en lugar de en archivos de configuración separados. Esto permite que la configuración sea parte del código fuente de la aplicación, lo que facilita la gestión y la evolución de la configuración a lo largo del tiempo.
Hay varias ventajas al trabajar de esta manera, y diferentes perspectivas de las que puedes verlos, desde una perspectiva de estandardización de procesos, gestion de calidad, seguridad y FinOps.
1. Estandardización de procesos
En un equipo pequeño es relativamente fácil acordar como se van a hacer las cosas. Podemos inclusive acordar como nombramos las cosas. Cuando alguien nuevo que entra, si bien se puede equivocar un par de veces al inicio, rapidamente se puede acomodar a lo que acostumbramos hacer como equipo.
Pero con más proyectos, más personas y sobretodo con proyectos que no hemos visto en un buen rato, esto ya no aplica. En el mejor caso hay documentación, como el modelo de despliegue que describimos en el Capitulo 8, pero nunca hay garantia de que este correcto y al dia. Inferir la estructura desde lo que esta desplegado toma tiempo y esta sujeto a interpretación y errores.
Cuando hay una configuración en codigo, esta incertidumbre no existe. Mejor aun, permite levantar rapidametne una infraestructura paralela para ver si esta al dia, y para ir a buscar la causa de un error o incidente sin tener que tocar la infraestructura en staging o produccion. Una vez encontrado el error en un entorno de desarrollo podemos ir por los pasos para validar la correccion (entorno de staging), y tras validación desplegarlo a produccion.
2. Gestion de calidad
Tener entoros que son faciles de reproducir tiene un beneficio enormo sobre la gestion de calidad porque facilita la mejora continua y evolución de productos de datos. Es muy común que la persona o el equipo que creó un producto de datos no esta disponible cuando necesitamos hacer una corrección o un pequeño cambio tecnico. Esto cambios, aún si tecnicamente son menores, pueden tener un gran impacto en el proceso de negocio donde esta embebido, y por lo tanto si tienen prioridad.
Si un entorno es fácilmente reproducible, y si tenemos lo lineamientos en el equipo para hacerlo, la barrera de entrada para alguien que desconoce el codigo va a ser mucho menor. Muchas veces un primer paso para entender código es experimentar, ver que pasa cuando cambiamos algo y que se rompe cuando lo hacemos. Esta posibilidad en combinación con documentación y la historia del proyecto en tiquetes, tipicamente permite a que en poco tiempo no sentemos comodos para hacer los cambios.
En este escenario, configuración como código permite no solamente desplegar una entorno para desarrollo, pero tambien llevarlo con pasos claros y predefinidos a pruebas y despues a producción, con la possibilidad de hacer “roll-back” y desplegar versiones anteriore si es necesario.
3. Seguridad
Configuración como codigo tambien permite hacer auditorias sobre las configuraciones desplegadas, sin tener que entrar a la infraestructura como tal. Es casi imposible documentar de forma completa y correcta todas las configuraciones que se hacen de forma manual. Todos hemos visto este tipo de documento con una serie de screenshots y comentarios. Pero muchas veces un ultimo cambio no quedo registrado, o por omision dejamos un screenshot que ya no concuerda con lo que esta escrito debajo.
Esto tiene un impacto para la seguridad de la infraestructura, pero que solamente podemos observar el comportamiento, y se nos hace dificil validar la configuración. Por el otro lado, configuración como codigo da un registro actual y veriridico de lo que tenemos desplegado. Lo podemo leer personalmente, o lo podemos usar para auditorias automatizadas en casa, o externalizado con especialistar tercerizados. Si lo externalizamos no hay necesidad de dar acceso a infraestructura a bajo nivel.
4. FinOps
Para la gestión de costos, infraestructura como codigo tiene varias ventajas. Primero nos permite trabajar con entornos de desarrollo y de pruebas temporales. Si es facil levantar y dar de baja todo el conjunto de infraestructura que necesitamos, entonces hay un incentivo grande para darlo de baja cuando no lo necesitamos. Algunos productos de datos viven mucho tiempo sin cambios, porque los requisitos no cambian. No es necesario mantener una infraestructura de prueabs disponible apra estos a la par de la infraestructura de produccion a largo plazo.
Otra ventaja, que requiere una madurez analitica mayor de los equipos, es que infraestuctura como codigo nos permite hacer experimentos para validar si hay componentes alternativos que funcionan mejor, o a un mejor costo dentro del conjunto de soluciones desplegadas. Hacer esto a mano puede consumir mucho tiempo durante el desarrollo, y cuando es asi tipicamente se dan incidentes al llevarlo a produccion por la misma complejidad de configuración.
8.1 Herramientas
Dadas las ventajas arriba un pensaria que esta forma de trabajar es el estandar en todas las situaciones. Pero tipicamente esto no es asi. Requiere, para comenzar que trabajemos en codigo. Requiere ademas que en el proceso de despliegue tengamos los permisos necesarios para levantar infraestructura, lo que no siempre es posible en todas las organizaciones.
La herramienta que nos permite trabajar con codigo es Terraform. Terraform es una herramienta de código abierto que permite crear, cambiar y versionar infraestructura de manera segura y eficiente. Terraform utiliza un lenguaje de configuración declarativo para describir la infraestructura que se desea crear, lo que permite que los cambios se apliquen de manera segura y eficiente.
Declarativo en el parrafo anterior significa que la configuración que definimos en un archivo de texto es el estado final de la infraestuctura a levantar. Esto es diferente a un script, donde la configuración se aplica paso a paso desde la primera linea hasta la final, como por ejemplo durante el build basado en un archivo docker. La jerga para ese tipo de configuración es imperativo.
Pero esto no significa que una aproximación imperativa sea mala. Ya vimos el ejejmplo de Docker, donde esta aproximación funcoina muy bien y tiene su razon de ser asi. Hemo construido soluciones donde manejamos la infraestructura con una combinación de instrucciones de gcloud de Google Cloud Platform y R, o con instrucciones en az de Azure y Python. Se podria hacer con cualquier combinación de herramientas de linea de comando de la infraestructura, con cualquier lenguaje de programación para actuyar de goma (glue) y pegar los diferentes componentes.
La clave esta en tener la disciplina de siempre levantar todas la infraestructura con codigo. Cuando hay que hacer una corrección hay que llevarlo a codigo (entorno de desarrollo) validar que funciona para el negocio (entorno de pruebas) y despues llevar como lanzamiento al entorno de producción. Tipicmaente damos más giros entre desarrollo y pruebas para pulir lo que buscamos hacer, lo que justamente hace el entorno de pruebas tan importante.
LLMs pueden jugar un papel importante aqui para agilizar el proceso de definir la infraestructura y plasmarla en codigo. Pero asi como son una herramienta poderosa, pueden genera riesgos grandes con pequeñas diferencias en interpretación. Estar atento a lo que se esta desplegando e incluir una infraestructura de monitoreo se hace más importante cuando se genera codigo de configuración de forma asisistida.