No se puede hacer una infraestructura impecable sin una arquitectura por aplicación

En 2013, nos presentaron el concepto de servidor inmutable . Un servidor inmutable es, como el término inmutable sugiere, estático. Su configuración es fija y no puede (o al menos no debe) modificarse. Si se requieren cambios, un nuevo servidor con la nueva configuración reemplaza al servidor en ejecución. La razón por la que esto es deseable, particularmente en entornos de nube y locales altamente automatizados, es que simplifica la configuración y mejora la confiabilidad de los sistemas de automatización que impulsan las implementaciones.

Este concepto funciona bien en entornos de nube y contenedores, incluso para servicios de red y aplicação , pero no tan bien en arquitecturas de infraestructura compartida tradicionales.

Esto se debe a que la definición de infraestructura compartida implica múltiples servicios en ejecución. Según datos de F5 iHealth , "múltiple" puede significar un promedio de 123 configuraciones individuales (servidores virtuales). No es práctico ni recomendable que intente detener y volver a implementar 122 de esos servidores virtuales para realizar un solo cambio en un servidor virtual.

Pero eso no hace que el concepto sea imprá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é una infraestructura inmutable?

¿Por qué emprender un cambio tan significativo en la arquitectura de la red corporativa? Permítanme citarme a mí mismo , porque no puedo pensar en una mejor manera de reformularlo hoy:

Porque, entropía.

La ley de la entropía del software está 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 desorden de un sistema cerrado no puede reducirse, sólo puede permanecer inalterado o aumentar. Una medida de este desorden es la entropía . Esta ley también parece plausible para los sistemas de software : a medida que se modifica un sistema, su desorden o entropía siempre aumenta. Esto se conoce como entropía de software.

Esta ley también se aplica a los sistemas para los cuales se deben aplicar actualizaciones de firmware o de nivel de sistema. Para los cuales se implementan correcciones y parches. Para lo cual se realizan ajustes de emergencia a la configuración que, en un mundo perfecto, solo se deberían cambiar mediante un proceso de gestión de cambios seguido estrictamente. El problema que la infraestructura inmutable (desechable) intenta resolver es que, cuanto más cambios se introducen en un sistema, más frágil e inestable parece volverse. Desorden. Caos. Entropía.

No se trata solo de realizar cambios en la configuración del servicio de una aplicación o de implementar parches virtuales de emergencia para alguna vulnerabilidad descubierta recientemente. Éstas son buenas razones para cambiar la configuración de un servicio de aplicação , pero no son las únicas. Las correcciones urgentes, los parches y las dependencias de versiones también son buenas razones por las que podría ser necesario cambiar una de las 123 configuraciones que se ejecutan en la infraestructura compartida.

Al cambiar a una arquitectura por aplicación, se elimina la posibilidad de que una, dos o incluso diez de esas instancias se vean afectadas por las otras cien que se ejecutan en la infraestructura compartida. Darle a cada aplicación su propia ruta de datos, esencialmente, prepara el escenario para apoyar un enfoque de infraestructura inmutable que respaldará mejor el avance hacia una práctica de implementación automatizada y basada en infraestructura como código.

Esto significa una canalización de servicios de aplicação completamente basada en software, con servicios de aplicação implementados en lo que es en gran medida una arquitectura de “microaplicación-servicio”, similar a cómo se implementan los microservicios dentro de contenedores. 

Julian Dunn de Chef lo expresó bien en su blog – Infraestructura Inmutable: ¿Práctico o no?

La infraestructura inmutable generalmente se define como una pila que se construye una vez (ya sea una imagen de máquina virtual , una imagen de contenedor u otra cosa), se ejecuta una o muchas instancias y nunca se vuelve a cambiar. El modelo de implementación es finalizar la instancia/contenedor y comenzar de nuevo desde el paso uno: crear una nueva imagen y descartar las instancias antiguas.

Entonces, si aplicamos eso a los servicios de aplicação que están más estrechamente acoplados (afines) a una aplicação dada, terminamos con una arquitectura de red de dos niveles que comprende servicios compartidos comunes centrales (como DDoS de red y acceso a través de firewalls tradicionales basados ​​en puertos) que alimentan una "pila" por aplicación que se trata como inmutable y se implementa/administra utilizando conceptos de infraestructura como código.

Pero realmente no se puede lograr algo inmutable sin una infraestructura por aplicación porque primero es necesario desacoplar los servicios de aplicação relevantes de sus plataformas compartidas . Si puede usar la misma plataforma, solo que en un formato de software, este proceso se vuelve aún más fácil porque ya tiene muchos de los conocimientos y conjuntos de herramientas que necesita para avanzar a toda máquina hacia un modelo inmutable por aplicación.

Incluso si no está considerando una infraestructura verdaderamente inmutable, la capacidad de aprovecharla cuando tenga más sentido (nueva versión de la infraestructura, correcciones, parches, etc.) hará que la vida sea más fácil tanto para usted como para los propietarios de DevOps de la aplicación que la infraestructura respalda.