Infrastructure as code (IaC), cocinando el presente de las infraestructuras IT

El panorama IT ha evolucionado a una velocidad vertiginosa. Cada día hay nuevas aportaciones, conceptos, tecnologías y metodologías que entran en escena, cobran protagonismo y nos sacuden con sus nuevos paradigmas: que si virtualización, hibridación, cloud computing, DevOps, SRE, computación cuántica, etc.

Curiosamente, pese a la evolución que ha experimentado nuestro entorno tecnológico todos arrastramos viejas prácticas heredadas de antiguas metodologías que, aunque válidas en su momento, hoy en día están obsoletas. Hay una frase que a menudo me gusta repetirme cuando pienso en esto: No puedes parar el futuro. Tampoco puedes detener el progreso. El futuro ni siquiera es hoy, es ayer.

Es muy posible que hayáis llegado aquí buscando como gestionar eficientemente la infraestructura de vuestra empresa y qué pueden aportar nuestras metodologías en ese proceso. Eso es exactamente de lo que trata este artículo, algo fundamental y necesario en nuestro día a día cuando trabajamos con infraestructuras IT y que en Hiberus tenemos muy claro: la IaC.

¿Qué es Infrastructure as Code (IaC)?

IaC es el acrónimo de la expresión Infrastructure as Code, es decir, infraestructura como código. Se trata de un paradigma, un concepto que condensa multitud de aspectos relacionados con la automatización y buenas prácticas a la hora de diseñar, desplegar, aprovisionar y mantener una infraestructura IT. Si queremos comprender el auténtico significado de esta expresión, echemos un vistazo por separado a los dos conceptos que la componen:

• Infraestructura. Cuando hablamos de infraestructura nos referimos tradicionalmente a todos los recursos que sustentan la estructura IT de una organización. Véase: routers, switches, cabinas de discos, servidores, dispositivos de almacenamiento, sistemas de alimentación ininterrumpida, firewalls, etc.
• Código. Tratamos con un lenguaje de programación de alto nivel muy descriptivo en el que declaramos los recursos a desplegar y sus configuraciones particulares.

Si combinamos ambos términos, los batimos, les damos vueltas, los agitamos y metemos al horno, lo que obtenemos es un suculento plato basado en una receta. Y eso es precisamente de lo que trata la IaC, preparar “recetas” que se almacenan, se controlan, se gestionan, se comparten y se “cocinan” cuando es necesario.

¿Cuándo nace la IaC?

Para decidir trabajar con IaC es necesario comprender el contexto en el que nace y por qué lo hace. Hoy en día pensar en IaC es pensar automáticamente en virtualización y cloud.

Hagamos un ejercicio de imaginación: pensemos el esfuerzo que tendríamos que realizar para crear, aprovisionar y mantener la infraestructura IT de nuestra nueva empresa. La llamaremos Turing S.A. ?

Veamos cómo podemos abordar este proceso desde dos perspectivas diferentes: una más tradicional y otra orientada a la nube. ¡Comencemos!

Tradicional / On-Premise

Turing S.A. va a necesitar un CPD (centro de procesamiento de datos) para poder desarrollar su actividad comercial. Tiene que alojar en algún lugar su prometedora aplicación web. La dirección de la empresa ha decidido que va a consistir en una instalación “física”.

Centro de proceso de datos (CPD)

Este tipo de despliegue de recursos es lo que denominamos on-premise y va tener una serie de gastos y consumo de tiempo:

• CAPEX (gastos relacionados con el capital): diseño, construcción, infraestructuras y equipamiento.
• OPEX (gastos operacionales): personal, suministro eléctrico, mantenimiento, reparaciones, etc.

Seamos francos, levantar un CPD funcional toma unos pocos meses en el mejor de los casos. ¿Cuántos problemas pueden surgir en el proceso? Y, una vez que está a pleno rendimiento, ¿Cómo lo redimensionamos cuando la demanda de recursos por parte de la organización o los clientes crece? ¿Y si estas demandas no son constantes si no esporádicas? ¿Asumimos una nueva inversión sobre los recursos del CPD para que luego queden desaprovechados? ¿Provocaremos cortes del servicio para realizar la operación de actualización? Son muchas preguntas, noches sin dormir y cantidades de ingentes de café para tomar la decisión y luego llevarla a cabo.

