A pergunta "onde a gente roda isso?" tem três respostas populares, e a escolha costuma ser feita por familiaridade ou por modismo em vez de pelo perfil da carga. O resultado aparece meses depois: fatura maior que o esperado, latência que ninguém explica, ou um projeto de migração para sair de onde não deveria ter entrado.
As três opções têm perfis bem distintos. Vale conhecê-los antes de decidir.
VM: o denominador comum
Uma máquina virtual é um computador completo, com sistema operacional próprio. Você instala o que quiser e opera como sempre operou.
Ganha quando:
- A aplicação é legada, monolítica, ou tem dependências estranhas — agente, driver, biblioteca nativa, licença amarrada ao hardware.
- Há estado local relevante: banco de dados, servidor de arquivos, aplicação que grava em disco.
- O time já sabe operar servidor e não há apetite para incorporar outra camada agora.
- A carga é estável e previsível, e você quer custo fixo.
- Há exigência de isolamento forte, especialmente com carga de terceiros.
Custa: você administra sistema operacional, atualização e capacidade. Inicialização medida em dezenas de segundos. Densidade menor por servidor.
O ponto que se perde em discussões modernas: VM continua sendo a resposta certa para muita coisa, e particularmente para banco de dados. Rodar banco em VM dedicada com storage local rápido e alta disponibilidade no nível da virtualização é mais simples, mais rápido e mais fácil de diagnosticar do que a alternativa — e é o desenho que recomendamos com frequência.
Container: o padrão para aplicação sem estado
Container empacota a aplicação com as dependências dela, compartilhando o kernel do host. Sobe em segundos, ocupa pouco e roda igual em qualquer lugar que tenha o runtime.
Ganha quando:
- A aplicação é sem estado, ou o estado está fora dela (banco, cache, storage de objetos).
- Há vários serviços que precisam subir juntos e de forma reprodutível.
- O ciclo de entrega é frequente e você quer deploy previsível.
- Importa escalar horizontalmente conforme a demanda.
- O "funciona na minha máquina" já custou tempo demais.
Custa: o estado vira um problema que precisa de desenho explícito. E existe o degrau da orquestração — um servidor com Compose é simples; vários servidores exigem orquestrador, que é outra coisa para manter.
O erro mais comum aqui não é usar container; é adotar Kubernetes cedo demais. Para uma aplicação com quatro ou cinco serviços em um servidor, Compose resolve com uma fração da complexidade. O orquestrador se justifica por sintoma — um servidor não aguenta mais, a queda do host deixou de ser tolerável, times diferentes precisam de isolamento — não por aspiração.
Serverless: você paga pela execução
Serverless cobre duas coisas que vale distinguir:
- Funções (FaaS): você entrega uma função, o provedor executa quando um evento chega e cobra por execução e tempo. Entre eventos, não há nada rodando — nem custo.
- Containers serverless: você entrega uma imagem, o provedor sobe instâncias conforme a demanda e reduz a zero quando não há tráfego.
Ganha quando:
- A carga é intermitente ou muito variável. Uma rotina que roda cinco vezes por dia não deveria manter um servidor ligado 24 horas.
- O trabalho é dirigido por evento: upload de arquivo, mensagem em fila, webhook, tarefa agendada.
- Não há time para operar infraestrutura e a escala é imprevisível.
- Trata-se de processamento curto, isolado e sem estado.
Custa, e aqui estão os três pontos que mais pegam gente:
1. Cold start. Quando não há instância aquecida, a primeira requisição espera a inicialização. Dependendo da linguagem e do tamanho das dependências, isso vai de dezenas de milissegundos a vários segundos. Para processamento assíncrono, irrelevante. Para API que responde usuário, pode ser inaceitável — e é a reclamação número um de quem adotou sem medir.
2. O custo inverte com volume. Serverless é barato com carga baixa ou esporádica e fica caro quando o tráfego é alto e constante. Existe um ponto de cruzamento em que manter instância ligada sai mais barato que pagar por execução. Descobrir isso pela fatura é a forma cara; calcular antes é a barata.
3. Aprisionamento. Funções se acoplam ao ecossistema do provedor — o formato do evento, os serviços de fila, de autenticação, de armazenamento. Migrar depois é reescrever, não mover. Containers serverless sofrem menos disso, porque a imagem é portável.
E há limites técnicos que eliminam casos inteiros: tempo máximo de execução, tamanho do pacote, conexões persistentes, e o problema de pool de conexões com banco — centenas de instâncias efêmeras abrindo conexão derrubam um banco relacional que não esperava isso.
O comparativo direto
| Inicialização | dezenas de segundos | segundos | ms a segundos (cold start) |
|---|---|---|---|
| Custo com carga baixa | fixo, alto | fixo, médio | quase zero |
| Custo com carga alta constante | previsível | previsível | pode ficar caro |
| Estado local | natural | exige desenho | não |
| Escala automática | lenta | boa | imediata |
| Esforço operacional | alto | médio | baixo |
| Aprisionamento | baixo | baixo | alto (funções) |
| Isolamento | forte | moderado | forte |
O critério que decide
Quatro perguntas, nessa ordem, resolvem a maioria dos casos:
- Tem estado local relevante? Banco, arquivos, sessão em disco → VM.
- A carga é intermitente ou dirigida por evento? → serverless, se o cold start for tolerável.
- A carga é constante e a aplicação é sem estado? → container.
- É legado com dependências estranhas? → VM, e modernize depois se houver motivo.
E uma quinta que vale mais que as outras: o que o seu time consegue operar bem? A melhor arquitetura mal operada perde para a arquitetura mediana bem operada, sempre.
Misturar é o normal
Sistemas maduros usam os três, cada um onde ele ganha:
- Banco de dados em VM dedicada, com storage rápido e alta disponibilidade no nível da virtualização.
- Aplicação em container, escalando horizontalmente.
- Processamento assíncrono em serverless — relatório, miniatura de imagem, notificação, integração disparada por evento.
- Legado em VM, com snapshot e backup, enquanto se decide o futuro dele.
Esse desenho combinado é o que mais vemos funcionar em infraestrutura própria, e ele aproveita o investimento que já existe em virtualização.
Erros comuns
- Adotar Kubernetes sem um sintoma concreto que o justifique.
- Colocar banco de dados em container no cluster sem ninguém que saiba operá-lo.
- Escolher serverless para API sensível a latência sem medir cold start.
- Não calcular o ponto em que serverless fica mais caro que instância ligada.
- Centenas de funções efêmeras abrindo conexão direta no banco.
- Ignorar o aprisionamento de funções até precisar migrar.
- Containerizar legado sem resolver o estado local.
- Escolher pela tecnologia da moda em vez do perfil da carga.
- Ignorar o que o time consegue operar.
Onde a Solvefy/Cloud entra
Essa decisão é uma das primeiras que tomamos junto com o cliente, e frequentemente a recomendação é mais simples do que se esperava. Avaliamos o perfil real da carga, o estado envolvido, o volume e a competência do time, e desenhamos a combinação que entrega o resultado com o menor custo operacional — incluindo o arranjo que mais recomendamos para quem tem infraestrutura própria: aplicação em container e banco em VM dedicada sobre cluster Proxmox com alta disponibilidade. Implantamos, documentamos e transferimos conhecimento.
Não sabe onde a sua aplicação deveria estar rodando? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.