AWS Lambda: escreva código sem se preocupar com infra

Serverless na AWS - Apresentação

Boas-vindas à Alura. Eu sou Vinícius Dias e vou guiar vocês nesse curso onde conheceremos um pouco sobre AWS Lambda.

Autodescrição: Vinicius Dias é uma pessoa de pele clara, olhos escuros e cabelos pretos. Usa bigode e cavanhaque, e tem cabelo curto. Veste camiseta preta e está sentado em uma cadeira preta. Ao fundo, há uma parede lisa com iluminação lilás.

Antes de falar sobre AWS Lambda, entenderemos para que ele serve. Para isso, conheceremos o conceito de Serverless. Já te adiantando, Serverless não significa que seu código irá rodar magicamente sem servidor, mas é uma ideia bastante interessante para delegarmos a ideia de infraestrutura para serviços como o AWS Lambda.

Tendo entendido o conceito de Serverless, começaremos a criar funções lambda. A partir disso criaremos nosso primeiro código, um "hello, world". Depois avançaremos em formas de execução:

• Execução agendada;
• Execução a partir de outro serviço da AWS
• Entre outras;

Também aprenderemos a monitorar funções lambda, aprendendo um pouco sobre métricas e indo para logs também que nossas funções podem gerar. Após entendermos essa parte, iremos configurar nossas funções lambda para termos, por exemplo, limite de memória e limite de tempo de execução.

A partir desse ponto, podemos publicar nosso código, então aprenderemos a fazer upload de códigos para AWS, inclusive utilizando o GitHub Actions. Essa é uma prática bem próxima do mercado, ou seja, mais profissional.

Além disso, aprenderemos a configurar variáveis de ambiente para termos algumas configurações que podem ser diferentes no ambiente local e de produção. Falando nisso, também conversaremos sobre modos de execução de código.

Entenderemos como executar localmente e falar que o ecossistema de cada linguagem pode ter ferramentas específicas. Também descobriremos como executar códigos na AWS Lambda com uma linguagem que não é "nativamente suportada", entre aspas.

Por final, ao fazermos o upload de um arquivo no bucket S3, uma função será executada e veremos um log no CloudWatch, verificando se o tamanho desse arquivo está bom ou muito grande. Então temos bastante coisa para aprender neste curso. Espero que vocês tirem bastante proveito.

Se ficarem com alguma dúvida no meio do caminho, não se esqueçam que temos um servidor no Discord onde vocês podem conversar com outras pessoas que também estão estudando. Elas podem ter a mesma dúvida que você ou a resposta para suas dúvidas.

No próximo vídeo, começaremos a conversar sobre Serverless.

Até lá!

Serverless na AWS - Conceito de serverless

Entendendo a utilidade do Serverless

Antes de falarmos sobre o assunto foco desse curso, vamos conversar sobre quando ele seria necessário e para que o utilizaríamos. Imaginem um cenário onde temos o código de uma função que será executada quando recebermos o upload de uma imagem no Bucket S3.

Observação: Caso queiram aprender mais sobre S3, podem acessar o curso Amazon S3: manipule e armazene objetos na nuvem.

Essa função realizará algum processamento na imagem, como redimensioná-la para deixar todas as imagens com tamanhos padronizados ou deixá-la em preto e branco para ocupar menos espaço. Esse processamento é muito pontual e específico.

Imaginem que vamos colocamos esse código no ar e precisaremos criar uma infraestrutura para executar essa função. Precisaríamos subir um servidor, como uma máquina no EC2, ter um Linux instalado com a linguagem de programação usada, além de bibliotecas externas, para só então fazer o deploy do código nessa máquina.

Além de prover toda essa infraestrutura, que é o trabalho inicial, precisamos monitorá-la. Por exemplo, se começarmos a receber muitas requisições, precisaremos configurar o auto scaling, ou escalar manualmente. Também Precisamos saber quanto de CPU iremos adicionar, ou seja, precisamos nos preocupar com detalhes de infraestrutura.

