Uma comparação de idempotência e imutabilidade

Muitos dos DevOps aplicam a mentalidade de gado não animais de estimação implementando infraestrutura imutável e reimplantando quando mudanças são necessárias (em vez de modificar).

O gerenciamento de configuração tem um princípio semelhante de idempotência . Quais são os benefícios comparativos, semelhanças e desvantagens da imutabilidade versus impotência e qual é mais eficiente? Elas podem ser usadas de forma sinérgica (por exemplo, exclusão e reimplementação periódica de VMs ou contêineres do Docker usando o gerenciamento de configuração?)

Os dois termos são muito diferentes.

Vamos começar com o immutabilityque literalmente significa "sem mutações" ou "sem alterações". No sentido do DevOps, significa que depois de criar um artefato, seja uma imagem de contêiner, uma imagem de VM ou talvez um pacote a partir de código compilado - você declara que nunca o mudará. Frequentemente, se alguma alteração for necessária, você declara que uma nova versão de "coisa" será criada.

O termo idempotencesignifica que, quando as alterações são aplicadas várias vezes, o estado é alterado (alterado) apenas uma vez . Primeiro, ele já pressupõe que haverá mudanças aplicadas, o que significa que você não pode ter algo imutável e ações idempotentes feitas a ele (nenhuma ação é feita por contrato).

No uso de ferramentas de gerenciamento de configuração, idempotenceé usado em alguns casos ao aplicar a mesma alteração várias vezes. Como adicionar a linha que diz localhostao /etc/hostsarquivo, você realmente não precisa de várias linhas, e se uma já existir, é seguro não tentar anexar novamente.

Também idempotenté um termo usado para descrever ações que tentam mudar as coisas, enquanto immutableé usado para descrever substantivos (objetos) que são definidos com relação às alterações feitas a elas.

Por que um immutableobjeto é útil? Porque quando você copia, por exemplo, de um ambiente de desenvolvimento para qa para produção. Você já sabe bastante (mas não tudo) sobre como vai se comportar. Em muitos casos, as peças que estão funcionando serão consistentes e as que estão quebradas também serão consistentes.

Por que as idempotentações são úteis? Como quando você deseja alterar o estado de algum objeto, em muitos casos, é útil verificar apenas se a alteração foi aplicada e aplicar alterações apenas no caso de ser necessário. Por exemplo, quando um item de configuração em um arquivo está ausente ou possui o valor errado, é útil adicioná-lo apenas uma vez ou alterá-lo apenas uma vez ao aplicar a ação várias vezes. Em muitos outros casos, como arquivos de log , você não deseja ter ações idempotentes porque geralmente deseja acrescentar outra linha sempre que algum evento ocorrer.

A infraestrutura imutável é, em minha opinião, um padrão diferente do Gerenciamento de Configuração. Embora possam ser usados ​​juntos, eles abordam os problemas por natureza de duas maneiras diferentes.

O conceito de artefatos imutáveis ​​tem uma longa história, os sistemas Unix os utilizam há décadas para implantar pacotes de software. Mas uma vez implantados, os arquivos de configuração foram alterados para que as coisas se tornassem mutáveis. Idempotency fornece algumas garantias legais com arquivos mutáveis, podemos saber quando as coisas mudaram e atualizar apenas as que precisam ser atualizadas. No entanto, não resolve todos os problemas de objetos mutáveis, ainda precisamos atender um número aparentemente infinito de casos extremos. Como as coisas são mutáveis ​​e estamos sendo idempotentes, precisamos estabelecer primeiro quais mudanças precisam ser feitas e executá-las geralmente em uma ordem muito específica. Ao implantar pacotes de software, principalmente com implantações com tempo de inatividade zero, precisamos orquestrar cuidadosamente as alterações para impedir que qualquer solicitação seja descartada.

Essa complexidade pode ser evitada com a implantação de artefatos imutáveis, em vez de alterá-los, porque simplesmente substituímos um objeto por outro (seja um binário, um contêiner ou uma Máquina Virtual), colocamos em serviço e retiramos o antigo . Este é apenas um exemplo de uma implantação de tempo de inatividade zero.

Com os avanços nas ferramentas para nos permitir implantar artefatos imutáveis ​​em milhares de sistemas em um período muito pequeno, vemos o uso de ferramentas imutáveis ​​para gerenciar sistemas muito mais viáveis ​​do que o gerenciamento de configuração. No entanto, as ferramentas ainda não estão lá e ainda há um caso de uso para ambos. Fiz uma palestra sobre esse assunto, que explica a progressão linear de totalmente mutável para totalmente imutável, é um espectro e cada empresa escolherá onde melhor se encaixa para eles.