Es un hecho que las metodologías ágiles han venido para quedarse. Las empresas con visión están comenzando a recortar su Time To Market de manera drástica a la vez que aumentan la calidad de su producto final al adoptar marcos de trabajo ágiles tales como Scrum o Kanban. Pero en muchas ocasiones la infraestructura sigue siendo un cuello de botella.

El Problema

Habitualmente nos encontramos con que estas metodologías se aplican únicamente en el desarrollo de aplicaciones. Elementos tan importantes como la infraestructura, la calidad y la gestión de los datos, quedan normalmente fuera del marco de aplicación de Agile.

Es común ver equipos de programadores trabajando en sprints semanales, con ceremonias y releases al final de la semana. Pero cuando tienen que poner su producto a correr en uno de los entornos corporativos son víctimas de un proceso basado en "petición/respuesta".

Además, esta "petición/respuesta" suele necesitarse para todo: Para pedir un pase entre entornos, para pedir la creación de un entorno nuevo, para pedir cambios en la configuración y un largo etcétera.

En la mayoría de los casos son procesos burocráticos, anticuados y muy lentos: Hojas Excel enviadas por email que tienen que aprobar varias personas... ¿te suena?

Esto suele ser así porque el departamento de infraestructura (llámalo "producción" o llámalo "sistemas") está "verticalizado" y orientado a servicio.

Ocurre a menudo que este departamento no es informado de los requisitos hasta que es demasiado tarde y se acaba pidiendo una infraestructura que no estaba prevista, la cual es entregada semanas después con incontables problemas: rendimiento, capacidad, escalabilidad, resiliencia, ...

Visto así, es sencillo comprender que, desde el punto de vista del Time To Market, estamos limitando la agilidad del equipo. Pero ¿qué podemos hacer?

La Solución

Lo primero es pensar en producto y no en servicio.

El departamento de Desarrollo ya ha recibido un buen meneo para alinearse con las necesidades reales de Negocio. Se han repartido en equipos orientados a producto. ¿Por qué no hacemos lo mismo con el departamento de infraestructura?

Si las personas de este departamento formaran parte de los equipos que desarrollan los productos, cada una de ellas sólo tendría que preocuparse de su producto, de los servidores de su producto, de las redes de su producto, del almacenamiento de su producto, de las reglas de firewall de su producto, etc.

Si además formaran parte desde el principio hasta el final como uno más del equipo, podrían dar una correcta solución a los requisitos no funcionales, aceptar cambios en cualquier momento y adaptarse a las necesidades reales de la aplicación según se va desarrollando, con un control continuo de la infraestructura necesaria.

Pero claro, crear un entorno cuesta días o ¡semanas! Instalar un Sistema Operativo, plataformar una máquina, actualizarla, configurarla, requiere mucho tiempo. ¡Y los entornos tienen muchas máquinas!

Encima, una vez creado el entorno, se corrompe con facilidad,    pierde su alineación con otros entornos (¿desarrollo y producción fueron alguna vez iguales?), la ejecución de pruebas de usuario los bloquea durante semanas y un sinfín de problemas derivados de la operación manual.

Está claro: necesitamos AUTOMATIZACIÓN.

Ahora bien, la automatización sólo es posible si nuestra infraestructura está virtualizada. Pero no sólo eso, necesitamos que esa virtualización tenga un API de control.

De nada nos sirve que todo esté virtualizado si cada vez que necesitamos un elemento nuevo tenemos que entrar en las consolas de administración.

Por suerte, los proveedores de IaaS en la nube y la mayoría de sistemas para virtualizar hardware "on premise" ya nos ofrecen el API que necesitamos.

Las Herramientas

La evolución que han sufrido los procesos de desarrollo durante estos últimos años es evidente. Los programadores cuentan con herramientas para escribir código en ficheros de texto de forma paralela, distribuida y totalmente descentralizada (Git y Gitflow, por ejemplo).

¿Por qué no las aprovechamos?

Si has oído hablar de DevOps lo habrás reconocido al instante: es el acercamiento de Operaciones a Desarrollo y viceversa.

Escribir infraestructura en un fichero de texto tal y como si fueras un programador ya es posible.

Si incluimos estos ficheros de texto como parte del ciclo de vida de nuestros productos podemos tener las mismas ventajas: ¡versionado de infraestructura!, ¡gestión de dependencias de infraestructura!, ¡integración continua de infraestructura!, ¡testing automatizado de infraestructura!

Suena bien. ¿Cómo lo hacemos?

En Amazon AWS se puede usar CloudFormation.

Azure tiene Resource Manager.

Y en OpenStack existe Heat.

Estas tres soluciones son propietarias y, evidentemente, sólo funcionan con sus productos.

Pero hay una herramienta que no le importa el proveedor que tengas: Terraform.

Con Terraform puedes escribir (describir) infraestructura en ficheros de texto para cualquiera de ellas o ¡para todas a la vez!

Su lenguaje declarativo está orientado a ser escrito por humanos y es muy sencillo de aprender.

En la siguiente parte de este artículo veremos como describir con Terraform un escenario real en Azure con varios elementos típicos de una infraestructura moderna (redes, vms, balanceadores, almacenamiento).

¡Síguenos en Twitter para no perderte los próximos posts!

Por cierto, en relación con este tema tenemos un artículo en este blog sobre cómo crear configuración de entorno como dependencia usando Gradle.