Serverless Framework: 10 melhores práticas recomendadas
Tags: ptbr, serverless, aws, webdev
Published: 2019-10-06 03:28:04

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](https://en.wikipedia.org/wiki/Principle_of_least_privilege) 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.

![](https://datree.io/wp-content/uploads/2019/09/1.jpg)

# 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`](https://www.npmjs.com/package/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](https://docs.aws.amazon.com/lambda/latest/dg/lambda-services.html)), 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)](https://aws.amazon.com/blogs/security/simplify-granting-access-to-your-aws-resources-by-using-tags-on-aws-iam-users-and-roles/). 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](https://github.com/lumigo-io/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](https://aws.amazon.com/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/), 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.

![](https://datree.io/wp-content/uploads/2019/09/serverless-arn.png)

Você pode ver [mais exemplos aqui](https://theburningmonk.com/2019/05/cloudformation-protip-use-fnsub-instead-of-fnjoin/).

# 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.

![](https://datree.io/wp-content/uploads/2019/09/serverless-timeline.png)

O webpack pode ajudar a reduzir significativamente o tempo de inicialização. Você deve usar o plugin [serverless-webpack](https://github.com/serverless-heaven/serverless-webpack) para executar o webpack automaticamente sempre que fazer deploy do seu código.

Você pode ver [mais detalhes aqui](https://theburningmonk.com/2019/03/just-how-expensive-is-the-full-aws-sdk/).

# 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](https://serverless.com/framework/docs/providers/aws/guide/variables/#reference-variables-in-other-files). 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 10 Serverless best practices](https://datree.io/serverless-best-practices/), escrito originalmente por [Yan Cui](https://twitter.com/theburningmonk)