Novamente, é um trabalho pontual, ou seja, apenas uma função que queremos executar. Queremos virar para a AWS ou qualquer outro provedor de serviços e dizer "Eu tenho uma função e quando eu receber um arquivo em algum *bucket do S3, executa essa função para mim*".

Essa ideia de delegar a responsabilidade de qualquer gerência de infraestrutura que está por trás do conceito de Serverless. "Server" significa "Servidor" e "less" significa "sem", portanto, "serverless" significa "sem servidor".

O real significado de Serverless

Esse "sem servidor" não significa que executaremos nosso código na AWS sem servidores. A ideia de "sem servidor" é para que nós, pessoas que estamos criando o código que será executado, não precisemos nos preocupar com a infraestrutura.

Quem está realmente desenvolvendo e contratando o serviço, não precisa se preocupar com a infraestrutura, porque estará delegando a responsabilidade de qualquer gestão de infraestrutura para esse serviço que iremos contratar. Portanto o real significado de Serverless é delegar o gerenciamento de infraestrutura.

Dessa forma, escrevemos o código e informamos que quando uma ação acontecer, queremos que uma função seja executada. O sistema que irá decidir em qual máquina isso vai acontecer, ou em quantas máquinas isso acontecerá, e a forma que ele executará. Nós apenas delegamos a responsabilidade, pedindo que ele execute nosso código.

Em cenários pontuais como o do exemplo, o Serverless é fantástico, porque não precisamos gerenciar toda uma infraestrutura, o que traria a complexidade da gestão e custos, por exemplo:

• Custo de ter uma máquina ativa o tempo todo enquanto só recebemos pedidos para executar essa função ocasionalmente;
• Custo de pessoal para monitorar essa infraestrutura, ou seja, direcionar recursos da empresa para uma equipe de operações monitorar essa parte também, ao invés de atividades que realmente precisam de monitoramento;

Resumindo, ao criar um servidor para essa atividade, teremos custos de infraestrutura, enquanto a abordagem Serverless delega a responsabilidade de infraestrutura para o provedor que fornece o serviço, nesse caso, a AWS.

Surgimento do Serverless

Cabe dizer que a AWS não inventou o conceito de Serverless, que já é falado a bastante tempo. Desde então temos evoluído para termo um modelo de arquitetura Serverless.

Começamos com a infraestrutura como serviço, que é algo que a AWS já fornece há muito tempo, como o EC2, por exemplo. A Amazon fornece um modo de conseguirmos provisionar nossa estrutura sem precisarmos comprar um servidor. Alugamos máquinas, gerenciamos a rede com VPC, tudo isso é estrutura como serviço.

Depois temos o conceito de plataforma como serviço. Aqui na Alura já temos cursos sobre esse assunto, mas vou dar como exemplo o Office, que nos fornece um software online. Então temos uma plataforma para ser executada. Eu, por exemplo, trabalho em uma plataforma como serviço no sistema de marketing.

Agora temos tudo isso abstraído com o conceito de Serverless. Fornecemos o código e não cabe a nós nos preocupar com a forma que ele é executado. Ou seja, não decidimos a quantidade de máquinas em que será executado, nem qual o processador vai executar. Também nos precisamos decidir se a rede estará conectada a uma rede específica.

A única coisa que faremos é solicitar que, quando um determinado evento acontecer, aquela função deve ser executada. Isso vai de encontro com a cultura de DevOps, onde temos a cultura de desenvolvimento (dev) e operações (ops) se unindo.

Nesse ponto, uma pessoa desenvolvedora que não faz parte da equipe de operações e infraestrutura consegue facilmente provisionar uma função lambda no seu trabalho. Um dos sistemas que trabalho fazendo a manutenção e criando funcionalidades está rodando em funções lambda.

Com isso eu não preciso requisitar uma equipe de operações para fazer o deploy e, talvez, criar uma nova função lambda se eu precisar. Tudo isso é bastante simples, permitindo que uma equipe especializada em operações foque nas operações necessárias e a equipe de desenvolvimento foque em escrever código.

