Serverless containers: como escolher a arquitetura ideal

Você está desenhando uma função, um microsserviço ou uma API e trava na mesma decisão: deploy em serverless puro ou em containers? A dúvida é legítima. Cada abordagem resolve um problema real, mas em contextos diferentes. Neste comparativo, nós olhamos lado a lado os critérios que realmente importam na hora de escolher: custo, escalabilidade, operação, portabilidade e ecossistema. Ao final, você sai com um critério de decisão claro, não com uma resposta genérica.

A diferença essencial está no nível de abstração. No serverless puro, você envia o código e a plataforma gerencia runtime, escala e disponibilidade. Nos containers, você empacota o ambiente inteiro, mas ainda precisa orquestrar, expor e dimensionar. Não existe arquitetura universalmente melhor, existe a que se encaixa no seu caso.

Custo: pagar por invocação ou por recurso alocado

O modelo de cobrança é o primeiro divisor de águas. No serverless puro, você paga por invocação e por tempo de execução, geralmente em incrementos de 100 ms. Se a função fica ociosa, o custo tende a zero. Isso é ótimo para workloads intermitentes, como processamento de eventos, webhooks ou integrações pontuais.

Nos containers gerenciados, você paga pelo tempo em que o container fica ativo, mesmo sem receber requisições. Se você mantém 10 instâncias rodando 24/7 para garantir pico, paga por todas elas, ociosa ou não. Para tráfego constante e previsível, o custo pode ser menor que o serverless, porque você negocia a capacidade. Para picos esporádicos, o serverless tende a sair mais barato.

Uma ressalva concreta: funções serverless com execução longa, acima de 15 minutos em alguns provedores, não são suportadas. Se o seu workload passa disso, containers viram necessidade, não escolha.

Escalabilidade: automática ou sob controle

Serverless escala de forma quase instantânea e automática. A plataforma cria novas instâncias conforme a demanda, sem intervenção sua. Isso resolve o problema de picos inesperados sem planejamento prévio. Para funções event-driven, é o comportamento ideal.

Containers, por outro lado, exigem configuração de auto scaling. Você define métricas, limites mínimo e máximo, e a plataforma ajusta o número de instâncias. O controle é maior, mas a responsabilidade também. Se você não configurar bem, pode ter subutilização ou latência em picos. Para workloads previsíveis, o controle fino compensa.

Um ponto que muitos esquecem: no serverless, a escala é por invocação, não por instância. Isso significa que o custo acompanha a demanda real, mas também que você não tem controle sobre a localização da execução. Em containers, você pode fixar regiões e zonas, o que ajuda em conformidade e latência.

Operação e manutenção: menos ou mais responsabilidade

A operação é onde o serverless brilha. Não há servidor para patchear, kernel para atualizar ou runtime para gerenciar. A plataforma cuida de tudo, e você se concentra no código. Para times pequenos ou sem equipe de infraestrutura dedicada, isso reduz drasticamente a complexidade.

Containers exigem mais cuidado. Mesmo em serviços gerenciados como AWS Fargate, você ainda precisa gerenciar imagens, atualizar base images, lidar com vulnerabilidades e configurar rede. A curva de aprendizado é maior. Em compensação, você ganha liberdade para escolher versões de runtime, bibliotecas e dependências específicas.

Um contraexemplo prático: se a sua função usa uma biblioteca que exige uma versão específica de OpenSSL, no serverless puro você depende do runtime da plataforma. No container, você empacota a versão exata e não tem surpresa. Para quem já viveu dor de cabeça com dependência quebrada em produção, esse controle vale o custo operacional.

Portabilidade e lock-in

Containers são portáveis por design. Uma imagem Docker roda em qualquer provedor que suporte o padrão, de AWS a on-premise. Isso reduz o risco de lock-in e facilita migrações futuras. Se a sua estratégia é multi-cloud ou híbrida, containers são quase obrigatórios.

Serverless puro, em geral, amarra você a um provedor. Cada plataforma tem seus próprios triggers, limites e configurações. Migrar uma função serverless entre provedores raramente é copiar e colar. Para quem prioriza flexibilidade de longo prazo, essa é uma desvantagem real.

