Conceitos
Limites do FaaS: funções sem estado e dados distantes do código
Intuição
Imagine um escritório onde cada tarefa é feita por um freelancer que chega, trabalha por pouco tempo, não guarda nada de uma visita para a outra e não tem telefone. Se um freelancer precisa dos papéis de um arquivo distante, alguém tem de levar os papéis até ele toda vez; se dois deles precisam conversar, só conseguem deixando recados numa caixa de correio lenta no corredor. Para tarefas independentes e curtas isso é ótimo, porque você contrata quantos precisar e paga só pelo trabalho feito. Para tarefas que dependem de muitos papéis e de muita conversa, o tempo todo vai embora em carregar papel e trocar recado.
Como funciona
O paper analisa o Function-as-a-Service (FaaS), como o AWS Lambda, e aponta quatro limitações. Primeiro, tempos de vida curtos: uma função vive no máximo 15 minutos, então não mantém estado de longa duração, e a máquina que a roda não garante cache entre invocações. Segundo, gargalos de E/S: uma única função alcançou 538 Mbps de banda de rede, mas com 20 funções em paralelo a média por função caiu para 28,7 Mbps. Terceiro, as funções não são endereçáveis pela rede, então a comunicação entre elas passa por um serviço de armazenamento lento; mover 1 KB leva cerca de 108 ms do Lambda para o S3 e 11 ms para o DynamoDB, contra 290 microssegundos entre instâncias EC2 com ZeroMQ. Quarto, não há hardware especializado como GPUs. O efeito combinado é o padrão que o paper critica: data shipping, isto é, o código é enviado ao dado e o dado é trazido até a função a cada execução, em vez de aproximar o dado do código (code shipping). Nos estudos de caso, treinar um modelo levou 465 minutos em funções contra cerca de 22 minutos numa EC2 m4.large (US$ 0,29 contra US$ 0,04, cerca de 21 vezes mais lento e 7,3 vezes mais caro). No serving de predições, a latência por requisição foi de 559 ms buscando o modelo a cada chamada e 447 ms com o modelo embutido e SQS, contra 13 ms com EC2 e SQS e 2,8 ms com EC2 e ZeroMQ. Os autores tratam isso como consequência do modelo de execução, não como detalhe que um ajuste fino resolveria.
Na prática
O paper lista três casos fáceis em que a FaaS funciona bem: cargas embaraçosamente paralelas (tarefas independentes entre si), orquestração de serviços (a função coordena chamadas a outros serviços) e composição de funções. Também reconhece um grande mercado de aplicações estreitas, pouco mais que lógica de negócio sobre um banco de dados, e cita o fluxo de cadastro de usuários da Autodesk, que passou a levar cerca de 10 minutos. Ao escolher serverless, a pergunta prática é onde estão os dados e quanta comunicação entre funções a carga exige: treino de modelos, serving de baixa latência e algoritmos distribuídos com conversa frequente tendem a ser melhores em máquinas que guardam estado e se endereçam diretamente. Como direção, os autores propõem colocação fluida de código e dados e agentes endereçáveis de longa duração.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.