Neste post iremos aprender a como criar um app serverless usando AWS SAM. AWS SAM (Serverless Application Model) é uma extensão do AWS CloudFormation, especificamente projetado para desenvolvimento e implantação de aplicativos sem servidor, o famoso serverless como AWS Lambda, API Gateway, DynamoDB, entre outros recursos da AWS. Nível de abstração AWS SAM é uma ferramenta de nível de aplicativo, focada principalmente na criação e implantação de aplicativos serverless na AWS. Ele fornece abstrações de nível mais alto para facilitar o desenvolvimento e a implantação de aplicativos serverless, com foco nos serviços da AWS necessários para suportar esse tipo de arquitetura, ou seja, todo o foco é AWS e não outra nuvem. AWS SAM possui toda uma forma de gerar o código do projeto localmente e possibilita gerar testes, Build e Deploy através de SAM CLI. Como instalar AWS SAM Acesse este link e siga os passos de acordo com cada sistema operacional. Como criar um projeto serverless Após instalado, através de um terminal, gere seu projeto localmente gerando os arquivo necessários para então, efetuar o deploy da aplicação. Primeiramente, acesse a pasta em que deseja gerar seu recurso serverless e em seguida abra o terminal. Digite no terminal o seguinte comando para iniciar o SAM: sam init Após digitar, um prompt com algumas opções aparecerá para que você preencha as informações do seu projeto. Acima temos 2 opções para gerar o nosso template inicial, vamos digitar 1 para gerarmos a opção 1 - AWS Quick Start Templates. Após digitarmos, uma nova lista será mostrada com algumas opções de templates. Perceba que cada opção se resume a um recurso como, Lambda, tabela Dynamo e até um simples API utilizando API Gateway. Para este cenário, vamos criar uma tabela Dynamo, neste caso, digite a opção 13 e aperte o enter. Após digitar, algumas questões serão feitas, apenas digite y para prosseguir até que uma nova tela sobre as informações do projeto seja ofertada como abaixo. Digite o nome do projeto em que deseja e aperte o enter. No nosso caso digitei o seguinte nome para o projeto dynamo-table-using-aws-sam como na imagem abaixo. Após digitar o nome do projeto, o template e arquivos contendo o código base estará disponível e pronto para o deploy. Acesse a pasta e veja que um arquivo chamado template.yaml foi criado contendo informações dos recursos que serão criados. É bem similar a um template do CloudFormation, porém mais resumido. Abra o arquivo e perceba que vários recursos auxiliares foram mapeados no template, como o próprio Dynamo, um Lambda e uma API Gateway. Foram criados também, alguns códigos bases relacionados ao Lambda e alguns testes unitários que possibilitam invocações locais. Como fazer o deploy Agora que o nosso template e o código base foi gerado, é hora de criarmos a tabela Dynamo na AWS, basta seguir os próximos passos. Acesse novamente o terminal e digite o seguinte comando: sam deploy --guided Após executar este comando, as seguintes opções serão mostradas no prompt do terminal para preenchimento: Para o campo Stack Name, digite um valor que será o identificador daquela stack no qual será usado pelo CloudFormation para criar os recursos necessários. Na dúvida, siga o que o foi digitado conforme imagem acima, no caso dynamo-stack. Após preencher todos os campos, um resumo do que será criado será apresentado conforme imagem abaixo: Por fim, mais uma última pergunta será feita sobre o desejo de efetivar o deploy, basta digitar y para confirmar. Após confirmar a operação, o progresso da criação dos recursos será apresentado no terminal até a finalização do processo. Deploy finalizado, perceba novamente os recursos que foram criados. Agora é só acessar o console da AWS e conferir a tabela criada no Dynamo. Deletando os recursos Caso seja necessário, você pode deletar os recursos via SAM CLI, basta executar o comando abaixo: sam delete dynamo-stack O argumento dynamo-stack refere-se ao identificador que digitamos anteriormente no campo Stack Name, lembra? Utilize o mesmo para deletar toda a stack criada. Após digitar o comando acima, é só confirmar os próximos passos. É bem simples a forma de como criar um recurso serverless com AWS SAM, existem algumas vantagens e desvantagens e isso tudo vai depender da sua estratégia. Espero que tenha curtido!

Existem diferentes formas de criar recursos na AWS, você pode criar um Bucket S3, SQS, RDS e dentre vários outros recursos de forma manual. Mas da forma que a sua infra vai crescendo, criar recursos manualmente se torna insustentável, pois chegará um ponto que se torna impossível gerenciar estes recursos. Uma outra forma é utilizando ferramentas IaC - Infrastructure as code que permite criar, gerenciar e provisionar recursos na nuvem com pouco esforço e mais clareza. Na AWS podemos utilizar o CloudFormation para nos ajudar na criação dos recursos em que deseja utilizar. Como funciona A partir de um template no formato JSON ou YAML e em seguida efetuando o upload deste arquivo para o CloudFormation na AWS. Bem simples. Para entender melhor este processo, vamos criar um Bucket S3 e uma fila SQS através do CloudFormation, seguindo o que foi descrito anteriormente, utilizando um template. Existe duas formas de criar um template, você pode utilizar um arquivo JSON ou YAML. Nesse exemplo vamos utilizar um template no formato YAML. Criando o template para um Bucket S3 Resources: S3Bucket: Type: 'AWS::S3::Bucket' DeletionPolicy: Retain Properties: BucketName: blog.data AccessControl: Private BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: "AES256" Para o template acima, utilizamos alguns parâmetros essenciais para a criação do Bucket, a lista completa pode ser consultada na própria documentação da AWS. A seguir, vamos entender de forma resumida o que significa cada parâmetro: S3Bucket: é um identificador dado ao recurso, crie sempre um identificador que faça sentido ao seu contexto Type: Tipo do recurso DeletionPolicy: Existem três opções, explicando de forma resumida: Delete: Caso a stack do CloudFormation seja deletada, todos os recursos relacionados serão deletados. Tome bastante cuidado e entenda dos riscos antes de utilizar esta opção Retain: Utilizando esta opção, você garante que ao deletar uma stack, os recursos relacionados serão mantidos. Snapshot: Opção utilizada para recursos que suportam snapshots, por exemplo: AWS::EC2::Volume AWS::ElastiCache::CacheCluster AWS::ElastiCache::ReplicationGroup AWS::Neptune::DBCluster AWS::RDS::DBCluster AWS::RDS::DBInstance AWS::Redshift::Cluster Nas propriedades, definimos as características do Bucket: BucketName: Nome do bucket. Lembrando que o nome do bucket deve ser único e deve seguir alguns padrões de nome conforme a documentação AccessControl: É o controle de acesso ao Bucket, existe diferentes opções de acesso, segue: Private PublicRead PublicReadWrite AuthenticatedRead LogDeliveryWrite BucketOwnerRead BucketOwnerFullControl AwsExecRead BucketEncryption: São as configurações de criptografia dos objetos do Bucket, neste caso utilizamos o algoritmo AES256 Fazendo o upload e criando o recurso 1. No console da AWS, acesse o CloudFormation 2. Clique no botão Create Stack 3. Selecione como pré-requisito Template is ready 4. Na seção Specify template, selecione Upload a template file, selecione o arquivo criado clicando em Choose file e por último clique no botão Next. Uma nova página será aberta para o preenchimento do nome da stack. 5. Clique em Next e faça o mesmo para as próximas paginas. 6. Por fim, o recurso será criado. Isso pode demorar alguns minutos dependendo do recurso. Perceba que foram criados dois buckets: blog.data: Criado via CloudFormation cf-templates-1nwl4b3ve439n-us-east-1: Bucket criado de forma automática no ato do upload do arquivo no início do processo. Criando o template para uma fila SQS Resources: SQS: Type: 'AWS::SQS::Queue' Properties: QueueName: sqs-blog.fifo ContentBasedDeduplication: true DelaySeconds: 120 FifoQueue: true MessageRetentionPeriod: 3600 Entendendo o template: SQS: Identificador do recurso Type: Tipo do recurso QueueName: Nome da fila SQS. Um detalhe importante é o sufixo .fifo, necessário caso a fila seja do tipo Fifo ContentBasedDeduplication: Garante a não duplicidade das mensagens, funciona apenas para filas do tipo Fifo DelaySeconds: Tempo de delay para cada mensagem (em segundos) FifoQueue: Forma de como a fila gerencia a chegada e saída das mensagens (First-in - First-out) MessageRetentionPeriod: Período em que as mensagens será retidas na fila (em segundos) Fila SQS criada Conclusão O CloudFormation é uma ferramenta exclusiva da AWS para a criação de recursos, ou seja, caso a sua arquitetura seja criado ou mantida com base na nuvem da AWS, o CloudFormation é uma ótima escolha. Caso você precise manter uma flexibilidade entre nuvens, como por exemplo a possibilidade em utilizar a Google Cloud, o Terraform pode ser uma melhor opção como ferramenta IaC. É isso, curtiu? Até mais!