No entanto, o ecossistema serverless está amadurecendo. Frameworks como o Serverless Framework ajudam a abstrair parte do lock-in, permitindo deploy em múltiplos provedores com o mesmo código. Ainda assim, a abstração não é perfeita e features específicas de cada plataforma podem escapar.

Ecossistema e integrações

Serverless puro se integra nativamente com serviços gerenciados do provedor, como filas, bancos de dados e storage. Isso reduz a latência e a complexidade de conexão. Para arquiteturas event-driven, é o caminho mais direto.

Containers exigem que você configure integrações manualmente, mas em compensação funcionam com qualquer serviço, dentro ou fora do provedor. Se você usa Kafka, Redis ou bancos específicos, containers oferecem mais compatibilidade.

Um exemplo de estrutura: um time que processa uploads de imagens pode usar serverless para o trigger de upload e containers para o processamento pesado de imagem. A combinação dos dois, inclusive, é uma prática comum e recomendada.

Tabela comparativa: serverless puro vs containers gerenciados

| Critério | Serverless puro | Containers gerenciados | | --- | --- | --- | | Custo | Por invocação e tempo | Por recurso alocado | | Escalabilidade | Automática e instantânea | Configurável e controlada | | Operação | Mínima, plataforma gerencia | Maior, você gerencia imagens e rede | | Portabilidade | Baixa, lock-in do provedor | Alta, padrão Docker | | Tempo de execução | Limitado (até 15 min em alguns) | Ilimitado | | Controle de runtime | Baixo, depende da plataforma | Alto, você define tudo | | Melhor para | Eventos, picos, workloads curtos | Workloads longos, previsíveis, customizados |

Veredito: qual escolher?

Para funções curtas, event-driven e com tráfego intermitente, serverless puro é a escolha mais simples e econômica. O custo acompanha a demanda e a operação é mínima. Se o seu time não quer lidar com infraestrutura, essa é a resposta.

Para workloads longos, previsíveis ou que exigem controle fino de runtime e dependências, containers gerenciados são mais adequados. O custo fixo compensa quando a utilização é constante, e a portabilidade protege contra lock-in.

E se você está em dúvida entre os dois, considere uma abordagem híbrida. Use serverless para o que é event-driven e containers para o que é processamento pesado. Muitas arquiteturas modernas combinam os dois sem conflito.

O próximo passo prático: desenhe suas funções em uma tabela e classifique cada uma por tempo de execução, previsibilidade de tráfego e necessidade de customização. Isso dá um critério objetivo antes de escolher a ferramenta.

FAQ

Serverless e containers são mutuamente exclusivos?

Não. Eles podem coexistir na mesma arquitetura. É comum usar serverless para triggers e eventos, e containers para processamento pesado. A escolha depende do workload específico, não de uma regra geral.

Qual é mais barato, serverless ou containers?

Depende do padrão de uso. Serverless tende a ser mais barato para workloads intermitentes, porque você paga apenas pelo que executa. Containers podem ser mais econômicos para uso constante e previsível, já que você negocia a capacidade alocada.

Containers gerenciados são considerados serverless?

Em parte. Serviços como AWS Fargate são chamados de serverless porque removem a gestão de servidores, mas ainda exigem configuração de scaling e recursos. Eles oferecem um meio-termo entre serverless puro e containers tradicionais.

Qual é o limite de tempo de execução no serverless?

Varia por provedor. Em alguns, o limite é de 15 minutos por invocação. Para funções que precisam rodar por mais tempo, containers são necessários. Verifique a documentação do seu provedor para o valor exato.

Posso migrar de serverless para containers depois?

Sim, mas a migração exige refatoração. O código pode ser reaproveitado, mas triggers, configurações e integrações precisam ser adaptados. Por isso, vale avaliar a portabilidade desde o início do projeto.

Containers são sempre mais complexos de operar?

Na maioria dos casos, sim. Eles exigem gestão de imagens, atualizações e rede. Mas serviços gerenciados reduzem parte dessa complexidade. Se o seu time já tem familiaridade com Docker, a curva é menor.