En este post vamos a hablar de la parte más devops de los puestos de programador. Pero en el mundo actual en el que estamos picar código, ya sea código para el front o código para el back no es suficiente, hay personas que prefieren centrarse en front y back, hay otros que pivotan hacia análisis de datos y luego hay otros como yo, que pivotan un poco hacia devops.
hacer devops no implica tener que saber todo sobre redes, o sobre balanceadores de carga, por supuesto necesitamos una base sobre todos los aspectos, pero lo que sí necesitamos es saber leer la documentación y en base a ella, elegir una buena configuración.
Índice
1 - ¿Qué es la infraestructura como código?
La infraestructura como código o infrastructure as code (IaC) en inglés, es una forma o técnica que nos permite proveer la infraestructura de nuestro servidor a través de software, en este caso código. Con el objetivo de conseguir consistencia y los resultados esperados (predecidos).
1.1 - A través del código
Cuando hacemos IaC estamos escribiendo código, lo que quiere decir que cuando queremos desplegar por ejemplo un nuevo servidor web no vamos a nuestro proveedor cloud como Azure o AWS y buscamos en pantalla “añadir instancia web”.
Si no que este proceso lo indicamos en un fichero el cual contiene toda la configuración de nuestro entorno, y en él, es donde indicaremos nuestra nueva instancia web.
Y estos ficheros vienen en formato JSON o YAML.
Por ejemplo en un fichero JSON podemos indicar que queremos aumentar nuestro servidor web de 8 gb de ram a 12gb, cambiando únicamente el número en el fichero, no debemos ir al servidor y manualmente cambiar las memorias físicas.
1.2 - Consistencia
Escribiendo todas las instrucciones en nuestro fichero de configuración, lo que buscamos es que siempre tengamos los mismo resultados, da igual que ejecutemos el fichero una vez o 50, y da igual en cuantos entornos diferentes, si ejecutas un bloque de configuración en un entorno, el resultado será el mismo que en otro entorno.
De esta forma podemos ejecutar nuestros ficheros de infraestructura como código en todos nuestros entornos (test/staging/producción) y el resultado será que tendremos tres entornos completamente iguales. Lo cual, es ideal para testear.
2 - Características de la infraestructura como código.
para comprender el poder de la infraestructura como código debemos entender varios puntos relacionados
2.1 - Infraestructura como código es código
Parece una obviedad, pero debemos de tratar nuestros ficheros de configuración como código normal y corriente. Es cierto que están escritos en JSON o YAML y que normalmente están tipados con nuestro proveedor de la nube. Pero código es código y como tal está sujeto a cambios y mejores por lo que si cambiamos algo debe haber una persona que nos compruebe que el cambio tiene sentido en una revisión del código. y por supuesto este debe estar en el controlador de versiones.
2.2 - Infraestructura como código declarativa vs imperativa
Por norma general cuando escribimos nuestro código de infraestructura lo escribimos de forma declarativa, esto quiere decir que escribimos un fichero con la configuración final que debe contener nuestra infraestructura.
Por lo tanto, estamos configurando el “qué” queremos, mientras que de forma imperativa sería el “cómo”.
Por ejemplo, queremos un servidor web con un balanceador de carga, y una alerta si el servidor está muy cargado, debemos indicarle a nuestro fichero que queremos un balanceador de carga e indicar una referencia a ese balanceador en nuestro servidor. Finalmente debemos crear una alerta con la referencia a nuestro servidor.
Al escribir de forma declarativa, el software (aws/azure/etc) ejecutará los comandos por detrás que tenga que ejecutar para asegurarse de que esa configuración se lleva a cabo.
Una forma de utilizar forma imperativa sería a través de la línea de comandos (CLI) de los mismos softwares.
2.3 - Consistente y variabilidad
El punto fuerte de la infraestructura como código es que la misma configuración ejecutada contra diferentes entornos nos devuelve el mismo resultado.
por ejemplo si ejecutamos un fichero que crea una web con un balanceador de carga, tanto en test, como staging y producción creará la web con el balanceador de carga.
Pero, qué sucede si hacemos un cambio al código, no a nuestro fichero de configuración, si no a otra parte?
Un punto muy importante es la variabilidad (Idempotence en inglés) que consiste en indicar que solo aquella información que cambia es vuelta a ejecutar.
Entonces si cambiamos un fichero en el código, nuestro balanceador de carga y nuestra web no se verán afectados por el cambio.
Mientras que si ampliamos la memoria ram de la web la configuración cambiará y por lo tanto la ampliación de ram se verá ejecutada en todos nuestros entornos.
3 - Beneficios de Infraestructura como código
3.1 - Automatizar los despliegues
Obviamente si tenemos toda nuestra configuración en ficheros, podemos automatizarlo todo para que se ejecuten y así tener CI/CD configurado.
3.2 - Consistencia en los entornos de desarrollo
Cuando queremos crear un nuevo entorno, únicamente debemos ejecutar dichos ficheros y todo funcionará a la perfección.
Y además nos permite poder ignorar todos los pasos manuales que en servidores comunes nos puede llevar horas arreglar.
3.3 - Reutilización con templates
No lo he mencionado anteriormente, pero los ficheros de configuración no son únicos, podemos tener ficheros con grupos de servicios y sus configuraciones, así como recibir variables en los mismos etc.
por ejemplo, si tenemos 100 servicios web o 100 funciones serverless no necesitamos crear 100 configuraciones de alertas cuando la memoria se queda corta o utiliza mucha cpu, sino que tenemos un fichero con un “template” donde indicamos todas las alertas y luego cada vez que indicamos una función serverless llamamos a este fichero pasando los parámetros como el nombre de la función, etc.
3.4 - Arquitectura queda documentada
Al tener toda la infraestructura como código, tendremos la misma automáticamente documentada, lo cual, es un gran paso y una forma muy buena de entender el sistema.
Conclusión
- En este post hemos visto qué es la infraestructura como código, sus características y sus beneficios.
- Personalmente indicar que, la primera vez que quieres mover tu infraestructura a la nube, lo sueles hacer con la interfaz ya que es más intuitivo, pero enseguida te das cuenta de que no tiene sentido, que todo en código es mucho mejor, ya que a la larga es más fácil de entender, y por supuesto, no te puede saltar pasos si quieres replicar la información en otros entornos.
- El único punto negativo es que la curva de aprendizaje es alta y las primeras veces parece que inviertes mucho tiempo en estos ficheros, pero a la larga ahorras cientos de horas de problemas por componentes que te has olvidado y temas así.
- Finalmente indicar a todo el mundo que es recomendable 100% y que no dudes en probar o intentar que tu empresa utilice infraestructura como código, ya que es muy útil.
