Es un hecho que las metodologas giles han venido para quedarse.

Las empresas con visin

estn comenzando a recortar su Time To Market de manera drstica 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 metodologas se aplican nicamente en el
desarrollo de aplicaciones. Elementos tan importantes como la infraestructura, la calidad y
la gestin de los datos, quedan normalmente fuera del marco de aplicacin de Agile.

Es comn 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 vctimas de un proceso basado en "peticin/respuesta".

Adems, esta "peticin/respuesta" suele necesitarse para todo: Para pedir un pase entre
entornos, para pedir la creacin de un entorno nuevo, para pedir cambios en la
configuracin y un largo etctera.

En la mayora de los casos son procesos burocrticos, 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 (llmalo "produccin" o llmalo

"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 despus 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 Solucin
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 slo tendra 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 adems formaran parte desde el principio hasta el final como uno ms del equipo,
podran dar una correcta solucin a los requisitos no funcionales, aceptar cambios en
cualquier momento y adaptarse a las necesidades reales de la aplicacin segn se va
desarrollando, con un control continuo de la infraestructura necesaria.

Pero claro, crear un entorno cuesta das o semanas! Instalar un Sistema Operativo,
plataformar una mquina, actualizarla, configurarla, requiere mucho tiempo. Y los entornos
tienen muchas mquinas!

Encima, una vez creado el entorno, se corrompe con facilidad, pierde su alineacin con
otros entornos (desarrollo y produccin fueron alguna vez iguales?), la ejecucin de
pruebas de usuario los bloquea durante semanas y un sinfn de problemas derivados de
la operacin manual.

Est claro: necesitamos AUTOMATIZACIN.

Ahora bien, la automatizacin slo es posible si nuestra infraestructura est virtualizada.

Pero no slo eso, necesitamos que esa virtualizacin 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 administracin.

Por suerte, los proveedores de IaaS en la nube y la mayora de sistemas para virtualizar
hardware "on premise" ya nos ofrecen el API que necesitamos.
Las Herramientas
La evolucin que han sufrido los procesos de desarrollo durante estos ltimos aos es
evidente. Los programadores cuentan con herramientas para escribir cdigo en ficheros de
texto de forma paralela, distribuida y totalmente descentralizada (Git y Gitflow, por
ejemplo).

Por qu no las aprovechamos?

Si has odo hablar de DevOps lo habrs 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!, gestin
de dependencias de infraestructura!, integracin continua de infraestructura!, testing
automatizado de infraestructura!

Suena bien. Cmo 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, slo 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 artculo veremos como describir con Terraform un escenario
real en Azure con varios elementos tpicos de una infraestructura moderna (redes, vms,
balanceadores, almacenamiento).
Sguenos en Twitter para no perderte los prximos posts!