Eu, como desenvolvedor, não preciso ficar pedindo o tempo todo para equipe de operações fazer alguma coisa, perguntando se uma ou outra coisa é possível. Da mesma forma, a equipe de operações não precisa parar o trabalho dela para provisionar uma nova função para mim ou algo do tipo.

Assim conseguimos ter a junção das equipes com cada uma focando no que precisa. Isso vai de encontro com a cultura DevOps. Inclusive, aqui na Alura temos vários cursos sobre DevOps que valem a pena serem conferidos.

Explicações sobre lambda

Tendo falado tanto sobre Serverless, o que é lambda?.

Como o site da AWS diz, lambda é uma forma de executarmos código sem nos preocuparmos com os servidores ou clusters. Com isso, não sabemos se tem vários servidores alias executando minha função ou se é apenas um. Também não sabemos onde ele está na nossa rede e não precisamos saber.

Informamos apenas o código e pedimos para ele ser executado, e é isso que a AWS fará para nós. Entretanto, como qualquer serviço da AWS, isso terá custos, ou seja, precisamos pagar por isso.

Uma das vantagens de subir uma função lambda é que, se tivermos um código pontual, que é executado poucas vezes, não seremos cobrados pela infraestrutura que fica executando, mesmo que não tenha nenhuma requisição chegando. No lambda, você é cobrado pelo número de execuções da sua função. Dessa forma, se subimos a função e ela nunca for executada, não haverá custos.

Custo da AWS Lambda

