Servidor próprio, dedicado ou cloud: como comparar corretamente

A pergunta "onde devo rodar meus sistemas?" costuma ser respondida comparando o preço de um servidor com o preço mensal de uma instância em nuvem. Essa comparação quase sempre engana, porque deixa de fora energia, pessoas, backup, tráfego de saída, licenças e o custo de algo dar errado. Este artigo propõe uma forma mais honesta de comparar as três opções e decidir com base no seu cenário real.

As três opções, sem rótulos de marketing

Antes de comparar custos, vale definir claramente o que cada modelo entrega e o que ele deixa sob sua responsabilidade.

Servidor próprio (on-premises)

A empresa compra o hardware e o instala no próprio ambiente ou em um rack alugado em data center (colocation). Você controla tudo: hardware, hipervisor, rede, sistema operacional. Em troca, assume a reposição de peças, a garantia, a climatização, a energia, o nobreak, o link e a mão de obra para manter tudo funcionando. É comum usar um hipervisor como Proxmox VE ou VMware para consolidar máquinas virtuais.

Servidor dedicado

Um provedor aluga um servidor físico exclusivo, hospedado no data center dele. O hardware e a energia passam a ser problema do provedor, mas o sistema operacional, a virtualização, a segurança e o backup continuam com você, salvo contratação adicional. É um meio-termo: sem investimento inicial em equipamento, mas com responsabilidade operacional quase igual à do servidor próprio.

Cloud pública

Você consome recursos virtuais (computação, armazenamento, banco de dados gerenciado, filas) cobrados por uso. Provedores como AWS, Azure ou Google Cloud oferecem elasticidade e serviços gerenciados que eliminam parte do trabalho operacional. Em contrapartida, o modelo de cobrança é granular e tem componentes que costumam surpreender, como tráfego de saída, IOPS provisionado, snapshots e endereços IP públicos.

Por que comparar só o preço da máquina engana

O preço de um servidor é um custo de capital que se dilui ao longo da vida útil. O preço de uma instância é um custo operacional recorrente. Comparar um com o outro diretamente mistura grandezas diferentes. Além disso, cada modelo esconde custos em lugares distintos:

• No servidor próprio, o custo escondido está em energia, refrigeração, peças de reposição, tempo da equipe e no risco de ficar parado esperando uma peça.
• No dedicado, está em tudo que o provedor não inclui: backup externo, painel de gerenciamento, IPs adicionais, suporte com tempo de resposta definido.
• Na cloud, está no consumo variável: tráfego de saída, armazenamento de snapshots, logs retidos, recursos esquecidos ligados e serviços gerenciados cobrados por requisição.

A comparação correta é feita pelo custo total de propriedade (TCO) em um horizonte definido, normalmente o ciclo de vida esperado do hardware, somando todos os componentes e o custo de risco.

Componentes do custo total (TCO)

A tabela abaixo organiza onde cada componente aparece em cada modelo. Ela não traz valores porque eles variam por região, volume, contrato e momento. Preços de cloud, em particular, dependem do provedor e mudam com frequência; simule sempre no calculador oficial de cada um.

Dois pontos merecem atenção especial. Primeiro, o custo de pessoas costuma ser o maior e o mais subestimado em qualquer modelo; cloud não elimina a necessidade de gente qualificada, só muda o perfil. Segundo, o egress pode inverter a conta para aplicações que entregam muito dado para fora, como distribuição de arquivos, backups replicados para outro provedor ou integrações com alto volume.

Critérios além do custo

Mesmo com um TCO bem feito, a decisão depende de fatores que não aparecem na planilha.

Perfil de carga

Cargas estáveis e previsíveis, rodando 24 horas por dia com uso constante, tendem a favorecer hardware próprio ou dedicado, pois você paga uma vez por uma capacidade que será efetivamente usada. Cargas com picos sazonais, ambientes de teste que podem ser desligados e projetos com demanda incerta tendem a favorecer a cloud, onde é possível pagar apenas pelo que se usa.

Latência e localização

Sistemas que conversam intensamente com equipamentos locais, como ERP com coletores, servidores de arquivos para estações ou integrações com automação industrial, podem sofrer com latência e dependência do link quando movidos para fora. Nesse caso, a disponibilidade do link passa a ser parte da disponibilidade do sistema.

Requisitos de dados e conformidade

A LGPD não proíbe nuvem, mas exige que você saiba onde os dados estão, quem os acessa e como são protegidos. Alguns contratos e setores impõem requisitos de localização ou auditoria que restringem as opções. Verifique isso antes de comparar preços.

Capacidade da equipe

Um ambiente on-premises sem ninguém para monitorar discos, aplicar atualizações e testar backup é um risco, não uma economia. Uma conta de cloud sem governança de custos e acessos tende a crescer sem controle.

Continuidade: o custo que ninguém coloca na planilha

Todo modelo pode falhar. A pergunta útil é: quando falhar, quanto tempo leva para voltar e quanto dado se perde? Esses são o RTO (tempo de recuperação) e o RPO (ponto de recuperação). Defina-os por sistema antes de escolher a infraestrutura.

• Servidor próprio sem redundância depende de peça em estoque ou entrega do fabricante; um único host é um ponto único de falha.
• Dedicado depende do tempo de troca de hardware do provedor e do seu backup externo.
• Cloud oferece mecanismos de alta disponibilidade entre zonas, mas eles precisam ser projetados e pagos; uma instância única em uma zona continua sendo um ponto único de falha.

Em todos os casos, backup que nunca foi restaurado em teste não é backup confiável. A regra 3-2-1 (três cópias, duas mídias diferentes, uma fora do local) continua válida, e na cloud ela inclui considerar uma cópia fora da mesma conta ou do mesmo provedor.

Modelos híbridos são frequentemente a resposta

Raramente a melhor resposta é colocar tudo em um único lugar. Combinações comuns e sensatas incluem:

• Produção estável em hardware próprio ou dedicado, com backup e recuperação de desastre na cloud.
• Sistemas legados e dependentes de rede local on-premises, com novas aplicações web na cloud.
• Ambiente principal na cloud, com cópias de backup em outro provedor ou em armazenamento local.

O híbrido adiciona complexidade de rede e de identidade, que precisa ser planejada, mas costuma equilibrar melhor custo, risco e desempenho.

Checklist para a sua comparação

Use esta lista para garantir que a análise está completa antes de decidir:

• Inventário de sistemas com uso real de CPU, memória, disco e rede, não apenas o provisionado.
• RTO e RPO definidos por sistema, aprovados pela área de negócio.
• Horizonte de análise definido, alinhado à vida útil esperada do hardware.
• Todos os componentes da tabela de TCO preenchidos para cada opção.
• Estimativa de tráfego de saída mensal, incluindo backups e integrações.
• Simulação nos calculadores oficiais dos provedores de cloud considerados, com data registrada.
• Licenças revisadas quanto à portabilidade entre ambientes.
• Responsáveis definidos para operação, segurança, backup e custos.
• Plano de saída: como migrar de volta ou para outro provedor, se necessário.
• Teste de restauração previsto no cronograma, não apenas a configuração do backup.

Como a Trihelix pode ajudar

A Trihelix apoia empresas no levantamento do ambiente atual, na montagem de uma comparação de TCO com os componentes que fazem sentido para o seu caso e no desenho da arquitetura escolhida, seja on-premises, dedicada, cloud ou híbrida. Também implementamos virtualização, backup e planos de recuperação, com testes de restauração documentados. Não existe resposta única, e nossa recomendação parte dos seus números e requisitos. Veja mais em Cloud e continuidade ou fale com a Trihelix.