Pessoal, o Fargate já deixa muito mais simples a nossa conversa. Eu coloquei aqui até a mesma estrutura que a gente falou do EC2, para a gente conseguir fazer as comparações. Qual é a grande diferença? O Fargate é um serviço de servers. Então ele também vai ter aquela mesma estratégia, onde você não precisa gerenciar todo o seu serviço, você deixa isso a cargo ali da AWS. E com isso você vai tirar um monte de dor de cabeça da sua cabeça aqui, você vai conseguir prestar atenção mais no que você tem para entregar ali no seu código. Então basicamente, como qualquer outro serviço que é gerido ali pelo seu provedor cloud, ele é um cara que vai abstrair algumas coisas para você de infraestrutura. provedor cloud, ele é um cara que vai abstrair algumas coisas para você de infraestrutura. Então no Fargate, você assim como no EC2, você vai ter que colocar ali quais são as especificações que você vai precisar para sua imagem de conteúdo, CPU, memória, política, segurança, essas coisas você vai ter que colocar. Só que diferente do EC2, você não vai ter que definir qual tipo de instância que você quer. Então coisas você vai ter que colocar só que diferente do EC2 você não vai ter que definir qual tipo de instância que você quer, então você não vai ter que falar lá com a máquina e assim por diante, você vai falar quais são as suas necessidades então é como se você estivesse fazendo um pedido pra AWS falar, olha, minhas necessidades são essas e daqui você se vira aí pra conseguir fazer elas serem atendidas quando você precisar de demanda para elas. Então a diferença, acho que grande é essa, do Fargate para o EC2. Basicamente você está terceirizando essas definições, acho que é o principal ganho do Fargate, que ele deixa bem mais simplificado a conversa ali, tá bom? O Fargate consegue ter outras integrações com outros serviços da AWS também, que por exemplo ele consegue falar com o ELB que a gente falou, a gente até já falou bastante dele nas últimas aulas e aqui você consegue fazer a gestão ali de carga e de tráfego de entrada usando o ELB, que também pode ser uma boa pra você separar melhor o que você vai ter que processar ali dentro de cada container, tá bom? Ele também trabalha com o AutoSc Scale ali do próprio ICS, o serviço de Auto Scale e que também vai te ajudar ali a fazer os ajustes tanto de Up Scale quanto de Down Scale e vão acabar deixando o seu serviço com um desempenho muito bom. Aqui, acho que uma outra grande diferença que a gente tem é em questão de custo, porque assim como qualquer outro serviço, ele só vai você só vai pagar quando você usar. Então porque assim como qualquer outro serviço, você só vai pagar quando você usar. Então quando você não estiver usando o Fargate, ele não vai subir nada e com isso você não vai pagar nada. No EC2 você tem que fazer a gestão daquela máquina e assim por diante você acaba pagando por isso. No Fargate ele só vai subir a hora que ele for acionado e ele vai te gerar talvez um custo menor, nesse ponto de você só pagar quando você está usando. É muito simples, aqui basicamente a diferença entre um e outro é, Fargate é mais simples de utilizar, te causa um certo lock-in com o AWS, que eu também não acho prejudicial, vou ser muito honesto, não acho que isso é ruim, se eu tivesse que optar, eu acho que Fargate é a melhor pedida aqui que a gente tem para fazer, porque ele vai simplificar muito a sua vida e você vai conseguir prestar atenção e dar foco em outras coisas que fazem mais sentido para o desenvolvimento do software, beleza? Vamos lá, galera. Vamos falar agora um pouquinho de EKS e qual que é a grande diferença entre o EKS e o EKS, que é a grande dúvida que a maior parte das pessoas tem. Acho que a gente pode usar ambos os casos para a gente fazer a orquestração de container. A diferença é que o EKS é basicamente o K, que ele utiliza o Kubernetes, que é um gestor de orquestração aqui de containers open source. Então você tem bastante ele sendo adotado no mercado, e como ele é muito adotado, você acaba tendo mais facilidade, por exemplo, para achar pessoas que conhecem sobre o EKS, porque o EKS não vai ser utilizado só na AWS, pode ser usado em outros provedores cloud, diferente do ECS, o ECS é utilizado em AWS e ele não é utilizado em outros provedores cloud então a primeira coisa que ele já sai na frente é sobre você achar recursos que conhecem esse tipo de linguagem esse tipo de orquestração no fim do dia o conhecer Kubernetes é mais fácil de ter no mercado então do que você ter pessoas que conhecem só o ECS. E com isso você acaba já tendo uma coisa que está na frente. Mas em compensação é mais complexo de você fazer a gestão. Quando que você deveria optar por ele? Primeira coisa que você tem que ter na cabeça é quando você tem um ambiente muito complexo. Então, por exemplo, o EKS consegue fazer integração com algumas ferramentas do tipo Istio, que vai fazer um service mesh de trabalho dos seus microserviços. E com isso você consegue orquestrar um ambiente muito complexo de microserviços. Então se você tem um ambiente onde você tem um dinamismo muito grande, muita complexidade de microserviços, ele pode ser uma opção. Ele também tem algumas opções avançadas de auto-handling e de descobertas de microserviços que podem te ajudar também. Ou seja, se você está nessa situação, esse é um cara que pode ser interessante para você. Ele já sai na frente por esses motivos. Mas voltando, ele é um pouco mais complicado de fazer a gestão. Você tem que manjar mais do que o ECS. Você cometer uma falha no ECS é muito mais fácil do que você cometer no ECS. Porque o ECS depende que você tenha mais conhecimento para fazer essas coisas acontecerem no dia a dia, tá bom? Uma outra coisa que tem de diferente do EKS para o ECS é o jeito que você gerencia os nodes da aplicação. Então, na AWS, quando você está fazendo o ECS, ele já faz o gerenciamento de nodes e de todo o plano de controle de execução e gerenciamento dos clusters. Quando você está falando do EKS, você vai ter que fazer a gestão dos nodes, o que traz mais complexidade, mas em compensação te dá outros pontos de parametrização para você decidir como você vai fazer essas coisas. Então, a execução dos nodes, você vai ter ali como é que funcionam os containers, os pods e como é que vai ser a gestão do ciclo de vida de cada container que você subiu. E com isso você pode ter estratégias diferentes para executar. Enquanto no ECS você não tem essa opção. Só que aqui, de novo, vai te trazer um trabalho adicional. Você vai ter que estar olhando para isso. Faz sentido? Faz sentido quando você precisar disso para a sua aplicação. Pode ser um caminho interessante o EKS para isso. Ou seja, se você tem uma aplicação mais normalzona vamos dizer se você tem uma aplicação mais complexa etc pode ser o e caet só que também tem um outro ponto de vista também é quando a gente está falando de caet ele tem uma portabilidade maior ou seja você consegue mudar de provedor cloud assim por diante indo para outros lugares enquanto o ECS não, ele só roda na AWS então quando você tem que fazer alguma mudança de provedor cloud você pode ter que mudar tudo se você tiver baseado no ECS, você vai ter que ter esse retrabalho enquanto no EKS isso não vai acontecer só que em compensação quando a gente está falando de EKS, você também vai poder levar para o seu provedor, se você quiser levar, por exemplo, para uma aplicação on-premise, você consegue usar o EKS também. Isso eu estou falando só de migração, mas eu vou dar um outro caso para você também. Pô, eu quero trabalhar com uma aplicação que ela é mista, é metade, uma cloud híbrida, é metade interna e metade cloud provider. Quando eu estiver com isso isso eu vou ter que fazer com utilizando e caetano é porque cai se vai rodar na minha na minha aplicação que é um prime se ele vai rodar na wf também fica mais fácil fazer essa gestão do que querer usar esse é se na wf então é um caso um cenário que você pode usar ou se você quiser migrar a aplicação no futuro você já sabe que você pode é fazer e caetano está mais fácil de você fazer a gestão disso ali no