¿Y si existiese una solución tecnológica que facilitase esta tarea? ¿Quizás algo tan sencillo como pulsar un botón mágico y desplegar infraestructura y cambios en cuestión de minutos?

Botón de despliegue automático. ?

La realidad generalmente supera con creces a la ficción. Este botón existe. Se llama nube y nos da la confianza de que nuestro proceso puede llevarse a cabo con una seguridad del 99,999999999%. Sí, once “nueves” garantizados.

Cloud

Nuestra inquieta empresa Turing S.A. desecha la idea de una instalación on-premise y ha decidido modernizarse apostando por el modelo cloud para todos sus servicios. Aquí podemos hablar de un modelo híbrido, donde coexisten recursos on-premise y en la nube, o un modelo 100% cloud.

De un “plumazo” reducimos los gastos derivados de las operaciones (OPEX) y ajustamos los asociados al capital (CAPEX). Al no haber una instalación física que mantener Turing SA. no ha de preocuparse por el alquiler del espacio, suministro eléctrico, stock de materiales, seguridad física del recinto, etc. Paga por lo que usa, ni más ni menos. ¡Genial!

Dicho y hecho. Tras semanas de ciclo de desarrollo: plan, investigación, análisis de necesidades, y desarrollo de una solución, el equipo técnico ha diseñado la arquitectura que mejor se ajusta a las necesidades de Turing S.A. cumpliendo con el marco de buena arquitectura.

Arranca el despliegue de la infraestructura. Dentro de un proveedor cloud todo el despliegue se realiza en una aplicación web que denominamos consola. Es user-friendly, bastante intuitiva en la mayoría de los casos y es capaz de darnos desbordantes cantidades de información sobre nuestros recursos instantáneamente: load CPU, gastos acumulados por uso de recursos, clicks en nuestra web, accesos de usuarios, procedencia de las peticiones, etc. (algo increíble para adictos al dato y las estadísticas).

AWS console

Así click aquí, click allá, unas cuantas definiciones, configuración de los recursos, unos cuantos tests de validación, etc. ¡Hecho!

Tiempo total invertido: unas pocas semanas. Turing S.A. está en la nube con todos los beneficios que ello conlleva. Todo llevado a cabo con una reducción de tiempo y costes más que significativo.

¿Qué papel desempeña la IaC en esta historia?

Buena pregunta. Respondámosla abordando en primer lugar su funcionamiento y posteriormente sus ventajas.

¿Cuál es el funcionamiento de la IaC?

En una primera etapa consensuamos con Turing S.A el proveedor cloud donde se va a alojar la infraestructura: Amazon Web Services (AWS), Microsoft Azure Azure, Google Cloud Platform (GCP), etc. Esta elección no es trivial para cliente ni para nosotros, pues los costos varían de un proveedor a otro y la codificación de la infraestructura va a depender de ello.

Tomemos como ejemplo la nube pública de AWS. Una vez se ha determinado el proveedor donde vamos a trabajar, nos ponemos manos a la obra. En esta etapa se establecen con claridad todos los recursos que vamos a invocar a través del código con sus correspondientes configuraciones.

Amazon Web Services, principal proveedor cloud a nivel global.

Para comenzar a trabajar necesitamos preparar nuestra lista de utensilios de “cocina”. Recordemos que trabajar con IaC es preparar recetas que luego se cocinan. Para eso necesitamos nuestras herramientas:

GitLab

Nos decantamos por este repositorio central para el código, en concreto, desplegamos nuestro propio servidor de GitLab interno. En este lugar es donde vamos a trabajar generando los archivos de configuración (.yml, .json. Ini, etc.).