Ao acessar a seção "Preço" da AWS Lambda (ou seção "Pricing, se tiver em inglês), temos a explicação "Você é cobrado com base no número de solicitações para suas funções e a duração necessária para execução do código". Faz todo sentido que sejam esses dois pontos.

Pensem assim, recebemos apenas uma chamada para executar uma função, mas ela leva três dias para ser executada, logo, esse tempo será cobrado. Retomando, essa cobrança acontece tanto pelo número de execuções da nossa função, quanto pelo tempo que ela fica rodando.

Como praticamente todos os cursos de AWS que fizemos até o momento, com o lambda não é diferente o fato de termo um free tier, ou seja, uma parte gratuita. Ainda na seção de preço, ao descermos mais nas explicações, encontramos informações sobre o nível gratuito do AWS Lambda.

Esse nível inclui um milhão de solicitações gratuitas por mês, o que é mais que suficiente para o nosso curso, porque nem chegaremos perto de um milhão de execuções da nossa função. Além disso, conta com 400.000 GB-segundos de tempo de computação.

Aprenderemos o que esse tempo de computação quer dizer ao longo do curso, mas para dar um spoiler, quando executamos o código, podemos informar o máximo de memória que ele irá ocupar. É importante que nós, pessoas desenvolvedoras, saibamos como colocar em memória um arquivo de 3GB, por exemplo.

É nosso papel como devs, e não da equipe operações, saber quanta memória nosso código irá consumir. Então se nossa função utiliza 1GB, teremos 400.000 segundos para executar. Já se nossa função utiliza meio gigabyte, ou seja, 512MB, teremos 800.000 segundos de tempo de execução.

Por via de regra, uma execução de função leva menos de um segundo para executar. Além disso, utilizaremos menos que 1GB, então teremos muito mais do que esses 400.000 segundos para executar no nosso free tier.

Basicamente, o nível gratuito é mais do que o suficiente para esse curso, mas em um cenário real, como sempre é recomendado, confiram a calculadora de preços. Analise como será sua execução, descubra quanta memória sua função gasta e assim saberão como levantar proposta, levar para equipe financeira e tudo mais o que já falamos em outros cursos da AWS.

Agora focaremos no que importa., que é a AWS Lambda. No próximo vídeo descobriremos como podemos criar uma função para ser executada na AWS Lambda.

Serverless na AWS - Conhecendo o AWS Lambda

Boas-vindas novamente!

Estou logado no meu console da AWS. Caso já tenham uma conta, façam o login e, se não tiverem, criem uma conta. É bem fácil. Fazendo esse procedimento vocês se deparam com a página inicial do console. Eu já tenho alguns serviços em "Visitado recentemente", até de cursos anteriores, mas no cenário de vocês, essa parte pode estar vazia.

Sendo assim, na barra de pesquisa superior da página, que podemos abrir clicando ou pressionando "Alt + S", pesquisaremos por "Lambda". Com isso, nos resultados temos a seção "Services" cujo primeiro item é o cartão do "Lambda".

Nesse cartão temos o símbolo do lambda, que parece um "Y" de cabeça para baixo, no canto superior esquerdo. Ao lado do símbolo temos o nome, e abaixo do nome temos a frase "Rum conde without thinking about servers" ("Execute o código sem se preocupar com os servidores"). É o que queremos, então clicaremos nele para acessarmos esse serviço.

Fazendo isso, a página muda e somos direcionados para o "AWS Lambda". Com ele, não criamos servidores ou instâncias, apenas funções. Portanto, a AWS Lambda lida com funções.

Isso não significa que todo nosso código precisa estar em uma única função enorme. O que precisamos fazer é uma função para o AWS Lambda executar e, dentro dela, podemos chamar outras funções do código.

Clicando no ícone com três linhas no canto superior esquerdo da tela, abaixo da logo do AWS, abrimos um menu lateral. Nele temos uma seção chamada "Recursos adicionais". Passaremos por alguns deles, mas o foco será as funções. Nesse caso, começaremos criando uma função.

Para isso, clicamos no botão "Criar função", que está na parte inferior esquerda do retângulo branco "Comece a usar". Com o menu lateral fechado, o "Comece a usar" fica à direita do título "AWS Lambda", enquanto, com o menu aberto, ele fica abaixo da explicação do que é o "AWS Lambda". Ao clicarmos em "Criar função", a página atualiza e abre o formulário "Criar função".

Criando funções

Podemos criar uma função do zero, selecionando a opção "Criar do zero". Em um cenário real, é o que faremos, mas existem outras opções. Por exemplo, podemos escolher a opção "Usar um esquema", onde esse esquema já traz um código pré-escrito para visualizarmos a execução por algum motivo.

Selecionando essa opção, que é a segunda da esquerda para direita e descendo o formulário para seção "Informações básicas", encontramos o campo "Nome do esquema", onde temos como exemplo de esquema o "Hello world function" (Função olá mundo). Clicando na seta que fica no canto direito desse campo, encontramos outros exemplos de esquema, como:

• Criação de um micro serviço (Create a microservice that interacts with a DDB table);
• Criação de um backend para um sistema móvel (Create a mobile backend that interacts with a DDB table);
• Pegar um objeto da S3 (Get S3 object);
• Fazer uma requisição em HTTPS (Make an HTTPS request)
• Entre outros.

Reparem que temos vários exemplos de esquema de código e talvez algum deles já possa ser o seu caso. Porém, no nosso caso, criaremos nossa função do zero, para fazer as coisas de forma mais manual. Sendo assim, voltaremos para o começo do formulário e selecionaremos a primeira opção abaixo do título, que é "Criar do zero".

Depois que fizerem a função junto comigo, façam testes! Usem um esquema ou com o "Imagem de contêiner", que é a terceira opção da esquerda para direita de criação de função. Analisem o formulário dessa opção e descubram o que vocês têm. Ainda assim, neste curso seguiremos com a opção "Criar do zero" para construir a função de forma manual.

Preenchendo o formulário

Agora vamos analisar a seção "Informações básicas", onde o primeiro campo é o "Nome da função". Precisamos nomear esse recurso que estamos criando dentro do AWS Lambda. Chamaremos de "primeiraFuncao" (primeiraFunção sem os sinais gráficos).

O campo seguinte é o "Tempo de execução", mas essa não é uma boa tradução. Esse termo veio do inglês "Run time", que é o que executará nossa função. Temos algumas run times padrões e existem run times que podemos criar. Para focarmos em algo mais simples, utilizaremos uma run time padrão. Entre as opções, temos:

• .NET 6 (C#/PowerShell)
• .NET Core 3.1 (C#/PowerShell)
• Go 1.x
• Java 11(Corretto)
• Node.js 18.x
• Python 3.9
• Ruby 2.7

Ainda tem algumas outras opções, que não são mais recentes. Por exemplo, o mais recente foi o Java 11, mas é possível executar o Java 8. Outro exemplo é o Node.js, cuja versão mais recente é a 18, mas é possível executar no Node.js 12, 14 ou 16. Então existem essas outras versões.

Caso queiramos, também podemos criar uma Run time com nossa linguagem de programação, nosso script em shell ou o que quisermos. No nosso caso, nos manteremos no simples. Vocês que já são devs podem escolher a linguagem que mais têm familiaridade.

Eu, Vinícius, sou desenvolvedor PHP, então eu escolheria uma Run time personalizada para eu criar e instalar o PHP. Contudo, como eu sei algumas dessas linguagens, vou selecionar o "Node.js 18.x", para executarmos um JavaScript.

Mesmo não sendo a minha especialidade, é uma linguagem na qual consigo escrever alguns códigos, então vamos conseguir criar a função. Porém, novamente, se já souberem uma linguagem, escolham o Run time, que acharem melhor.

Por exemplo, se souberem C#, podem escolher qualquer um dos ".NET" sem se preocupar. Também podem escolher o Go, o Python ou qualquer uma que foram listadas. Eu vou seguir com o Node.js porque tenho mais familiaridade.

Em seguida temos o campo "Arquitetura", que define a arquitetura do computador. Isso é o mais perto que chegaremos de infraestrutura. Podemos escolher entre um "x86_64", que normalmente é o padrão de computadores, ou um "arm64", que são outras arquiteturas muito comumente usada em celulares também.

Deixaremos marcada a opção "x86_64", que é a arquitetura mais comum de processadores, mas se tiverem que tomar essa decisão em algum momento, já saberão o que estão fazendo. Não sabendo do que se trata, podem deixar o "x86_64", que já vem selecionado por padrão, porque ele é o mais comum.

Em seguida temos a subseção de "Permissões", onde poderíamos alterar as permissões, escolhendo quais papéis nossa função lambda terá. Para isso, podemos estender a lista de "Alterar a função de execução padrão", que está logo depois da explicação dessa subseção.

Se não alterarmos nada, o IAM (Identity and Access Management ou "Gerenciamento de Identidade e Acesso), que é o serviço de gerenciamento de permissões da AWS, vai criar uma nova função, ou roll, no inglês, com permissões padrão que uma lambda precisa.

Se você precisar acessar outros serviços da AWS, como o S3 ou o RDS, você pode criar sua própria roll. Nesse ponto, é importante que vocês tenham alguma familiaridade com a parte de segurança da AWS, mas isso já foge do tema deste curso, que é lambda.

Reparem que, até o momento, deixamos todas as configurações padrões. Eu estou apenas explicando para vocês, porque são pouquíssimas opções. A ideia é justamente nos preocuparmos apenas com o código.

Em seguida, temos as opções de "Configurações avançadas". Nela temos quatro caixas de seleção:

• Habilitar assinatura de código;
• Habilitar URL da função;
• Habilitar etiquetas;
• Habilitar VPC;

Se habilitarmos a assinatura de código, garantimos que foi de uma origem aprovada. Se habilitamos uma URL da função, podemos disponibilizar a função como URL. Podemos também adicionar as tags (etiquetas) e habilitar o VPC. Não iremos habilitar nada disso, porque não usaremos nenhuma dessas opções no nosso cenário.

Então, dentre todas as opções, só definimos o nome da função e escolhemos o Run time. Feito isso, podemos clicar no botão laranja "Criar Função" no canto inferior direito do formulário. Portanto nós, pessoas desenvolvedoras, podemos apenas nomear a função que iremos criar e em alguns segundos já estamos aptos para criar uma função.

Esse processo pode de criação pode demorar um pouco, então vocês podem fazer uma pausa para pegar uma água ou um café. Eu vou pausar o vídeo e voltar quando essa função estiver sendo executada.

Tela de carregamento com ruídos de circuitos

Analisando a primeiraFuncao

Assim que o processo termina, somos direcionados para outra página, onde já temos a "primeiraFuncao". Reparem que abaixo desse título temos o painel "Visão geral da função".

No centro desse painel, tem o ícone do lambda ao lado do nome primeiraFuncao e, abaixo, a informação "Layers (0)", ou seja, não temos nenhuma camada. Futuramente podemos falar mais sobre essas camadas, que são um assunto mais complexo, mas vamos entender basicamente o que informamos com essas camadas.

Imaginem que queremos criar uma run time personalizada. Para isso podemos criar uma imagem Linux da Amazon, que é uma camada, e podemos criar um executável do PHP, por exemplo, então adicionamos mais uma camada. Também podemos querer algumas bibliotecas disponíveis, o que adicionaria outra camada. Então camadas são muito comuns quando criamos uma run time personalizada. No nosso caso, não precisaremos disso.

Rolando a página para baixo, temos o código dessa função dentro de um editor de códigos. Então vamos analisar esse código para entendermos o que ele tem.

export const handler = async(event) => {
    //TODO implements
    cons response = {
        statusCode: 200,
        body: JSON, stringfy('Hello from Lambda!'),
    );
    return response;
};

Na primeira linha temos uma função sendo exportada, o que é perfeito, já que estamos trabalhando com uma função lambda, então faz todo sentido ter uma função. Essa função está dentro do arquivo index.mjs, como observamos na lateral esquerda do código.

Podemos conversar sobre porque tem um "m" antes de "js", mas basicamente é arquivo um JavaScript que roda dentro do Node.js como qualquer outro. Caso não conheçam o Node.Js, podemos conversar sobre esse .mjs, mas basicamente é um módulo que estamos exportando.

Exportando essa função chamada handler(), o serviço de AWS Lambda sabe o que precisa executar. Então, quando acontecer o evento que iremos configurar, essa função será chamada.

Para essa função, o serviço AWS Lambda passou o parâmetro (event), ou seja, "(evento)". Nesse evento teremos os detalhes do pedido de execução. Por exemplo, imaginem que estamos configurando para quando um upload acontecer no S3, executaremos essa função. A partir do evento sabemos qual objeto foi criado lá.

Dessa forma, o evento contém as informações que precisamos para executar a função, manipulando os dados que precisamos. Dentro dessa função, o que precisamos fazer é retornar uma resposta contendo um statusCode e um body (corpo). Poderíamos retornar algo diferente, mas a sugestão foi retornarmos com essa estrutura.

O statusCode são o equivalente ao status HTTP, então é interessante seguirmos a mesma convenção. Por exemplo, se estamos tentando executar uma ação em um objeto do S3 que não existe mais, retornaríamos um statusCode: 404. Como body manteremos a frase "Hello from Lambda!" (Olá do Lambda).

Reparem que não precisamos fazer nada e temos nossa função criada. Temos várias formas de executar essa função e, justamente por isso, a execução de uma função lambda ficará para próxima aula.

Basicamente, descendo a tela da primeiraFuncao encontramos o editor de código, onde podemos criar vários arquivos e fazer todo nosso código nele, se quisermos. Além disso, na parte superior da página, temos um gráfico com um diagrama dentro do painel "Visão geral da função" mostrando as camadas da nossa função. Nesse caso, não precisamos de nenhuma.

Tendo criado nossa primeira função, na próxima aula aprenderemos tranquilamente como executar funções lambda de diversas formas.

Sobre o curso AWS Lambda: escreva código sem se preocupar com infra

O curso AWS Lambda: escreva código sem se preocupar com infra possui 134 minutos de vídeos, em um total de 39 atividades. Gostou? Conheça nossos outros cursos de AWS em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Serverless na AWS
• Executando sua função
• Monitorando a função
• Códigos na AWS Lambda
• Estendendo a execução