Cloud pública versus on-premise qual escolher?

Quando uma aplicação crítica falha, quando uma renovação de servidores se aproxima ou quando a factura cloud cresce sem explicação clara, a discussão deixa de ser teórica. A escolha entre cloud pública versus on-premise condiciona custos, segurança, capacidade de resposta e, sobretudo, a continuidade operacional da empresa.

Depois de mais de três décadas a trabalhar com infraestruturas empresariais, vejo um erro repetido: tratar esta decisão como uma comparação entre tecnologia antiga e tecnologia moderna. Não é. Trata-se de decidir onde cada carga de trabalho deve operar, quem assume a responsabilidade diária e qual o risco que a empresa está preparada para gerir.

Cloud pública versus on-premise não é uma escolha ideológica

A cloud pública disponibiliza recursos de computação, armazenamento e serviços geridos através de um fornecedor externo, normalmente cobrados por consumo. Permite activar capacidade depressa, escalar ambientes sem comprar hardware e aceder a serviços avançados que seriam difíceis de manter internamente.

On-premise significa operar os sistemas em infraestrutura própria, instalada nas instalações da empresa ou num datacenter contratado. A organização controla os servidores, a rede, o armazenamento, as configurações e o ciclo de vida do equipamento. Esse controlo pode ser determinante para aplicações legadas, dados sensíveis, requisitos de latência ou processos industriais.

Nenhum dos modelos é automaticamente mais seguro, económico ou simples. Uma plataforma cloud mal desenhada torna-se cara e exposta. Um datacenter local sem monitorização, backups testados e manutenção preventiva torna-se um ponto único de falha. A pergunta certa não é «qual é melhor?». É «qual oferece o nível de serviço, o controlo e o custo total de propriedade adequados a esta carga de trabalho?».

Custos: comparar mensalidades não chega

A cloud pública substitui investimento inicial por despesa operacional. Isto pode ser uma vantagem clara quando há crescimento imprevisível, projectos temporários ou necessidade de lançar rapidamente novos serviços. Em vez de adquirir servidores para um pico de utilização, a empresa consome capacidade durante o período necessário.

Mas o custo mensal da cloud não é sinónimo de custo previsível. Recursos sobredimensionados, ambientes de testes deixados activos, armazenamento sem política de retenção, tráfego de saída e licenças podem criar desvios relevantes. Sem governance activa, etiquetagem de custos e revisão regular do consumo, a factura torna-se difícil de explicar ao CFO.

No modelo on-premise, o investimento inicial é mais elevado. Há servidores, armazenamento, switches, firewalls, UPS, licenças, garantia, energia e espaço físico a considerar. Ainda assim, para cargas estáveis, intensivas e previstas para vários anos, o custo por recurso pode ser inferior ao de uma cloud pública equivalente.

A comparação séria deve considerar um horizonte de três a cinco anos. Inclui aquisição, renovação tecnológica, energia, suporte, administração, conectividade, licenciamento, indisponibilidade potencial e requisitos de disaster recovery. Se a equipa interna não tiver capacidade para operar a plataforma, esse custo também existe, mesmo que não apareça numa proposta de hardware.

Onde a cloud pública tende a fazer sentido

A cloud pública é particularmente eficaz para ambientes com variação de procura, desenvolvimento e testes, portais externos, colaboração, análise de dados ou serviços que beneficiam de componentes geridos. Também permite reduzir o tempo entre uma necessidade de negócio e a disponibilização da infraestrutura.

Contudo, rapidez de aprovisionamento não elimina a necessidade de arquitetura. Redes, identidades, permissões, cópias de segurança, encriptação e recuperação devem estar definidos antes de colocar dados e aplicações em produção.

Onde o on-premise continua a ser competitivo

Sistemas ERP com utilização constante, bases de dados de elevado desempenho, workloads com grande volume de dados e aplicações dependentes de baixa latência são candidatos naturais a infraestrutura local. O mesmo se aplica a organizações que já dispõem de datacenter adequado e equipas capazes de o operar.

O on-premise não significa comprar equipamento e esquecer o assunto durante cinco anos. Exige renovação planeada, manutenção, testes de recuperação e capacidade de monitorização contínua. Sem estes elementos, o controlo transforma-se em responsabilidade não gerida.

