Nesta postagem MUITO opinativa, compartilharei minhas ideias sobre as extensões do AWS Lambda, as boas e as ruins, e quando você deve ou não usá-las.
Índice
Introdução às extensões Lambda
Extensões Lambda são um mecanismo interessante. A AWS recomenda usá-las para aprimorar suas funções com recursos de caixa preta desenvolvidos pela AWS ou provedores externos.
use extensões Lambda para integrar funções com suas ferramentas preferidas de monitoramento, observabilidade, segurança e governança - AWS
Você pode pensar neles como caixas pretas que você pode anexar ao seu Lambda, que funciona como uma camada Lambda e aproveita novos recursos.
Aqui está uma lista de usos clássicos que vêm à mente:
Busque configuração, segredos e parâmetros e armazene-os no cache. Busque-os automaticamente uma vez a cada vários minutos. Pense em buscar segredos do Secrets Manager ou Parameter Store.
Envie logs, rastreamentos e métricas para um provedor de observabilidade externo, como Lumigo, DataDog e outros.
Monitore a CPU, a memória, o uso do disco e outros parâmetros interessantes da máquina da função Lambda e envie-os para um sistema de monitoramento, como a extensão Lambda Insights .
Você pode encontrar mais casos de uso de extensão neste repositório . Alguns são apoiados pela AWS e outros são de terceiros.
Para usar uma extensão Lambda, você só precisa anexá-la como uma camada Lambda. Confira meu post para aprender sobre camadas Lambda e quando usá-las. Eu as acho particularmente úteis para otimização de implantação.
O caso das extensões Lambda
No papel, as extensões parecem um mecanismo fantástico: você adiciona uma camada Lambda e algumas variáveis de ambiente e pronto, agora você está integrado a um provedor terceirizado de observabilidade e obtém uma nova funcionalidade que não desenvolveu.
E fica ainda melhor: os desenvolvedores de extensões podem desenvolver extensões em Rust, uma linguagem compilada que oferece desempenho extremamente rápido, um pequeno impacto na inicialização a frio, é independente do ambiente e pode ser executada em funções Lambda que usam um tempo de execução diferente.
A vantagem de um executável é que ele é compilado para código nativo e está pronto para ser executado. A extensão é agnóstica de ambiente, então pode ser executada junto com uma função Lambda escrita em outro tempo de execução. - Otimizando extensões AWS Lambda em C# e Rust
No entanto, as extensões Lambda geralmente têm um custo que supera essas vantagens.
Vamos rever meus motivos e os casos de uso para os quais atualmente utilizo extensões.
O caso contra extensões Lambda
Extensões Lambda são uma ferramenta poderosa que herda a maioria dos seus problemas do mecanismo em que é construída - camadas Lambda . Vamos rever os casos contra extensões Lambda.
Podemos dividir os casos em várias categorias:
Segurança
Experiência do desenvolvedor
Desempenho e custo
Segurança
As extensões são semelhantes a qualquer biblioteca SDK de código aberto. No entanto, há uma diferença adicional.
As extensões podem expor você a um risco de segurança, pois você nunca tem certeza do que está incluído na camada (alguns provedores de extensão documentam e fazem um bom trabalho, mas muitos não).
Além disso, de acordo com a documentação da AWS:
As extensões têm acesso aos mesmos recursos que as funções. Porque as extensões são executadas dentro do mesmo ambiente que a função - Documentação da AWS
Se você usar uma versão comprometida de uma extensão (pense em hackers obtendo acesso e publicando sua versão da camada na conta oficial da AWS do publicador da camada), eles podem acessar qualquer recurso que sua função tenha em seu processo de execução de caixa preta. Até agora, isso é bem parecido com um SDK de código aberto comprometido.
Mas há uma reviravolta na trama.
Os pipelines de CI/CD seguros incluem um scanner de vulnerabilidades, como o Synk , que verifica seus arquivos de dependências do Python ( poetry.to ml), verifica se há alguma versão comprometida e falha seu pipeline antes que uma versão comprometida seja implantada na produção.
Esse não é o caso com camadas e extensões do Lambda. O código delas é adicionado ao Lambda durante a invocação, onde ferramentas como o Amazon Inspector podem escanear as camadas, o código e as dependências do Lambda e encontrar código comprometido.
No entanto, isso é tarde demais. Sua extensão comprometida já está em produção.
Então, há um risco de segurança adicional.
Experiência do desenvolvedor
Configurar um ambiente de desenvolvedor local com extensões é difícil. Você precisa descobrir quais dependências externas a camada da extensão traz e instalá-las localmente para testar seu código e depurar no IDE. Isso pode ser desafiador, especialmente em casos onde há conflitos de versão. Uma discrepância entre o desenvolvedor local e os ambientes de função do Lambda pode levar a travamentos e bugs que só acontecem na produção e não em ambientes locais.
Além disso, algumas extensões do Lambda exigem que o código da sua função Lambda interaja com ela (provavelmente por meio de chamadas de rede localhost ), tornando quase impossível testar seu código no IDE. Se você não tem ideia do que estou falando, confira minha sessão AWS re:invent 2023 e minha série de testes do Lambda , onde mostro como você pode testar suas funções localmente. As extensões quebram essa experiência.
Outra experiência crítica do desenvolvedor está relacionada à manutenção e atualizações.
As extensões Lambda são habilitadas por meio de camadas Lambda.
As camadas lambda têm problemas inerentes:
Versionamento — Camadas são versionadas, e sua função sempre consome uma versão específica que muda entre regiões, tornando sua vida ainda mais complicada (em uma região, é a versão 55, em outra, 43). A versão é parte do ARN da camada.
Atualizações — Você precisa estar ciente de uma nova versão (de alguma forma) e alterá-la manualmente para a versão mais recente. Camadas Lambda não têm um gerenciador de pacotes como Python e outras linguagens, então atualizações se tornam um esforço manual.
O tamanho total descompactado da função e de todas as camadas não pode exceder a cota de tamanho de pacote de implantação descompactado de 250 MB. Sua extensão tira um pedaço dessa cota.
Desempenho e Custo
Não há refeições gratuitas. As extensões compartilham recursos de função, como CPU, memória e armazenamento, e você pode ver uma duração maior da função cobrada.
Além disso, cada extensão deve concluir sua inicialização antes que o Lambda invoque a função. Portanto, uma extensão que consome um tempo de inicialização significativo pode aumentar a duração da inicialização a frio da função. Pode valer a pena para você, mas é um fato do qual você precisa estar ciente.
Quando usar extensões Lambda
Vamos cobrir vários casos de uso para ver se eles se encaixam nas extensões Lambda ou não.
Buscar configuração
Recentemente, li um blog provando que uma extensão pode buscar a configuração mais rápido do que a função Node Lambda que a usa. Provavelmente porque a extensão é escrita em Rust, que é mais rápido do que o Node. No entanto, uma vez que o segredo é buscado, ele é armazenado em um cache por vários minutos. O Powertools for AWS , uma incrível biblioteca de código aberto, fornece os mesmos recursos sem uma extensão. Uma extensão economiza algumas dezenas de milissegundos na primeira chamada (e para a primeira chamada toda vez que o cache expira), mas é tudo a mesma coisa quando o cache não está vazio. A menos que você busque um volume ridiculamente alto de segredos na função, provavelmente não vale a pena adicionar a complexidade e os problemas mencionados acima para economizar uma dúzia de milissegundos a cada poucos minutos.
TL;DR — não use uma extensão.
Enviar logs para um provedor de observabilidade de terceiros
Este é um dos casos de uso mais comuns para usar a extensão Lambda. Ela funciona, e funciona bem, e você provavelmente não precisa que seu código interaja com ela diretamente no IDE. Parece adequado para a maioria das empresas.
No entanto, vindo de uma empresa de segurança, escolhemos uma rota diferente. Escrevi uma postagem de blog sobre por que é melhor usar um serviço centralizado para enviar todos os logs da sua conta AWS para um provedor de observabilidade de terceiros em vez de ter todas as funções do Lambda enviando-os individualmente. É simples quando você tem poucos serviços, mas fica doloroso em escala, especialmente quando você quer ter a mesma configuração e governança de filtragem de log em centenas de serviços. É melhor gravar os dados no CloudWatch e usar um mecanismo centralizado para enviar seus dados para qualquer provedor que desejar e filtrar os dados que não deseja enviar. É mais seguro e tem melhor desempenho, mas você paga mais (mas vale a pena!). Confira minha postagem aqui para obter prós e contras detalhados.
TL;DR — use uma extensão, mas talvez você queira reconsiderar em escala.
Monitorando as métricas de contêiner do Lambda
Este é um ótimo caso de uso, e não consigo encontrar nenhum problema com ele, exceto que ele deveria sair da caixa no Lambda. Não quero pensar sobre isso ou anexar extensões. Quero habilitá-lo por meio da configuração do IaC e ver as estatísticas no CloudWatch.
TL;DR — use uma extensão
Engenharia do Caos
Outro caso de uso exclusivo com extensões na engenharia do caos é onde as extensões Lambda são uma ferramenta prática.
Koby Aharon cobriu conceitos de engenharia de caos sem servidor em seus dois fantásticos guest posts no meu site e forneceu detalhes de implementação. Ele conduziu seu experimento de caos usando uma extensão Lambda. Você pode revisar seu post de introdução aqui e seus detalhes de experimento aqui .
Ele "instalou" a extensão no início do experimento, deixando seu código de implantação e código de função limpos de extensões e camadas, e removeu-a assim que o experimento foi concluído. É superlimpo, e ele faz isso apenas durante um experimento de caos, que é feito em uma conta separada, então não afeta a produção. Neste exemplo, a manutenção é um problema menor, e os desenvolvedores não precisam estar cientes disso durante o desenvolvimento. Zero contras, e você obtém todos os prós da extensão.
TL;DR — use uma extensão
Agora, eu não cobri todas as extensões do mundo. Ainda assim, esses exemplos cobrem uma grande porcentagem dos casos de uso generalizados.
Resumo
Nesta postagem, analisei vários casos de uso comuns de extensões Lambda.
Listei os prós e contras das extensões lambda e sugeri os casos de uso mais adequados.
Resumindo, se o seu código interage ativamente com a extensão, você está fazendo algo errado e deve substituir a extensão pelo código de função Lambda regular ou, na maioria dos casos, por uma biblioteca de código aberto que faz o mesmo trabalho, às vezes até com mais recursos.
Só porque você pode fazer isso com uma extensão não significa que você deva fazer .
Observabilidade e engenharia de caos, por outro lado, são bons exemplos de uso adequado de extensão.
Comments