AWS Lambda: o guia completo pra começar no mundo serverless
Aprenda o que é o AWS Lambda, como uma função serverless funciona por baixo dos panos, o que é cold start e como funciona o modelo de cobrança. Guia direto pra quem está começando no mundo serverless.
Se preferir consumir esse conteúdo em forma de vídeo, veja nosso canal do youtube:
O que é AWS Lambda?
De forma bem simples, AWS Lambda é um serviço que te permite subir seu código e a AWS executa ele quando for chamado. Você não precisa instanciar ou cuidar de servidores e nem pensar na escala já que quem cuida de tudo isso é a AWS!
Essa ideia de desenvolver sem se preocupar com servidores é a base do conceito de serverless. A nuvem cuida da infraestrutura e nós podemos focar no código.
Esse artigo faz parte de uma série onde cobriremos os fundamentos sobre compute e serverless. Vamo juntos!
Como funciona meu código na Lambda?
Quando subimos um código na Lambda, dizemos que estamos criando uma função Lambda. Essa é justamente a forma mais fácil de entender Lambda, como uma função. Ela deve ser chamada, recebe parâmetros, executa alguma lógica e devolve uma resposta.
A essência é essa, mas ela se traduz na prática com alguns termos específicos.
Handler
O handler é o ponto de entrada da sua função Lambda, ou seja, é por ele que a execução começa quando alguém chama a função. É dentro do handler que mora a sua lógica: processar o que veio na chamada, fazer cálculos, chamar outros serviços (como um banco de dados ou outra Lambda), e devolver uma resposta.
Em código, o handler é uma função que recebe alguns parâmetros padrão. Em JavaScript, por exemplo, fica mais ou menos assim:
1
2
3
4
5
6
7
export const handler = async (event, context) => {
// lógica de código
return {
statusCode: 200,
body: JSON.stringify('Olá mundo!'),
};
};Repare nos dois parâmetros: o
event traz a informação do evento que chamou a função, vamos entender mais sobre ele na sequência. Já o context contém informações gerais sobre a função, como nome, ID da execução e tempo até o timeout.Trigger
Diferente de um servidor que fica ligado o tempo todo esperando requisição, uma função Lambda só acorda quando é acionada por um evento externo, que chamamos de trigger (ou gatilho).
Existem vários tipos de triggers que podem acionar uma função Lambda. Alguns dos mais comuns são:
- Requisição HTTP vinda de uma chamada de API (geralmente pelo Amazon API Gateway)
- Upload de arquivo em um bucket do Amazon S3
- Mensagem chegando em uma fila (como Amazon SQS) ou em um stream (como Amazon Kinesis)
- De tempos em tempos agendado, como a cada hora, todo dia às 3 da manhã, etc. Pode ser configurado com Amazon EventBridge
- Evento de outro serviço da AWS, como uma escrita em uma tabela do Amazon DynamoDB
Quando o trigger aciona a função, ele manda junto o event, um objeto JSON com todas as informações daquele acontecimento. É esse objeto que o handler recebe no parâmetro
event que vimos ali em cima.O conteúdo do event muda dependendo do tipo de trigger. Por exemplo, um event de upload em um bucket S3 fica mais ou menos assim:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"Records": [
{
"eventName": "ObjectCreated:Put",
"s3": {
"bucket": {
"name": "meu-bucket-de-preciosidades"
},
"object": {
"key": "fotos/gatinho.jpg",
"size": 245678
}
}
}
]
}Olhando esse JSON, conseguimos entender que alguém subiu uma imagem de gatinho no bucket onde guarda preciosidades (totalmente coerente). A função Lambda agora poderia baixar o arquivo, processar e ser feliz.
Retomando a metáfora
Voltando na nossa comparação de Lambda como uma função de fato, podemos atualizar o último diagrama com os termos que acabamos de aprender.
- A chamada da função acontece quando um trigger gera um evento
- Os parâmetros que ela recebe são o conteúdo desse evento
- A lógica executada é o código que vive dentro do handler
- E a resposta é o que o handler retorna no final
Mas o que acontece por trás dos panos?
Mas esse negócio de não ter servidor está muito estranho né? É porque na verdade, existem servidores sim, a única questão é que você não precisa cuidar deles. Por baixo dos panos, existem máquinas sendo alocadas e ambiente de execução sendo preparado.
Para entender isso melhor, precisamos olhar para o ciclo de vida do ambiente de execução Lambda: init, invoke e shutdown.
Init
A fase de Init acontece quando a função é invocada e não existe ambiente preparado para executar. É comum ouvirmos falar que a Lambda "está fria".
Nessa fase, a AWS faz três coisas principais: escolhe uma máquina virtual pra rodar sua função, prepara o runtime da linguagem que você está usando (Node.js, Python, Java, etc) e baixa o seu código pra dentro desse ambiente.
Em seguida, executa qualquer instrução que esteja fora do handler, como imports, conexões com banco e variáveis globais. Tudo isso antes da sua lógica principal rodar.
Depois da primeira execução, o ambiente ainda fica disponível por um tempo, então próximos requests aproveitarão a mesma infraestrutura e a Lambda pulará essa fase de init.
Invoke
A fase de Invoke faz a execução da função propriamente dita. É o momento em que, com o ambiente todo preparado, a função do handler é chamada, assim como todas as outras funções e serviços da sequência.
Shutdown
Quando a Lambda passa algum tempo sem receber chamadas ou sofre alguma mudança de configurações, ela inicia o processo de Shutdown que desativa o ambiente de execução preparado na primeira fase.
A AWS não garante um tempo fixo em que o ambiente continua "quente", mas na prática o ambiente costuma ficar disponível por alguns minutos depois da última invocação. Quanto mais frequente as chamadas, maior a chance de manter o ambiente aquecido.
Quando o shutdown finalmente acontece, a AWS encerra o ambiente, libera os recursos e a máquina virtual. Da próxima vez que sua função for chamada, vai ser preciso começar tudo de novo, ou seja, passar pela fase de init mais uma vez.
Resumo geral das etapas
Resumido, a fase de Init prepara o ambiente, a de Invoke executa a lógica do código e a de Shutdown libera os recursos não utilizados.
Cold start, a consequência
Mas é claro que toda essa flexibilidade e agilidade tinha que vir com um preço, e esse é o cold start. Ele se refere ao tempo de resposta mais alto que as funções Lambda apresentam na primeira vez que são chamadas após um tempo de inatividade ou pico de requests.
Isso acontece pelo período de Init que vimos na última seção. A preparação do ambiente de execução e alocação de recursos iniciais geram esse aumento inicial de latência, ou tempo de resposta.
Mas como diria minha mãe, quanto custa essa brincadeira?
Agora entramos em um dos grandes benefícios do mundo serverless. Como não temos servidores reservados para nosso código a todo momento, pagamos apenas pelo que usamos.
Assim, o modelo de preço da Lambda segue a regra: quantidade de invocações + duração.
Indo um pouquinho mais a fundo, o cálculo da duração não é só o tempo bruto que sua função executa. Ele também leva em conta a quantidade de memória configurada pra ela. A unidade que a AWS usa pra essa cobrança é o GB-segundo, que é basicamente quanto tempo sua função rodou multiplicado por quanta memória ela tinha disponível. Quanto mais memória, mais cara cada invocação.
A boa notícia é que tem uma camada gratuita generosa: 1 milhão de invocações e 400 mil GB-segundos por mês, sem prazo de validade. Pra projetos pequenos e estudos, conseguimos fazer muita coisa gratuitamente!
Esse modelo combina muito bem com aplicações de tráfego variável ou imprevisível. Por outro lado, em sistemas de carga muito alta e constante, pode acabar saindo mais caro que um servidor dedicado. Vale fazer as contas pro seu caso específico, e o AWS Pricing Calculator é uma boa ferramenta pra essa comparação.
Próximos passos
Agora você já sabe o que é o AWS Lambda, como ele funciona por baixo dos panos, o que é cold start e como funciona o modelo de cobrança. Esses são os fundamentos que vão te acompanhar em qualquer aplicação serverless que você construir daqui pra frente.
Agora recomendo se aventurar e ver tudo isso na prática! Se ainda não tem uma conta na AWS, sugiro criar uma conta Free Tier e começar a brincar com a tranquilidade de que você não será cobrado. Eu também já escrevi um artigo guiando a criação da sua primeira função Lambda do zero, com direito a integração com S3 e tudo.
Além disso, se quiser entender mais sobre servidores, como funcionam e como devemos administrá-los, deixo ainda o último artigo onde exploramos os fundamentos de compute.
Nas próximas semanas, a gente vai continuar essa série de serverless explorando como a Lambda se encaixa em sistemas maiores. Me conta nos comentários: você já tinha mexido com Lambda antes? Que tipo de aplicação você gostaria de construir com ela?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article