Una comparación de idempotencia e inmutabilidad

Muchos en DevOps aplican la mentalidad de ganado no mascotas mediante la implementación de infraestructura inmutable y la redistribución cuando se necesitan cambios (en lugar de modificar).

La gestión de la configuración tiene un principio similar de idempotencia . ¿Cuáles son los beneficios comparativos, las similitudes y los inconvenientes de la inmutabilidad frente a la impotencia y cuál es más eficiente? ¿Se pueden usar de forma sinérgica (por ejemplo, eliminación periódica y redistribución de máquinas virtuales o contenedores Docker mediante la gestión de la configuración)?

Los dos términos son muy diferentes.

Comencemos con immutability, lo que literalmente significa "sin mutaciones" o "sin cambios". En el sentido de DevOps, significa que una vez que haya creado un artefacto, ya sea una imagen de contenedor o una imagen de VM, o tal vez un paquete de código compilado, declara que nunca lo cambiará. A menudo, si se requieren cambios, usted declara que se creará una nueva versión de "cosa".

El término idempotencesignifica que cuando los cambios se aplican varias veces, el estado muta (cambia) solo una vez . Primero, ya supone que se aplicarán cambios, lo que significa que no se puede hacer algo inmutable y que se le hagan acciones idempotentes (no se realizan acciones por contrato).

En el uso de herramientas de gestión de configuración, idempotencese utiliza en algunos casos cuando se aplica el mismo cambio varias veces. Al igual que agregar la línea que dice localhostal /etc/hostsarchivo, realmente no necesita múltiples líneas de este tipo y si ya existe una, es seguro no intentar agregar nuevamente.

También idempotentes un término usado para describir acciones que intentan cambiar cosas, mientras que immutablese usa para describir sustantivos (objetos) que se comparan con los cambios que se les han hecho.

¿Por qué es immutableútil un objeto? Porque cuando lo copia, por ejemplo, desde un entorno de desarrollo a qa a producción. Ya sabes bastante (pero no todo) sobre cómo se va a comportar. En muchos casos, las partes que funcionan serán consistentes, y las partes que están rotas también serán consistentes.

¿Por qué son idempotentútiles las acciones? Porque cuando desea cambiar el estado de algún objeto, en muchos casos es útil verificar solo que el cambio se haya aplicado y aplicar cambios solo en caso de que sea necesario. Por ejemplo, cuando falta un elemento de configuración en un archivo o tiene un valor incorrecto, es útil agregarlo solo una vez o cambiarlo solo una vez mientras se aplica la acción varias veces. En muchos otros casos, como los archivos de registro , no desea tener acciones idempotentes porque a menudo desea agregar otra línea cada vez que ocurre algún evento.

La infraestructura inmutable es, en mi opinión, un patrón diferente a la Gestión de la configuración. Si bien pueden usarse juntos, abordan los problemas por naturaleza de dos maneras diferentes.

El concepto de artefactos inmutables tiene una larga historia, los sistemas Unix los han estado utilizando durante décadas para implementar paquetes de software. Pero una vez que se implementaron, los archivos de configuración cambiaron para que las cosas se volvieran mutables. Idempotency proporciona algunas garantías agradables con archivos mutables, podemos saber cuándo han cambiado las cosas y solo actualizar las cosas que necesitan actualizarse. Sin embargo, no resuelve todos los problemas de los objetos mutables, aún necesitamos atender un número aparentemente infinito de casos extremos. Debido a que las cosas son mutables y estamos siendo idempotentes, necesitamos establecer primero qué cambios deben hacerse, luego ejecutarlos generalmente en un orden muy específico. Al implementar paquetes de software, particularmente con implementaciones de tiempo de inactividad cero, debemos organizar cuidadosamente los cambios para evitar que se eliminen las solicitudes.

En última instancia, esta complejidad se puede evitar desplegando artefactos inmutables en lugar de mutarlos en su lugar, porque simplemente reemplazamos un objeto con otro (ya sea un binario, un contenedor o una máquina virtual), lo ponemos en servicio y retiramos el antiguo. . Este es solo un ejemplo de una implementación de tiempo de inactividad cero.

Con los avances en herramientas que nos permiten implementar artefactos inmutables en miles de sistemas en muy poco tiempo, vemos que el uso de herramientas inmutables para administrar sistemas es mucho más factible que la administración de configuración. Sin embargo, las herramientas aún no están allí y todavía hay un caso de uso para ambos. Hice una charla sobre este tema que explica la progresión lineal de completamente mutable a completamente inmutable, es un espectro y cada compañía elegirá el mejor lugar para ellos.