Vamos falar de lambda functions?
O modelo de desenvolvimento “sem servidor” vem ganhando enorme espaço nos últimos tempos e as Functions as a Service (FaaS) estão no mainstream do rolê, portanto irei compartilhar um pouco do que pude conhecer sobre FaaS com base na cloud da AWS.
Antes de adentrar nas entranhas do código, é importante ressaltar que FaaS é apenas uma das opções da arquitetura Serverless, se não sabe ainda o que significa o conceito segue abaixo um brevíssimo resumo das palavras de Mike Roberts no artigo Serverless Architectures.
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform.
Dado o contexto podemos falar brevemente sobre os AWS Lambdas, que são funções que nos permite focar diretamente no desenvolvimento do negócio, descartando toda complexidade para provisionar e gerenciar servidores, ficando por conta da vendor cloud — AWS.
Os lambdas são cobrados pelo tempo de execução e quantidade de chamadas, podendo ser acionados automaticamente por serviços da AWS ou através de aplicações via HTTP — o período em que o serviço não é requisitado não é cobrado.
Como gerenciar seu código
Sistema baseado em funções é bem granular, com isso torna-se um tanto quanto doloroso gerenciar inúmeros deploys, reutilização de código e etc.
Talvez seja mais fácil utilizar alguma plataforma ou framework para obter uma melhor produtividade:
Ambiente local para desenvolvimento
Um item importantíssimo é como o desenvolvedor poderá simular localmente o mesmo cenário que será deployado, possibilitando realizar debug e testes do código — para demonstrar isso criaremos algumas funções mais a frente através do Serverless Framework, porém caso não esteja utilizando nenhum framework que facilite este processo é possível utilizar a ferramenta localstack.
Overengineering
Lambdas possui inúmeros pontos positivos, porém tome muito cuidado antes de inseri-los em sua stack de serviços, pois como tudo na vida existem trade-off.
Fragmentação
Existem várias formas de arquitetar uma aplicação FaaS, lembre-se sempre de como será entregue a esteira de CI/CD e o versionamento de código, pois dependendo do quão fragmentado fique a solução você ganhará milhares de repositórios, pipelines e configurações para gerenciar — e não receberá insalubridade no final do mês para lidar com YAML :)
Reutilização de código
Reutilizar módulos não é nada trivial, apesar de existir os Lambdas Layers, então dependendo da linguagem que irá escolher de runtime, realize uma análise de como será reutilizado os módulos e se existe a necessidade.
Limite de recursos
Alocação de memória: 128 MB a 3,008 MB, em incrementos de 64 MB.
Tempo-limite de processamento: 900 segundos (15 minutos)
Variáveis de ambiente: 4 KB
Lambda Layers: 5
Solicitações por segundo: 10x o limite de execuções simultâneas (forma síncrona, todas as origens) — 10x o limite de execuções simultâneas (forma assíncrona — origens que não são da AWS) — Ilimitado (forma assíncrona — origens de serviços da AWS)
Veja mais detalhes dos limites na docs.
Com esse breve contexto e sem mais delongas, podemos partir para a epopéia de desenvolvimento em lambdas, sendo assim irei dividir em vários posts para que o conteúdo fique melhor organizado.