O que são as classes de armazenamento do Amazon S3? O Amazon S3 (Simple Storage Service) provê uma forma estratégica em organizar os objetos em diferentes camadas, onde cada camada possui suas particularidades que iremos detalhar mais a frente. As classes de armazenamento tem como características oferecer diferentes níveis de durabilidade, disponibilidade, desempenho e custos. Para isso, deve entender bem qual estratégia utilizar para manter os objetos visando o melhor custo benefício. A seguir, iremos detalhar cada classes, descrevendo suas vantagens de desvantagens. S3 Standard A classe de armazenamento S3 Standard é a opção padrão e mais utilizada do Amazon S3. Ela é projetada para oferecer alta durabilidade, disponibilidade e desempenho para objetos frequentemente acessados. Vantagens S3 Standard é a classe mais comum utilizada no armazenamento e acesso a objetos com maior frequência, pois é a camada que oferece baixa latência e isso permite ser usado por diferentes casos de usos onde o acesso dinâmico aos objetos é imprescindível. Outra vantagem é a durabilidade de 99.999999999%, ou seja, as chances dos objetos serem corrompidos ou até perdidos é muito baixa. Quanto a disponibilidade, esta classe fornece um SLA de 99,99%, significa que os objetos possuem uma alta disponibilidade para o acesso. Desvantagens S3 Standard possui algumas desvantagens comparado as outas classes. Uma delas é o alto custo de armazenamento para objetos pouco acessados. Por isso é importante definir políticas de ciclo de vida para lidar com objetos pouco acessados. No caso, existe a classe S3 Standard-Infrequent Access, que seria a mais apropriada para este contexto. Falaremos em breve sobre esta classe. Outra desvantagem está relacionada ao acesso a objetos recém-criados. Mesmo que esta classe possui como umas das principais características a baixa latência. Objetos recém-criados podem não estar disponíveis de imediato em todas as regiões, podendo levar um tempo para a disponibilidade dos objetos para algumas regiões, gerando uma alta latência S3 Intelligent-Tiering A classe de armazenamento S3 Intelligent-Tiering fornece um mecanismo em que possibilita mover objetos com base no padrão de uso de forma automática para camadas mais adequadas, visando baixo custos de armazenamento. Vantagens O próprio conceito já diz tudo sobre uma das vantagens de se usar S3 Intelligent-Tiering. Esta classe é capaz de gerenciar objetos com base no padrão de uso, ou seja, para aqueles objetos que são poucos acessados, a própria classe move para classes mais adequada visando menor custos de armazenamento. S3 Intelligent-Tiering monitora e move objetos de forma automática para camadas mais adequadas de acordo com o padrão de uso, geralmente esta integração funciona para 3 tipos de camadas. Uma camada otimizada para objetos de acessos frequentes, uma camada otimizada para objetos pouco acessados, que segundo a AWS gera uma economia de até 40%. E uma última camada direcionada a objetos que são raramente acessados, gerando uma economia de armazenamento em torno de 68%. Outro ponto de vantagem é que não existe cobrança por acesso aos dados utilizando S3-Intelligent-Tiering. Somente cobranças pelo armazenamento e transferência. Desvantagens Possível aumento na latência para objetos acessados pela primeira vez. O motivo é de que ao mover os objetos para camadas mais adequadas, existe a possibilidade do aumento de latência para estes objetos que são pouco acessados. S3 Standard-Infrequent Access (S3 Standard-IA) Classe adequada para armazenar objetos com acessos menos frequentes mas que precisam estar disponíveis para acessos rápidos, mantendo uma baixa latência. É uma típica classe para armazenar dados a longo prazo. Vantagens O custo de armazenamento é mais baixo se comparado a classe S3 Standard, mantendo as mesmas características de durabilidade. Sobre a disponibilidade dos dados, possui as mesmas características que a classe S3 Intelligent-Tiering, de 99.9% de SLA. E também, permite acesso rápido aos dados oferecendo uma alta taxa de vazão (throughput). A taxa mínima de armazenamento é cobrada mensalmente, diferente de classes como S3-Standard e S3-Intelligent Tiering. Desvantagens Não que necessariamente seja uma desvantagem, mas se comparado a outras classes pode não fazer tanto sentido, no caso, seria o custo de acesso aos dados. O acesso é cobrado por gigabyte acessado, ou seja, dependendo da frequência de acesso e volume acessado, seria melhor manter os dados em uma camada como S3 Standard. Tudo vai depender da sua estratégia. S3 One Zone-Infrequent Access (S3 One Zone-IA) Classe de armazenamento ideal para objetos que são acessados com pouca frequência e que estarão disponíveis em apenas uma zona (Availability Zone). A própria AWS sugere esta classe para cópias secundárias de backup de dados. Vantagens O custo é mais baixo comparada as demais classes de armazenamento, pois os dados serão armazenados em apenas uma zona, tornando o custo operacional baixo. Desvantagens Diferente das demais classes de armazenamento, onde o armazenamento dos objetos estão disponíveis em no mínimo 3 zonas de disponibilidade (AZ). A S3 One Zone-Infrequent Access disponibiliza os dados em somente 1 zona, fazendo com que não exista nenhum tipo de redundância, ou seja, existe uma possível chance na perda dos dados, caso haja alguma falha naquela determinada zona. S3 Glacier Instant Retrieval S3 Glacier Instant Retrieval faz parte da família Glacier, que tem como caraterística o baixo custo de armazenamento para objetos raramente acessados. É uma classe de armazenamento ideal para arquivamento de dados que necessita de acesso imediato. Vantagens O custo de armazenamento é baixo. Possui a mesma disponibilidade, comparado as classes S3 Intelligent-Tiering e S3 Standard-IA. Fornece redundância, ou seja, os dados são replicados para no mínimo 3 zonas de disponibilidades (AZ). Desvantagens Embora ofereça recuperação imediata dos dados mantendo a mesma vazão (throughput) do que classes como S3 Standard e S3 Standard-IA, o custo se torna alto quando é necessário a recuperação destes dados com uma grande frequência em um curto período. S3 Glacier Flexible Retrieval S3 Glacier Flexible Retrieval é a antiga classe de armazenamento chamada somente de S3 Glacier, possui uma característica em armazenar objetos com longa vida de duração, como qualquer outra classe da família Glacier. Esta classe é ideal para objetos que são acessado de 1 a 2 vezes ao ano e que requer recuperação de forma assíncrona, ou seja, sem acesso imediato. Vantagens Esta classe é ideal para manter objetos que não requer recuperação imediata, tornando uma vantagem quanto a custos. No caso, dados como backup, nos quais a recuperação é bem rara, esta classe não oferece custo de recuperação pela ideia da frequência de acessar estes dados ser bem perto de zero. Desvantagens Tempo de recuperação pode ser lento para alguns cenários. Como característica da própria classe, S3 Glacier Flexible Retrieval pode não atender quando seja necessário o acesso imediato aos dados. S3 Glacier Deep Archive Classe de armazenamento com o menor custo entre as classes da família Glacier. Ideal para armazenar dados que podem ser acessados de 1 a 2 vezes ao ano. A AWS sugere o uso desta classe para cenários onde temos que manter dados entre 8 a 10 anos visando atender regulamentos relacionados a compliance ou qualquer outro tipo de regra relacionada a retenção dos dados para longos períodos. Vantagens O menor custo entre as classes do mesmo segmento e com disponibilidade de 99.99%. Classe disponível em no mínimo 3 zonas de disponibilidade (AZ) e ideal para dados que requer longos períodos de retenção. Desvantagens Tempo de recuperação longo, ou seja, caso precise de uma recuperação rápida, este SLA não atenderá. Por ter uma característica em que o dado deve ser pouco acessado, o custo de recuperação pode ser mais alto, dependendo da frequência de acessos. Espero que tenha curtido!

