Edge computing: processamento na borda para PMEs

O que é edge computing e por que ele voltou ao centro da conversa

Edge computing é o modelo de arquitetura em que o processamento dos dados acontece perto de onde eles são gerados — no chão de fábrica, na loja, no consultório, no rack da filial — em vez de percorrer centenas de quilômetros até um data center central ou uma região de nuvem pública. A ideia não é nova: sistemas industriais processam dados localmente há décadas. O que mudou foi a escala. Câmeras, sensores, leitores, balanças, catracas, PDVs e equipamentos conectados passaram a gerar volumes de dados que simplesmente não compensam trafegar inteiros pela internet.

A conta é direta. Uma única câmera IP em 1080p a 15 quadros por segundo produz algo entre 2 e 4 Mbps de fluxo contínuo. Dez câmeras já consomem mais banda de upload do que a maioria dos links de internet empresarial de PME entrega com folga. Se a intenção é aplicar análise de vídeo — contagem de pessoas, detecção de EPI, leitura de placas —, mandar tudo para a nuvem significa pagar link dedicado, pagar transferência de dados e ainda conviver com falha de análise sempre que o link oscilar. Processar na borda e enviar só o resultado (um evento de 200 bytes em vez de um stream de 3 Mbps) muda completamente a economia do projeto.

Vale dizer o que edge computing não é: não é substituto da nuvem, e não é sinônimo de "servidor local". É uma decisão de topologia — escolher deliberadamente qual etapa do processamento roda perto da origem e qual roda no centro. Na prática quase toda arquitetura de borda bem feita é híbrida: a borda decide em milissegundos, a nuvem consolida, treina modelos, guarda histórico e apresenta relatórios.

Latência: o critério que decide se vale a pena

Latência é o argumento mais citado e o mais mal compreendido. Não se trata de "internet rápida" — trata-se do tempo de ida e volta de uma requisição. Um link de fibra empresarial em São Paulo até uma região de nuvem em São Paulo entrega tipicamente 5 a 15 ms de RTT. Até uma região nos Estados Unidos, 110 a 160 ms. Para carregar uma página, abrir um e-mail ou sincronizar um arquivo, isso é irrelevante. Para um braço robótico, um sistema de visão que precisa reprovar uma peça antes dela sair da esteira, ou um controle de acesso que não pode deixar a catraca travada, 150 ms é a diferença entre funcionar e não funcionar.

A regra prática que usamos ao avaliar um caso é simples: se a aplicação tolera perder o link por 30 minutos sem parar a operação, ela provavelmente não precisa de borda. Se parar, precisa.

Não é a velocidade do link que define a arquitetura — é a consequência de ele cair. Toda decisão de edge computing começa com a pergunta "o que acontece com o negócio nos 40 minutos em que a operadora está com problema?"

Há um segundo eixo, muitas vezes mais determinante que a latência em PMEs: soberania e volume de dados. Regras de LGPD podem tornar preferível manter imagens brutas e dados biométricos dentro do perímetro da empresa, enviando à nuvem apenas metadados anonimizados. E há o custo de egresso — a maioria dos provedores cobra por GB que sai da nuvem. Um pipeline mal desenhado, que sobe vídeo bruto e depois baixa recortes para análise, produz fatura crescente sem nenhum ganho funcional.

Casos de uso reais para empresas de médio porte

Edge computing costuma ser apresentado com exemplos de montadora e porto automatizado, o que afasta a PME da conversa. Os cenários que realmente aparecem no dia a dia são bem mais prosaicos e, justamente por isso, mais viáveis:

• Varejo multi-loja — PDV que continua vendendo, emitindo cupom fiscal e controlando estoque local mesmo com o link caído, sincronizando com o ERP central quando a conexão volta. É o caso clássico de borda: a venda não pode esperar a nuvem.
• Videomonitoramento com analytics — gravação e análise no NVR ou em um servidor local, com envio à nuvem apenas de eventos, clipes curtos e cópia de retenção legal. Reduz banda em uma ordem de grandeza.
• Indústria e logística — coleta de sensores (temperatura, vibração, corrente) com agregação local. Em vez de 1 leitura por segundo por sensor subindo para a nuvem, sobe-se a média por minuto mais qualquer anomalia detectada localmente.
• Clínicas e laboratórios — imagens de diagnóstico têm arquivos grandes e exigência de disponibilidade imediata. PACS local com replicação para nuvem resolve os dois lados.
• Controle de acesso e ponto — catracas e leitores biométricos precisam liberar em menos de um segundo, sempre. A base de credenciais fica replicada na borda; a gestão é central.
• Filiais com aplicação legada — sistemas antigos sensíveis a latência de banco de dados que quebram quando o servidor sai para a nuvem. Manter o motor local e levar backup, monitoramento e DR para a nuvem é o caminho pragmático.

