Terraform, Pulumi e Cloud Formation
Tags: iac, devops, terraform, aws
Published: 2020-02-01 16:48:39

Terraform, óbvio. No entanto, tenho arriscado há algum tempo a travar contato com as outras duas ferramentas que no fim das contas se propõe a fazer o mesmo, isto é, manipular recuros cloud.

Pulumi

O Pulumi foi criado no intuito de criar recursos na nuvem, mas com uma breve e crucial diferença, na camada das sintaxes, a ferramenta abstrai para outras linguagens, como Go, Python, Java e etc. Então, voce que já é desenvolvedor, não precisa se preocupar em novamente aprender uma outra linguagem como a do Terraform, que possui seus próprios paradigmas.

Mas, pontuo dois contras: o primeiro se trata da verbosidade, mesmo que se use linguagens high-level e simples com Python para escrever suas chamadas de recursos, as chamadas de variaveis e funcões, torna-a cansativa, laborosa e pode ser um pouco cansastivo na hora de debugar, já que todas as exceções se dão na camada da própria linguagem. O segundo é que a necessidade de ter que usar virtual env’s para ambientes simples a objeta com mais uma coisa trivial a ser feita, e no dia-a-dia ninguem quer perder tempo com trivialidades.

Terraform

Bem, Terraform agora ahn, antes das ‘cheat-shits’ considero que os produtos da Hashicorp vieram cada uma em seu tempo hábil para ajudar a comunidade, foi assim com Vagrant, Vault, Consul e agora com o Packer, as possibilidades de usar módulos remotos, trocar facilmente de ambientes, integraçoẽs com CI, recuperação de estado, securidade usando tabelas na nuvem e etc. As possibilidades são muitas, literalmente empresas tem mantido suas plataformas e infraestruturas apenas com Terraform, e de tempos em tempos alguma nova biblioteca ou sub-ferramenta que podem usadas em conjunto aparecem como Terraforming, Terragrunt, Terra Test e outras.
Pois bem, é claro que deve se notar os problemas que uma simples má organização em seu código, torna a capacidade do Terraform de recuperar estado, em algo desastroso. O que voce deve notar sem ambiguidade é que a mesma se baseia inteiramente no estado da sua infraestrutura (que ou pode ficar local ou ser guardada em bucket por exemplo), a ferramenta não é interpretativa como Python, ela é declarativa e ao compilar ela usa o Cycle para encontrar uma saida e no final, assim como um binário nasce, uma infra também nasce.

Cloud Formation

Já o Cloud Formation da AWS, é daquelas que abstraem tanto que no final você começa a se perguntar como que ela faz por de baixo dos panos para manter estado e chamadas de recursos, bem, ao cavar a API, alguns problemas aparecem.
A AWS fez um bom trabalho mantendo a compatibilidade com versões anteriores. Provavelmente, isso ocorre porque seus serviços geralmente são alimentados como cães e isso internamente antes de serem renomeados e públicos. “Bom trabalho” é provavelmente um eufemismo. É ridiculamente difícil manter APIs compatíveis com versões anteriores para um sistema tão diverso e complicado quanto a AWS. Qualquer pessoa que tenha mantido uma API pública tão amplamente usada quanto a AWS deve respeitar a dificuldade de um trabalho que durou tantos anos. Nunca tive uma situação em que o comportamento do CloudFormation mudou anos depois.

Tanto quanto eu sei, é impossível excluir o recurso de outra pilha do CloudFormation da sua própria pilha do CloudFormation. Isso é quase verdade para o Terraform. O Terraform permite importar recursos existentes para sua própria pilha. Na verdade, esse é um recurso realmente impressionante, mas com grande poder vem uma grande responsabilidade. Quando o recurso estiver em sua própria pilha, é possível modificá-lo ou excluí-lo enquanto estiver trabalhando em sua pilha. Este também não é um problema hipotético. Na Twitch, o site realmente teve um problema uma vez em que alguém, trabalhando de boa fé, importou o grupo de segurança da AWS de outra pessoa para sua própria pilha Terraform por acidente. Alguns comandos depois, e o grupo de segurança (e todo o tráfego de entrada) desapareceu.

Estado desalinhado

Fiz uma experiência simples em que as duas ferramentas criaram uma instância simples do EC2. Excluí as duas instâncias e tentei executar as duas etapas de implantação novamente.

Escondido no Terraform, planhá um refreshque é usado para reconciliar seu arquivo de estado com a infraestrutura do mundo real. Isso significa que o Terraform foi capaz de detectar a exclusão e inicializar uma nova instância. O CloudFormation não tem essa reconciliação e depende da pilha existente. Portanto, era inflexível que nada havia mudado. A única correção para o CloudFormation foi renomear o recurso EC2.

Mas talvez alguem possa se interessar por certas caracteristicas do Cloud Formation, coisas como pilhas aninhadas, funções e interpolações, que no Terraform, são um pouco confusas.

Escrevi isso para alguem que esta começando a testar essas ferramentas e podem encontrar algum sentido para sua necessidade técnica.