Debemos entenderlo como lo que es, un almacenamiento donde todos los ingenieros y técnicos involucrados en el proyecto trabajan coordinada y sincronizadamente generando y editando nuestras valiosas “recetas” con un control de versión. Esto es extremadamente importante porque uno de los fragmentos más representativos del ADN de la IaC es la gestión y control de versiones. Saber quién, qué, cuándo y por qué ha realizado un cambio de código es fundamental. Existe trazabilidad de los errores y, por qué no, de los aciertos.

Ansible

Se trata de un software que es sinónimo de automatización. Es lo que comúnmente conocemos como un orquestador. Con él podemos gestionar el aprovisionamiento y configuración de nuestra infraestructura de una manera sencilla, remotamente. En Ansible es fundamental el concepto de inventario, pues se trata de archivos .ini, .yml o .json donde definimos los recursos sobre los que vamos a trabajar (servidores, dispositivos de red, etc.).

No podríamos pasar al siguiente párrafo sin hablar de los protagonistas absolutos: los playbooks. Se trata de los archivos de texto que contienen los estados que queremos aplicar a los recursos administrados. Por simplificarlo mucho, se trata de las configuraciones que deseamos aplicar a nuestros servidores.

Python

Aquí tenemos que hacer una pequeña diferenciación de conceptos. Python es un lenguaje de programación multiparadigma muy extendido que Ansible utiliza para ejecutarse. Por ello, es necesario tener instalado un intérprete de Python en nuestras máquinas para poder desplegar las recetas.

Teniendo estos conceptos claros solo nos queda abordar el servicio para la implementación de IaC que nuestro proveedor cloud nos proporciona. En este caso, al haber elegido AWS el servicio que utilizamos es CloudFormation.

Para poder operar sobre este servicio solo necesitamos generar un usuario programático dentro del servicio IAM de AWS con sus correspondientes access keys. Este usuario será el utilizado para realizar todas las operaciones que están declaradas en nuestro recetario. ¡Fácil y sencillo!

Resumiendo: imaginemos esta operación como preparar un menú a demanda. Utilizando diferentes herramientas elaboramos plantillas acordes a las necesidades de la plataforma del cliente.

Estas plantillas contienen declaraciones de recursos a desplegar y aprovisionar, con GitLab mantenemos un control de los cambios que realizamos en el código a través del versionado y por último, con Ansible para la automatización y servicios como Cloudformation (AWS) desplegamos esa receta en la nube generando los recursos necesarios para que nuestro cliente pueda realizar su trabajo sin preocuparse de nada más que de lo único realmente importante: su negocio.

¿Cuáles son las ventajas de la IaC?

Trabajar con Infraestructura como Código es una garantía. Sí, una garantía de éxito, control, excelencia operacional, seguridad, confiabilidad y profesionalidad. Para terminar de convencernos pensemos qué problemas puede experimentar Turing S.A. en el proceso de creación y posterior gestión de la infraestructura.

Imaginemos que Turing S.A. tiene en nómina a un excelente ingeniero de sistemas: Bill.

Bill tiene que realizar una operación sobre la infraestructura y desea que el downtime de la aplicación afectada sea el menor posible. Así que programa esta intervención de madrugada. Se levanta somnoliento, accede a la consola web del proveedor cloud, realiza sus cambios, verifica que todo funciona correctamente y vuelve a la cama.

Al despertarse por la mañana, ¡sorpresa! La aplicación web de Turing S.A. lleva caída unas horas y sus compañeros del primer turno no consiguen levantarla.

Podéis imaginaros el impacto: miles de usuarios sin acceder a un servicio por el que han pagado, decenas de usuarios que no pueden contratar ese servicio, centralita telefónica desbordada por las llamadas de clientes, jefes a punto de un ataque de ansiedad y el pobre Bill… En estado de shock.

Bill, ¿qué demonios hiciste anoche?

Bill es ordenado y riguroso en su trabajo, pero realizó numerosos cambios en diferentes servicios manualmente. Lo documentó, pero no está seguro de que algo se le haya escapado. Así que lleva ya un buen rato revisando los servicios y contrastando sus notas con los logs de aplicación sin encontrar nada que apunte claramente al motivo del error.

