Síguenos:
Cloud
3 de Noviembre de 2016

Infraestructuras inmutables o cómo lo único estable es el cambio

Infraestructuras inmutables o cómo lo único estable es el cambio

Infraestructuras inmutables o cómo lo único estable es el cambio

Escrito por , 3/11/2016

Hace ya casi dos años que escribí en este blog sobre los nuevos modelos de desarrollo de aplicaciones, sus implicaciones en los equipos de operaciones y los nuevos modelos de gestión que se vislumbraban en el horizonte. Y lo cierto es que, en la actualidad, las infraestructuras inmutables o el software defined infrastructure está cada vez más extendido. Ya no solo Amazon o Facebook se encargan de realizar cientos o miles de cambios en sus páginas webs para mejorar la experiencia de usuario, la calidad de servicio o el despliegue de nuevas funcionalidades. Como bien reza el dicho, lo único constante es el cambio y mucho más para un departamento de sistemas.

Días atrás un compañero mencionaba un nuevo palabro que llamó mi atención: “infraestructuras inmutables”. Después de sacar el manual del buen friki, revisé y no encontré mención alguna al nuevo término. Así que pase al plan B y ejecuté el procedimiento de emergencia: abrí el navegador e hice la búsqueda pertinente. La verdad es que Google nos muestra una realidad muy fiel sobre la popularidad de un término y me sorprendió su escasa popularidad: si comparamos el número de resultados de una búsqueda como cloud computing (75,6 M), DevOps (18M) o continuos delivery (14,7 M), frente a los devueltos para inmutable infraestructure (0,4 M) llama la atención lo poco extendido que está.

Según Gartner, las infraestructuras inmutables son un patrón de arquitectura en el cual la aplicación y la infraestructura que la sustentan, una vez desplegadas, nunca volverán a ser actualizadas. De hecho, cuando sea necesario realizar un cambio en la infraestructura ésta será reemplazada desde cero. Como comentaba al principio del artículo, este tipo de arquitecturas está pensado para desarrollar metodologías DevOps y CDCI (Continuos Delivery and Continous Integration). Una de sus características principales es la simplicidad, tanto: desde el punto de vista de las arquitecturas de la propia aplicación como en lo que concierne a la configuración de los sistemas, que podríamos llegar a definir como minimalista.

Las infraestructuras inmutables están íntimamente relacionadas con las API (Application Programming Interface) o las interfaces de programación de aplicaciones, en este caso la API que proporcionan los servidores de cloud pública (ya sea en sus servicios de IaaS o PaaS). El uso de las API se centra en la simplificación y automatización de los despliegues de este tipo de infraestructuras; el objetivo final es que cada uno de los elementos de la misma sea invocado desde la API, ya sea una imagen o un servicio de balanceo de carga del propio servicio de cloud pública. La filosofía de este tipo de infraestructuras podría resumirse en: “define sencillo, regenera después de cada cambio y promociona entre los diferentes entornos”.

A continuación me detendré en cada una de las partes de esta premisa.

-” Define o crea sencillo”. El objetivo principal es definir la unidad mínima basada en el principio de minimalismo. En la actualidad seguimos trabajando con arquitecturas de los años 80; construimos los servicios en diferentes pilas de hardware, sistema operativo, lenguaje de programación y la propia aplicación. Y en cada una de estas capas incorporamos todos los elementos necesarios para cuidar de los servicios como si fuesen nuestros propios hijos, con todo lo necesario para que subsistan solos en la selva que es el data center o Internet. Para ello, como buenos padres, les proporcionamos la consola de gestión remota para poder acceder a los mismos y ver en qué estado se encuentran, sistemas de parcheo para poder mantenerlos actualizados, antivirus para que estén sanos y salvos, su repositorio de logs para que en caso de que exista un problema podamos realizar un análisis forense de cuál ha sido la causa raíz del mismo y así un largo etcétera de capas adicionales que provocan que cuando vamos a definir una plantilla de la configuración del sistema haga totalmente incompatible mover imágenes de GB de información entre un servicio de cloud pública y nuestro data center, o entre el proveedor A y el B, en caso de que necesitemos diferentes localizaciones.

Desde el enfoque de las infraestructuras inmutables, la pregunta es la siguiente: ¿realmente necesitamos todos estos servicios que corren en nuestros sistemas, si el objetivo es remplazarlos desde cero una vez que definamos un cambio? Y la respuesta evidente es: no. ¿Para qué queremos una consola de gestión si nunca vamos a acceder al equipo?, ¿para que necesitamos un repositorio de logs locales, si llegado el momento lo vamos a matar y no vamos a poder auditar en caso de fallo?, ¿no será mejor crear un repositorio general y almacenar los logs de toda la aplicación de forma centralizada? El objetivo final es aligerar al máximo cada una de los servicios auto arrancables (bootable) para facilitar el despliegue y reducir los tiempos de provisión, tened en cuenta que vamos a crear y matar servicios en un data center probablemente más veces en un año de lo que algunas empresas lo hayan hecho en toda su vida.

-Regenera después de cada cambio se refiere a que, una vez que dispongamos de una nueva versión de la aplicación, el objetivo es desplegar desde cero y aplicar los cambios de arquitectura necesarios en ese despliegue, haciendo convivir la versión actual de la misma y migrando progresivamente a los usuarios a la nueva versión. El plan B siempre será regresar a la versión previa para recomponer un fallo o error, y volver a desplegar desde cero en caso de necesidad.

– Todo ello respetando la última parte de la premisa de promocionar los cambios entre los distintos entornos de desarrollo, calidad y producción, al igual que haríamos en cualquier otra infraestructura.

Como podéis ver, las infraestructuras inmutables están mucho más cerca del software que del hardware y, a partir de ahora, los despliegues de plataformas cloud serán cada vez más cercanos a la creación de un script que a la instalación de software y configuración de parámetros en el servidor. Y, como muchos analistas creen, el gran acelerador de todo este tipo de plataformas será el uso de los contenedores.

¿Vosotros estáis ya utilizando API en el despliegue de los servicios cloud?

Imagen: Namelas Frade

 

 

 

 

 

 

Sobre el autor

Alejandro de Fuenmayor

Alejandro de Fuenmayor

Ingeniero de Telecomunicación y MBA, apasionado de la música, el deporte y la tecnología. Vivo en las nubes desde hace ya unos cuantos años. Convencido de que las TIC tienen que hacernos la vida aún más divertida.
Ver todos sus artículos »