Altos e baixos da nossa primeira experiência com AWS Lambda

Escrito por Luiz Panariello

Apenas para contextualizá-los, na DT+Seekr, uma ou duas vezes por ano temos um evento chamado SedexDay, uma espécie de Hackaton, onde todos os colaboradores podem participar desenvolvendo projetos de um dia. Aparecem projetos de diversas áreas, desde culturais até novos produtos.

Em 2016 no SedexDay da primeira metade do ano, a minha escolha foi experimentar com um FaaS (Function as a Service). E esse artigo vai ser sobre os altos e baixos dessa minha escolha, além de deixar algumas dicas para quem quiser se arriscar nesse novo paradigma.

Já que toda nossa plataforma hoje reside na AWS, a escolha óbvia para um FaaS foi o Lambda. Para o que fazer, escolhi um integrador para uma de nossas ferramentas, criei o FacebookBot.

A API fazia sentido e muitos clientes requisitavam essa funcionalidade.

O que é um FaaS ou Serverless?

Dependendo de onde vem a fonte do Hype o nome difere, mas são o mesmo produto. Referenciando Mike Roberts no blog do Martin Fowler:

“Arquiteturas serverless referem-se a aplicações que significantemente dependem de serviços de terceiro (conhecidos como Backend as a Service ou “BaaS”) ou um código que roda em containers efêmeros (Function as a Service ou “FaaS”)…”

Portanto, a primeiro momento tudo parece mágica. Você escreve um código em um editor de texto no próprio admin da AWS, aperta salvar e “vua-la”, seu código já está rodando e aguardando instruções. E se você estiver no Free-tier da AWS você não vai pagar nada até ter milhões de requisições.

E como esse cara se comunica com a internet?

O UI (no caso o browser) se comunica com o Gateway API ( Serviço da AWS ) que pode ser configurado para invocar o Lambda, e por sua vez também faz o trabalho de Router, apontando para um Lambda certo dependendo do fragmento da URL que ele representa. Fora isso também é possível configurar throttling e limitar recursos através dele.

Quando o usuário cria um Lambda ele também precisa estipular a memória e o tempo de Timeout dessa aplicação e isso está vinculado diretamente ao custo desse recurso.

Custos($$$)?

Então… quanto maior o número de clientes usando maior seria o uso de recursos, logo inicialmente para desenvolvimento e testes este seria muito baixo, fora que, ele é calculado pelo (tempo de execução * memória alocada) * execuções. Quanto mais rápido ele rodar menos vamos pagar, por isso é importante estipular corretamente os recursos disponíveis para função.

Como foi a implementação?

Um desenho simples do que foi entregue:

No caso o Facebook Message API se comunica com o integrador que contém regras de negócios necessárias para se comunicar com o DTBot. Manter a sessão e fatores de infraestrutura me forçaram a criar um Lambda dentro da VPC para fazer a comunicação com o nosso cluster de Redis. Então o Integrador também se comunica com o Lambda interface do Redis através de um API Gateway isolado.

A solução parecia bastante sólida porém ao longo do desenvolvimento conseguimos pegar alguns problemas, que mais pra frente, poderiam acarretar problemas para desenvolver a fundo a aplicação. Como por exemplo testar em uma máquina local do desenvolvedor, identificar erros e realizar o deploy com as dependências.

Para facilitar o desenvolvimento usamos um framework chamado Serverless.

No que esse Framework pode me ajudar?

O framework possibilita testar, fazer deploy e criar plugins para o lambda da sua própria máquina. O Serverless Framework tem um sistema de scaffolding de aplicação que gera CloudFormations para sua aplicação dependendo das suas escolhas, podendo escolher o Stage que você quer usar a ferramenta e configurar algumas variáveis de ambiente desse Stage.

Fora que o Framework te deixa livre para implementar o tipo de arquitetura que você quiser para a sua aplicação. Poderíamos tanto utilizar Nano serviços, que vem ganhando espaço com FaaS, ou micro serviços, que já é uma arquitetura mais conhecida no nosso mercado e é amplamente implementada. Para quem não sabe a diferença: micro serviços tem dentro de si todo um domínio e tratam de uma entidade, no caso de Usuários, o micro serviço seria responsável por todas as ações dessa entidade. Nano serviços por sua vez divide essa responsabilidade em diversos endpoints, uma para cada ação da entidade.

Exemplo de nano serviços

Como se tratava de um POC optamos por utilizar Micro serviços dado que a gente tinha que ter algo em até 1 dia de trabalho.

Problemas

Um ponto que nos atentamos logo de cara foi de como fazer a verificação de erros. Nosso Lambda foi escrito em Node.js e o Lambda nos permite cuspir logs no CloudTrail utilizando o um simples “console.log”, então criamos um sistema de logs simples que criava um log para cada requisição, que por sua vez ia parar no CloudTrail com os dados da execução e resultado da mesma.

Enviar o Lambda dinamicamente e executar ele de diferentes máquinas, inicialmente, também foi um problema. O Serverless Framework resolve isso de uma forma bem legal. O Lambda, assim como qualquer recurso na AWS, necessita de Policy e Roles para ter acesso a recursos já provisionados. Então usamos o CloudFormation para adicionar os Roles para o Lambda que estava sendo criado.

Outro problema que enfrentamos foi que um Lambda, por ser um contêiner efêmero, tem um tempo de “subida” que no nosso caso atrapalha porque o primeiro request a função acaba ou demorando muito mais que o timeout especificado ou retornando um erro.

Para tratar esse tipo de problema utilizamos o Pingdom para manter o serviço sempre de pé (iuck)

Comentário do autor: Se alguém tem uma solução mais bonita e quiser compartilhar com a gente, por favor!

O Serverless nos deu a oportunidade de subir toda aplicação usando apenas a Chave pública e privada de um usuário, permitindo pular toda a etapa de deploy, o que já foi um ganho de velocidade algo para o desenvolvimento.

Concluindo… e algumas novidades

Hoje temos clientes utilizando a ferramenta e passou a ser comum pensar em utilidades para pequenas para o Lambda.

O Lambda passou a integrar nossas ferramentas como uma articulação bastante eficaz. Hoje a própria AWS disponibiliza mais recursos do que quando experimentamos o Lambda a primeira vez, agora já existe até um framework oficial da AWS chamado chalice. Passou a aceitar C# que é a linguagem mais comum entre os programadores da Direct Talk e a documentação se tornou mais completa. Agora é possível usar Node Edge, que no caso executa seu código nas Edge Zones de antemão e não apenas na região escolhida.

Se você, leitor, chegou até aqui, espero que tenha elucidar algumas dúvidas e te ajudado a sair de cima do muro com essa tecnologia.

Se tiver algo a adicionar ou alguma dúvida, comente!