Padrão FLAME: uma nova abordagem para a escalabilidade elástica de aplicações
- Serverless/FaaS (Function as a Service) oferece vantagens como escalabilidade elástica e cobrança baseada no uso, mas, na prática, acaba introduzindo mais complexidade.
- Se fosse possível envolver o código de um app existente em funções e executá-lo em cópias temporárias da aplicação, a escalabilidade automática se tornaria viável.
- O padrão FLAME (Fleeting Lambda Application for Modular Execution) trata a aplicação inteira como se fosse uma lambda e executa partes modulares em infraestrutura de curta duração.
Padrão FLAME
- O padrão FLAME busca uma escalabilidade elástica granular, orientada pela demanda, para partes específicas do código da aplicação, sem gerenciamento de servidores.
- Não é necessário reescrever a aplicação existente nem escrever partes dela em um runtime proprietário.
- A biblioteca
flamede Elixir implementa o padrão FLAME e inclui um adaptador de backend para Fly.io, mas pode ser usada em qualquer nuvem que ofereça uma API para executar o código da aplicação.
Backend do FLAME
- Na infraestrutura da Fly.io, o
FLAME.FlyBackendpode inicializar uma nova Machine e conectá-la à tarefa pai em cerca de 3 segundos. - O FLAME fornece
LocalBackendeFlyBackendpor padrão, mas qualquer host que ofereça uma API para provisionar servidores e executar o código da aplicação pode funcionar como backend do FLAME. - Como a Fly.io empacota e executa aplicações como imagens Docker, basta inicializar uma nova Machine com a mesma imagem.
Elixir fora do FLAME
- Elixir é muito adequado ao modelo do FLAME porque oferece recursos como supervisão de processos e mensageria distribuída praticamente de graça.
- Se a linguagem tiver primitivas de concorrência razoáveis, esse padrão poderá ser aproveitado.
- Há também exemplos de como implementar o padrão FLAME em aplicações JavaScript, movendo a execução modular para novos arquivos.
Sobre processadores de tarefas em segundo plano
- O FLAME funciona bem dentro de processadores de tarefas em segundo plano, mas isso é um problema separado da expansão do pool de tarefas feita pela biblioteca de jobs.
- É importante separar as tarefas que garantem durabilidade da execução elástica.
Pooling para escalabilidade elástica
- Com a implementação de FLAME em Elixir, é possível definir runners de pools elásticos, permitindo escalar para zero e expandir elasticamente servidores FLAME com limite máximo de concorrência.
Posicionamento de processos
- Em Elixir, as partes da aplicação que mantêm estado são construídas em torno da primitiva de processos e funcionam bem quando encapsuladas com
FLAME.callouFLAME.cast.
Monitoramento remoto
- Quando o pai inicializa o runner, o runner precisa gerenciar sozinho o estado ocioso quando não há trabalho e encerrar-se com segurança caso a conexão com o nó pai seja perdida.
Opinião do GN⁺
O ponto mais importante deste texto é que o padrão FLAME pode simplificar a escalabilidade elástica de aplicações ao reduzir a complexidade das abordagens tradicionais de serverless/FaaS. Esse padrão permite que desenvolvedores expandam rapidamente apenas as partes necessárias sem grandes mudanças no código existente, o que pode torná-lo uma solução atraente para muitos engenheiros de software que usam infraestrutura em nuvem. O padrão FLAME pode ser uma ferramenta especialmente poderosa em linguagens como Elixir, e como a possibilidade de implementação em outras linguagens também está sendo explorada, ele desperta expectativa de aplicação em diversos ambientes de desenvolvimento.
1 comentários
Comentários do Hacker News
Tendo lidado por 4 anos com uma aplicação composta por mais de 100 funções Lambda, este texto aponta bem a dor e a complexidade das desvantagens de uma arquitetura serverless FaaS.
Como autor do texto, espero despertar o interesse de quem quiser implementar o padrão FLAME em outras linguagens, como JavaScript e Go, e estou pronto para responder perguntas.
O serviço PiCloud usava um modelo que encaminhava tarefas de forma transparente para workers, o que sugere que algo semelhante também pode ser aplicado em outras linguagens além de Elixir.
Com FLAME, é possível envolver o código existente da aplicação em uma função e executá-lo em uma cópia temporária do app, algo semelhante a bifurcar um processo em um ambiente serverless.
O Windmill.dev considera a unidade de abstração no nível do código-fonte, faz parsing das funções principais e dos imports para extrair argumentos e dependências, e executa o código no runtime desejado.
Com FLAME, os runners de desenvolvimento e teste rodam em um backend local, o que oferece uma boa experiência de desenvolvimento local em um ambiente serverless.
Cada vez que se usa
Flame.call, um novo processo da aplicação é iniciado e o contexto de execução é copiado; isso é uma solução simples para escalar, mas exige considerar a latência adicionada ao tempo de inicialização do app e o uso de memória.Junto com uma crítica ao uso de headline case no Hacker News, expressa-se a esperança de que o que seja repensado não sejam os princípios de serverless, mas sim a empresa serverless.com.
O Inngest.com oferece uma abordagem semelhante, permitindo usar código existente como funções serverless, gerenciando o estado do código externamente e enfatizando a importância de monitoramento e observabilidade.
Se fosse criado um sistema chamado "Long Lambda" em que a Lambda pudesse rodar por mais de 15 minutos, seria possível tratar todo o trabalho dentro da Lambda, com execução e depuração locais.
Este resumo transmite de forma concisa os pontos principais de cada comentário e foi escrito em um nível fácil de entender para engenheiros de software iniciantes. As partes que exigem conhecimento prévio foram explicadas ao mínimo, mantendo uma postura neutra e sem fugir do tema.