Para este post, vamos criar um AWS Lambda com Terraform e Java como linguagem de programação. Mas antes de tudo, você já ouviu falar de Lambda? Caso não, recomendo ver este post sobre Lambda. E sobre Terraform? Neste post eu mostro os primeiros passos usando Terraform, é só clicar aqui. A ideia deste post é criar um AWS Lambda que será trigado através do CloudWatch Events por meio de um agendamento automatizado usando uma expression cron. Normalmente, podemos criar qualquer recurso da AWS usando o console, mas aqui usaremos o Terraform como uma ferramenta IaC (Infraestrutura como código) que criará qualquer recurso necessário para executar nosso AWS Lambda. Como runtime ou linguagem de programação, escolhemos Java. Lembre-se de que você pode executar o Lambda usando diferentes linguagens de programação, como Java, Python, .NET, Node.js e muito mais. Mesmo que seja um projeto Java, a parte mais importante deste post é tentar entender sobre o Lambda e como você pode cria-lo através do Terraform. Introdução O Terraform será responsável por criar todos os recursos para este post, como o prórprio Lambda, roles, policies, CloudWatch Events e S3 Bucket, onde manteremos o arquivo JAR de nosso aplicativo. Nosso Lambda será invocado pelo CloudWatch Events a cada 3 minutos executando um método simples em Java no qual imprimirá uma mensagem. Você pode observar na imagem acima que estamos usando S3 para armazenar nosso pacote de implantação, arquivo JAR neste caso. É uma recomendação da AWS fazer upload de pacotes de implantação maiores diretamente para o S3, em vez de manter no próprio Lambda. Isso acontece pois o S3 oferece suporte para armazenar arquivos maiores. Não se preocupe em carregar arquivos manualmente, o Terraform também será responsável por fazer isso durante a fase de build. Criando o projeto Para este post vamos usar Java como linguagem e Maven como gerenciador de dependências. Portanto é necessário gerar um projeto Maven que irá criar a estrutura do nosso projeto. Se você não sabe como gerar um projeto Maven, recomendo ver este tutorial onde mostro como gerar. Estrutura do projeto Após gerar o projeto Maven, vamos criar os mesmos arquivos e pacotes conforme imagem ao lado, exceto o pom.xml que foi criado pelo gerador maven. É uma característica dos projetos Maven gerar essas estruturas de pastas como mostrado src/main/java/. Dentro da pasta java/, crie um pacote chamado coffee.tips.lambda e crie uma classe Java chamada Handler.java dentro deste mesmo pacote. Alterando o pom.xml Para este tutorial, adicione as seguintes dependências e também copie a fase de build abaixo: Criando o Handler Uma classe handler é basicamente o controlador Lambda. O Lambda sempre procura um handler para iniciar seu processo, resumindo, é o primeiro código a ser invocado. Criamos um handler básico apenas para "printar" mensagens quando invocadas pelo CloudWatch Events. Obeserve que implementamos a interface RequestHandler permitindo receber como parâmetro um objeto Map. Mas para este exemplo não vamos explorar os dados deste parâmetro. Entendendo os arquivos Terraform Agora vamos entender como os recursos serão criados usando o Terraform. vars.tf No arquivo vars.tf é onde declaramos as variáveis. As variáveis ​​fornecem flexibilidade quando precisamos trabalhar com diferentes recursos e ambientes de execução. vars.tfvars Agora precisamos definir os valores dessas variáveis. Então, vamos criar uma pasta chamada /development dentro da pasta terraform. Após a criação da pasta. Crie um arquivo chamado vars.tfvars como na imagem ao lado e cole o conteúdo abaixo. Observe que no campo for bucket, você deve especificar o nome do seu próprio bucket. O nome do bucket deve ser único. main.tf Para o arquivo main.tf, apenas declaramos o provedor. Provider é o serviço de nuvem que usaremos para criar nossos recursos. Neste caso, estamos usando a AWS como provider e o Terraform fará o download dos pacotes necessários para criar os recursos. Observe que, para o campo region, estamos usando a palavra-chave var para obter o valor da região já declarado no arquivo vars.tfvars. s3.tf É no s3.tf que vamos declarar os recursos relacionados ao S3 em geral. Nesse caso, criamos apenas o bucket S3. Mas se você quiser criar mais recursos relacionados ao S3, como policies, roles ou qualquer recurso relacionado, pode declarar aqui. É uma forma de separar os arquivos Terraform por recurso. Observe novamente que estamos usando a palavra-chave var para a variável bucket declarada no arquivo var.tf. lambda.tf Finalmente nosso último arquivo terraform, neste arquivo estamos declarando recursos relacionados ao Lambda e ao próprio Lambda. Agora acho que vale a pena explicar alguns detalhes sobre o arquivo acima. 1. Declaramos 2 objetos do tipo data aws_iam_policy_document, que definem quais ações os recursos que serão atribuídos a essas policies podem executar. 2. aws_iam_role: recurso que fornece a função IAM e que também controlará algumas ações do Lambda. 3. aws_iam_role_policy: fornece IAM role inline policy e registrará a role e as policies anteriores relacionadas ao aws_iam_policy_document.aws_iam_policy_coffee_tips_aws_lambda_iam_policy_document. 4. Declaramos o recurso aws_s3_object porque queremos armazenar nosso arquivo jar no S3. Assim, durante a fase de deploy, o Terraform obterá o arquivo jar que será criado na pasta target/ do projeto e fará o upload para o S3. depends_on: Terraform deve criar este recurso antes do atual. bucket: É o nome do bucket onde irá armazenar o arquivo jar. key: nome da jar. source: localização do arquivo de origem. etag: aciona atualizações quando acontecem alterações. 5. aws_lambda_function is the resource responsible to create Lambda and we need to fill some fields such as: function_name: Nome do Lambda role: role declarada nas etapas anteriores que fornece acesso aos serviços e recursos da AWS. handler: Neste campo você precisa especificar o diretório da classe principal. source_code_hash: Este campo é responsável por acionar as atualizações do lambda. s3_bucket: É o nome do bucket onde irá armazenar o arquivo jar gerado durante o deploy. s3_key: Nome do jar runtime: Aqui você pode especificar a linguagem de programação suportada pelo Lambda. Para este exemplo, java 11. timeout: Tempo limite de execução do Lambda. 6. aws_cloudwatch_event_rule é a regra relacionada à execução do evento do CloudWatch. Neste caso, podemos definir o cron através do campo schedule_expression para definir quando o lambda será executado. Neste caso, definimos que o Lambda será executado a cada 2 minutos - rate(2 minutes), especificado no arquivo vars.tfvars. 7. aws_cloudwatch_event_target é o recurso responsável por acionar o Lambda usando eventos do CloudWatch. 8. aws_lambda_permission permite execuções do CloudWatch. Packaging Agora que você está familiarizado com o Lambda e o Terraform, vamos empacotar nosso projeto via Maven antes da criação do Lambda. A ideia é criar um arquivo jar que será usado para execuções do Lambda e armazenado no S3. Para este exemplo, vamos empacotar localmente. Vale lembrar que para um ambiente de produção, poderíamos utilizar ferramentas de integrações contínuas como Jenkins, Drone ou até Github actions para automatizar esse processo. Primeiro, abra o terminal e verifique se você está no diretório raiz do projeto e execute o seguinte comando maven: mvn clean install -U Este comando além de empacotar o projeto, irá baixar e instalar as dependências declaradas no arquivo pom.xml. Depois de executar o comando acima, um arquivo jar será gerado dentro da pasta target/ também criada. Executando Terraform Bem, estamos quase lá. Agora, vamos provisionar nosso Lambda via Terraform. Então, vamos executar alguns comandos do Terraform. Dentro da pasta terraform, execute os seguintes comandos no terminal: terraform init O comando acima iniciará o terraform, baixando as bibliotecas do terraform e também validará os arquivos do terraform. Para o próximo comando, vamos executar o comando plan para checar quais recursos serão criados. terraform plan -var-file=development/vars.tfvars Após a execução, você verá logs semelhantes no console: Por fim, podemos solicitar a criação definitiva dos recursos através do seguinte comando: terraform apply -var-file=development/vars.tfvars Após a execução, você deve confirmar para executar as ações, digite "sim". Agora a provisão foi concluída! Execução do Lambda Vá e acesse o console da AWS para ver a execução do Lambda que acabamos de criar. Acesse a aba monitor Acesse a aba Logs dentro da seção Monitor Veja as mensagens abaixo que serão impressas a cada 2 minutos. Destroy As cobranças de faturamento da AWS ocorrerão se você não destruir esses recursos. Portanto, recomendo destruí-los evitando algumas cobranças desnecessárias. Para evitar, execute o comando abaixo. terraform destroy -var-file=development/vars.tfvars Lembre-se que você precisa confirmar essa operação, ok? Conclusão Neste tutorial, criamos um AWS Lambda provisionado através do Terraform. Lambda é um serviço da AWS que podemos usar para diferentes casos de uso trazendo facilidade para compor uma arquitetura de software. Pudemos notar que o Terraform traz flexibilidade criando recursos para diferentes serviços em nuvem e fácil de implementar em projetos de softwares. Github repository Espero que tenha curtido!

Tenho experimentado Python e tenho me surpreendido com a facilidade no desenvolvimento e sem muitas configurações de projeto. Para este post, vamos criar um exemplo de como criar uma fila SQS e enviar mensagens utilizando Python e boto3, que possui uma grande variedade de métodos para acesso aos recursos da AWS. Instalando boto3 A instalação é bem simples, assegure-se que já exista o Python instalado em seu ambiente. Caso já exista, via terminal, execute o comando a seguir para a instalação do boto3. pip install boto3 Importando boto3 para o projeto Após instalado, vamos escrever o nosso código em partes, começando pelo import da biblioteca boto3 e atribuindo para uma variável sqs e client, conforme imagem abaixo: import boto3 sqs = boto3.resource('sqs') client = boto3.client('sqs') Criando fila SQS Criando uma function que criará a fila SQS passando alguns parâmetros como, name e attributes. def create_sqs(name, attributes): sqs.create_queue(QueueName=name, Attributes=attributes) Envio de mensagens para a fila SQS Criando uma function que enviará as mensagens para a fila SQS def send_messages_to_sqs(name, message): queue = sqs.get_queue_by_name(QueueName=name) client.send_message(QueueUrl=queue.url, MessageBody=message) No código acima, existe um método chamado get_queue_by_name que no qual precisamos usar para recuperar a url da fila existente, para que seja repassada para o método send_message Executando o código Após criada as functions, vamos executar o código para a criação da fila SQS e o envio das mensagens. if __name__ == '__main__': attributes = { 'DelaySeconds': '60', 'MessageRetentionPeriod': '600' } create_sqs('sqs_messages', attributes) send_messages_to_sqs('sqs_messages', "Hello, SQS!") Código completo import boto3 sqs = boto3.resource('sqs') client = boto3.client('sqs') def create_sqs(name, attributes): sqs.create_queue(QueueName=name, Attributes=attributes) def send_messages_to_sqs(name, message): queue = sqs.get_queue_by_name(QueueName=name) client.send_message(QueueUrl=queue.url, MessageBody=message) if __name__ == '__main__': attributes = { 'DelaySeconds': '60', 'MessageRetentionPeriod': '600' } create_sqs('sqs_messages', attributes) send_messages_to_sqs('sqs_messages', "Hello, SQS!") Simples, certo? É um código prático que permite acessar recursos da AWS com poucas linhas de código. Sou novo em Python e espero trazer mais posts como este, assim vamos aprendendo juntos =) É isso, curtiu? Até mais!

