VM ou Serverless? A diferença real entre subir um servidor e subir código na nuvem

Se você já trabalhou com suporte, infraestrutura ou operações, provavelmente já viveu aquele momento clássico: alguém pede “um servidor novo”, você cria a máquina, configura rede, abre porta, instala dependências, ajusta permissões e, no fim, ainda precisa ficar de olho para ver se tudo continua saudável depois que entra em produção. Esse fluxo é tão normal que muita gente acha que “usar nuvem” é simplesmente fazer isso dentro do portal da AWS ou do Azure.

Mas existe uma virada de chave aqui. Porque subir uma máquina virtual na nuvem é, no fundo, a mesma mentalidade do datacenter, só que com mais velocidade e mais opções. Você continua trabalhando com o conceito de servidor, com recursos fixos e com a responsabilidade de manter aquele ambiente funcionando.

É aí que entra o Serverless. E o nome engana um pouco, porque não significa “sem servidor”. Significa que você não precisa pensar nele. No Serverless, ao invés de subir infraestrutura para rodar uma aplicação, você sobe a própria lógica, ou seja, o código, e deixa a nuvem decidir como aquilo vai ser executado por trás. É exatamente a proposta do Azure Functions e do AWS Lambda.

Quando você sobe uma VM, você está alugando um computador completo na nuvem. Você escolhe CPU, memória, disco, rede e sistema operacional. Na prática, isso te dá um nível de controle enorme, só que junto com ele vem o pacote completo de responsabilidades. Você precisa cuidar de atualizações, segurança do sistema, disponibilidade do serviço, monitoramento, tuning de performance e, muitas vezes, escalabilidade. Mesmo que use automação, ainda existe um custo operacional real, porque a VM não é só um “recurso”, ela vira um compromisso.

E tem mais um detalhe importante: a VM geralmente é cobrada pelo tempo em que está ligada. Mesmo que esteja parada, mesmo que esteja rodando com pouca carga, você está pagando por aquele recurso reservado. É excelente quando você tem um serviço constante, previsível, que roda 24 horas por dia e precisa de controle total do ambiente. Só que pode virar desperdício quando o consumo é irregular.

Já no Serverless, a lógica é diferente. Você publica uma Function ou uma Lambda, define o gatilho, por exemplo, uma requisição HTTP, uma fila, um evento de armazenamento, e pronto. Quando o evento acontece, a nuvem executa sua função, entrega o resultado e encerra. O custo costuma estar ligado à execução, ao tempo de processamento e à quantidade de chamadas. Na prática, isso muda o jogo, porque você não paga por uma máquina “existindo”, você paga por trabalho sendo feito.

Esse modelo traz uma sensação muito boa de velocidade e simplicidade. Você para de perder tempo com o “antes”, e foca no que realmente entrega valor: a automação, a integração, a regra de negócio, o processamento, o retorno. É como sair da necessidade de montar uma estrutura inteira para cada pequena necessidade e começar a plugar peças inteligentes que executam exatamente o que você quer, na hora que você quer.

Só que aqui vem a parte madura da conversa: Serverless não é mágico, e nem sempre é a melhor escolha.

O mundo das VMs é estável e previsível, especialmente quando você precisa de aplicações longas, com processos contínuos, com grande dependência de estado, com bibliotecas pesadas ou com requisitos específicos de sistema operacional. Se você precisa de algo rodando o tempo todo, com controle fino e customização total, a VM continua sendo uma solução muito forte.

No Serverless, por outro lado, você entra em um estilo de arquitetura que pede funções pequenas, bem definidas e preferencialmente stateless. Como essas execuções sobem e descem sob demanda, você precisa assumir que aquele ambiente pode ser recriado a qualquer momento. Isso obriga boas práticas e também exige que você pense mais em integrações, observabilidade e desenho do fluxo.

Outro ponto que aparece rápido na prática é o famoso “cold start”, que é quando a nuvem precisa iniciar o ambiente de execução do zero porque não havia nada pronto naquele momento. Dependendo da linguagem, do tamanho do pacote e da configuração, isso pode impactar latência. Em cenários sensíveis, como APIs ultra rápidas, isso vira um ponto técnico que você precisa conhecer para decidir com clareza.

E existe ainda um custo invisível que pouca gente comenta no início: a complexidade do ecossistema. Quando você sobe uma VM, boa parte do “mundo” está dentro dela. Quando você trabalha com Serverless, normalmente você se apoia em vários serviços ao redor: fila, API gateway, eventos, armazenamento, permissões e logs distribuídos. A execução fica simples, mas a arquitetura pode ficar mais fragmentada. Se você não tiver organização e padrão, vira bagunça rápido.

No fim das contas, a diferença real entre VM e Serverless não é só técnica. É mentalidade.

VM é como alugar um apartamento. Você tem o espaço inteiro, faz do seu jeito, mas precisa cuidar de tudo: limpeza, manutenção, contas e estrutura. Serverless é como usar um serviço por demanda. Você consome só quando precisa, escala com facilidade e foca no resultado, mas aceita regras do serviço e perde parte do controle.

E é exatamente por isso que entender esse contraste te coloca um nível acima. Porque muita gente aprende a “criar recurso na nuvem”. Pouca gente aprende a escolher conscientemente o modelo certo para cada tipo de problema.

Se a sua meta é crescer em Cloud, o melhor caminho não é “decorar serviço”. É dominar essas decisões. Saber quando VM é a escolha segura e quando Functions e Lambda fazem você entregar mais rápido, com menos custo e menos operação.

No final, nuvem de verdade não é sobre subir servidor. É sobre construir soluções melhores. E quando você entende a diferença entre infraestrutura tradicional e Serverless, você deixa de ser alguém que “configura ambiente” e começa a ser alguém que desenha sistemas com visão de futuro.

Conclusão: VMs continuam essenciais e imbatíveis em muitos cenários, principalmente quando controle e estabilidade são prioridade. Mas Serverless é a ponte perfeita para escala automática, custos eficientes e entrega rápida, desde que você saiba lidar com as regras do jogo. Quem domina os dois modelos não fica preso em ferramenta, escolhe com estratégia e cresce muito mais rápido na área.