Duas formas de pedir o mesmo
Suponha que precisa de três servidores atrás de um balanceador. Há duas maneiras de o escrever.
Ordenando (um script): cria um servidor, cria outro, cria um terceiro, cria o balanceador, liga os três. Funciona à primeira. E à segunda? Cria mais três servidores. E se já havia dois? Cria três, e ficam cinco. E se falhar no passo quatro? Fica a meio, e é preciso adivinhar o que foi feito.
Declarando (infraestrutura como código): «devem existir três servidores deste tamanho atrás de um balanceador». Uma ferramenta compara o declarado com o que existe e faz apenas o que falta.
Porque declarar é mais seguro
- Pode repetir-se sem medo. Executar duas vezes o mesmo deixa o mesmo resultado. Se já está como deve, não se mexe em nada.
- O existente respeita-se. Se dois dos três servidores já existem, só se cria o terceiro.
- As falhas recuperam-se. Se algo falhar a meio, volta-se a executar e a ferramenta continua de onde ficou.
- O código lê-se como uma descrição. Quem o abre vê o que há, não uma receita que tem de executar na cabeça para a entender.
Quando se continua a precisar de ordenar
Algumas tarefas são passos por natureza: migrar dados, rodar uma chave, reiniciar serviços numa ordem concreta. Para essas, os scripts continuam a ser a ferramenta adequada, com duas condições: que verifiquem antes de agir (não criar o que já existe) e que se possam repetir sem quebrar nada.
Declarar o que deve existir tem uma consequência prática: a ferramenta precisa de se lembrar do que criou e de como o relaciona com o código. Essa memória é o estado.
Como o aplicamos: Automação e IaC.