O S3 (Simple Storage Service) possibilita notificar através de eventos, quando alguma ação ocorre dentro de um Bucket ou em alguma pasta específica. Em outras palavras, funciona como um listener, ou seja, qualquer ação ocorrida em uma origem, ocorrerá um evento de notificação para um destino. O que seriam estas ações? Qualquer ação que acontece dentro de um Bucket como, a criação de um novo arquivo manual ou através de um upload, criação de uma pasta, remoção de arquivos, restauração de arquivos e etc. Destinos Para cada configuração de notificação de evento, deve existir um destino. Para este destino, será enviado informações sobre cada ação, por exemplo: Um novo arquivo foi criado em uma pasta específica, assim, informações sobre o arquivo será enviada, como a data de criação, tamanho do arquivo, o tipo do evento, nome do arquivo e dentre outros. Lembrando que neste processo, não é enviado o conteúdo do arquivo, GG? Existem 3 tipos de destinos disponíveis: Lambda SNS SQS Entendendo o funcionamento na prática Neste post vamos criar uma configuração de notificação de evento em um Bucket S3, simular uma ação e entender o comportamento final. Todo este conteúdo é baseado na documentação oferecida pela HashiCorp, empresa mantenedora do Terraform. Poderíamos criar esta configuração via console mas por motivos de boas práticas, utilizaremos o Terraform como ferramenta IAC. Para quem não conhece muito sobre Terraform, segue este tutorial sobre Primeiros passos utilizando Terraform na AWS. No próximo passo, criaremos um fluxo simulando a imagem abaixo. Criaremos uma configuração no Bucket S3, que para cada arquivo criado na pasta files/, um evento de notificação será enviado para um fila SQS. Criando os arquivos Terraform Crie no seu projeto, uma pasta chamada terraform/ e a partir de agora, todos os arquivos .tf serão criados dentro dela. Agora, crie um arquivo chamado vars.tf onde armazenaremos as variáveis que serão utilizadas. variable "region" { default = "us-east-1" type = string } variable "bucket" { type = string } Crie um arquivo chamado provider.tf , onde adicionaremos a configuração do provider, no qual será a AWS. Isso significa que, o Terraform utilizará a AWS como nuvem para criar os recursos e fará o download dos plugins necessários na inicialização. Copie o código abaixo para o arquivo. provider "aws" { region = "${var.region}" } Crie um arquivo chamado s3.tf , onde adicionaremos as configurações para a criação de um novo Bucket S3 que será usado para a prática resource "aws_s3_bucket" "s3_bucket_notification" { bucket = "${var.bucket}" } Agora, crie um arquivo chamado sqs.tf , onde adicionaremos as configurações para a criação de uma fila SQS e algumas permissões conforme código abaixo: resource "aws_sqs_queue" "s3-notifications-sqs" { name = "s3-notifications-sqs" policy = <<POLICY { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:*:*:s3-notifications-sqs", "Condition": { "ArnEquals": { "aws:SourceArn": "${aws_s3_bucket.s3_bucket_notification.arn}" } } } ] } POLICY } Entendendo o código acima No código acima, estamos criando uma SQS e adicionando algumas configurações de policy, segue mais detalhes: O nome da SQS será s3-notifications-sqs, valor detalhado no campo name No campo policy, definimos uma política para que o S3 possa enviar mensagens de notificações para a SQS. Veja que estamos referenciando o Bucket S3 através de ARN no trecho ${aws_s3_bucket.s3_bucket_notification.arn} Para o último arquivo, vamos criar a configuração que permitirá o envio de notificações de eventos do Bucket S3 para uma SQS. Crie o arquivo s3_notification.tf e adicione o código abaixo: resource "aws_s3_bucket_notification" "s3_notification" { bucket = aws_s3_bucket.s3_bucket_notification.id queue { events = ["s3:ObjectCreated:*"] queue_arn = aws_sqs_queue.s3-notifications-sqs.arn filter_prefix = "files/" } } Entendendo o código acima No código acima, estamos criando um recurso chamado aws_s3_bucket_notification no qual será responsável por habilitar as notificações de um Bucket S3. No campo bucket, estamos referenciando através do ID, o bucket que será criado. Neste caso, estamos utilizando aws_s3_bucket + alias + id para a referência, no qual, o alias é o s3_bucket_notification, definido no arquivo s3.tf e por último, o id que será o identificador do Bucket que será criado. O campo queue é um bloco contendo algumas configurações como: events: É o tipo do evento da notificação. Neste caso, para eventos do tipo ObjectCreated, as notificações serão feitas apenas por objetos criados, ou seja, para objetos deletados, não haverá notificação. Isso ajuda para restringir alguns tipos de eventos. queue_arn: Referência para a SQS definida no arquivo sqs.tf filter_prefix: Este campo define a pasta em que desejamos que as notificações sejam disparadas. No código, definimos que a pasta files/ seja o gatilho. Resumindo, para todos arquivos criados dentro desta pasta, um notificação será enviada para a SQS definida no campo queue_arn. Executando o Terraform Inicie o Terraform terraform init Executando o Plan O plan possibilita verificar quais recursos serão criados, neste caso é necessário passar o valor da variável bucket para a criação do mesmo no S3. terraform plan -var bucket = 'digite o nome do bucket' Executando o Apply Neste passo, a criação dos recursos serão aplicados. Lembre-se de passar o nome do bucket em que deseja criar para a variável bucket e o nome bucket deve ser único. terraform apply -var bucket = 'digite o nome do bucket' Simulando um evento de notificação Após a execução dos passos anteriores e criado os recursos, vamos fazer um upload manual de um arquivo na pasta files/ do bucket que foi criado. Via console, acesse o Bucket criado no S3 e crie uma pasta chamada files. Dentro dela, carregue qualquer arquivo. Carregando um arquivo Após carregar o arquivo na pasta files, acesse o SQS criado. Você verá que existe mensagens disponíveis na SQS que foi criada nos passos anteriores. Acesse as mensagens e navegue pelas informações. Pronto, temos uma notificação de evento criada. Para mais informações, acesse os links: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_notification https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications.html Repositório do Github com o código: https://github.com/coffeeandtips/s3-bucket-notification-with-sqs-and-terraform Material de estudo Se quer aprender mais sobre o assunto e alcançar um alto nível de conhecimento, recomendo fortemente a leitura do(s) seguinte(s) livro(s): Terraform: Up & Running: Writing Infrastrucutre as Code (Versão Inglês) é um livo focado em como utilizar Terraform e seus benefícios. O autor buscou fazer comparações com diversas outras ferramentas IAC (Infrastructure as code) como Ansible e Cloudformation (IAC nativa da AWS) e principalmente de como criar e provisionar diferentes recursos para múltiplos serviços de nuvem. Atualmente, Terraform é a ferramenta mais utilizada em projetos de Software para a criação e gerenciamento de recursos no serviços de nuvem como AWS, Azure, Google cloud e vários outros. Se você quer ser um engenheiro completo, recomendo fortemente aprender sobre o tema. Amazon AWS: Descomplicando a computação na nuvem é um livro para aqueles que estão começando na AWS e querem entender o funcionamento e a dinâmicas dos serviços como S3, EC2, ElasticCache, Route 53, SNS, Cloudwatch e muito mais. AWS Cookbook (Versão Inglês) é um guia prático contendo 70 receitas detalhadas sobre os recursos da AWS e como resolver diferentes desafios. É um livro bem escrito e de fácil entendimento cobrindo os principais serviços da AWS através de exemplos práticos. A AWS ou Amazon Web Services é o serviço de nuvem mais utilizando atualmente em todo o mundo, caso queira entender mais sobre o tema para ficar bem posicionado no mercado, recomendo fortemente o estudo. É isso, curtiu? Até mais!

Salesforce é uma plataforma com vários módulos específicos para fazer a gestão do relacionamento do cliente em várias etapas da jornada, como venda e pós-venda, suporte, marketing, etc. O desenvolvimento com na plataforma Salesforce é uma das várias áreas do mundo dev que mais cresce nos últimos anos. É bem provável que se você está trabalhando com o CRM, também vai precisar fazer algumas integrações com outros sistemas ou base de dados da sua empresa, e para quem está iniciando nessa jornada, aqui vai um exemplo simples com a implementação de um endpoint no Salesforce e uma chamada externa a ele. Vamos lá!!! O primeiro passo é liberar o Salesforce para receber chamadas externas de URLs específicas. Por padrão, o Salesforce não aceita chamadas externas, então para liberar, você deve seguir os seguintes passos: Logar no Salesforce com acesso de administrador. Ir em Setup Na barra de busca procure por “Remote Site Settings” Crie um novo registro com a url da aplicação que fará a chamada REST ao Salesforce. Feito isso, agora podemos implementar um endpoint no salesforce como no modelo abaixo: @RestResource(urlMapping='/coffeeandtips/exemplo/*') global with sharing class ExemploController { @HttpPost global static void recebeDadosESalva(List req) { String requestData = JSON.serialize(req); [...] } } No próximo passo, vamos precisar fazer mais algumas configurações no salesforce. Logar no Salesforce com acesso de administrador. Ir em Setup Na barra de busca procure por “Connected Apps” Procure pelas informações “Consumer Key” e “Consumer Secret” Pronto! Agora já conseguimos fazer chamadas para o endpoint que acabamos de criar. Para isso, antes de fazer a chamada de fato, vamos precisar obter um token utilizando a key e secret do passo anterior. A chamada deve ser feita com os seguintes parâmetros: POST para https://minhaurl.salesforce.com/services/oauth2/token Content-type : application/x-www-form-urlencoded Parametros: grant_type : {esse parâmetro será sempre do tipo “password”} client_id: {Consumer Key obtida no passo anterior} client_secret : {Consumer Secret obtida no passo anterior} username: {username de um usuário com permissões para fazer chamadas externas (pode ser o usuario que você usou para logar no salesforce)} password: {senha de um usuário com permissões para fazer chamadas externas (pode ser o usuario que você usou para logar no salesforce)} Você receberá um token como resposta desse POST. E Finalmente podemos fazer uma chamada rest para o endpoint que criamos no Salesforce. POST para https://minhaurl.salesforce.com/services/apexrest/coffeeandtips/exemplo Content-type: application/json Parametros: Authorization : Bearer “Token Obtido no passo anterior” É isso pessoal. Espero ter contribuído. Até a próxima!

Antes de começar a falar sobre o acesso aos estados, é necessário explicar o que são os estados ou State. O que são os States? O que é o Terraform State? O Terraform State é uma forma do Terraform gerenciar a infra, configurações e os recursos criados afim de manter um mapeamento do que já existe e controlar a atualização e criação de novos recursos. Um exemplo básico é quando criamos um Bucket S3, um EC2 ou uma SQS via Terraform. Todos estes recursos são mapeados no estado e passam a ser gerenciados pelo Terraform. Localização do State Local Por padrão o Terraform aloca o estado localmente no arquivo terraform.tfsate. Utilizar o State localmente pode funcionar bem para um estudo específico no qual não exista a necessidade em compartilhar o State entre times. Remote Ao contrário do Local, quando temos times compartilhando dos mesmos recursos, a utilização do State de forma remota se torna imprescindível. O Terraform provê suporte para que o State possa ser compartilhado de forma remota. Não entraremos em detalhes em como configurar, mas é possível manter o State no Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS e entre outras nuvens. O State é representado pelo arquivo terraform.tfsate, um arquivo no formato JSON, segue um exemplo de um Bucket S3 mapeando no State: { "version": 4, "terraform_version": "0.12.3", "serial": 3, "lineage": "853d8b-6ee1-c1e4-e27e-e10", "outputs": {}, "resources": [ { "mode": "managed", "type": "aws_s3_bucket", "name": "s3_bucket_xpto", "provider": "provider.aws", "instances": [ { "schema_version": 0, "attributes": { "acceleration_status": "", "acl": "private", "arn": "arn:aws:s3:::bucket.xpto", "bucket": "bucket.xpto", "bucket_domain_name": "bucket.xpto", "bucket_prefix": null, "bucket_regional_domain_name": "bucket.xpto", "cors_rule": [], "force_destroy": false, "grant": [], "hosted_zone_id": "Z3NHGSIKTF", "id": "bucket.xpto", "lifecycle_rule": [], "logging": [], "object_lock_configuration": [], "policy": null, "region": "us-east-1", "replication_configuration": [], "request_payer": "BucketOwner", "server_side_encryption_configuration": [], "tags": { "Environment": "staging" }, "versioning": [ { "enabled": false, "mfa_delete": false } ], "website": [], "website_domain": null, "website_endpoint": null }, "private": "UJbhV==" } ] } ] } Acessando e alterando o State Apesar do State estar alocado em um arquivo JSON, não é recomendado a alteração direta no arquivo. O Terraform provê a utilização do comando Terraform state executado via CLI para que pequenas modificações sejam efetuadas. Através do CLI, podemos executar comandos afim de manipular o State, segue o uso: terraform state [options] [args] Sub-comandos: list Lista os recursos no estado mv Move um item no estado pull Extrai o estado atual e lista o resultado no stdout push Atualiza um estado remoto de um arquivo de estado local rm Remove instância do estado show Mostra recursos do estado 1. Listando os recursos do State Comando: terraform state list O comando acima possibilita listar os recursos que estão sendo gerenciados pelo State Exemplo: $ terraform state list aws_s3_bucket.s3_bucket aws_sqs_queue.sqs-xpto No exemplo acima, temos um Bucket S3 e um SQS que foram criados via terraform e que estão sendo gerenciados pelo State. 2. Visualizando um recurso e seus atributos Comando: terraform state show [options] ADDRESS O comando acima possibilita mostrar em detalhes um recurso específico e seus atributos Exemplo: $ terraform state show aws_sqs_queue.sqs-xpto # aws_sqs_queue.sqs-xpto: resource "aws_sqs_queue" "sqs-xpto" { arn = "arn:aws:sqs:sqs-xpto" content_based_deduplication = false delay_seconds = 90 fifo_queue = false id = "https://sqs-xpto" kms_data_key_reuse_period_seconds = 300 max_message_size = 262144 message_retention_seconds = 345600 name = "sqs-xpto" receive_wait_time_seconds = 10 tags = { "Environment" = "staging" } visibility_timeout_seconds = 30 } 3. Removendo recursos do State Comando: terraform state rm [options] ADDRESS... O comando acima remove um ou mais items do State. Diferente de um terraform destroy, que remove o recurso do State e os objetos remotos criados na nuvem. Exemplo: $ terraform state rm aws_sqs_queue.sqs-xpto Material de estudo Se quer aprender mais sobre o assunto e alcançar um alto nível de conhecimento, recomendo fortemente a leitura do(s) seguinte(s) livro(s): Terraform: Up & Running: Writing Infrastrucutre as Code (Versão Inglês) é um livo focado em como utilizar Terraform e seus benefícios. O autor buscou fazer comparações com diversas outras ferramentas IAC (Infrastructure as code) como Ansible e Cloudformation (IAC nativa da AWS) e principalmente de como criar e provisionar diferentes recursos para múltiplos serviços de nuvem. Atualmente, Terraform é a ferramenta mais utilizada em projetos de Software para a criação e gerenciamento de recursos no serviços de nuvem como AWS, Azure, Google cloud e vários outros. Se você quer ser um engenheiro completo, recomendo fortemente aprender sobre o tema. Amazon AWS: Descomplicando a computação na nuvem é um livro para aqueles que estão começando na AWS e querem entender o funcionamento e a dinâmicas dos serviços como S3, EC2, ElasticCache, Route 53, SNS, Cloudwatch e muito mais. AWS Cookbook (Versão Inglês) é um guia prático contendo 70 receitas detalhadas sobre os recursos da AWS e como resolver diferentes desafios. É um livro bem escrito e de fácil entendimento cobrindo os principais serviços da AWS através de exemplos práticos. A AWS ou Amazon Web Services é o serviço de nuvem mais utilizando atualmente em todo o mundo, caso queira entender mais sobre o tema para ficar bem posicionado no mercado, recomendo fortemente o estudo. E aí, Curtiu? Até mais!

Neste post, iremos criar uma aplicação Lambda AWS usando Python. Será um passo a passo, desde criar o código fonte, que será bem simples, passando pela criação da role e por fim, o deploy da aplicação. Este tutorial será baseado na documentação da AWS, pois, muitas vezes os usuários possuem uma dificuldade em ler uma documentação por talvez ser um pouco verbosa ou até estar em outra língua, por isso, decidi criar este passo a passo baseando-se na própria documentação da AWS e espero que gostem. O que é um Lambda? Lambdas são conhecidos como aplicações serverless, ou seja, são aplicações que não tem a necessidade em configurar um servidor memória, CPU etc. Todo o poder computacional é gerenciado pela própria AWS e isso nos dá a flexibilidade de apenas se preocupar com o código que será executado. Característica de um Lambda O Lambda possui uma característica diferente de uma aplicação tradicional, que tem uma característica de uptime 24/7, para isso, temos que ter em mente a finalidade do seu uso. A característica principal é que um Lambda é executado para uma tarefa específica e após o término, ela basicamente "morre". Isso é muito positivo, pois gera uma boa economia e os recursos são bem mais utilizados. Imagine que você recebeu uma tarefa para criar uma aplicação que enviará emails algumas vezes durante o dia. Faz sentido manter uma aplicação online 100% do tempo para este tipo de tarefa? Você até pode fazer, mas estaria desperdiçando recursos, por na maioria do tempo a aplicação estar ociosa e o tempo de execução da tarefa seria em questão de poucos minutos ou nem isso. Já um Lambda, seria uma abordagem ideal para este cenário. Imagine que os emails devem ser enviados 6 vezes ao dia em um intervalo de 4 horas. A aplicação executaria a tarefa, terminaria e depois de 4 horas executaria novamente. E cada execução seria em torna de 2 minutos. Resumindo, o objetivo da tarefa seria alcançado em pouco tempo e com um baixo custo computacional. Mãos na massa Nos próximos passos, criaremos o nosso código em Python na versão 3.8, em seguida, a role com as permissões necessárias para a execução do Lambda. Vamos anexar a role criada á uma policy, criaremos a aplicação Lambda, e em seguida, vamos compactar o arquivo com o código para o deploy, e por fim, faremos uma invocação para execução da Lambda. Os passos após o código, iremos executar utilizando CLI, para isso faça a instalação do AWS CLI seguindo esta documentação . O CLI é uma das maneiras de interação com a AWS e é bem simples a sua utilização. Existem outras maneiras também de interagir com a AWS para a criação de recursos, o mais comum no mercado é utilizando ferramentas IAC, como Cloudformation e Terraform. Já até criamos um tutorial sobre estes recursos, basta acessar os links abaixo para entender melhor, mas para este tutorial, seguiremos como base a documentação da AWS, utilizando CLI. Criando recursos utilizando Cloudformation Primeiros passos utilizando Terraform na AWS Após a instalação do CLI, configure suas credenciais da AWS executando o comando abaixo via terminal. Caso você não conheça este comando, recomendo a leitura de como utilizar, nesta documentação, aws configure Criando o código da Lambda A seguir, criaremos o código que será executado na aplicação Lambda, será um código muito simples apenas para exemplificar a execução. Utilizaremos Python neste exemplo, mas é possível utilizar várias outras linguagens de programação para a criação da Lambda. Crie um arquivo chamado lambda_function.py e escreva o código abaixo. import logging logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): name = event['yourname'] message = {'Message': 'hello ' + name + ' ,this is your first ' 'Lambda application!' } logger.info(message) Criando a role O comando a seguir criará a role chamada lambda-default-role. A role é uma forma de dar permissão para um recurso específico executar uma ação específica. Execute via terminal. aws iam create-role --role-name lambda-default-role --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole"}]}' Após a execução do comando acima, um output como este será mostrado. { "Role": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" } } ] }, "RoleId": "AROA5WDL5GTDVI43EJEUOV", "CreateDate": "2021-09-12T22:11:04Z", "RoleName": "lambda-default-role", "Path": "/", "Arn": "arn:aws:iam::id-da-sua-conta:role/lambda-default-role" } } Anexando a role á uma policy Para este passo, basta executar o comando abaixo via terminal aws iam attach-role-policy --role-name lambda-default-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Zipando o arquivo Python Neste passo, vamos compactar o arquivo Python contendo o código que escrevemos nos passos anteriores, para isso, acesse a pasta onde o arquivo se encontra e execute o comando abaixo. zip my-deployment-package.zip lambda_function.py Criando a função Lambda e efetuando o deploy Agora criaremos a função Lambda chamada my-first-lambda e no mesmo comando, vamos anexar o código compactado no passo anterior. Lembre-se que este comando deve ser executado na mesma pasta onde o arquivo foi zipado, ok? aws lambda create-function --function-name my-first-lambda --zip-file fileb://my-deployment-package.zip --handler lambda_function.lambda_handler --runtime python3.8 --role arn:aws:iam::id-da-sua-conta:role/lambda-default-role Entendendo o comando acima aws lambda create-function --function-name my-first-lambda: Comando para criar a função Lambda chamada my-first-lambda --zip-file fileb://my-deployment-package.zip: Anexa o arquivo my-deployment-package.zip na criação da função, onde contém o código fonte. --handler lambda_function.lambda_handler: Esse parâmetro seta a nome da função lambda_handler, ou seja, quando o Lambda for invocado, será está função que será executada. Esta mesma função deve existir no arquivo Python, conforme criamos anteriormente no primeiro passo. --runtime python3.8: Neste parâmetro, passamos como argumento a linguagem em que estamos usando para o Lambda, no nosso caso, Python com a versão 3.8 --role arn:aws:iam::id-da-sua-conta:role/lambda-default-role: Por último, passamos o valor do parâmetro role. O valor deste parâmetro é mostrado no output após a criação da role, no campo Arn, basta copiar e colar. Pronto, agora que você entendeu, basta executar via terminal para a criação definitiva do Lambda. Veja que o Lambda foi criado com sucesso, agora vamos fazer algumas invocações para que o Lambda seja executado. Invocando o Lambda Neste passo, vamos executar o Lambda através de uma invocação manual. Existem diversas outras formas em invocar uma aplicação Lambda. A invocação pode ser feita através de um Event-Bridge que funcionaria como um gatilho, no qual podemos configurar um cron, que poderá invocar o Lambda de tempos pré-determinados, como, minuto a minuto, hora em hora, 1 vez por semana e dentre outras opções. Existem várias outras formas, todas elas são descritas na documentação da AWS, mas para este post, faremos de forma manual, utilizando o CLI. aws lambda invoke --function-name my-first-lambda --payload '{"yourname": "Mônica"}' output.txt Entendendo o comando acima aws lambda invoke --function-name my-first-lambda: Invoca o Lambda my-first-lambda ---payload '{"yourname": "Mônica"}': No payload é onde passamos o valor do input que o Lambda vai processar. Neste caso, estamos passando um JSON com uma informação. O segundo parâmetro, o output.txt, será o arquivo que armazenará informações como, o response do Lambda caso exista ou algum log de erro, caso aconteça. Você pode acessar os logs do Lambda através do Cloudwatch para visualizar melhor os logs que definimos no código Python. Atualizando o código Caso precise alterar o código, refaça o passo em que zipamos o arquivo e em seguida, execute o comando abaixo. aws lambda update-function-code --function-name my-first-lambda --zip-file fileb://my-deployment-package.zip Pronto, agora temos um Lambda! Caso queira ler a documentação da AWS sobre como criar um Lambda, siga esta documentação. É isso, curtiu? Até mais!

