Infraestrutura imutável
Infraestrutura imutável é uma regra simples: componentes em execução não são alterados. Para mudar qualquer coisa — versão da aplicação, pacote do sistema, configuração — cria-se uma instância nova a partir de uma imagem versionada e descarta-se a antiga.
O contrário é o modelo mutável, em que o servidor vive por anos recebendo apt upgrade,
edições de arquivo e correções manuais.
Estimação e gado
Seção intitulada “Estimação e gado”A metáfora conhecida: no modelo mutável, servidores são animais de estimação — têm
nome, história e alguém que sabe seus segredos. Ninguém reinicia srv-web-01 sem ansiedade,
porque não se sabe se ele volta.
No modelo imutável, são gado: numerados, intercambiáveis, substituídos sem cerimônia. O que existe de valioso não é a instância — é a imagem e o código que a geram.
O que a imutabilidade elimina
Seção intitulada “O que a imutabilidade elimina”Deriva de configuração. No modelo mutável, cada servidor acumula uma história própria de correções aplicadas às pressas. Com o tempo, servidores que deveriam ser idênticos se comportam de forma diferente — e o bug que aparece só em um deles consome dias.
A pergunta “o que tem nesta máquina?”. A resposta passa a ser a imagem, que está versionada e é a mesma em todos os ambientes.
Rollback complicado. Voltar é subir a imagem anterior, não desfazer alterações.
Ambiente irreprodutível. Se a única forma de recriar o servidor for a memória de alguém, você não tem infraestrutura, tem arqueologia.
Container é a expressão mais familiar dessa ideia, mas ela é anterior: imagem de máquina construída no pipeline e node group substituível funcionam do mesmo jeito.
O custo
Seção intitulada “O custo”Ser honesto sobre o preço:
- Build mais pesado. Toda mudança, por menor que seja, exige gerar e distribuir um artefato novo. Trocar uma linha de configuração vira um ciclo completo.
- Distribuição. Imagens grandes custam tempo e banda em cada deploy — o que torna imagem enxuta uma preocupação prática.
- Diagnóstico diferente. “Entrar na máquina e olhar” deixa de ser o caminho padrão; é preciso observabilidade decente e containers efêmeros de depuração.
- Emergência. Aplicar uma correção urgente pelo pipeline leva mais tempo que editar um arquivo. Vale a pena mesmo assim — a alternativa é a correção que ninguém registrou.
- Estado. Precisa ser explicitamente externalizado, o que é trabalho de projeto.
Onde ela não se aplica
Seção intitulada “Onde ela não se aplica”Nem tudo pode ser descartado e recriado.
Bancos de dados têm estado por definição. Você pode ter binário e configuração imutáveis, mas o dado persiste — e é por isso que upgrade de banco continua sendo procedimento, não substituição.
Sistemas legados que exigem instalação manual, licença atrelada ao host ou configuração feita em interface gráfica. Forçar imutabilidade neles costuma custar mais que o benefício.
Equipamento físico e appliances, que não se recriam por API.
A fronteira útil: computação é descartável, dado é preservado. Deixe essa linha explícita no desenho do sistema — a confusão entre os dois lados é a origem de boa parte dos incidentes com perda de dado.
A regra que sustenta tudo
Seção intitulada “A regra que sustenta tudo”Imutabilidade só funciona com disciplina: não altere o que está rodando. Uma única correção manual em produção, feita durante um incidente e não registrada, some no próximo deploy — e volta o comportamento que ninguém entende.
Se a emergência exigir a correção manual, ela é temporária por definição: abra o pull request no mesmo dia. É a mesma disciplina que vale para IaC, pelo mesmo motivo — o código precisa continuar sendo a verdade.