Menudo drama. Nuestra querida Turing S.A. cayendo en picado, perdiendo unos cuantos miles de dólares por cada hora que el servicio está caído. ¿No os recuerda a un evento acontecido recientemente?

Veamos como la IaC puede solucionar y, lo más importante, prevenir estos problemas.

Minimización de riesgos

Al centralizar y trabajar el código en un único repositorio, reducimos la variabilidad de los errores. Si algo ha salido mal en un despliegue o intervención solo hay que acudir al código, localizar la modificación realizada y deshacerla. Realizamos rollback, redesplegamos y solucionado. De esta manera los errores humanos que desembocan en malas configuraciones se reducen drásticamente.

Los compañeros de Bill no hubiesen tenido más que acceder al repositorio, comprobar las últimas modificaciones que había realizado y proceder con un rollback o, incluso, una edición de estas para solucionarlo.

Control

Sirviéndonos de una herramienta de versionado como puede ser GitLab, siempre queda claro quién, cuándo y por qué se realizó una modificación en el código. Vamos más allá. Si nuestro equipo de arquitectos de soluciones y/o sysopers se renueva, con IaC no existirá una pérdida del conocimiento de la infraestructura y su funcionamiento. Siempre va a estar disponible para consultar y desplegar aunque su desarrollador principal sea destinado a otro proyecto o abandone nuestra empresa.

Al pobre Bill le puede salir caro no haberse tomado un café de madrugada para despejarse y realizar las operaciones. Con nuestro repositorio podemos saber quién ha realizado los cambios y por qué.

Es más, si Bill abandona la empresa su conocimiento no se pierde porque toda la infraestructura está declarada. Todo debe documentarse adecuadamente, pero parte de esa documentación con la IaC es implícita, el propio código (al ser declarativo) ya presenta esa información que de otra manera estaría perdida.

Celeridad

Realizar una modificación de la infraestructura es tan sencillo y rápido como modificar una serie de líneas de código. Una vez realizado esto, lanzar el proceso de actualización consiste en ejecutar un comando de Python en Shell con los parámetros que estimemos oportunos. En cuestión de minutos nuestra infraestructura en la nube ha cambiado.
Permitamos volar nuestra imaginación e imaginemos que nuestra empresa imaginaria se ha recuperado del “batacazo” que la intervención de Bill provocó (no os preocupéis por Bill, la dirección de la empresa es comprensiva y comprenden que un error lo puede tener cualquiera).

El volumen de negocio ha crecido exponencialmente. La empresa está experimentando tal demanda de sus servicios y productos que se está planteando abrir nuevas sucursales en diferentes localizaciones globales siguiendo el modelo de la sede central.

¿Cuánto tiempo va a tomar levantar estas nuevas infraestructuras IT?

Muy sencillo, nuestro ingeniero Bill solo tendrá que recabar unos pocos datos sobre el proveedor de servicios para la nueva delegación, modificar unos pocos parámetros en los archivos del repositorio de la IaC, lanzar el correspondiente comando desde su terminal y… ¡Listo! ¡Infraestructura desplegada en cuestión de horas!

Hiberus + IaC

En Hiberus Sistemas nos gusta hacer las cosas bien y, como habéis podido comprobar, IaC es sinónimo de ello. No concebimos realizar nuestro trabajo alejándonos de este paradigma y siempre es un servicio que ofrecemos a nuestros clientes.

Evidentemente codificar una infraestructura es un proceso más costoso en términos temporales que desplegarla manualmente. Pero, sinceramente, pensamos que es la mejor manera de hacerlo. IaC significa algo más: tranquilidad y confianza.

Tranquilidad para cliente, pues sabe que las nuevas características que desee implementar en su aplicación serán desplegadas con garantías y celeridad. Esto es fundamental pues permite al cliente preocuparse por lo verdaderamente importante: su negocio.

Ya lo hemos implementado para clientes como Diario de Navarra, La Vanguardia o Heraldo de Aragón, entre otros. Si quieres contactar con nosotros, te ayudamos a mejorar el funcionamiento de tu negocio.