É muito comum que Devs Salesforce precisem integrar dados do CRM com um banco de dados ou data lake por exemplo de uma empresa. Quando o volume desses dados são altos, fazer essa integração via REST pode não ser a forma mais elegante, até porque o próprio Salesforce possui algumas travas que dificultam por exemplo enviar um payload com uma lista de objetos para integração. O passo a passo a seguir mostra como podemos enviar dados de uma API qualquer para o Salesforce ou do Salesforce para qualquer API utilizando o serviço AppFlow da AWS para a orquestração e S3 para integração. Envio de dados do Salesforce para S3 Vamos criar um objeto simples para simular a integração. No Salesforce vá em Setup e procure por Integrations >> Platform Events e crie um novo evento. Na seção Custom Fields, vamos criar apenas dois campos para exemplificar, ID e Name. Agora, vamos focar em algumas tarefas no painel AWS. Procure pelo serviço AppFlow e crie um novo Fluxo. Dê um nome para o Fluxo e clique em próximo. No segundo passo, você deverá selecionar a origem do evento. Nesse caso, dentre as diversas opções você encontrará “Salesforce”. Após selecionar, você precisará especificar a conexão. Faça login na conta de sua preferencia (Production ou Sandbox) e prossiga. Ainda nesse formulário de origem, selecione o evento criado no Salesforce no primeiro passo deste tutorial. No formulário de destino, selecione um bucket do S3 onde deseja que os arquivos de integração sejam salvos e prossiga. Na próxima tela, faça o mapeamento dos campos do Evento que você deseja salvar no arquivo S3. Clique em próximo no Passo 4 e em Criar Fluxo no passo 5. Será exibida uma mensagem que o Fluxo foi criado. Por fim, clique em Ativar Fluxo. Pronto!!! O Fluxo já está com status ativo. Agora vamos escrever um simples teste no Salesforce para enviar um evento e verificar o funcionamento do nosso fluxo criado acima. Abra o Developer Console do Salesforce, vá em Debug e selecione Open Execute Anonymous Window. Vamos publicar um simples evento como o exemplo abaixo: EventTest__e myEvent = new EventTest__e(); myEvent.ID__c = 1; myEvent.Name__c = 'My First Event'; EventBus.publish(myEvent); E… PRONTO! Agora é só verificar o S3 e você irá encontrar uma pasta com o nome do Fluxo e os arquivos do evento na pasta. Nessa situação você pode conectar qualquer API do seu ambiente externo ao Salesforce e consumir esses dados. Envio de Dados S3 para Salesforce E se podemos usar o S3 para consumir os dados do Salesforce por uma API externa, também podemos usá-lo para enviar dados para o CRM. Nesse caso faremos da seguinte forma. Dentro do mesmo bucket S3 do exemplo anterior, criaremos uma pasta chamada ingest que usaremos para enviar os arquivos com os dados que queremos integrar com o Salesforce. Agora, voltamos ao AppFlow e vamos criar um novo fluxo. No próximo passo, selecionamos o bucket e a pasta criada e ainda o formato de dados JSON. Em seguida, informamos o destino desses dados, selecionamos Salesforce, a sandbox e o objeto onde será inserido os dados. Nesse caso, criamos um objeto customizado no Salesforce chamado S3EventIngest. Nesse primeiro momento, deve ser adicionado a pasta especificada acima “ingest”, um arquivo JSON contendo um mapeamento DE-PARA relacionando os atributos do Json que será consumido pelo fluxo e os campos referentes ao salesforce. No caso, adicionamos o um arquivo.json com o seguinte código: {"ID":"ID__c","Name":"Name__c"} No próximo passo, faça o mapeamento dos atributos JSON que serão enviados no arquivo para o S3 para os campos do objeto Salesforce. Com o mapeamento feito, seguiremos os próximos passos sem fazer nenhuma modificação até que o fluxo seja concluído e criado. É possível configurar triggers para que o fluxo seja executado de forma periódica, mas aqui vamos apenas executar manualmente. Depois de criado, podemos fazer um teste simples. Para isso, vamos EXCLUIR o arquivo da pasta ingest que adicionamos anteriormente e adicionar um arquivo com registros reais de fato. Nesse caso, vamos adicionar a pasta ingest um arquivo com o seguinte json: [ {"ID":779,"Name":"My Event Json 1"}, {"ID":780,"Name":"My Event Json 2"}, {"ID":781,"Name":"My Event Json 3"}, {"ID":782,"Name":"My Event Json 4"} ] Após carregar o arquivo no S3, volte ao fluxo e clique no botão “Executar Fluxo” Espere alguns segundos e você verá uma mensagem de sucesso e também pode consultar o histórico de execução com os últimos processamentos. Além disso, consulte também no Salesforce e você verá os dados inseridos. É isso pessoal, espero ter ajudado!!

