- Serverless parece simples, mas na prática é uma arquitetura que gera complexidade, limitações e alto custo
- Contêineres oferecem portabilidade, manutenção de estado e controle claro, sendo mais adequados para a maioria dos casos de uso
- Serverless tem uma estrutura de custos opaca e imprevisível, além de causar complexidade desnecessária entre os componentes
- A escalabilidade e a praticidade do serverless só se aplicam bem a casos de uso limitados
- Em ambientes reais de produção, a implantação baseada em contêineres é mais simples, escalável e econômica
Serverless Is a Scam. Just Use a Container.
O que é serverless?
- Serverless é uma forma de implantar código em funções individuais, em que a plataforma de nuvem cuida automaticamente da execução e da escalabilidade
- Mas, na prática, existem os seguintes problemas
- Limite de tempo de execução (ex.: AWS Lambda tem limite de 15 minutos)
- Impossibilidade de manter estado (reinicializa a cada execução)
- Problema de cold start
- Ambiente impossível de depurar
- Configuração e ajustes específicos de cada plataforma
- Uso excessivo de YAML
- Parece simples, mas não é adequado para tarefas complexas
Contêineres: simples, poderosos e, no bom sentido, sem graça
- Contêineres têm as seguintes vantagens
- Inicialização rápida
- Podem rodar em qualquer ambiente
- Permitem manter estado (usando
Docker volume) - Sem limite de tempo de execução
- Liberdade para depuração, desenvolvimento local e transição para produção
- Exemplo de código:
docker run -v my-data:/data my-app - Como resultado, é possível executar workloads com estado de forma consistente em qualquer lugar
- Sem dependência de fornecedor, sem custos ocultos e sem mudanças estruturais desnecessárias
Precificação de serverless: feita para confundir o usuário
- O custo de serverless é estruturado de forma muito complexa
- Custo por invocação
- Uso de memória
- Tempo de execução
- Volume de dados transferidos
- Variação por região
- Custo de acesso a chaves secretas, entre outros
- Exemplos de termos que geram confusão:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- Por causa da estrutura imprevisível de cobrança, podem surgir faturas inesperadas
- Comparação: um VPS de $5 oferece preço fixo previsível com controle total dos recursos
Contestando a ideia de que “serverless escala”
- Serverless é tecnicamente escalável, mas na prática a maioria dos apps não precisa disso
- O que a maioria das aplicações realmente precisa é do seguinte
- Previsibilidade
- Capacidade de monitoramento
- Limites adequados de recursos
- Ambientes de desenvolvimento e staging
- Em uma base com contêineres, escalar também é simples
replicas: 5 - Ou é possível fazer escalabilidade horizontal com um load balancer
O design stateless cria problemas artificiais
- Serverless força um design necessariamente stateless
- Sem cache, sessão, arquivos temporários ou conexões persistentes
- Como resultado, passam a ser necessários
- Banco de dados externo
- Cache distribuído
- Armazenamento de arquivos
- Event bus
- State machine
- No fim, um app serverless “simples” acaba tendo mais de 6 dependências de SaaS
- Já com contêineres, é possível ter
- Cache em memória
- Escrita em disco
- Manutenção de sessão
- Execução ilimitada
Resposta para “não quero gerenciar servidor”
- Existem formas de usar plataformas baseadas em contêineres sem precisar administrar servidor
- Uso de plataformas como Sliplane, Railway e Coolify
- Ou simplesmente com Docker + systemd em um VPS
- Implantação baseada em Git, rollback, logs, métricas e outras facilidades operacionais continuam garantidas
- Também é possível entender e controlar o sistema como um todo
Contestando a alegação de que “serverless é mais barato”
- Em frequência de invocação extremamente baixa, pode ser barato
- Mas o custo dispara nas situações abaixo
- Quando o tráfego passa de certo nível
- Quando é necessário aumentar a memória
- Quando há muito processamento real
- Quando há muita transferência de dados
- Como a plataforma esconde tudo, o serverless é difícil de otimizar
- Já os contêineres
- Podem rodar continuamente mesmo em hardware barato
- Podem ser integrados a cache e armazenamento
- São fáceis de medir e ajustar
- Sem cobrança por milissegundo
Quando serverless realmente faz sentido
- É adequado para trabalhos intermitentes e sem estado, como
- Funções orientadas a eventos (ex.: redimensionamento de imagem)
- Tarefas ou webhooks executados raramente
- Ferramentas internas
- POC
- Casos em que é preciso subir ou descer escala rapidamente
- Mas, em aplicações reais, ele bate em limites e
- acaba cobrando um preço alto em tempo, custo e complexidade
Por que contêineres são a melhor escolha
- Contêineres oferecem
- Portabilidade
- Controle
- Simplicidade
- Transparência
- Flexibilidade
- Permitem implantação com um ou vários contêineres, escalabilidade, manutenção de estado, tarefas em background e integração com banco de dados
- Também é possível mudar de plataforma sem reescrever o código
Resumo (TL;DR)
- Serverless parece interessante na teoria
- Na prática, é:
- Opaco
- Caro
- Complexo demais
- Superestimado
Antes de começar, pergunte a si mesmo:
“Será que eu não poderia simplesmente fazer isso com um contêiner?”
- Se a resposta for “sim”, começar com um contêiner é a melhor escolha
Próxima ação recomendada
- Recomenda-se compartilhar casos em que o serverless causou custos inesperados ou fluxos de trabalho ineficientes
- Não transforme problemas simples em algo excessivamente complexo
19 comentários
Existe xfaas... e também há o CF Workers. Parece um artigo tendencioso.
Eu estava pensando em, ao alugar uma GPU, executar algo por um curto período com uma função serverless.
Isso também é possível com contêineres?
Nos antigos serviços de hospedagem web em PHP, se você tirar o PHP e colocar um monte de JS com forte vendor lock-in....
não consigo deixar de pensar que fica difícil distinguir isso das plataformas serverless FaaS mais representativas.
Claro, eu, como um verdadeiro "sommelier de porcaria" que usa principalmente PHP e JS/TS, tenho usado isso de forma bem satisfatória,
mas ainda assim não entendo muito bem por que tanta gente acha isso tão bom.
Na minha opinião, usar o serviço serverless de um fornecedor é arriscado, mas usar containers para a própria empresa oferecer um ambiente serverless parece uma boa ideia. Acho que seria bom aproveitar serverless não como um serviço, mas como um conceito.
Por um tempo, ficaram em alta um tuíte e um vídeo[1] sobre o abandono do Edge rendering da Vercel, além de um texto sobre servidor serverless (kkk)[2]. Acho que tenho uma visão parecida com a dos textos que surgiram naquela época.
É uma opinião pessoal, mas, do ponto de vista de um desenvolvedor front-end, acho que ainda está longe o momento de acoplar serverless functions às requisições dos usuários (a não ser que a aplicação que você quer criar seja um MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Claro, como já comentaram neste post, parece ser um texto excessivamente caça-cliques mesmo :(
Tendo experiência tanto com ambientes baseados em contêineres (principalmente ECS Fargate e clusters Kubernetes) quanto com ambientes serverless (AWS), isso não me convence tanto assim.
Os pontos listados como vantagens de ambientes baseados em contêineres também podem, ao mesmo tempo, acabar sendo desvantagens.
Todas essas partes mencionadas como "é possível controlar diretamente e manter estado" acabam virando pontos de gestão, o que aumenta a dificuldade operacional.
Eu, particularmente, recomendo fortemente serverless para organizações pequenas, especialmente aquelas que não têm uma equipe especializada em administração de servidores.
Ah, concordo com a questão de que o cálculo de custos é complexo ou difícil de prever, e também com o problema de vendor lock-in.
Como alguém mencionou experiência de desenvolvimento e observabilidade, acrescentando um ponto,
se o ambiente inicial de integração for bem montado, dá para ter uma experiência de desenvolvimento tão boa quanto a baseada em containers, talvez até mais próxima do nativo do que a baseada em containers. (Existem várias ferramentas para isso.)
Quanto à observabilidade, se quiser fazer algo realmente profundo, tanto serverless quanto uma base em containers deixam de ser um problema simples. Centralização de logs, visualização de vários tipos de métricas, APM, visualização de uso de CPU/memória e definição de estratégias de escalonamento com base nisso etc...
Se não for nesse nível, a integração de métricas/logs que o vendor de nuvem oferece por padrão é poderosa, então no fim fica elas por elas.
Colocando de forma agressiva, dá vontade de perguntar: "até que ponto você realmente fez serverless direito?" 😅
Também fico pensando se não seria melhor subir só alguns endpoints necessários no Lambda. Desde o início, eu não tenho experiência com desenvolvimento serverless, então não posso falar muito, mas parece que pode ser bom para alguns casos bem específicos.
Será que o fato de a empresa que escreveu este texto ser uma plataforma de hospedagem de contêineres não faz com que ele tenha sido escrito de um ponto de vista enviesado? rs
Antes, também houve gente desconfiando de um texto de um desenvolvedor da Netlify (concorrente) expressando preocupações sobre Next.js (Vercel) no lado do frontend, né. Pelos comentários, não parece ser algo tendencioso.
Eu sou mais da área de frontend... então não sou tão próximo desse lado, mas acho que já vi bastante esse meme de “serverless (tem servidor)” haha
A experiência de desenvolvimento é visivelmente muito pior do que a nativa, o que é um grande ponto de dor, e como o próprio software passa a ter dependência do provedor de infraestrutura, depois que você se estabelece fica difícil escapar. Sem falar que há claramente menos referências, e a observabilidade é muito fraca.
A Cloudflare parece ser a que mais tenta fazer serverless direito em comparação com as outras empresas. Banco de dados serverless, armazenamento chave-valor serverless, e até fila de mensagens serverless...
(Claro, à medida que isso acontece, também dá uma sensação de rejeição por parecer que você fica completamente dependente e preso à plataforma)
Ainda assim, se depuração, observabilidade e experiência de desenvolvimento não melhorarem, continuará sendo andar em círculos.
Cloud Run, vai fundo
Operar um serviço com serverless é escolher a ferramenta errada.
Existem problemas específicos para os quais serverless é necessário. É adequado para usos esporádicos.
Será que a mesma opinião vale para serviços de contêiner serverless também?
Por causa dos problemas dos serviços serverless existentes (tipo o Lambda), a AWS criou o Fargate e depois até o App Runner, que é mais simples ainda 🤔
E ainda tem o Cloud Run, da Google Cloud, um serviço de contêiner serverless scale to zero maravilhoso
Desses aí, pessoalmente achei que o Cloud Run foi o que ofereceu a melhor experiência de desenvolvimento
Serverless (tem servidor)
Comentários do Hacker News
Desde o começo, não era
Serverless, e simServerlease.kkkkkkk