Uma comparação de idempotência e imutabilidade


8

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?)

Respostas:


9

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.


1
idempotência também implica pesudo-onipotência por causa de sua natureza repetitiva. Se um usuário alterar algo fora do sistema de gerenciamento de configuração, provavelmente será alterado novamente (se o sistema de gerenciamento de configuração for executado como root). Portanto, isso não significa apenas, the state is not changed.mas que o estado permanece da maneira que o sistema de gerenciamento de configuração determina. Por isso, os sistemas de idempotentes de sentido único e sistemas imutáveis são semelhantes
James Shewey

Você descreve uma propriedade dos sistemas de gerenciamento de configuração, talvez a "teoria da promessa". Mas não é o que significa idempotência, a idempotência é apenas uma ferramenta no arsenal do sistema de gerenciamento de configuração. Depois que você começa a mudar de estado, modificando as coisas de qualquer maneira, elas não podem ser parecidas com a imutabilidade. É uma contradição.
Evgeny

Onipotência @ JamesShewey significa poder ilimitado, duvido que idempotência signifique algo relacionado a isso.
Evgeny #

onmi = muitos | idem = repetido | potência = poder. Ambos compartilham a mesma raiz, indicando que algo (uma configuração) foi feito. Portanto, ao fazer a mesma coisa repetidamente, se uma alteração é tentada, ela é substituída pelo sistema de gerenciamento de configuração, tornando-a onipresente em potencial. (e eu tenho certeza que isso pode ser hackeado, digamos, desativando o serviço de gerenciamento de configuração, portanto, não é realmente onmi). Esta propriedade pode ser usada para definir um estado imutável.
James Shewey #

1
Once you start changing state- Se você alterar o estado com o sistema de gerenciamento de configuração, sim, em seguida, torna-se contraditório. A presença e o uso de um sistema de gerenciamento de configuração não são mutuamente exclusivos com imutabilidade - é tudo na maneira como você escolhe usá-lo.
precisa saber é o seguinte

2

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.


Você tem um vídeo da conversa com a qual você poderia criar um link?
James Shewey

1
Ele está vinculado no post youtube.com/watch?v=I3DuUzGC-SU
Robo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.