DEV Community

Cover image for Serverless Framework: 10 melhores práticas recomendadas
Eduardo Rabelo
Eduardo Rabelo

Posted on

Serverless Framework: 10 melhores práticas recomendadas

O Serverless Framework é uma dos frameworks de implantação mais antigos (e ainda está forte!) para aplicativos serverless. É a meu framework de escolha e conta com um grande apoio da comunidade em termos de contribuições e plugins. De fato, seu ecossistema de plugins é um dos seus maiores pontos fortes em comparação com outros frameworks.

O Serverless Framework fornece várias práticas recomendadas prontas para uso, como:

  • Convenção de nomenclatura consistente.
  • Gerando as permissões mínimas do IAM para outros serviços, para que eles possam chamar suas funções do Lambda.
  • Suporte ao uso do armazenamento de parâmetros do SSM para armazenar dados confidenciais com segurança com o SecureStrings.

Mas ainda há muitas coisas a fazer para garantir que nossos aplicativos sejam seguros e robustos. Então, aqui estão minhas 10 melhores práticas recomendadas que você deve adotar ao trabalhar com o Serverless Framework.

1. Nenhum "*" nas declarações IAM

Aplicativos serverless podem ser mais seguros que seus contrapartes, como contêineres de VM. Mas ainda precisamos fazer nossa parte e garantir que não super-provisionemos o acesso de nossas funções.

Devemos seguir o princípio do menor privilégio e conceder às nossas funções a quantidade mínima de acesso de que precisam. E isso significa conceder permissões para executar operações específicas contra recursos específicos.

2. Um modelo IAM por função

Por padrão, o Serverless Framework usa um modelo compartilhado para todas as funções no serverless.yml. Isso também viola o princípio do menor privilégio, pois as funções teriam acesso desnecessário por meio do modelo compartilhado.

Ao invés disso, você deve usar o plugin serverless-iam-roles-per-function e definir modelos do IAM para cada função.

3. Configure DLQ para funções assíncronas

Ao definir funções que são invocadas por fontes de eventos assíncronas (lista completa aqui), você deve configurar um DLQ (Dead Letter Queue) separado para cada função. Os serviços que invocam funções Lambda de forma assíncrona fornecem replay por padrão, com atraso exponencial. No entanto, se a função retornar erros persistentemente, os eventos de chamada podem ser perdidos para sempre se você não tiver configurado um DLQ.

4. Configure a versão do framework

Se você estiver usando uma instância do Serverless Framework instalada em sua máquina (ou no servidor de CI), adicione a propriedade frameworkVersion ao serverless.yml.

frameworkVersion: ‘>=1.0.0 <2.0.0’

Isso verifica se você está usando uma versão do Serverless Framework compatível com o serverless.yml atual.

5. Configure o modelo para deploy com CloudFormation

O Serverless Framework permite passar um modelo dedicado ao CloudFormation para executar seu deploy.

cfnRole: arn:aws:iam::XXXXXX:role/role

Você pode usar um modelo diferente para cada projeto ou equipe e aplicar o princípio do menor privilégio ao pipeline de deploy. Essa abordagem também combina bem com o controle de acesso baseado em atributos (ABAC). Por exemplo, o modelo de deploy da equipe A pode ser restrita para criar e excluir (necessário para rollbacks) as tabelas do DynamoDB com a tag "Team=TeamA".

6. Configure Tags em suas Stacks

As tags ajudam a encontrar recursos mais facilmente e você pode até usá-los para rastrear seus gastos na AWS. Por padrão, o Serverless Framework insere a tag STAGE no modelo CloudFormation gerado.

No entanto, considere adicionar outras tags personalizadas usando a propriedade stackTags. As tags comuns a serem consideradas incluem Autor, Equipe, Recurso, Centro de Custo e Região. Infelizmente, o CloudFormation não propaga suas tags para alguns recursos, como grupos de log do CloudWatch. Você pode solucionar essa limitação implantando o aplicativo SAR propagate-cfn-tags na sua conta.

7. Ao usar VPCs, configure pelo menos 2 subnets

Ao configurar suas funções com acesso à VPC, configure pelo menos 2 sub-redes (subnet) dedicadas para o Lambda. Isso diminui o risco de exaustão de IP na sub-rede e limita o raio dessa falha às funções do Lambda.

No entanto, dado o recente anúncio de melhoria da rede VPC para o Lambda, isso não seria mais necessário depois que a melhoria for lançada em sua conta.

8. Use "Fn::Sub" ao invés de "Fn::Join" para maior clareza

Na maioria das vezes, o Fn::Join é usado para construir ARNs e URLs a partir de diferentes partes. Nesses casos, você deve usar Fn::Sub, o que torna o código muito mais legível.

Você pode ver mais exemplos aqui.

9. Para as funções Node.js, use webpack para melhorar o "cold start" e reduzir o tamanho final

Para funções do Node.js, o tempo de inicialização é uma grande parte do cold start e pode variar bastante, dependendo de quantas dependências você possui.

O webpack pode ajudar a reduzir significativamente o tempo de inicialização. Você deve usar o plugin serverless-webpack para executar o webpack automaticamente sempre que fazer deploy do seu código.

Você pode ver mais detalhes aqui.

10. Divida seu serverless.yml em vários arquivos

O Serverless Framework permite que você faça referência a arquivos YML e JSON externos. Quando seu serverless.yml ficar muito grande, você deve dividi-lo em arquivos menores e referenciá-los novamente no serverless.yml principal. Isso ajuda a manter o arquivo serverless.yml gerenciável.

Créditos

Top comments (0)