Você sabe o que é Infra as Code?

Imagina o seguinte cenário: sua organização tá passando por uma grande transformação digital, e como tática vocês decidiram por mover os seus principais serviços pra cloud. Os seus serviços que não puderam ser substituidos por commodities foram refatorados e desenvolvidos como "native cloud" em várias ondas de migração. Por estratégia de alta disponibilidade foi decidido que alguns recursos estariam publicados na Europa e no Brasil, seus maiores mercados atualmente, portanto as regiões com maior necessidade de performance. Ao final da primeira onda de migração, o core do seu portifólio ficou parecido com isso:

Mas aí cê me fala: "cara, sou desenvolvedor, o que tem a ver a reza com a missa?", e eu respondo: "tudo!". Em cenários cada vez mais complexos, com ambientes mistos de desenvolvimento em casa, comprado como serviço, comprado e customizado. Misturando onprem, cloud, cloud privada, ter complexidade na recuperação de ambiente, ou no escalonamento do mesmo não ajuda em nada, muito pelo contrário.

Infra as Code não nasceu junto com a cloud, mas se mostrou uma ferramenta absurdamente útil pra manutenção e gerenciamento de ambientes cloud. Consiste em "escrever" o seu ambiente inteiro, pra que se, em caso de um ataque, por exemplo, com alguns cliques você possa ter todo o seu ambiente produtivo de pé novamente. Se quiser também aumentar as regiões nas quais a sua solução vai estar, basta alterar o seu template e voilà, sem dor de cabeça, sem ficar em dúvida se todos os recursos sofreram a alteração necessária, e provavelmente sem downtime.

Confesso que quando olhei a primeira vez pro cloudformation, que é o serviço de provisionamento de infra que eu uso hoje, eu torci o nariz: "Já programo a solução, agora vou ter que programar a infra que ela vai rodar também?". Hoje alguns anos se passaram e não posso conceber uma solução na cloud que seja resiliente e não passe por esse nível de maturidade, algumas vantagens:

1. O desenvolvedor se engaja muito mais com a qualidade do que vai sair lá na ponta, não é responsabilidade do time de operações, que tem um papel muito mais consultivo e de apoio.
2. As resoluções de instabilidade na aplicação têm um caráter muito mais definitivo e diferente do "vou mudar isso aqui rapidinho pra voltar e depois eu vejo o que rolou".
3. Fazer testes é muito mais fácil, visto que cê pode só subir um novo ambiente, fazer os seus testes fora do seu ambiente de homologação, ou de desenvolvimento principal e ao fim, matar o ambiente provisório e integrar ou não suas alterações no seu código principal.

Enfim, você já deu uma chance pra IaC hoje?