No puedes implementar una infraestructura inmutable sin una arquitectura por aplicación

F5

En 2013, conocimos el concepto de servidor inmutable. Un servidor inmutable es, como sugiere el término «inmutable», estático. Su configuración es fija y no se puede (o, al menos, no se debería) modificar. Si es necesario realizar cambios, un nuevo servidor con la nueva configuración sustituye al servidor en ejecución. Esto resulta conveniente, especialmente en entornos en la nube y entornos locales altamente automatizados, porque simplifica la configuración y mejora la fiabilidad de los sistemas de automatización que gestionan los despliegues.

Este concepto funciona bien en entornos de nube y contenedores, incluso para servicios de red y aplicaciones, pero no tanto en arquitecturas tradicionales de infraestructura compartida.

Esto se debe a que la definición de infraestructura compartida implica la ejecución de varios servicios. Según los datos de F5 iHealth, «varios» puede suponer una media de 123 configuraciones individuales (servidores virtuales). No resulta práctico ni recomendable intentar detener y volver a implementar 122 de esos servidores virtuales para realizar un único cambio en un servidor virtual.

Pero eso no hace que el concepto sea poco práctico ni indeseable. La clave para adoptar una infraestructura inmutable junto con sus sistemas de automatización e infraestructura como código (IaC) es pasar a una arquitectura por aplicación.

¿Por qué usar una infraestructura inmutable?

¿Por qué emprender un cambio tan importante en la arquitectura de la red corporativa? Permítanme citarme a mí mismo, porque hoy no se me ocurre una forma mejor de expresarlo:

Por la entropía.

La ley de la entropía del software fue descrita por Ivar Jacobson et al. en «Ingeniería de software orientada a objetos: un enfoque basado en casos de uso»:

La segunda ley de la termodinámica, en principio, establece que el sistema cerrado tiene un desorden que no puede reducirse, sino que solo puede permanecer igual o aumentar. Una medida de este desorden es la entropía. Esta ley también parece aplicable a los sistemas de software; a medida que se modifica un sistema, su desorden, o entropía, siempre aumenta. Esto se conoce como entropía del software.

Esta ley también se aplica a los sistemas en los que deben instalarse actualizaciones de firmware o del sistema, en los que se implementan correcciones urgentes y parches, y en los que se realizan ajustes de emergencia en la configuración que, en un mundo perfecto, solo debería modificarse mediante un proceso de gestión de cambios seguido rigurosamente. El problema que la infraestructura inmutable (desechable) trata de resolver es que, cuantos más cambios se introducen en un sistema, más elementos obsoletos acumula y más inestable parece volverse. Desorden. Caos. Entropía.

No se trata solo de realizar cambios en la configuración para dar servicio a una aplicación o implementar parches virtuales de emergencia para alguna vulnerabilidad descubierta recientemente. Esos son buenos motivos para cambiar la configuración de un servicio de aplicaciones, pero no son los únicos. Las correcciones urgentes, los parches y las dependencias entre versiones también son buenos motivos por los que podría ser necesario cambiar una de las 123 configuraciones que se ejecutan en una infraestructura compartida.

Al adoptar una arquitectura por aplicación, se elimina la posibilidad de que una, dos o incluso diez de esas instancias afecten a las otras cien que se ejecutan en una infraestructura compartida. En esencia, proporcionar a cada aplicación su propia ruta de datos sienta las bases para adoptar un enfoque de infraestructura inmutable que facilitará la transición hacia una práctica de despliegue automatizada y basada en la infraestructura como código.

Esto implica una canalización de servicios de aplicaciones basada íntegramente en software, con servicios de aplicaciones desplegados en lo que podría considerarse una arquitectura de «microservicios de aplicaciones», similar a la forma en que se despliegan los microservicios dentro de contenedores.

Julian Dunn de Chef lo explicó muy bien en su blog: Infraestructura inmutable: ¿es práctica o no?

La infraestructura inmutable se define generalmente como una pila que se crea una sola vez (ya sea una imagen de máquina virtual, una imagen de contenedor u otra cosa), de la que se ejecutan una o varias instancias y que no se vuelve a modificar. El modelo de despliegue consiste en finalizar la instancia o el contenedor y volver a empezar desde el primer paso: crear una imagen nueva y descartar las instancias antiguas.

Así pues, si aplicamos este enfoque a los servicios de aplicación más estrechamente vinculados (afines) a una aplicación determinada, obtenemos una arquitectura de red de dos niveles: unos servicios centrales comunes y compartidos (como la protección de red frente a ataques DDoS y el acceso mediante cortafuegos tradicionales basados en puertos) que dan servicio a una «pila» específica para cada aplicación, tratada como inmutable y desplegada y gestionada según los principios de la infraestructura como código.

Pero, en realidad, no se puede adoptar un modelo inmutable sin una infraestructura específica para cada aplicación, porque es necesario desacoplar los servicios de aplicación pertinentes de sus plataformas compartidas primero. Si se puede utilizar la misma plataforma —solo que en formato de software—, este proceso resulta aún más sencillo, porque ya se dispone de gran parte de los conocimientos y las herramientas necesarios para avanzar a toda máquina hacia un modelo inmutable y específico para cada aplicación.

Aunque no estés pensando en adoptar una infraestructura verdaderamente inmutable, poder aprovecharla cuando resulte más conveniente (una nueva versión de la infraestructura, correcciones urgentes, parches, etc.) os facilitará la vida tanto a ti como a los responsables de DevOps de la aplicación a la que da soporte dicha infraestructura.

Sobre el autor

F5

Más artículos de F5