Nem toda a migração para a cloud é uma boa migração. Às vezes, a solução mais simples é a mais correta.
Nota: Este artigo é inteiramente fictício. Todos os nomes de empresas, pessoas e entidades mencionados são inventados e não correspondem a organizações ou indivíduos reais. Qualquer semelhança com situações reais é meramente coincidental. A narrativa foi construída com base em padrões recorrentes observados em projetos de migração tecnológica, com o objetivo de ilustrar os desafios comuns que muitas empresas enfrentam.
Este post foi escrito em parceria com a Aubay Portugal, deixo aqui o link para o blog deles: https://www.aubay.pt/blog
A LusoFicta Foods, Indústria Alimentar, S.A. é uma empresa de produção e distribuição alimentar sediada em Sabrosa, no coração do Alto Douro. O que começou há três décadas como uma exploração agrícola familiar (vinhas e olivais herdados de gerações anteriores) transformou-se, ao longo dos anos, numa operação integrada que cobre toda a cadeia de valor: cultivo, colheita, processamento, embalamento e distribuição de produtos alimentares para o mercado nacional e exportação.
A empresa emprega cerca de 85 colaboradores permanentes, desde os técnicos agrícolas e operadores da unidade de processamento até à equipa administrativa, financeira e de logística. Mas esse número conta apenas uma parte da história. Durante as campanhas de colheita, entre setembro e novembro, a LusoFicta Foods contrata até 200 trabalhadores temporários para a vindima e a apanha da azeitona. Na época de maior volume de processamento e expedição, entre novembro e fevereiro, juntam-se mais dezenas de operadores à linha de produção e motoristas à frota de distribuição. Em pico, a empresa pode ter mais de 300 pessoas no ativo, muitas delas durante poucas semanas, com contratos sazonais, seguros temporários e processamento salarial que não pode atrasar um único dia.
Toda esta operação (gestão de pessoal permanente e temporário, controlo de produção agrícola, rastreabilidade de lotes, gestão de armazéns refrigerados, faturação, expedição, comunicação com a Autoridade Tributária e processamento salarial) era suportada por um sistema de gestão integrado (ERP), instalado num servidor físico que vivia numa pequena sala técnica no edifício administrativo, entre o escritório da contabilidade e a copa.
O servidor não era novo. Na verdade, já tinha sido adquirido em segunda mão quando o ERP foi implementado. Mas funcionava. Todos os meses, os relatórios saíam, os salários eram processados (incluindo os dos temporários, com os seus contratos de duração variável e horas extraordinárias de campanha), as guias de transporte eram emitidas a tempo, e o Sr. Teixeira, fundador e administrador, podia consultar os números da semana no seu computador, com o pequeno-almoço ainda quente.
Até ao dia em que deixou de funcionar. Não o servidor, mas o suporte ao software.
O Upgrade Inevitável
A fabricante do ERP anunciou o fim de vida da versão instalada. Sem atualizações de segurança, sem correções, sem suporte técnico. A LusoFicta Foods precisava de migrar para a versão mais recente ou ficar por sua conta e risco.
Foi contratada uma consultoria especializada para conduzir o processo. Após a avaliação inicial, o diagnóstico foi claro: o hardware existente não cumpria os requisitos mínimos da nova versão. A recomendação era investir num servidor novo antes de avançar com o upgrade.
O Sr. Teixeira ouviu, fez as contas, e decidiu que não era o momento. A empresa vinha de uma campanha difícil. A seca do verão anterior tinha reduzido a produção, as margens estavam apertadas pelo aumento dos custos de energia e combustível, e havia investimentos urgentes na modernização do sistema de rega. Gastar milhares de euros num servidor novo não estava nos planos.
"O servidor atual aguenta. Sempre aguentou." Insistiu o Sr. Teixeira.
A consultoria insistiu. Apresentou os benchmarks, explicou os riscos, detalhou os cenários de falha. Mas a decisão estava tomada. A LusoFicta Foods assinou um termo de isenção de responsabilidade, assumindo os riscos de instalar o novo software em hardware que não cumpria os requisitos mínimos, e o upgrade avançou.
"Está Tudo a Funcionar"
A instalação decorreu sem grandes sobressaltos, e num momento conveniente: estávamos em agosto, o período mais calmo do ano, antes do arranque da campanha de colheita. A nova versão foi configurada, os dados migrados e a validação realizada com dois utilizadores em simultâneo: a D. Conceição, da contabilidade, e o Nuno, dos recursos humanos. Ambos navegaram pelos menus, abriram alguns relatórios, registaram movimentos de teste. Tudo fluido, tudo responsivo.
"Vêem? Funciona perfeitamente." Exclamou um satisfeito Sr. Teixeira, feliz em como a sua visão estratégica afiada tinha feito a empresa economizar milhares de euros, e ainda ter a versão nova da aplicação!
A migração foi dada como concluída. O software antigo foi removido. A consultoria encerrou o projeto, entregou a documentação, e seguiu para o próximo cliente.
O servidor velho continuou ali, entre a contabilidade e a copa, a zumbir baixinho. Como sempre.
O Primeiro Mês de Campanha: A Tempestade
Os problemas não apareceram em agosto, com a empresa em ritmo de férias. Apareceram em setembro, quando a campanha de colheita arrancou e, com ela, o caos.
Em poucas semanas, os 85 colaboradores permanentes transformaram-se em mais de 250. O departamento de recursos humanos, que habitualmente geria um universo estável (mesmo nas campanhas dos anos anteriores, com o sistema antigo), viu-se a registar dezenas de novos contratos temporários por semana, cada um com as suas particularidades: durações diferentes, turnos variáveis, horas extraordinárias de campanha, seguros de trabalho temporários, dados fiscais de trabalhadores que vinham de diferentes regiões e alguns de fora do país. Cada um destes registos passava pelo ERP.
Cada cálculo salarial, cada contribuição para a Segurança Social, cada retenção na fonte dependia de um sistema que agora carregava um peso para o qual não tinha sido dimensionado.
A lista de queixas cresceu rapidamente:
O processamento salarial tornou-se um pesadelo. A D. Conceição, que processava os salários nos primeiros cinco dias úteis de cada mês, viu o que antes demorava uma manhã transformar-se numa maratona de três dias. Com mais de 250 registos ativos (muitos com horas extras, subsídios de alimentação variáveis e contratos de dias) o sistema congelava a meio do cálculo, obrigando-a a recomeçar. Numa empresa onde os trabalhadores temporários dependem daquele pagamento para a semana seguinte, o atraso não era apenas administrativo, era pessoal. Resultado: Pela primeira vez em trinta anos, os salários da LusoFicta Foods saíram com atraso. Um duro golpe no orgulho que o Sr. Teixeira tinha, de nunca atrasar salários de toda aquela gente.
A aplicação caía constantemente. Com os operadores da linha de produção, os técnicos agrícolas, os motoristas e a equipa administrativa todos ligados em simultâneo (facilmente mais de 80 sessões ativas) o servidor atingia o limite de memória e o ERP simplesmente parava de responder. Os motoristas, que registavam as entregas através de terminais portáteis, ficavam bloqueados em plena rota, sem conseguir confirmar as guias de transporte. Os operadores da unidade de processamento não conseguiam registar os lotes em produção, comprometendo a rastreabilidade, um requisito legal para produtos alimentares.
Os relatórios de produção tornaram-se noturnos. Gerar o relatório diário de expedição (essencial para planear as rotas de distribuição do dia seguinte) deixou de ser possível durante o horário de trabalho. Passou a ser executado manualmente, à noite, um de cada vez, pelo único colaborador de TI da empresa, que entrava às 22h para lançar os processos e ficava a vigiar o ecrã até de madrugada. Resultado: Durante o dia, não havia ninguém para prestar suporte aos utilizadores (e ao crescente número de problemas da nova versão da aplicação).
O módulo de faturação tornou-se imprevisível. As faturas demoravam minutos a ser emitidas em vez de segundos. Em dias de maior volume de expedição (e na época alta, a LusoFicta Foods expedia para dezenas de clientes por dia, incluindo cadeias de retalho com janelas de entrega apertadas) o sistema recusava gerar documentos, devolvendo erros de timeout. Os clientes começaram a reclamar de atrasos no envio de faturas e, por consequência, a atrasar os pagamentos. Para uma empresa que precisava de liquidez para pagar a centenas de trabalhadores temporários, isto era mais do que um inconveniente.
As integrações com a Autoridade Tributária falhavam. O envio automático do SAF-T e a comunicação de documentos de transporte começaram a falhar por excesso de tempo de resposta. A empresa recebeu notificações da AT e, com elas, o pânico de uma possível coima, precisamente quando o volume documental era mais elevado.
A rastreabilidade dos lotes ficou comprometida. Com o sistema a perder sessões a meio de registos, começaram a surgir falhas na cadeia de rastreabilidade dos produtos. Num setor alimentar, onde cada lote de azeite, cada caixa de fruta, cada palete de vinho tem de ser rastreável da origem ao destino por exigência regulamentar, isto não era apenas um problema operacional. Era um risco de compliance que podia custar certificações e acesso a mercados de exportação.
O controlo de stock dos armazéns refrigerados tornou-se caótico. Discrepâncias entre o stock físico e o stock no sistema multiplicavam-se. Produtos com prazos de validade curtos eram esquecidos em câmaras frigoríficas porque o sistema não refletia a realidade. Resultado: desperdício alimentar e prejuízo.
A gestão de contratos temporários fugiu ao controlo. O módulo de RH, sobrecarregado, não conseguia processar em tempo útil as entradas e saídas de trabalhadores sazonais. Contratos que deviam ter sido encerrados permaneciam ativos; seguros de trabalho que deviam ter sido ativados não eram processados a tempo. O risco jurídico e laboral acumulava-se silenciosamente.
O Sr. Teixeira já não tomava o pequeno-almoço a olhar para os números da semana. Tomava-o a ouvir queixas e a perguntar-se como é que uma empresa que tinha sobrevivido a secas, geadas e crises de mercado estava agora a ser posta de joelhos por um computador.
A Solução Mágica: A Nuvem
Foi neste contexto de desespero que surgiu uma segunda consultoria, com uma proposta sedutora:
"O vosso problema é o hardware. Mas não precisam de comprar, precisam de migrar para a cloud. Esqueçam servidores, esqueçam manutenção, esqueçam limitações. Na nuvem, tudo é elástico: o sistema escala automaticamente conforme a procura. Em agosto, quando estão em ritmo calmo, pagam menos; em outubro, no pico da campanha com 300 pessoas no sistema, a infraestrutura cresce sozinha e vocês nem notam. Além disso, têm monitorização em tempo real, agendamento de tarefas, backups automáticos, alta disponibilidade..."
A apresentação foi impecável. Slides polidos, gráficos de custos projetados que mostravam uma despesa mensal perfeitamente comportável, promessas de um onboarding rápido e sem dor. A sazonalidade da LusoFicta Foods foi, aliás, o principal argumento de venda: "Porquê pagar o ano inteiro por um servidor dimensionado para o pico, quando na cloud pagam apenas pelo que usam, quando usam?"
O Sr. Teixeira, exausto dos problemas dos últimos meses e a poucas semanas do início da campanha seguinte, disse que sim.
A migração para a cloud foi executada em poucas semanas. O ERP foi transferido para a infraestrutura de um grande fornecedor de serviços cloud, numa abordagem de lift-and-shift, ou seja, o sistema foi movido tal como estava, sem otimização, sem refatoração, sem um dimensionamento cuidadoso dos recursos necessários.
E, para garantir que "nada falhava sem ser detetado", a consultoria ativou todas as opções de monitorização disponíveis... T O D A S: Logs de aplicação, de sistema operativo, de rede, de base de dados, de acesso, métricas de CPU, memória, disco, latência. Tudo era capturado, armazenado e com a cereja no topo do bolo: Alimentado para um pipeline de inteligência artificial que consumia milhares de tokens por hora para analisar os registos em tempo real e disparar alertas customizados.
Cada pico de CPU gerava um alerta. Cada query lenta à base de dados gerava um alerta. Cada sessão expirada gerava um alerta. O telemóvel do colaborador de TI da LusoFicta Foods tornou-se uma máquina de notificações, centenas por dia, a maioria irrelevantes, enterrando os poucos alertas que realmente importavam. No segundo dia, ele já ignorava todos os alertas, eram só ruído.
Mas o sistema funcionava. Rápido, estável, disponível. O Sr. Teixeira voltou a tomar o pequeno-almoço a olhar para os números. A D. Conceição processou os salários dos 280 colaboradores numa manhã. Os motoristas confirmavam guias em segundos. A rastreabilidade dos lotes voltou a funcionar sem falhas. Os relatórios saíam quando eram pedidos, sem filas, sem esperas.
Durante as primeiras semanas, tudo parecia perfeito.
A Fatura
No final do primeiro mês na cloud, chegou a fatura do fornecedor de serviços.
O valor era dez vezes superior ao estimado pela consultoria: Dez vezes, 10x, 1000%
O auto-scaling, que deveria ser a grande vantagem, tinha-se tornado o grande problema. Sem uma configuração cuidadosa de limites, o sistema escalava agressivamente a cada pico de utilização, e numa empresa com centenas de utilizadores em época de campanha, picos são a norma, não a exceção. Cada processamento salarial, cada relatório pesado, cada importação de dados de produção acionava novos recursos que eram cobrados ao minuto.
O armazenamento de logs, que parecia inofensivo na proposta, revelou-se um sorvedouro de custos. Gigabytes de registos acumulados diariamente, retidos sem política de expiração, armazenados em camadas de alta performance em vez de arquivo frio.
E o pipeline de inteligência artificial, aquela funcionalidade premium que prometia "observabilidade inteligente", consumia milhares de tokens por hora, 24 horas por dia, 7 dias por semana, analisando logs que, na sua maioria, não precisavam de ser analisados. O custo da "inteligência" sobre os logs rivalizava com o custo da própria infraestrutura.
Mas havia outro problema que ninguém tinha antecipado, ou que a consultoria tinha convenientemente omitido. Sabrosa não é Lisboa. No interior do Alto Douro, a conectividade à Internet não é fibra simétrica de gigabit. A LusoFicta Foods dependia de uma ligação que, nos bons dias, era aceitável, mas que, em dias de mau tempo, com chuva forte ou vento nas serras, se degradava significativamente. E quando a ligação à Internet falhava, falhava tudo. Sem acesso à cloud, o ERP simplesmente não existia. Não havia modo offline, não havia plano B. Os operadores da unidade de processamento ficavam parados, os motoristas não recebiam guias, a faturação congelava. Numa empresa que dependia de expedir produtos perecíveis dentro de prazos apertados, cada hora sem sistema era prejuízo direto.
Num único dia de temporal (comum no Douro entre outubro e março) a empresa perdeu um dia inteiro de expedição. O Sr. Teixeira calculou o prejuízo e percebeu que aquele único dia de inatividade tinha custado mais do que um mês da prestação do servidor que lhe tinham proposto comprar.
O Sr. Teixeira olhou para a fatura da cloud, olhou para o contabilista, e disse apenas:
"Desliga isso."
O Regresso a Casa
A LusoFicta Foods regressou ao on-premises. Mas desta vez, fê-lo da forma certa.
A decisão não foi tomada por teimosia nem por aversão à tecnologia. Foi tomada porque, finalmente, alguém se sentou com o Sr. Teixeira e fez as contas certas.
A empresa não precisava de cloud. Não precisava de auto-scaling, nem de pipelines de IA sobre logs, nem de infraestrutura elástica distribuída por múltiplas zonas de disponibilidade. A LusoFicta Foods precisava de uma coisa: um servidor novo.
Um servidor corretamente dimensionado para os requisitos da nova versão do ERP, com capacidade para os mais de 300 utilizadores simultâneos dos meses de pico, com espaço em disco para os próximos anos de operação, e com um contrato de suporte e manutenção.
O custo? Significativo, sim, mas finito. O servidor foi adquirido através de um empréstimo bancário, com prestações mensais que a empresa podia comportar. Durante três anos, a LusoFicta Foods teria uma prestação fixa ao banco. Ao fim desses três anos, o servidor estaria pago e o custo mensal desaparecia. Restava apenas o contrato de manutenção, uma fração do que pagavam na cloud.
Na nuvem, o custo seria eterno. Todos os meses, a fatura do fornecedor de serviços cloud estaria lá, e, mesmo otimizada, mesmo com os excessos corrigidos, representaria uma despesa recorrente e permanente que, ao fim de três anos, teria ultrapassado largamente o custo do servidor físico. E continuaria. No quarto ano, no quinto, no décimo. Para sempre.
E o servidor novo não dependia da Internet. Estava ali, no edifício administrativo, ligado à rede interna. Chovesse, ventasse ou caísse a ligação ao mundo, o ERP continuava a funcionar. A D. Conceição processava salários. Os motoristas recebiam guias. Os lotes eram rastreados. A empresa não parava.
A Lição
A história da LusoFicta Foods não é uma história contra a cloud. A cloud é uma ferramenta extraordinária, para quem precisa dela. Empresas com cargas de trabalho verdadeiramente imprevisíveis, startups que precisam de escalar de zero a milhões sem investimento inicial, organizações com equipas distribuídas globalmente, plataformas SaaS que servem clientes em múltiplos fusos horários: para todas estas, a cloud é, frequentemente, a resposta certa.
Mas nem toda a empresa é uma startup. Nem toda a carga de trabalho é imprevisível. Nem todo o problema de performance se resolve com mais infraestrutura. E nem toda a localização tem a conectividade que a cloud exige.
A LusoFicta Foods tinha uma carga de trabalho sazonal, sim, mas previsível. Todos os anos, a campanha começa em setembro e termina em fevereiro. Todos os anos, o pico de pessoal é entre outubro e novembro. Não há surpresas. Não há picos imprevisíveis às três da manhã vindos de utilizadores do outro lado do mundo. Há uma empresa agroindustrial no Douro que, como todas as outras, segue o ritmo das estações.
Não precisava de elasticidade, precisava de capacidade. Não precisava de monitorização com inteligência artificial, precisava de um sistema que funcionasse sem precisar de ser vigiado 24 horas por dia. E não precisava de depender de uma ligação à Internet para que 300 pessoas pudessem trabalhar.
O erro não foi da cloud. O erro foi de diagnóstico.
A primeira consultoria identificou corretamente o problema (hardware insuficiente) mas não conseguiu convencer o cliente a investir. A segunda consultoria vendeu uma solução desproporcionada para o problema real, embrulhada em promessas de modernização e transformação digital. Nenhuma das duas resolveu efetivamente o problema fundamental: a LusoFicta Foods precisava de um servidor novo, e alguém precisava de ajudar o Sr. Teixeira a perceber que esse investimento, ainda que doloroso a curto prazo, era o caminho mais sensato a longo prazo.
Para Reflexão
Antes de migrar para a cloud, pergunte:
Qual é o problema real que estou a tentar resolver? Se a resposta for "o meu hardware é insuficiente", a solução pode ser tão simples quanto comprar hardware novo.
A minha carga de trabalho é verdadeiramente imprevisível? Sazonal não é o mesmo que imprevisível. Se sabe exatamente quando vão chegar os picos, pode dimensionar para eles, uma vez.
A minha localização suporta uma dependência total da Internet? Para empresas em zonas com conectividade limitada ou instável, ter a infraestrutura crítica localmente não é um retrocesso. É resiliência.
Fiz as contas a longo prazo? O custo mensal da cloud pode parecer comportável, até o somar ao longo de três, cinco, dez anos e comparar com o investimento único em infraestrutura própria.
A solução proposta é proporcional ao problema? Um pipeline de IA para analisar logs de uma empresa agroindustrial de 300 pessoas é como usar um drone de vigilância militar para verificar se as uvas estão maduras.
A nuvem não é a resposta para tudo. Às vezes, a resposta é um servidor novo, um empréstimo ao banco e um bom pequeno-almoço com vista para as vinhas, sem preocupações.
E se precisar de ajuda para fazer as contas, ou responder as perguntas, a Aubay está a postos.
Este artigo reflete uma situação inteiramente fictícia. Todos os nomes de empresas, pessoas e entidades são inventados e não correspondem a organizações ou indivíduos reais. A narrativa foi construída com base em padrões recorrentes observados em projetos de migração tecnológica, com o objetivo de promover uma reflexão sobre as decisões de infraestrutura.
Top comments (0)