Em todos esses casos o padrão se repete: decisão local, consolidação central. E, quase sempre, um ganho colateral importante — a operação deixa de ser refém da estabilidade da operadora, que é o ponto único de falha mais comum e menos controlável em uma PME brasileira.

O que você precisa ter antes de colocar processamento na borda

A tentação, ao ouvir "processamento na borda", é comprar um servidor e colocá-lo na filial. É exatamente assim que nascem os problemas. Um nó de borda é infraestrutura de produção fora do data center: sem controle de acesso físico decente, sem climatização, sem energia estabilizada e, principalmente, sem gestão remota. Ele vira uma caixa-preta que ninguém atualiza e que quebra num sábado.

Os requisitos mínimos que consideramos inegociáveis em qualquer projeto de borda:

1. Gestão remota real — inventário, patch, monitoramento e acesso remoto fora de banda. Se depende de alguém ir presencialmente para reiniciar, não é arquitetura, é dívida técnica.
2. Backup com cópia fora do site — o nó de borda está no ambiente mais hostil da empresa. Regra 3-2-1 vale aqui com mais força, não menos.
3. Hardening e segmentação — o dispositivo de borda costuma conviver na mesma rede que impressoras, câmeras e IoT sem manutenção. VLAN separada, firewall com política explícita e zero exposição direta à internet.
4. Padronização — mesma imagem, mesma configuração, mesmo agente de gestão em todas as unidades. Dez filiais com dez configurações diferentes é o custo operacional que mata o projeto no segundo ano.
5. Plano de sincronização e conflito — quando o link volta, quem ganha? Definir isso no projeto, não no incidente.
6. Energia — nobreak dimensionado e testado. Queda suja de energia corrompe banco de dados local com uma frequência que surpreende.

Há também uma armadilha de custo. Borda parece barata porque o hardware é modesto, mas o custo real está na multiplicação: dez unidades significam dez ciclos de atualização, dez backups, dez pontos de suporte. O ponto de equilíbrio raramente é técnico — é operacional. Se a empresa não tem quem gerencie isso de forma industrializada, o modelo correto é borda mínima (só o que não pode parar) e todo o resto centralizado.

Como decidir: um roteiro em quatro perguntas

Antes de discutir fornecedor ou hardware, vale rodar um filtro rápido sobre cada carga de trabalho. Primeiro: essa aplicação para o negócio se o link cair por uma hora? Se sim, ela é candidata a borda. Segundo: qual o volume de dados que ela gera por dia e quanto disso é descartável? Vídeo, telemetria e log bruto costumam ter 95% de conteúdo sem valor após processamento — esse é o argumento mais forte para processar localmente.

Terceiro: existe requisito regulatório ou contratual de manter o dado no perímetro? Setores de saúde, jurídico e financeiro frequentemente têm. Quarto: qual o custo de manter esse nó atualizado, monitorado e com backup, multiplicado pelo número de sites? Essa última pergunta reprova mais projetos do que as três primeiras juntas, e é bom que reprove antes da compra, não depois.

O resultado saudável desse exercício quase nunca é "tudo na borda" ou "tudo na nuvem". É um desenho híbrido explícito: uma lista curta de serviços que rodam localmente porque não podem parar, e todo o resto — ERP, e-mail, colaboração, BI, arquivos, DR — consolidado em nuvem, onde a gestão é mais barata e a resiliência já vem pronta.

Como a Duk conduz projetos de borda e nuvem híbrida

Com 18+ anos de estrada e mais de 550 empresas atendidas, a Duk Informática & Cloud construiu a prática de infraestrutura híbrida a partir do problema real das PMEs brasileiras: link instável, equipe de TI enxuta e orçamento que não perdoa erro de dimensionamento. Nosso ponto de partida nunca é o catálogo de produtos — é o mapeamento das cargas de trabalho e a pergunta sobre o que acontece com a operação quando cada uma delas fica indisponível.

Na prática, isso se traduz em um desenho em duas camadas. Na borda, entregamos nós padronizados com gestão remota, monitoramento 24/7 com SLA, patch contínuo, segmentação de rede e backup automatizado com cópia externa — o mesmo padrão em todas as unidades, para que a décima filial custe operacionalmente quase o mesmo que a primeira. No centro, nosso data center próprio em Alphaville e as plataformas Microsoft, onde nossa condição de Microsoft Gold Partner nos permite estruturar identidade, e-mail, colaboração e recuperação de desastre com licenciamento correto e sem surpresa de custo.

Se sua empresa está avaliando levar processamento para a borda — ou desconfia que está pagando nuvem por algo que deveria rodar localmente, ou o contrário — o caminho mais rápido é um diagnóstico da infraestrutura atual: inventário, mapa de dependências, medição real de latência e banda por site, e a conta de custo total por cenário. É a partir desses números, e não de tendência de mercado, que a decisão certa aparece.