Segurança e conformidade: responsabilidade partilhada não é responsabilidade transferida

Na cloud pública, o fornecedor protege a infraestrutura física e os serviços de base. A empresa continua responsável pela configuração das identidades, permissões, dados, máquinas virtuais, aplicações e políticas de retenção. Uma conta privilegiada sem autenticação multifactor ou um bucket de armazenamento exposto podem anular muitas das protecções da plataforma.

Em on-premise, a responsabilidade é ainda mais directa. A organização tem de proteger o perímetro, segmentar a rede, actualizar sistemas, gerir acessos, monitorizar eventos e garantir cópias imutáveis fora do domínio de produção. É um modelo viável, desde que exista disciplina operacional e capacidade técnica para o sustentar.

Para empresas abrangidas pela NIS2, ou que trabalham com clientes exigentes em matéria de segurança, a conversa deve ir além da localização dos dados. É necessário demonstrar gestão de risco, controlo de acessos, resposta a incidentes, continuidade de negócio, cadeia de fornecedores e evidência de operações. A arquitetura escolhida tem de facilitar este governo, não criar mais zonas sem dono.

Desempenho, disponibilidade e recuperação

A proximidade física dos sistemas ainda conta. Uma aplicação que comunica continuamente com máquinas de produção, equipamentos de armazém ou ficheiros pesados pode sofrer com a latência e a dependência da ligação à Internet. Nestes casos, manter processamento local pode proteger a experiência do utilizador e a operação diária.

Por outro lado, a cloud pública permite distribuir serviços por regiões, automatizar escalabilidade e construir cenários de recuperação sem manter um segundo datacenter próprio. Mas a disponibilidade não surge por defeito. Uma máquina virtual numa única zona continua a poder falhar. A alta disponibilidade exige desenho, redundância e testes.

O mesmo princípio aplica-se ao backup. Ter dados na cloud não equivale automaticamente a ter um backup recuperável. É necessário definir o que proteger, por quanto tempo, onde manter as cópias e quanto tempo pode demorar a recuperação. Os objectivos de RPO e RTO devem nascer do impacto no negócio, não de valores genéricos definidos por tecnologia.

O modelo híbrido resolve muitos casos reais

Para a maioria das empresas portuguesas de média dimensão, a resposta raramente está num extremo. Uma arquitetura híbrida permite manter aplicações estáveis ou sensíveis em on-premise, utilizar cloud pública para serviços elásticos e estabelecer uma camada de backup e disaster recovery independente.

Um exemplo frequente: o ERP e os sistemas de ficheiros de grande utilização permanecem num cluster local bem dimensionado; o Microsoft 365 suporta colaboração; cópias de segurança imutáveis são mantidas fora do ambiente de produção; e um plano de recuperação permite repor serviços críticos numa localização alternativa ou em cloud. Não é uma solução intermédia por falta de decisão. É uma forma deliberada de colocar cada componente onde gera mais valor e menos risco.

A complexidade híbrida existe e não deve ser ignorada. Há mais integrações, redes, identidades e contratos a gerir. Por isso, o valor está numa operação unificada, com visibilidade sobre toda a stack e responsabilidades claras quando algo falha.

Um processo de decisão que evita surpresas

Antes de migrar ou renovar, recomendo quatro fases. Primeiro, diagnóstico: inventariar aplicações, dependências, volumes de dados, consumo, riscos e requisitos de continuidade. Segundo, arquitetura: definir o destino de cada workload, as regras de segurança, conectividade, backup e recuperação.

A terceira fase é implementação, com plano de migração, validação técnica, janela de mudança e plano de reversão. A última é operação contínua: monitorização, gestão de capacidade, correcções, revisão de custos, testes de recovery e reporte por SLA contratual.

Este método impede decisões baseadas apenas numa promoção de cloud ou no preço de um servidor. Também dá aos decisores financeiros uma visão mais honesta: custo mensal, investimento inicial, risco operacional e responsabilidades explícitas.

A escolha entre cloud pública e on-premise deve reduzir incerteza, não mudá-la de sítio. Comece pelas aplicações que não podem parar, defina os RTO e RPO que o negócio realmente exige e escolha a arquitetura que a sua equipa consegue operar com controlo. A tecnologia certa é a que continua a funcionar quando deixa de estar no centro da reunião.