Em muitos casos, separar a funcionalidade em funções diferentes pode proporcionar melhor performance e também tornar uma aplicação mais fácil de manter e escalar. No entanto, os “monólitos” do Lambda podem ser um trampolim útil na migração de uma aplicação existente.
Quanta funcionalidade uma única função do Lambda deve conter?
A função deve realizar uma única tarefa no fluxo de dados entre os serviços da AWS em seu microsserviço. No entanto, se a tarefa funcional for muito pequena, isso poderá gerar latência adicional na aplicação e sobrecarga no gerenciamento de um grande número de funções. O escopo exato de uma função é determinado pelo caso de uso.
As aplicações baseadas no Lambda podem funcionar em várias regiões?
Sim, muitos serviços com tecnologia sem servidor oferecem replicação e suporte para várias regiões, incluindo o DynamoDB e o Amazon S3. As funções do Lambda podem ser implantadas em várias regiões como parte de um pipeline de implantação, e o API Gateway pode ser configurado para dar suporte a essa configuração. Confira este exemplo de arquitetura
As funções do Lambda podem ser executadas em um cronograma?
Sim, você pode usar expressões programadas para regras no EventBridge para acionar uma função do Lambda. Esse formato usa a sintaxe cron e pode ser definido com uma granularidade de um minuto. Consulte este tutorial para conferir um exemplo.
Como uma função do Lambda pode reter o estado entre as invocações?
Em muitos casos, uma tabela do DynamoDB é a forma ideal de retenção, pois fornece acesso a dados de baixa latência e pode ser escalada com o serviço Lambda. Você também pode armazenar dados no Amazon EFS for Lambda
Quais tipos de workloads são adequados para arquiteturas orientadas por eventos?
As arquiteturas orientadas por eventos se comunicam entre diferentes sistemas usando redes, que introduzem latência variável. Para workloads que exigem latência muito baixa, como sistemas comerciais em tempo real, esse design talvez não seja a melhor escolha. No entanto, para workloads altamente escaláveis e disponíveis, ou aquelas com padrões de tráfego imprevisíveis, as arquiteturas orientadas por eventos podem fornecer uma maneira eficaz de atender a essas demandas.
Por que o serviço Lambda tem um limite de 15 minutos para funções?
As funções do Lambda existem para processar eventos e a maioria deles é processada muito rapidamente (normalmente, menos de um segundo para a maioria das invocações de produção). A duração de uma função é determinada pelo tempo gasto para processar um evento. Embora existam algumas workloads com uso intenso de computação que podem levar vários minutos, poucas requerem 15 minutos para serem concluídas.
Se você achar que precisa de uma duração maior, certifique-se de que seu código de função esteja processando eventos únicos, executando tarefas únicas e usando as práticas recomendadas descritas neste documento. Em muitos casos, as funções podem ser reformuladas para processar eventos únicos e reduzir o tempo necessário do processamento.
Por que uma função com simultaneidade reservada não está sendo escalada para atender ao tráfego de entrada?
A simultaneidade reservada para uma função do Lambda também atua como um valor máximo de capacidade. Aumentar o limite flexível na simultaneidade total não afeta esse comportamento. Se precisar de uma função com simultaneidade reservada para processar mais tráfego, você pode atualizar o valor da simultaneidade reservada, o que aumenta o throughput máximo da sua função.
Por que uma função com simultaneidade provisionada ainda está passando por inicializações a frio?
Você pode medir as inicializações a frio durante o aumento de escala do Lambda adicionando o monitoramento do X-Ray à sua função. Uma função que usa a simultaneidade provisionada não apresenta comportamento de inicialização a frio, pois o ambiente de execução é preparado antes da invocação. No entanto, a simultaneidade provisionada deve ser aplicada a uma versão ou alias específico de uma função, e não à versão $LATEST. Nos casos em que você continuar observando o comportamento de inicialização a frio, certifique-se de invocar a versão do alias com a simultaneidade provisionada configurada.
Qual é o melhor runtime para usar na minha função do Lambda?
O Lambda não faz distinção do runtime que você escolher usar. Para funções simples, as linguagens interpretadas, como Python e Node.js, oferecem a performance mais rápida. Para funções com computação mais complexa, as linguagens compiladas, como Java, geralmente demoram mais para inicializar, mas são executadas rapidamente no manipulador do Lambda. A escolha do runtime também é influenciada pela preferência do desenvolvedor e pela familiaridade com a linguagem.
Como posso garantir que a versão do SDK não mude?
Os SDKs incorporados podem mudar sem aviso prévio à medida que a AWS lançar novos serviços e recursos. Você pode bloquear uma versão do SDK criando uma camada no Lambda com a versão específica necessária. Dessa forma, a função sempre usará a versão na camada, mesmo que a versão incorporada no serviço mude.
Como posso testar se uma aplicação baseada no Lambda pode ser escalada para atender ao tráfego esperado?
Para garantir que sua aplicação seja escalada conforme o esperado, use o teste de carga em seu processo de desenvolvimento para simular o nível esperado de tráfego.
Quais workloads são adequadas para a simultaneidade provisionada?
A simultaneidade provisionada foi projetada para disponibilizar funções com tempos de resposta de dois dígitos em milissegundos. Geralmente, as workloads interativas são as que mais se beneficiam do recurso. São aplicações em que os usuários iniciam solicitações, como aplicações móveis e da Web, e que são mais sensíveis à latência. As workloads assíncronas, como pipelines de processamento de dados, costumam ser menos sensíveis à latência e, portanto, geralmente não precisam de simultaneidade provisionada.
Por que minha função do Lambda não está registrando nenhuma saída em log?
Se uma função do Lambda não estiver sendo registrada em log no CloudWatch, primeiro certifique-se de que a função esteja sendo invocada pelo chamador. Verifique os logs do serviço de chamada e todas as métricas do CloudWatch que indiquem que um evento acionou a função. Em seguida, verifique a função no CloudWatch Logs. Todas as funções do Lambda registram três linhas em log, mesmo que não haja nenhum outro registro explícito no código personalizado da função:
Se um registro em log não for exibido no CloudWatch, apesar da função ter sido invocada, verifique as permissões da função. O perfil do IAM deve incluir permissões de registro em log, ou a função não poderá gravar logs no serviço. É possível anexar a política AWSLambdaBasicExecutionRole ao perfil de execução da sua função para conceder essas permissões.
