Migrar app para serverless: os passos e o que muda no custo

No fim deste texto você vai saber o que a sua aplicação precisa ter para rodar 100% serverless na AWS e quais são os dois caminhos que eu apresentei: Fargate no lugar das EC2, ou funções Lambda no lugar do servidor. Vai entender também por que, nesse modelo, o custo passa a acompanhar o uso e não a capacidade que você deixou ligada.

O que é "100% serverless" aqui

Serverless, nesta conversa, é um cenário em que a sua aplicação não tem nenhum servidor para você gerenciar. Você não sobe instância EC2 para rodar os serviços: quem se preocupa com a infraestrutura é a AWS, que lança os recursos para a aplicação.

Gravei esta aula em novembro de 2021, depois de ter levado uma aplicação local para a nuvem da AWS, com alta disponibilidade, no Bootcamp Imersão AWS, em outubro. A aplicação é a Bia, um front-end em React e uma API em Node. Dali eu parto para dois cenários de migração.

1Tire o estado da aplicação

Este é o primeiro requisito, e vale para qualquer um dos caminhos: a aplicação não pode ter estado. Se ela tem, você não chega nem a um cenário de alta disponibilidade, que dirá a um serverless.

O que isso significa na prática. Imagine várias instâncias atendendo a mesma aplicação. Você faz uma requisição e ela cai na máquina 1. Faz a mesma requisição de novo e ela cai na máquina 2. A resposta tem que ser a mesma.

Se a aplicação guarda informação dentro da máquina, isso quebra. Exemplo: o usuário envia uma imagem, ela fica guardada na máquina 1, e a requisição seguinte cai na máquina 2, onde essa imagem não existe. Esse é um estado preso à máquina, e ele impede a migração para alta disponibilidade e, por consequência, para o cenário 100% serverless.

2Caminho 1, Fargate no lugar das EC2

O primeiro cenário parte de uma aplicação que já está em alta disponibilidade com containers, que foi onde chegamos no evento. A mudança é simples: você configura a aplicação para não levantar instâncias EC2 para rodar os serviços e passa a usar o Fargate. Você coloca só o serviço; a AWS cuida da infraestrutura.

O segundo ponto desse caminho é o banco. Você migra para um banco serverless da estrutura do RDS e também se despreocupa dele. Com Fargate e banco serverless, a aplicação fica 100% serverless.

É o caminho mais simples dos dois, e nem por isso menos válido: a aplicação chega ao 100% serverless por ele também.

3Caminho 2, funções Lambda atendendo a API

O segundo cenário é a arquitetura que, para mim, é uma das mais incríveis para aplicações serverless. Em vez de atender as requisições com containers, você usa Lambda. Traz mais desafios, mas é também o mais interessante.

O desenho que usei na aula:

Na arquitetura anterior, o usuário passava por um Application Load Balancer (ALB) e as requisições eram distribuídas para os serviços no Fargate. Aqui entra um CDN na ponta:

• CDN como centralizador. Ele recebe as requisições do usuário e é a entrada de tudo. A origem dele aponta para o ALB.
• ALB e funções Lambda. O ALB fica na frente e conversa com as funções Lambda, que atendem a API no lugar dos servidores.
• Front-end no S3. Você entrega o front-end pelo S3 e o roteia pelo CDN.
• Banco serverless. Embaixo, o banco também é 100% serverless.

Nesse cenário não existe nenhum servidor, e a arquitetura é extremamente escalável.

Por que o custo muda

A maior vantagem do segundo cenário sobre o primeiro é o custo. A explicação é um gráfico de custo contra o recurso demandado.

Com instâncias EC2. Para ter alta disponibilidade, você precisa de pelo menos duas instâncias, e elas custam desde o primeiro minuto, mesmo sem nenhuma requisição. Quando a demanda sobe, o auto scaling aloca mais instâncias (no desenho, de 2 para 3 e depois para 4). Quando a demanda cai, ele volta para 2. Entre a linha do que a aplicação pede e a linha do que está alocado fica uma folga: capacidade ligada e paga sem necessidade.

Com Lambda. A aplicação começa com zero recurso alocado. Chegou uma requisição, a função processa, e parou de cobrar. Chegou outra, processa de novo, e para de cobrar. O custo fica muito próximo do que de fato foi requisitado, sem essa folga.

Dois cuidados que eu mesmo fiz questão de dizer: o serverless traz desafios, e não é para toda aplicação. Não é bala de prata que resolve custo de qualquer cenário.

4Escolha a ferramenta para fazer a migração

Para executar essa migração, você precisa de uma ferramenta que automatize o processo. Eu conheço duas de que gosto muito:

• Serverless Framework. Ajuda no deploy da aplicação na AWS e faz mais do que isso.
• AWS SAM (Serverless Application Model). É a ferramenta nativa da AWS, e é a que eu vou usar nessa migração.

Escolha uma antes de começar, porque é nela que a arquitetura serverless vai ser descrita.

Checklist

• Procure o que a sua aplicação grava localmente (imagens, sessão, arquivos). Se há estado preso à máquina, resolva isso primeiro.
• Defina o caminho: Fargate com banco serverless (mais simples) ou Lambda atrás do CDN, com front-end no S3 (mais avançado).
• Decida se o seu caso é de serverless: não é para toda aplicação, nem resolve o custo de qualquer cenário.
• Escolha a ferramenta: Serverless Framework ou AWS SAM.

Serverless é um modelo em que você paga pelo uso e deixa de gerenciar servidor, mas só funciona depois que a aplicação perde o estado. Se você quer levar a sua aplicação para a AWS por um desses caminhos, vale uma conversa sobre o seu cenário antes de escolher.