O Terraform é uma ferramenta do tipo IaC (Infrastructure as code) que possibilita provisionar infra-estrutura nos serviços de nuvem, ou seja, ao invés de criar manualmente recursos na nuvem, o Terraform facilita a criação e o controle deste serviços através de gerenciamento de estado em poucas linhas código. O Terraform tem sua linguagem própria e pode ser utilizada de forma independente com outras linguagens de forma isolada. Para este tutorial, iremos criar um Bucket S3 e uma SQS utilizando Terraform na AWS. Instalação Terraform Para a instalação, faça o download do instalador neste link https://www.terraform.io/downloads.html e escolha o seu sistema operacional. Provider AWS Utilizaremos a AWS como provider, ou seja, quando selecionamos a AWS como provider, o Terraform fará o download dos pacotes que possibilitará a criação de recursos específicos para a AWS. Para seguir nos próximo passos, estamos levando em conta que você já possui: Credenciais da AWS O seu usuário já possui permissões necessárias para criar recursos na AWS Autenticação Como nós estamos utilizando a AWS como provider, precisamos configurar o Terraform para autenticar e em seguida criar os recursos. Existem algumas maneiras de autenticação. Pare este tutorial, escolhi utilizar um dos mecanismos da AWS que permite alocar as credencias em um arquivo na pasta $HOME/.aws e utilizar como fonte de autenticação única. Para criar esta pasta com as credenciais, precisamos instalar o AWS CLI, acesse este link e siga os passos de instalação. Este mecanismo evita a utilização das credenciais diretamente no código, dessa forma, caso precise executar algum comando ou SDK que conecte a AWS localmente, estas credencias serão carregadas a partir deste arquivo. Configuração das credenciais Após instalar o AWS CLI, abra o terminal e execute o comando a seguir: aws configure No próprio terminal, preencha os campos utilizando os dados das credencias do seu usuário: Após o preenchimento, 2 arquivos textos serão criados no diretório $HOME/.aws config: contendo o profile, neste caso o profile default foi criado credentials: contendo as credenciais Vamos alterar os arquivos para adequar a este tutorial, altere o arquivo config conforme abaixo: [profile staging] output = json region = us-east-1 [default] output = json region = us-east-1 No caso, temos 2 perfis configurados, o default e um perfil de staging. Altere o arquivo credentials conforme abaixo, substituindo pelas suas credenciais. [staging] aws_access_key_id = [Access key ID] aws_secret_access_key = [Secret access key] [default] aws_access_key_id = [Access key ID] aws_secret_access_key = [Secret access key] Criando os arquivos Terraform base Após todas estas configurações, iremos começar a trabalhar de fato com o Terraform. Para isso precisamos criar alguns arquivos base que vai nos auxiliar na criação dos recursos na AWS. 1º Passo: No diretório root do seu projeto, crie um pasta chamado terraform/ 2º Passo: Dentro da pasta terraform/, crie os arquivos: main.tf vars.tf 3º Passo: Crie uma pasta chamada staging dentro de terraform/ 4º Passo: Dentro da pasta terraform/staging/ crie o arquivo: vars.tfvars Pronto, agora temos a estrutura de pasta que vamos utilizar nos próximos passos. Configurando os arquivos Terraform Vamos começar pela declaração das variáveis utilizando o arquivo vars.tf. vars.tf Neste arquivo é onde vamos criar a variáveis em que vamos utilizar em nosso contexto, podemos criar variáveis com um valor default ou simplesmente vazias, onde estas serão preenchidas de acordo com o ambiente de execução, onde será explicado mais a frente. variable "region" { default = "us-east-1" type = "string" } variable "environment" { } Criamos 2 variáveis: region: Variável do tipo string e seu valor default é a região da AWS em que vamos criar os recursos environment: Variável que vai representar o ambiente de execução staging/vars.tfvars Neste arquivo estamos definindo o valor da variável environment criada anteriormente sem valor default. environment = "staging" Essa separação é bem útil quando temos mais de um ambiente, caso tivéssemos um ambiente de produção, poderíamos ter criado outro arquivo vars.tfvars em uma pasta chamada production. Dessa forma, podemos escolher em qual ambiente vamos executar o Terraform. Vamos entender esta parte, quando executamos mais a frente. main.tf Este será o principal arquivo onde iremos declarar os recursos para que sejam criados na AWS. Nesta etapa vamos declarar os recursos para que seja criado um Bucket S3 e uma SQS. Vamos entendendo o arquivo em partes. Nesta primeira parte estamos declarando a AWS como provider e setando a região utilizando a variável que criamos anteriormente através de interpolação ${..}. Provider provider "aws" { region = "${var.region}" } Criando o Bucket S3 Para criar um recurso via Terraform, sempre começamos com a palavra chave resource e em seguida o nome do recurso e por fim um identificador. resource "nome do recurso" "identificador" {} Neste trecho estamos criando um Bucket chamado bucket.blog.data, lembre-se que nomes de Buckets devem ser únicos. O campo acl define as restrições do Bucket, neste caso, private. O campo tags é utilizado para passar informações extras ao recurso, neste caso será passando o valor da variável environment. Mais campos são descritos na documentação. resource "aws_s3_bucket" "s3_bucket" { bucket = "bucket.blog.data" acl = "private" tags = { Environment = "${var.environment}" } } Criando a SQS No próximo trecho, vamos criar uma SQS chamada sqs-posts. A criação do recurso segue as mesmas regras que descrevemos anteriormente. Para este cenário configuramos os campos delay_seconds que define o tempo de espera de uma mensagem ser entregue. Mais campos são descritos na documentação. resource "aws_sqs_queue" "sqs-blog" { name = "sqs-posts" delay_seconds = 90 tags = { Environment = "${var.environment}" } } Executando o Terraform 1º Passo : Inicializar o Terraform Dentro do diretório /terraform execute o comando: terraform init Mensagens no console após a execução: 2º Passo: No Terraform existem workspaces. São ambientes de execução em que o Terraform provê para executar os recursos e separar os estados entre eles. Após inicializado, um workspace default é criado. terraform workspace list Para este tutorial vamos simular um ambiente de desenvolvimento. Lembra que criamos uma pasta chamada /staging ? Sim, esta pasta simula um ambiente de desenvolvimento. Para isso, vamos criar um workspace no Terraform chamado staging também. Se tivéssemos um ambiente de produção, um workspace de produção poderia ser criado. terraform workspace new "staging" Pronto, criamos um novo workspace e já estamos utilizando. 3º Passo: Neste passo, vamos listar todos os recursos existentes ou os que serão criados, neste caso, a última opção. terraform plan -var-file=staging/vars.tfvars O argumento plan possibilita visualizar os recursos que serão criados ou atualizados, é uma boa opção para entender o comportamento antes que o recurso seja criado definitivamente. O segundo argumento -var-file possibilita escolher um caminho específico contendo os valores das variáveis que serão utilizadas de acordo com o ambiente de execução. Neste caso o arquivo /staging/vars.tfvars contém valores referentes ao ambiente de staging. Caso existisse um workspace de produção, a execução seria a mesma, porém para uma pasta diferente. Mensagens no console após a execução: 4º Passo: Neste passo, vamos criar os recursos definitivamente. terraform apply -var-file=staging/vars.tfvars Basta substituir o plan por apply, em seguida uma mensagem de confirmação será mostrada no console: Digite yes para aplicar os recursos e aguarde o fim da execução. Pronto, o Bucket S3 e a SQS form criados! Agora você pode conferir direto no console da AWS. Escolha de workspace Caso necessite mudar de workspace, execute o comando selecionando o workspace em que deseja utilizar: terraform workspace select "[workspace]" Destruindo os recursos Esta parte do tutorial requer muita atenção. O próximo comando possibilita remover todos os recursos que foram criados sem a necessidade em remover um por um. terraform destroy -var-file=staging/vars.tfvars Digite yes, caso deseja que todos os recursos criados sejam destruídos. Não recomendo utilizar este comando em um ambiente profissional, mas para este tutorial é útil para que você não esqueça de apagar e a AWS te cobrar no futuro. Conclusão Terraform possibilita criar infra-estruturas de forma bem simples através de código e também oferece bastante segurança mantendo os recursos através do uso de estados. Para este tutorial utilizamos a AWS como provider, mas é possível utilizar Google Cloud, Azure e entre outros. Material de estudo Se quer aprender mais sobre o assunto e alcançar um alto nível de conhecimento, recomendo fortemente a leitura do(s) seguinte(s) livro(s): Terraform: Up & Running: Writing Infrastructure as Code (Versão Inglês) é um livro focado em como utilizar Terraform e seus benefícios. O autor buscou fazer comparações com diversas outras ferramentas IAC (Infrastructure as code) como Ansible e Cloudformation (IAC nativa da AWS) e principalmente de como criar e provisionar diferentes recursos para múltiplos serviços na nuvem. Atualmente, Terraform é a ferramenta mais utilizada em projetos de Software para a criação e gerenciamento de recursos nos serviços de nuvem como AWS, Azure, Google cloud e vários outros. Se você quer ser um engenheiro completo ou atuar na área de Devops, recomendo fortemente aprender sobre o tema. Amazon AWS: Descomplicando a computação na nuvem é um livro para aqueles que estão começando na AWS e querem entender o funcionamento e a dinâmica dos serviços como S3, EC2, ElasticCache, Route 53, SNS, Cloudwatch e muito mais. AWS Cookbook (Versão Inglês) é um guia prático contendo 70 receitas detalhadas sobre os recursos da AWS e como resolver diferentes desafios. É um livro bem escrito e de fácil entendimento cobrindo os principais serviços da AWS através de exemplos práticos. A AWS ou Amazon Web Services é o serviço de nuvem mais utilizando atualmente em todo o mundo, caso queira entender mais sobre o tema para ficar mais bem posicionado no mercado, recomendo fortemente o estudo.

