Olá pessoal, sejam muito bem-vindos. É um grande prazer estar aqui falando com vocês sobre este assunto tão importante, tão interessante que é a infraestrutura como código. O meu nome é Igor e na aula de hoje nós iremos fazer uma breve contextualização, falar sobre definições, sobre características e principalmente os benefícios que nós temos ao adotar infraestrutura como código no nosso dia a dia. Então, claro, nós começaremos aqui primeiro trazendo um breve conceito. Se fosse para nós definirmos infraestrutura como código de uma forma bem resumida, de uma forma bem direta, poderíamos dizer que IAC, que vem do inglês Infraest Code, é a prática de nós provisionarmos, gerenciarmos e até mesmo configurarmos os recursos de infraestrutura através de código, ao invés de nós fazermos isso através de processos manuais. Bom, então imagina que você acabou de criar sua conta lá na AWS, ou que você criou uma conta lá no portal do Azure, e agora você precisa provisionar os recursos da aplicação que você está desenvolvendo. Você vai provisionar ali uma rede virtual, uma subnet, você precisa subir algumas instâncias de máquinas virtuais, você precisa de um banco de dados, você precisa de um determinado serviço gerenciado que esses providers oferecem. Então você acessa o console ou o portal e cria tudo isso manualmente. Com certeza você vai demorar bastante, você vai ter alguns erros durante o processo, enquanto você testa, você vai alterar configurações e assim por diante. E aí quando tudo está funcionando, chegou a hora de subir para a produção, chegou a hora de implantar isso em produção. E agora, você vai lembrar de todos os passos que você executou, você vai precisar fazer tudo isso novamente, vai demorar bastante tempo e muito provavelmente você vai esquecer de um detalhe ou outro no decorrer do caminho e com certeza vai ser uma dor de cabeça. Então, infraestrutura como código nos auxilia bastante quando nós precisamos provisionar esses recursos de infraestrutura. Então vamos falar aqui de alguns benefícios, inclusive eu já citei aqui um pouquinho, mas o primeiro deles e o mais óbvio é a parte de automação. Se toda a sua infraestrutura está definida como código, está documentada, você pode rodar um script, você pode rodar um comando que provisiona tudo aquilo que você colocou naquele arquivo ou naqueles arquivos, você pode fazer isso de uma forma muito rápida, de uma forma muito simples e muito confiável. Então você economiza tempo, você reduz a possibilidade de erros humanos, certo? Logo em seguida nós temos consistência. Então é aquilo que eu falei. Você tem o seu ambiente de desenvolvimento, o seu ambiente de teste. Aparentemente tudo funciona, mas quando você sobra para produção, você tem um problema de configuração. Houve um desvio de configuração do seu ambiente de desenvolvimento ou de teste para o seu ambiente de produção. Inclusive tem um termo muito utilizado em inglês, que você vai ver aí quando você pesquisar sobre o assunto, na literatura, nos artigos, que é Configuration Drift. Então há um desvio de configuração entre um ambiente e outro, porque no decorrer do caminho você acabou alterando as coisas manualmente e você não replicou adequadamente essas alterações de um ambiente para o outro. Então, ter todos os seus recursos definidos como código garantem a consistência através dos seus ambientes. E é claro que, como nós estamos falando de código, nós podemos utilizar os benefícios de versionamento que nós já utilizamos no nosso dia a dia com as nossas aplicações, as nossas aplicações web, ou seja lá qual tecnologia com a qual você esteja trabalhando, você já está utilizando muito provavelmente versionamento. pode utilizar o Git para versionar todos esses arquivos e ali você terá um histórico de como a sua infraestrutura evoluiu através do tempo. E é claro que isso vai facilitar também a colaboração, que toda a sua equipe vai poder alterar, vai poder trabalhar com esses arquivos que definem sua infraestrutura. Uma outra característica também que é bastante óbvia, mas muito importante, é a repetibilidade. Então você pode rodar esse script, você pode subir a sua infraestrutura a qualquer momento. E essa irrepetibilidade aqui, ele tem associado a ele uma característica muito importante de infraestrutura como código, que é a idempotência. Nós falaremos um pouco sobre esse termo. de infraestrutura como código, que é a idempotência. Nós falaremos um pouco sobre esse termo, ele é muito importante, e ele é que possibilita, na verdade, nós podermos, por exemplo, executar um script várias vezes, nós podemos, por exemplo, definir uma pipeline de continuous integration, continuous deployment, que inclusive, quando enxerga alterações nesses arquivos, faça o deploy desses arquivos, rode esses arquivos e nós garantiremos que o resultado será sempre o mesmo. Então, nós teremos ali a garantia de que nós não precisamos nos preocupar, por exemplo, sobre criação de recursos duplicados. Então, nós temos idepotência quando nós falamos sobre infraestrutura como código e com isso nós podemos repetir esse processo várias vezes sem nenhum prejuízo, beleza? E claro, implícito nós temos aqui a documentação, porque se você tem um código, toda a sua infraestrutura, você tem a sua infraestrutura documentada, você não tem nada que foi criado ali ao acaso, manualmente, por alguém que às vezes já saiu da empresa, que você nem sabe por que aquilo foi criado. Não, agora você tem aquilo documentado, está no código, está no Git, você pode visualizar aquilo através do tempo, você pode saber quem alterou alguma coisa, quem adicionou alguma coisa, enfim, você tem uma documentação viva da sua infraestrutura, algo que não mente. Então, às vezes a gente pode ter documentações ali no Confluent, por exemplo, ou em qualquer outra plataforma. Então, nós podemos tentar manter essas documentações atualizadas, mas chega um ponto que sempre algo vai ficar desatualizado, sempre nós temos algo que nós fazemos que acaba não ficando documentado, mas quando nós falamos de código, não tem jeito. O código não mente, o código é um reflexo daquilo que de fato está implementado, que de fato está rodando. E é claro que todos esses benefícios, todos esses pontos que eu já citei, eles garantem uma maior eficiência. Com isso, fica muito fácil de nós criarmos, por exemplo, um ambiente de teste, subirmos o nosso ambiente de produção, rodarmos quando for preciso, derrubarmos um determinado ambiente. Então, imagina que você queira executar essa aplicação no ambiente de testes, mas esse ambiente de teste não precisa ficar disponível o tempo todo. Basta ele ficar disponível no momento em que você está testando. Então, para economizar gastos, você pode, sempre que terminar de executar os seus testes, desprovisionar, desalocar todos os recursos que foram alocados para a execução daqueles testes, e assim, claro, que você vai ser muito mais eficiente, porque você vai fazer algo com qualidade, algo bem feito, gastando a menor quantidade de recursos possível. Então temos todos esses benefícios aqui quando nós utilizamos infraestrutura como código. E agora para nós finalizarmos essa aula, nós vamos falar um pouco sobre os tipos de infraestrutura como código que nós temos. Em primeiro lugar, claro, foi o que eu mais comentei aqui, nós temos a parte de provisionamento. Então nós vamos criar os nossos recursos, nós vamos gerenciar esses recursos na nossa infraestrutura através de código, criando, por exemplo, máquinas virtuais, redes, criando um bucket lá no S3 ou criando um container lá no blob storage da Azure e assim por diante. Então, a parte de criar recursos, nós podemos fazer isso através de infraestrutura como código e nós chamamos essa característica de provisionamento, esse tipo de infraestrutura, por exemplo, na AWS, no Azure, no GCP, ou inclusive em um premises, mas tem muitos outros providers que nós podemos utilizar aqui com Terraform. Temos especificamente para a AWS o CloudFormation e temos especificamente para a Azure o Azure Resource Manage, ou os templates ARM que também definem a infraestrutura como código. Eu trouxe aqui, eu trago aqui mais exemplos de AWS, de Azure, porque são os providers mais comuns, mais utilizados. Mas hoje em dia, para todos os grandes providers, nós temos ferramentas muito parecidas que vão fornecer infraestrutura como código para nós, beleza? Além disso, nós temos também uma outra parte de configuração, então nós precisamos garantir que tudo aquilo que já foi provisionado, que já foi criado, que já está alocado lá na nossa infraestrutura, esteja configurado corretamente, tá? E aí nós temos ferramentas como Ansible, como Puppet, como Chef, temos também algumas ferramentas específicas de algum Cloud Provider, por exemplo, nós temos no Azure o Desired State Configuration, então nós conseguimos definir ali a configuração, o estado que nós queremos para os nossos recursos através dessa ferramenta, mas eu trouxe esses outros aqui porque eles são os mais comuns e nós também podemos utilizá-los com vários providers. E por fim, nós temos uma parte de orquestração, barra deployment, que seria mais a parte Kubernetes ou de Docker. Ali também com Kubernetes, com Docker, nós temos a definição daquilo que precisa ser implantado, daquilo que nós estamos subindo através de arquivos. Então, os arquivos IEM que nós geralmente utilizamos também se encaixam como infraestrutura, como código. É claro que nós falaremos um pouco mais sobre essas ferramentas, principalmente Terraform. Eu coloquei aqui essas ferramentas divididas em categorias, mas não significa que Terraform, por exemplo, é só para provisionamento. Não. Nós conseguimos também configurar e conseguimos, às vezes, dependendo do provider e do serviço utilizado, nós conseguimos também orquestrar ou fazer deployment com Terraform. A mesma coisa é CloudFormation e assim por diante. Ansible também, às vezes, você pode provisionar. Então, essas ferramentas aqui, eu coloquei elas divididas em categorias, mas há um merge, há um overlap entre essas categorias. Uma ferramenta pode ser utilizada para mais de uma característica ou para mais de um tipo de IA. Eu coloquei aqui de acordo com a característica principal. O principal do Terraform é aprovisionamento, o principal do Ansible é configuração, mas eles podem fazer as mesmas coisas em alguns cenários. Beleza? Então eu acho que já deu para você se contextualizar, já deu para você entender quais são os benefícios de você implantar ou implementar infraestrutura como código aí na sua empresa e com certeza vai ajudar bastante, com certeza vai deixar todo o seu fluxo de trabalho mais eficiente, com mais qualidade e mais confiável. Beleza? Na próxima aula nós falaremos um pouco mais sobre outros conceitos também muito importantes que infraestrutura como código traz implícito já quando nós estamos trabalhando com esses tipos, com provisionamento, com configuração e com orquestração. Espero que você tenha gostado e vejo você lá.