Infraestructura Inmutable. Qué es y por qué deberíamos implantarla en nuestra organización

A través de este artículo se pretende explicar qué es y en qué se basa el concepto de Infraestructura Inmutable, sus principales ventajas y cuáles son las aproximaciones por las que podemos optar para poder implantarlo en nuestra organización.

Índice de contenidos


1. Introducción

La reducción drástica del coste del hardware unido a la explosión de proveedores de infraestructura en la nube (IaaS) han sido el hilo conductor de lo que se conoce como Infraestructura Inmutable. En este artículo descubrirás en qué se basa este concepto y cuáles son las espectaculares ventajas de uso.


2. ¿Qué es infraestructura inmutable?

El concepto de infraestructura inmutable deriva del concepto de programación “Inmutabilidad”, es decir, que una vez se crea o se instancia algo, éste nunca será modificado.

En base a este concepto, la infraestructura o el contenedor donde se va a ejecutar nuestra aplicación también forma parte de nuestro producto, y no solamente la aplicación en sí misma.

Esto significa que una vez la instancia esté funcionando, esta no se verá modificada. Cuando se requiera la aplicación de algún cambio una nueva instancia será creada, pero la anterior seguirá estando disponible por si hubiera que hacer rollback del propio entorno.

Con esto conseguimos crear versiones del entorno completo de una forma controlada y segura, que puede además ser fácilmente versionables y ubicadas en el tiempo, eliminando los problemas derivados de las instancias “rotas” casi por completo.

Además de ello, gracias al nivel de capacidad de virtualización de los sistemas operativos, concepto fundamental donde se apalanca el concepto de infraestructura inmutable, estas imágenes pueden ser desplegadas de forma casi instantánea.

immutable_infrastructure-animated-gif

Fuente: O’Reilly Media


3. ¿Por qué surge el concepto de infraestructura inmutable?

Básicamente por los problemas, y por lo tanto, costes asociados a la administración y mantenimiento de la infraestructura mutable. A continuación es planteo una lista de motivos por los que el mantenimiento artesanal de la infraestructura compuesta por componentes tradicionales de larga duración (y por lo tanto mutable) es insuficiente para las tareas de operación en un entorno de servicios distribuidos en la nube:

  • Incremento de la complejidad operacional: Con la implantación de las arquitectura de servicios distribuidos y la necesidad de escalado dinámico, hacen extremadamente complejo el encargarse de todas esas máquinas. Usando los métodos tradicionales de mantenimiento para actualizaciones o parches por cientos de miles de instancias es difícil, propenso a errores y un desperdicio de tiempo.

  • Despliegues más lentos, incremento de fallos: Cuando la infraestructura está compuesta de componentes “copos de nieve” (que cada uno de ellos tiene una configuración única, artesanal) derivados de los métodos tradicionales de mantenimiento (a través de scripts o herramientas de gestión de la configuración), existen muchas más probabilidades de que algo vaya mal.

  • Identificación de errores y amenazas para mitigar el daño: Los sistemas mutables de larga duración se apoyan en la identificación de errores o amenazas para prevenir el daño. Es de sobra conocido que esta tarea es imposible de realizar, puesto que existe una gran incertidumbre de lo que le pueda a pasar al sistema en el futuro. No sabemos lo que no conocemos. No podemos tener todas las casuísticas bajo control.


4. ¿Por qué hacer que nuestras aplicaciones sigan el patrón de infraestructura inmutable?

Los beneficios de la infraestructura inmutable son numerosos, siempre y cuando se aplique de forma conveniente a tu aplicación, se disponga de un entorno completamente automatizado y existan formas de recuperación de la infraestructura. A continuación te detallo una lista de los principales beneficios:

  • Simplificación de operaciones: Si se dispone de un método de despliegue completamente automatizado, es posible renovar los componentes de la aplicación de tal forma que no sea necesario llevar un control de los cambios que han ocurrido en la instancia.

  • Despliegues continuos, disminución de fallos: Con infraestructura inmutable, es posible saber qué se está ejecutando y cómo se comporta, haciendo que los despliegues de las actualizaciones sean rutinarios y continuos, disminuyendo así los fallos en producción. Cada uno de los cambios es registrado en el repositorio de código y en los procesos de Continuous Integration / Continuous Deployment.

  • Reducción de errores y amenazas: En general, la compleja pila de hardware y software en la que se apoya los servicios que desplegamos tiende a degradarse con el tiempo. Disponer de una forma automatizada de sustitución de esa pila en vez de estar manteniéndola, hace que se reduzca drásticamente la deriva de la configuración, las fallas de seguridad y el esfuerzo necesario para cumplir con los SLAs

  • Reinicios de la Nube sin impacto: Si nuestra infraestructura es inmutable sabemos en todo momento qué estamos ejecutando, y que disponemos de métodos de recuperación completamente automatizados que permiten que los reinicios de las instancias donde se albergan las aplicaciones deberían ser totalmente transparentes para la propia aplicación.


5. ¿Cómo implementar Infraestructura Inmutable en nuestro producto?

Con los servidores inmutables, la transición de estados desaparece ya que se realiza una reconstrucción completa todo el tiempo. Tras cada uno de los commits, se crea una imagen, de despliega y se testea. Una vez que es testada, la imagen puede ser copiada N veces, y seguirá funcionando como se espera.

Para lograr esto existen dos aproximaciones:

  • Imágenes ‘Golden’ dinámicas: Cada vez que se hace un commit, se crea una instancia en la nube, se provisiona y de obtiene una imagen. Esta imagen es el artefacto que se desplegará en los diferentes entornos. En caso de que se requiera auto-escalado, es necesario actualizar la configuración para instalar la nueva imagen.

  • Contenedores: Con los contenedores, el concepto es muy similar. Sin embargo, éstos son mucho más ligeros y tardan mucho menos en arrancar. Se provisiona una imagen que es publicada en un repositorio. Desplegar el contenedor es arrancar tu aplicación.

En cualquiera de los dos casos, todos los procesos deberían estar automatizados end-to-end, y ser parte de un Pipeline de Continuous Delivery. El servidor de Continuous Integration debería detectar los cambios en el repositorio de código (aplicación y/o infraestructura) y ejecutar una serie de scripts para construir y publicar la imagen.

large-container-vessel-ship-and-horizon

Fuente: InfoWorld


6. Conclusiones

  • Una infraestructura inmutable es un patrón para administrar servicios cuya infraestructura se divide en “aplicación” y “todo lo demás”. Los componentes “todo lo demás” son reemplazados en cada despliegue.

  • Aplicar infraestructura inmutable es una forma de simplificar la administración de las actualizaciones: los servidores nunca se corrompen y permite pensar en una aplicación como un único artefacto desplegable.

  • Para adoptar un modelo de infraestructura inmutable es necesario disponer de una infraestructura basada en Cloud, orientando las aplicaciones a imágenes que contengan tanto los datos como el servidor en un solo artefacto.

¿Habéis implantado un modelo de infraestructura inmutable en vuestra organización?

Cuéntanos tus experiencias dejándome un comentario en el artículo o a través de mi cuenta de Twitter: @drodriguezhdez


7. Referencias