O DBT tem sido utilizado por muitas empresas na área de Dados e acredito que podemos extrair bons insights neste post sobre ele. Esse vai ser um post prático mostrando como o DBT funciona e espero que vocês gostem. O que é DBT? DBT significa Data Build Tool e permite que equipes transformem os dados já carregados em seu warehouse através de operações de DML como um simples Select. DBT representa o T no processo de ELT, ou seja, ele não trabalha para extrair e carregar dados mas sim, para transformá-los. Passo 1: Criando o projeto DBT Agora, assumimos que o DBT já esteja instalado, mas se não estiver, recomendo consultar este link para mais informações. Após a instalado, você pode criar um novo projeto usando CLI ou pode clonar este projeto do repositório DBT no Github. Aqui para este post, vamos usar o modo CLI para criar nosso projeto e também para concluir as próximas etapas. Para criar um novo projeto, execute o comando abaixo no seu terminal. dbt init Depois de executar o comando acima, você precisa digitar o nome do projeto e qual warehouse ou banco de dados você vai usar conforme a imagem abaixo. Para este post, vamos usar o adaptador do postgres. É muito importante que você tenha o banco de dados postgres já instalado ou você pode criar uma imagem postgres usando o docker. Sobre os adaptadores, o DBT suporta vários deles e você pode conferir aqui. Criei uma estrutura de tabela e também carreguei os dados simulando dados de uma plataforma de vídeo chamada wetube e vamos utilizá-los para entender como o DBT funciona. Acompanhe a estrutura: Passo 2: Estrutura e mais sobre DBT Após executar o comando dbt init para criar o projeto, uma estrutura de pastas e arquivos abaixo será criada. Não vou falar sobre todos os diretórios do projeto, mas gostaria de focar em dois deles. Sources Antes de falarmos sobre os dois diretórios, vamos falar sobre os Sources, são basicamente os dados já carregados em seu warehouse. No processo DBT, as fontes têm o mesmo significado de dados brutos. Não há pastas que representem dados Sources para este projeto, mas você precisa saber sobre este termo pois vamos configurar tabelas já criadas como Sources para as próximas seções. Seeds Seeds é um diretório que oferece um mecanismo interessante e útil para carregar dados estáticos em seu warehouse por meio de arquivos CSV. Se você deseja carregar esses dados, você precisa criar um arquivo CSV neste diretório e executar o comando abaixo. dbt seed Para cada campo no arquivo CSV, o DBT irá inferir os tipos e criará tabelas e suas colunas no warehouse ou banco de dados. Models O DBT funciona com o paradigma de Model, a ideia principal é que você pode criar modelos através da transformações utilizando instruções SQL baseadas em fontes de tabelas ou modelos existentes Cada arquivo SQL localizado na pasta de model criará um modelo em seu warehouse ou banco de dados quando o comando abaixo for executado. dbt run Lembre-se que um modelo pode ser criado através de uma fonte ou outro modelo e não se preocupe com isso, vou mostrar mais detalhes sobre isso. Passo 3: Configurando a configuração com o banco de dados Com o projeto já criado, precisamos configurar a conexão com o banco de dados e aqui neste post vamos usar o postgres como banco de dados. Depois de inicializar o projeto, vários arquivos são criados e um deles é chamado de profiles.yml. profiles.yml é o arquivo é responsável por controlar os diferentes perfis/profiles para as diferentes conexões com os bancos de dados, como ambiente de desenvolvimento e produção. Se você notou, não podemos ver este arquivo na imagem acima porque este arquivo é criado fora do projeto para evitar credenciais que sejam confidenciais. Você pode encontrar esse arquivo no diretório ~/.dbt/. Se você observar, temos um perfil chamado dbt_blog e um destino chamado dev, por padrão, o destino refere-se a dev com as configurações de conexão do banco de dados. Além disso, é possível criar um ou mais perfis e alvos(target), permitindo trabalhar com diferentes ambientes. Outro detalhe importante é que o perfil dbt_blog deve ser especificado no arquivo dbt_project.yml como um perfil padrão. Nas próximas seções, discutiremos o que é e como o arquivo dbt_project.yml funciona. Passo 4: Criando o arquivo dbt_project.yml Todo projeto DBT possui um arquivo dbt_project.yml, você pode configurar informações como nome do projeto, diretórios, perfis e tipo de materialização. name: 'dbt_blog' version: '1.0.0' config-version: 2 profile: 'dbt_blog' model-paths: ["models"] analysis-paths: ["analyses"] test-paths: ["tests"] seed-paths: ["seeds"] macro-paths: ["macros"] snapshot-paths: ["snapshots"] target-path: "target" # directory which will store compiled SQL files clean-targets: # directories to be removed by `dbt clean` - "target" - "dbt_packages" models: dbt_blog: # Config indicated by + and applies to all files under models/example/ mart: +materialized: table Observe que o campo de profile foi configurado como o mesmo profile especificado no arquivo profiles.yml e outro detalhe importante é sobre o campo materialized. Aqui foi configurado como um valor table, mas por padrão, é uma view. O campo materialized permite que você crie modelos como uma tabela ou view em cada execução. Existem outros tipos de materialização, mas não vamos discutir aqui e eu recomendo ver a documentação do dbt. Passo 5: Criando nosso primeiro modelo Criando os primeiros arquivos Vamos mudar um pouco e vamos criar uma subpasta no diretório do model chamada mart e dentro desta pasta vamos criar nossos arquivos .SQL e também outro arquivo importante que ainda não discutimos chamado schema.yml. Criando o arquivo schema Os arquivos de schema são usados ​​para mapear fontes e documentar modelos como o nome do modelo, colunas e muito mais. Agora você pode criar um arquivo chamado schema.yml e preencher com as informações abaixo. version: 2 sources: - name: wetube tables: - name: account - name: city - name: state - name: channel - name: channel_subs - name: video - name: video_like - name: user_address models: - name: number_of_subs_by_channel description: "Number of subscribers by channel" columns: - name: id_channel description: "Channel's ID" tests: - not_null - name: channel description: "Channel's Name" tests: - not_null - name: num_of_subs description: "Number of Subs" tests: - not_null Sources: No campo source você pode incluir tabelas do seu warehouse ou banco de dados que serão utilizadas na criação do modelo. models: No campo models você pode incluir o nome do modelo, colunas e suas descrições Criando um modelo Esta parte é onde podemos criar scripts .SQL que resultarão em nosso primeiro modelo. Para o primeiro modelo, vamos criar uma instrução SQL para representar um modelo que podemos ver os números de inscritos do canal. Vamos criar um arquivo chamado number_of_subs_by_channel.sql e preenchê-lo com os scripts abaixo. with source_channel as ( select * from {{ source('wetube', 'channel') }} ), source_channel_subs as ( select * from {{ source('wetube','channel_subs') }} ), number_of_subs_by_channel as ( select source_channel.id_channel, source_channel.name, count(source_channel_subs.id_subscriber) num_subs from source_channel_subs inner join source_channel using (id_channel) group by 1, 2 ) select * from number_of_subs_by_channel Entendendo o modelo Observe que temos vários scripts separados por expressão de tabela comum (CTE) que se torna útil para entender o código. O DBT permite usar o template Jinja {{ }} trazendo uma maior flexibilidade ao nosso código. O uso da palavra-chave source dentro do modelo Jinja significa que estamos nos referindo a tabelas de origem. Para referenciar um modelo, você precisa usar a palavra-chave ref. A última instrução SELECT baseada nas tabelas de origem (source) irá gerar o modelo (model) como tabela no banco de dados. Executando o nosso primeiro modelo Execute o comando abaixo para criar nosso primeiro modelo baseado nos arquivos anteriores. dbt run Saída Criando um novo modelo Imagine que precisamos criar um novo modelo contendo as informações da conta e seus canais. Vamos voltar ao arquivo schema.yml para adicionar esse novo modelo. - name: account_information description: "Model containing account information and it's channels" columns: - name: id_account description: "Account ID" tests: - not_null - name: first_name description: "First name of user's account" tests: - not_null - name: last_name description: "Last name of user's account" tests: - not_null - name: email description: "Account's email" tests: - not_null - name: city_name description: "city's name" tests: - not_null - name: state_name description: "state's name" tests: - not_null - name: id_channel description: "channel's Id" tests: - not_null - name: channel_name description: "channel's name" tests: - not_null - name: channel_creation description: "Date of creation name" tests: - not_null Agora, vamos criar um novo arquivo SQL e nomeá-lo como account_information.sql e adicionar os scripts abaixo: with source_channel as ( select * from {{ source('wetube', 'channel') }} ), source_city as ( select * from {{ source('wetube','city') }} ), source_state as ( select * from {{ source('wetube','state') }} ), source_user_address as ( select * from {{ source('wetube','user_address') }} ), source_account as ( select * from {{ source('wetube','account') }} ), account_info as ( select account.id_user as id_account, account.first_name, account.last_name, account.email, city.name as city_name, state.name as state_name, channel.id_channel, channel.name as channel, channel.creation_date as channel_creation FROM source_account account inner join source_channel channel on (channel.id_account = account.id_user) inner join source_user_address user_address using (id_user) inner join source_state state using (id_state) inner join source_city city using (id_city) ) select * from account_info Criando nosso último modelo Para o nosso último modelo, vamos criar um modelo sobre quantas curtidas tem um vídeo. Vamos alterar novamente o schema.yml para descrever e documentar nosso futuro e último modelo. - name: total_likes_by_video description: "Model containing total of likes by video" columns: - name: id_channel description: "Channel's Id" tests: - not_null - name: channel description: "Channel's name" tests: - not_null - name: id_video description: "Video's Id" tests: - not_null - name: title description: "Video's Title" tests: - not_null - name: total_likes description: "Total of likes" tests: - not_null Crie um arquivo chamado total_likes_by_video.sql e coloque o código abaixo: with source_video as ( select * from {{ source('wetube','video') }} ), source_video_like as ( select * from {{ source('wetube','video_like') }} ), source_account_info as ( select * from {{ ref('account_information') }} ), source_total_like_by_video as ( select source_account_info.id_channel, source_account_info.channel, source_video.id_video, source_video.title, count(*) as total_likes FROM source_video_like inner join source_video using (id_video) inner join source_account_info using (id_channel) GROUP BY source_account_info.id_channel, source_account_info.channel, source_video.id_video, source_video.title ORDER BY total_likes DESC ) select * from source_total_like_by_video Executando novamente Após a criação dos arquivos, vamos executar DBT novamente para criar os novos modelos dbt run Saída Os modelos foram criados no banco de dados e você pode executar instruções select diretamente em seu banco de dados para verificá-lo. Perceba que além dos modelos criados, você pode notar as demais tabelas que foram mapeadas no arquivo schema.yml e que já existiam na estrutura do banco inicial. Lembre-se do mecanismo de criar tabelas estáticas através do diretório Seeds, pode ser uma boa escolha para uma carga inicial. Modelo: account_information Modelo: number_of_subs_by_channel Modelo: total_likes_by_video Passo 6: DBT Docs Documentação Depois de gerados nossos modelos, agora vamos gerar documentos com base nestes. O DBT gera uma documentação completa sobre modelos (models), sources e suas colunas, através de uma página da web. Gerando as docs dbt docs generate Disponibilizando as docs no servidor Web Após a geração dos documentos, você pode executar o comando abaixo no seu terminal para iniciar um servidor da Web na porta 8080 e consultar a documentação localmente utilizando o seu navegador. Caso o navegador não abra automaticamente, digite o seguinte endereço localhost:8080 no seu navegador. dbt docs serve Lineage Outro detalhe sobre a documentação é que você pode ver através de um Lineage os modelos e suas dependências. Código no Github Você pode conferir esse código na nossa página do Github. Curtiu? Eu espero que tenha gostado!