La infraestructura inmutable es un concepto que, a pesar de sus muchos beneficios, suele ser un objetivo elevado en lugar de una práctica implementada. Muchas organizaciones han considerado adoptarlo, pero a menudo se le quita prioridad en la búsqueda de un tiempo de comercialización más rápido y el envío de nuevas funciones.
Sin embargo, la infraestructura inmutable es una práctica fundamental para implementar de manera segura la infraestructura de aplicaciones a escala. Minimizar la desviación de la configuración y los cambios no deseados hace que la infraestructura de aplicaciones sea más fácil de escalar y más segura de mantener, y también mejora la postura de seguridad general.
En esta serie de dos partes, analizaremos qué es la infraestructura inmutable, por qué es más que una forma segura de implementar aplicaciones a escala y por qué es una parte importante de la estrategia de seguridad de cualquier organización.
¿Qué es la infraestructura inmutable?
El principio de la infraestructura inmutable (II) se puede resumir de la siguiente manera: una vez que se implementa la infraestructura de software, no se cambia hasta que una nueva versión, función o revisión la reemplaza por completo.
Esto parece bastante simple, pero ¿qué significa decir que la infraestructura es inmutable? ¿Cómo se ve esto en la práctica?
Una analogía común para explicar II es «ganado contra mascotas». Cuando pensamos en mascotas, pensamos en animales con nombres, comportamientos, dietas y regímenes de cuidado únicos. El ganado, por el contrario, generalmente no recibe nombres, tiende a actuar con una mentalidad de manada y es alimentado y cuidado de manera generalizada y a gran escala.
Reemplace «animales» en la analogía anterior con «servidores», y los paralelos se vuelven obvios. Los servidores, nodos o máquinas virtuales que se tratan como mascotas tienen nombres y comportamientos únicos, y la secuencia de pasos o acciones que se tomaron para llegar al estado o configuración actual no se pudo replicar fácilmente en otro nodo. Por el contrario, los servidores que se tratan como ganado generalmente se nombran como parte de un rebaño más grande, con secuencias alfanuméricas como su único identificador único. Su cuidado y alimentación, o en este caso la configuración, es un proceso escalable y repetible que se puede aplicar a los nuevos miembros de la manada para llevarlos rápidamente al mismo estado que otros miembros.
En este paradigma, los componentes de red implementados, como los servidores, no se reparan, actualizan ni modifican. Si se necesita una actualización, el componente existente se destruye y se reemplaza por uno nuevo.
El concepto de infraestructura inmutable también se extiende a los artefactos de software. Los artefactos de software generalmente se consideran un subproducto o resultado del desarrollo de software. (En el contexto de este artículo, el término «artefacto de software» se referirá específicamente a una unidad de código o funcionalidad de aplicación que se puede implementar como una función o aplicación independiente o como parte de un sistema más grande).
Los artefactos de software mutables a menudo resultan en procesos de implementación difíciles y propensos a errores. En un entorno de desarrollo hipotético, es posible que un desarrollador deba realizar pequeños cambios en su software para permitir que se ejecute correctamente en su entorno de desarrollo local, en el entorno de prueba y, finalmente, en el entorno de prueba. ¿Qué sucede si falla la implementación de producción? ¿La función original funcionó mal o fue uno de los muchos cambios realizados para que el artefacto funcionara en los diversos entornos? Los artefactos mutables dan como resultado una complejidad excesiva y hacen que la depuración de software y los problemas de infraestructura sean mucho más difíciles.
Un enfoque más inmutable, como el control de versiones de artefactos de software con etiquetas inmutables (como un hash de confirmación de Git) o el uso de contenedores para encapsular todo, da como resultado un proceso que es mucho más simple y menos propenso a errores.
¿Cuáles son los beneficios de la infraestructura inmutable?
Centrarse en hacer que la infraestructura sea inmutable proporciona una variedad de beneficios para una organización de software; simplifica los gastos generales y la complejidad de la administración, permite una mejor postura de seguridad básica y mejora los resultados operativos y la escalabilidad.
Reducir la complejidad
Explorando un poco más el ejemplo del artefacto de software, los artefactos de software inmutables ayudan a reducir la complejidad y la sobrecarga de administración en el desarrollo de software. La mayoría de las aplicaciones de software modernas ya no son solo un compilador o un intérprete; a menudo representan una red compleja de dependencias de software, varios artefactos de compilación, archivos de configuración y middleware.
Tratar de administrar todos estos componentes interconectados rápidamente se convierte en un asunto insostenible a escala; ¿Cómo pueden los equipos de desarrollo realizar un seguimiento eficaz de todas las diversas dependencias y configuraciones únicas en miles de nodos y microservicios? Con artefactos de software inmutables, todas las dependencias, los archivos de configuración y las herramientas se encapsulan en algo así como un contenedor Docker, que tiene una versión y una etiqueta únicas.
Este proceso ocurre una vez, en el momento de la compilación, y ese artefacto nunca se vuelve a cambiar, independientemente del contexto o el entorno de implementación. Si un desarrollador realiza un cambio en cualquier aspecto del artefacto, incluso una pequeña dependencia o cambio de configuración, se crea un nuevo artefacto con una nueva etiqueta de versión y se implementa sobre el anterior.
Mejorando la seguridad
La infraestructura inmutable también ayuda a los equipos de software a mantener una mejor postura de seguridad general. La inmutabilidad puede extenderse a la gestión de vías de acceso remoto tradicionales como SSH, SFTP y otros tipos de conectividad.
En los sistemas mutables heredados, los servidores se configuraban y actualizaban mediante acceso remoto manual mediante SSH o herramientas similares. El acceso SSH requiere la gestión de las cuentas de usuario y las claves SSH permitidas en cada servidor que permite el acceso. Administrar este tipo de acceso a escala a menudo significaba que los equipos de software y operaciones también tendrían que implementar y administrar la infraestructura de software de administración de configuración, lo que agregaba complejidad adicional y superficie de ataque a la pila. Cada nodo que permite el acceso remoto es un objetivo potencial para los piratas informáticos y aumenta la complejidad de la gestión.
En un patrón inmutable, las cuentas de acceso y de usuario se definen durante la configuración de la infraestructura y la fase de implementación, y nunca se vuelven a modificar sin que se implemente una nueva versión de la configuración como reemplazo completo. Las organizaciones que con frecuencia necesitan otorgar o revocar el acceso a los sistemas pueden querer explorar patrones de administración alternativos, en lugar de reemplazar su flota cada vez que se agrega un nuevo usuario. La Parte 2 de este artículo explorará con mucho más detalle varios patrones de implementación que se pueden usar para el acceso y la administración de la infraestructura.
Mejorar los resultados operativos
Mejorar los resultados operativos en las implementaciones de software debe ser un enfoque clave para cualquier organización de ingeniería. Una de las métricas clave de DORA es «Change Failure Rate: el porcentaje de implementaciones que causan una falla en la producción». Las bajas tasas de fallas en los cambios son un indicador seguro de un entorno de operaciones y desarrollo de software saludable.
Considere una implementación hipotética de software en un gran sistema distribuido. En el patrón heredado, mutable de la infraestructura, se permitió que los pequeños cambios y ajustes se acumularan con el tiempo. Esto resultó en una desviación de la configuración; en otras palabras, los sistemas en vivo ya no reflejan su estado de configuración canónicamente aceptado según lo definido por los desarrolladores y el personal de operaciones. Los cambios o implementaciones en el sistema dan como resultado comportamientos inesperados y fallas que no se pueden modelar adecuadamente en las pruebas debido a la falta de entornos homogéneos. La implementación provoca una interrupción en la producción y los ingenieros tienen que esforzarse para determinar la causa raíz. Volver a un estado de trabajo es casi imposible porque el estado de trabajo definido no refleja la realidad.
Con una implementación inmutable, se conoce y define el estado de funcionamiento actual de la infraestructura y los componentes de la aplicación; todo está claramente etiquetado con hashes de confirmación y números de versión. Si una nueva implementación de software o un cambio de infraestructura provocan una interrupción de la producción, es fácil identificar el cambio culpable. Revertir es simplemente una cuestión de restaurar el estado de funcionamiento conocido anterior. Ser capaz de minimizar el tiempo medio de resolución (MTTR) es otra métrica clave de DORA y da como resultado mejores resultados en los equipos de ingeniería y negocios.
Infraestructura inmutable en la nube
La infraestructura de software distribuida moderna a menudo se aloja en la nube. Los proveedores de la nube como AWS, Azure y Google Cloud Platform ofrecen una gran cantidad de servicios administrados y no administrados que tanto las empresas emergentes como las organizaciones empresariales pueden usar para alojar sus aplicaciones. Sin embargo, la naturaleza pública de la infraestructura en la nube trae sus propios desafíos de seguridad únicos que no están necesariamente presentes en la infraestructura local heredada. La superficie de ataque más grande significa que cualquier victoria en la reducción de la complejidad es una victoria en la postura de seguridad.
La infraestructura inmutable puede reducir la complejidad al limitar los cambios sin alcance y, en última instancia, la desviación de la configuración en el entorno. Este es un resultado de seguridad clave para los entornos de nube. La reducción de la complejidad conduce a una arquitectura de software que es más fácil de administrar, comprender y, en última instancia, segura.
Este es un buen experimento mental para la infraestructura de software: ¿podrían sus equipos de ingeniería enumerar correctamente todos los vectores de acceso que un atacante podría explotar sin mirar las cargas de trabajo activas y en ejecución? Los sistemas en vivo requieren mantenimiento y pruebas de seguridad, sin duda. Pero con una configuración de infraestructura inmutable, las organizaciones pueden comprender completamente el estado de los sistemas de producción críticos.
No todos los servicios en la nube son iguales en este sentido; es perfectamente posible crear una pila de software compleja, frágil y mutable sobre los servicios informáticos tradicionales como Amazon EC2. Basándose aún más en el ejemplo de AWS, una organización podría optar por crear contenedores inmutables, almacenarlos en Amazon ECR con etiquetas de compilación e implementarlos en Amazon ECS, proporcionando una solución mucho más inmutable.
La infraestructura inmutable no es solo una palabra de moda
La Infraestructura inmutable no es solo algo «bueno de tener»; debe considerarse un principio fundamental de la creación de una infraestructura de aplicaciones distribuida basada en la nube. Permite a los equipos de ingeniería gestionar grandes cantidades de infraestructura de forma segura y a escala. La gestión manual de cambios se atasca rápidamente y conduce a vulnerabilidades en la infraestructura mutable heredada.
