A peça invisível
Quando uma ferramenta de infraestrutura como código cria um servidor, anota em algum lugar que «este servidor do código corresponde a este recurso real, com este identificador». Esse registo é o estado. Graças a ele, na vez seguinte sabe o que já existe, o que mudou e o que tem de criar ou apagar.
Enquanto tudo funciona, ninguém pensa nele. Quando se perde, se corrompe ou duas pessoas o modificam ao mesmo tempo, a ferramenta deixa de saber o que é seu, e as consequências vão desde duplicados até eliminações que ninguém pediu.
Regras para o estado
Nunca num portátil. O estado vive num armazenamento partilhado e remoto, não na máquina de quem executou a última mudança.
Com bloqueio. Enquanto alguém aplica uma mudança, mais ninguém o pode fazer. Duas mudanças simultâneas sobre o mesmo estado são a receita clássica para o corromper.
Com versões. Cada mudança do estado guarda uma cópia da versão anterior. Se algo correr mal, pode voltar-se atrás.
Cifrado e com acesso restrito. O estado pode conter dados sensíveis (endereços, identificadores, às vezes valores que o fornecedor devolve). Trata-se como mais um segredo.
Dividido por âmbito. Um estado gigante para toda a organização faz com que cada mudança seja lenta e arriscada. O saudável é separar por ambiente e por área (rede, dados, aplicações), de modo que um erro num não alcance os restantes.
Ninguém o edita à mão
O estado modifica-se apenas através da ferramenta. Editá-lo à mão para «arranjar» algo é como mudar o registo contabilístico para que bata certo: o problema fica escondido, não resolvido. Se o estado e a realidade discrepam, investiga-se porquê e corrige-se com os comandos previstos para isso.
Com o estado sob controlo, o problema seguinte é de escala: como descrever vinte ambientes sem copiar vinte vezes o mesmo código.
Como o aplicamos: Automação e IaC.