Bom, vamos falar um pouquinho mais também sobre Policy as Code. Policy as Code é uma abordagem de gerenciamento de políticas na qual as mesmas são definidas, atualizadas, compartilhadas e aplicadas por meio de código. Nesse contexto, Policy pode ser considerado qualquer tipo de regra, condição ou instrução de governança ou processos de tecnologia. de governança ou processos de tecnologia. Usando essa abordagem, é possível adicionar essas ferramentas tanto em tempo de desenvolvimento quanto também na pós-implementação, garantindo o compliance dos ambientes. Usando o Policy as Code, é possível que os desenvolvedores e engenheiros de segurança falem a mesma língua, aproximando também esses dois papéis. Bom, temos algumas ferramentas relacionadas a Policy as Code, como o OPA, que é o Open Policy Agent, o Chekhov, a Hashcorp também tem uma ferramenta chamada Sentinel, que tem integração com outros serviços que eles possuem, como o próprio Terraform, que a gente citou, o Consul, o Vault, enfim. A gente também tem o Turbo, enfim, tem algumas ferramentas aí que nos atendem nesse sentido de policy as code. E qual que é a grande vantagem desse tipo de ferramenta? A gente consegue em tempo de shift e left, adicionar ferramentas como essa para conseguir, por exemplo, fazer gestão de custo, se a gente quiser. Então, o Sentinel, por exemplo, eu sei que ele consegue analisar o seu código com base naquilo que der de drift, o Terraform vai fazer o provisionamento, ele já vai entender o que está no ar, o que não está. Ele já consegue fazer ali para você um forecast, vamos dizer assim, de quanto que você vai ter de custo adicional ou o que você vai ter de decréscimo no seu mês ali. Fora isso, a gente consegue configurar algumas regras de compliance, então vamos supor que a gente quer fazer algum tipo de enforcement que a gente não possa utilizar uma versão de Kubernetes muito defasada. A gente tem duas abordagens. A gente pode ter uma ferramenta de policy as code em tempo de runtime, ou seja, eu faço todo o provisionamento desse ambiente, e aí eu vou ter algum lambda, alguma automação, que vai olhar para tudo que está sendo provisionado e vai validar que aquele recurso não está compliance. E aí eu também posso ter algumas ações, como gerar algum tipo de score, que afete o time de operação, ou eu posso ter uma ação de remediação e simplesmente deletar aquele recurso para a gente conseguir ter um ambiente sempre atualizado. E a gente também tem uma abordagem que eu gosto mais, apesar de eu achar que a gente tem que ter as duas abordagens, que seria a gente ter essas validações todas no shift left. que seria a gente ter essas validações todas no shift left. Então, eu não posso subir nenhum tipo de recurso defasado numa versão específica, eu não posso utilizar de repente algum tipo de flavor de máquina EC2, por exemplo. A gente pode configurar isso como um código, criar uma policy falando que aquele tipo de recurso não pode ser implementado e durante as minhas validações, quando eu estiver fazendo deployment, a própria pipeline já vai quebrar e já vai me falar que aquele recurso não está compliance. compliance. Então, olha a riqueza, a quantidade de benefícios que a gente consegue adicionar pensando no dia a dia de um desenvolvedor, de um SRE, para a gente economizar tempo e esforço e até dinheiro. A gente não tem esse esforço e a grana ali de subir aquele recurso e depois fazer a remediação com uma deleção por exemplo e falando de algumas ferramentas como eu citei a gente tem aí o checov que é uma ferramenta mais voltada para essas validações em tempo de shift left. A gente tem o Sentinel na mesma linha, também é mais voltado para shift left. O OPA, mesma coisa, também é uma ferramenta mais voltada para shift left, são todas ferramentas que a gente desenvolve essas policies e já faz o enforcement delas ou warning ou qualquer coisa nesse sentido em tempo de pipeline, em tempo de desenvolvimento. E por fim outras duas ferramentas que já são mais voltadas para runtime, então o turbo e o custodian. São ferramentas que a gente faz a implementação e elas ficam rodando ali no nosso cloud provider. Então, cara, um exemplo, a gente subiu uma fila e essa fila não tem, por exemplo, nenhuma DLQ associada. E por best practice a gente gostaria que tivesse. Então, esse é o tipo de ferramenta que também consegue olhar para isso e gerar algum finding ali para que o time de SRE possa atacar. Bom, e falando de infraestrutura como código, quais são os benefícios que a gente tem nesse tipo de abordagem. Então, a gente está falando de redução de custos, aumento na velocidade das implementações, facilidade em replicar o ambiente, documentação viva, redução de erros, melhoria na consistência da infraestrutura, automação, controle de inversão. Por que eu estou citando todos esses benefícios? Se a gente tem nossa infraestrutura como código, automaticamente a gente consegue fazer isso via pipeline. Então, a gente consegue aumentar a velocidade das nossas implementações. A gente tem a facilidade de replicar, porque é um código que a gente consegue simplesmente copiar e subir uma infraestrutura nova. Beleza, a gente pode até alterar alguns valores de variáveis, para não ter nenhum tipo de conflito de nome, mas fica muito, muito mais fácil a gente replicar o nosso ambiente se a gente quiser rodar algum tipo de teste apartado, como chaos, por exemplo, rodar algum tipo de game day. A nossa documentação é viva, então a gente consegue olhar para o código e saber o que está sendo implementado em produção. A gente tem uma redução de risco, de erros, uma vez que a gente tenha todas as validações, a gente não tem etapas manuais, isso também toca na parte de consistência, então a gente torna a infraestrutura de fato um código, como se fosse uma imagem que a gente consegue rodar toda uma bateria de testes, a gente consegue ter uma série de validações e a gente vai promovendo o mesmo código de desenvolvimento para homologação e para produção. Então, a gente acaba tendo uma confiabilidade muito maior daquilo que a gente está subindo também.