Por Flank Manoel da Silva Especialista Sênior Full Stack | Analista de Infraestrutura e Performance
Existe uma conversa que acontece em todo projeto de migração para edge computing. Alguém abre um deck, mostra o gráfico de latência, 500ms na nuvem centralizada, 80ms na borda e a sala concorda em seguir em frente. O número seduz. Quarenta, cinquenta, às vezes duzentos milissegundos a menos na resposta. É o tipo de melhoria que aparece bonita em qualquer apresentação de resultados.
O que não aparece nessa mesma planilha é o custo de manter aquele ganho funcionando continuamente, em escala, com equipes finitas, dentro de janelas de manutenção reais. Não aparece o que acontece quando um rollback precisa ser executado em 1.200 nós simultâneos às 23h de uma sexta-feira. Não aparece o custo mensal de observabilidade quando o volume de telemetria escala linearmente com cada novo nó adicionado à frota. E definitivamente não aparece a pergunta mais importante: quanto custa, em tempo de recuperação e em nervo operacional, cada novo ponto de falha que você criou ao distribuir a computação?
Este artigo existe para preencher essa lacuna. A premissa é direta: reduzir 40ms de latência pode dobrar a superfície de falha operacional. E esse trade-off raramente é medido com a mesma seriedade que o ganho de performance.
A ilusão do ganho líquido: como o TCO real do Edge se distancia do projetado
Antes de qualquer discussão técnica, vale entender a estrutura de custos que a maioria das organizações subestima ao projetar uma migração para edge.
O IDC estimou que os gastos globais com edge computing atingiram US$ 232 bilhões em 2024, um crescimento de 15% sobre o ano anterior. Esse número, por si só, não revela nada sobre eficiência. Revela apetite. E apetite sem disciplina operacional produz dívida técnica disfarçada de modernização.
O erro mais comum não está na decisão de ir para a borda, essa decisão, em muitos contextos, é tecnicamente correta. Está no modelo de custo que acompanha essa decisão. As equipes calculam CAPEX de hardware, licenças de software, custo de conectividade. Raramente calculam com precisão o que o setor chama de custo operacional de segunda ordem: a sobrecarga humana e sistêmica de manter uma frota distribuída saudável.
O que a planilha captura vs. o que ela ignora
| Categoria | Capturado no modelo inicial | Frequentemente omitido |
|---|---|---|
| Hardware de nó edge | Sim | Custo de substituição em campo, logística reversa |
| Conectividade | Sim (estimado) | Custo de failover, links redundantes, SIM management |
| Software/licenças | Parcialmente | Custo por nó de ferramentas de observabilidade |
| Deploy inicial | Sim | Custo de rollout incremental em fleets de 500+ nós |
| Observabilidade | Raramente | Volume de telemetria × custo/GB × número de nós |
| Rollback | Quase nunca | MTTR por incidente × frequência × custo-hora da equipe |
| Configuration drift | Nunca | Tempo de auditoria, divergência acumulada entre nós |
| Treinamento de equipe | Estimado | Curva de aprendizado específica para ops distribuído |
O problema com as colunas omitidas não é que são imprevisíveis, é que são sistemáticas. Elas crescem com a frota. Cada novo nó edge é uma nova instância do mesmo custo marginal oculto.
Deploy em escala: o que muda quando você tem 50 nós vs. 5.000
- Cenário A: deploy centralizado com pipeline convencional
Em uma arquitetura centralizada, digamos, uma aplicação rodando em três zonas de disponibilidade em um único provedor de nuvem, um deploy segue um padrão razoavelmente previsível. O time usa um pipeline de CI/CD, executa testes de smoke, faz blue-green ou canary deployment, e tem visibilidade imediata sobre o estado da aplicação. Se algo der errado, o rollback é uma operação de minutos. O blast radius de um deploy ruim é geograficamente contido e tecnicamente revertível.
O MTTR médio em ambientes com maturidade de observabilidade tende a ser medido em minutos ou horas. O State of Observability 2024 da Splunk mostrou que times com práticas maduras de observabilidade têm 2,3x mais probabilidade de medir MTTR em minutos, não em dias. Esse benchmark faz sentido em arquiteturas centralizadas porque o volume de variáveis controlado é manejável.
- Cenário B: deploy em frota edge distribuída
Agora projete o mesmo exercício para uma rede de 2.000 nós distribuídos, lojas de varejo, plantas industriais, pontos de presença urbanos. O deploy não é um evento. É uma campanha.
Primeiro, os nós não são homogêneos. Firmware diverge. Conexões de rede variam de fibra a 4G com latência instável. Hardware pode ter gerações diferentes com capacidade diferenciada. Segundo, a janela de manutenção não é global, cada localidade tem restrições operacionais próprias. Terceiro, e mais crítico: a capacidade de observar o estado real de cada nó durante e após o deploy é fundamentalmente diferente do que em nuvem centralizada.
Uma pesquisa publicada pela ScienceDirect mostrou que a taxa de falha em frotas edge sobe gradualmente conforme o número de dispositivos aumenta: de 1,02% em 100 dispositivos para 2,6% em 2.000 dispositivos. Isso não parece dramático até que você faça a conta: em uma frota de 2.000 nós, 2,6% de falha de deploy significa 52 nós em estado indeterminado ou degradado após cada atualização. Se cada incidente de campo custa 3 horas de resposta remota mais eventual visita presencial, o custo operacional de um único ciclo de deploy já supera facilmente o valor do ganho de latência obtido.
O problema do configuration drift
Existe um fenômeno que qualquer engenheiro que operou frota edge em produção reconhece imediatamente: o configuration drift. Com o tempo, os nós de uma frota acumulam divergências, um patch aplicado parcialmente aqui, uma variável de ambiente diferente ali, uma versão de biblioteca que não foi atualizada porque o nó estava offline durante o rollout. O resultado é que, progressivamente, nós que deveriam ser funcionalmente idênticos passam a ter comportamentos sutilmente diferentes.
Em arquitetura centralizada, drift é um problema gerenciável: a infraestrutura como código (IaC) e os pipelines de CD atuam continuamente para reconciliar o estado declarado com o estado real. Na borda, a capacidade de reconciliação depende de conectividade estável, que é exatamente o recurso mais escasso nos contextos em que edge faz mais sentido.
O Cisco Unified Edge Design Guide aponta explicitamente para isso: “Proven policy-based templates eliminate configuration drift”, o que implicitamente confirma que, sem esse controle, drift é o estado padrão, não a exceção.
Observabilidade na borda: o custo que cresce sem você perceber
Em uma arquitetura centralizada, o custo de observabilidade é relativamente previsível. Você tem métricas, logs e traces fluindo para um destino central, e o custo escala com o volume de dados. O problema é gerenciável porque a topologia é simples: poucos serviços, muitas instâncias, ambiente homogêneo.
Na borda, a equação muda em três dimensões simultaneamente:
A primeira é o volume por nó. Cada nó edge gera sua própria telemetria, métricas de hardware (temperatura, CPU, memória), métricas de aplicação, logs de sistema, eventos de rede. Multiplicado por 500 ou 5.000 nós, o volume de dados de observabilidade pode crescer 30 a 50% ao ano, de acordo com dados do setor de monitoramento.
A segunda é a latência e conectividade variável. Diferente de um data center onde a rede é controlada, nós edge frequentemente operam em links não gerenciados. Isso significa que a telemetria pode chegar atrasada, fora de ordem ou simplesmente não chegar. Sistemas de observabilidade desenhados para ambientes centralizados falham silenciosamente nesses cenários, o que é, paradoxalmente, o pior tipo de falha possível para uma ferramenta de diagnóstico.
A terceira é o custo de vendor lock-in em ferramentas de observabilidade. Pesquisa da Apica mostrou que organizações que não gerenciam ativamente sua estratégia de telemetria podem ver o custo de observabilidade dobrar enquanto a infraestrutura cresce 50%. O modelo de precificação linear das plataformas tradicionais, cobrado por volume ingerido ou por host, torna frotas edge desproporcionalmente caras de monitorar. Uma frota de 1.000 nós pode gerar custos de observabilidade comparáveis a um cluster cloud de 10x o tamanho em custo de compute.
O paradoxo da observabilidade distribuída
Aqui está a nuance que poucos reconhecem antes de experimentar: a borda precisa de mais observabilidade, não menos, exatamente porque o ambiente é menos controlado. Mas o custo de obter essa observabilidade destrói parte do benefício econômico que justificou ir para a borda.
O survey 2024 da CNCF sobre MTTR é revelador nesse ponto: 82% dos profissionais de TI relataram que o MTTR está aumentando em suas organizações pelo terceiro ano consecutivo. O motivo principal identificado é a complexidade crescente dos ambientes monitorados e ambientes distribuídos com nós edge são o epítome dessa complexidade.
A implicação prática é que times que migram para edge sem recalibrar sua estratégia de observabilidade não apenas pagam mais pela ferramenta, eles ficam mais cegos, não mais informados. Um nó em estado degradado que não reporta sua condição corretamente é pior operacionalmente do que um nó inexistente.
Rollback na borda: a operação que ninguém ensaia
Em arquitetura centralizada, rollback é um exercício técnico bem definido. Você mantém a versão anterior da imagem, tem controle sobre o ambiente de execução, e pode reverter em minutos com um comando. O ambiente não te resiste.
Na borda, rollback envolve variáveis que a arquitetura centralizada nunca precisa considerar:
Conectividade parcial: Um rollback orquestrado para 2.000 nós pode completar em 1.800 deles e falhar silenciosamente nos outros 200, que continuam rodando a versão com bug, criando um estado híbrido de fleet que é o pesadelo operacional de qualquer SRE.
Estado local: Muitos workloads edge mantêm estado local (cache, dados de sessão, filas de processamento). Rollback da aplicação não necessariamente implica rollback do estado, o que pode criar inconsistências entre versão de software e dados que ela gerou.
Autonomia desconectada: Se um nó está processando dados offline quando o rollback é disparado, ele pode completar o rollback, reiniciar, e perceber que os dados locais são incompatíveis com a versão para a qual reverteu. O resultado é um nó que não consegue subir e que está fisicamente em algum lugar difícil de acessar.
Tempo de propagação: Em nuvem, rollback propaga em segundos ou minutos. Em frota edge com links lentos ou instáveis, o rollback pode levar horas para completar, período durante o qual você tem simultaneamente múltiplas versões da aplicação em produção, servindo usuários diferentes.
O Blast Radius aumenta exponencialmente com a distribuição
O conceito de blast radius, o alcance do impacto de uma configuração ruim ou falha de sistema é bem entendido em SRE centralizada. Estratégias como canary releases, blue-green deployments e feature flags existem especificamente para conter o blast radius.
Na borda, o blast radius tem uma propriedade adicional: ele pode ser geograficamente localizado mas operacionalmente invisível. Um bug que se manifesta apenas em nós com determinado hardware ou em determinada condição de rede pode afetar uma região inteira antes que a equipe de operações entenda o padrão. A janela de diagnóstico é maior, a contenção é mais difícil, e o custo de cada hora de operação degradada multiplica pelo número de usuários afetados em cada nó comprometido.
Dois fluxos de trabalho, dois mundos: análise comparativa de cenários reais
- Cenário de uso A: varejo com 300 lojas e processamento de pagamento local
Uma rede de varejo com 300 lojas decide mover o processamento de pagamento para edge com o objetivo de continuar operando durante quedas de conectividade e reduzir latência de aprovação de 800ms para 120ms. O caso de negócio é sólido.
Doze meses depois, o cenário operacional revela o que a planilha não capturou:
Cada atualização de versão do sistema de pagamento, obrigatória por compliance a cada trimestre, exige um rollout coordenado para 300 nós. Com janelas de manutenção restritas (horário de fechamento da loja), o rollout leva em média 11 dias para completar. Durante esse período, o fleet opera com duas versões simultâneas, e os relatórios consolidados precisam reconciliar diferenças de formato entre versões.
A observabilidade de cada PDV edge gera aproximadamente 2,4GB de logs por mês. Para 300 lojas, são 720GB mensais apenas em logs de POS. Adicionando métricas de sistema e traces de transação, o volume total de telemetria do fleet supera 2TB mensais, com custo de ingestão em plataformas tradicionais que não foi previsto no modelo inicial.
A taxa de incidentes por nó é de aproximadamente 1,8% por mês, pequena individualmente, mas representando cerca de 5 lojas com algum problema de operação em qualquer semana. Cada incidente remoto consome em média 2,5 horas de engenharia, mais eventual envio de técnico presencial estimado em 4 horas adicionais.
O ganho de latência foi real. O custo de manter esse ganho foi 40% superior ao projetado.
- Cenário de Uso B: processamento de vídeo industrial com 50 câmeras em planta
Uma planta industrial instala processamento de visão computacional em edge para análise de qualidade em tempo real. Cinquenta câmeras, cinquenta nós de processamento, latência de inferência de 30ms versus os 200ms anteriores na nuvem. O resultado de qualidade melhora 23% na detecção de defeitos.
Aqui, o perfil operacional é diferente e mais favorável. A planta é um ambiente controlado, com rede interna gerenciada, pessoal técnico presente 24 horas, e hardware homogêneo. O fleet é pequeno o suficiente para gerenciamento quase manual. A observabilidade é local, com dashboards na própria rede da planta.
Nesse cenário, edge não apenas faz sentido técnico, faz sentido operacional. O custo de manutenção é proporcional ao ganho. O blast radius de qualquer incidente é limitado à planta. O rollback pode ser feito manualmente se necessário.
A diferença entre o Cenário A e o Cenário B não é a tecnologia. É a escala, a heterogeneidade do ambiente e a presença, ou ausência, de pessoal técnico próximo aos nós.
A equação de trade-off que precisa ser formalizada
Existe uma forma de estruturar esse trade-off de maneira que seja comparável e comunicável. O custo operacional incremental de uma arquitetura edge pode ser aproximado pela seguinte lógica:
Considere que cada nó edge adiciona ao custo total: o custo fixo de observabilidade por nó (C_obs), a probabilidade de incidente por período (P_inc) multiplicada pelo custo médio de resolução (C_res), e o custo de participação em cada ciclo de rollout (C_deploy) multiplicado pela frequência de deploys (F_deploy).
O que torna essa equação traiçoeira é que C_obs e C_res não são constantes. C_obs tende a crescer com o volume de telemetria e com a sofisticação da análise necessária conforme o fleet envelhece. C_res tende a crescer com a complexidade do estado acumulado em cada nó, quanto mais tempo um nó opera em produção, mais estado local ele acumula, e mais complexo se torna qualquer diagnóstico ou intervenção.
Matriz de decisão: quando edge vale a complexidade
Uma forma prática de avaliar se o trade-off favorece edge ou centralizado em um dado contexto:
| Fator | Favorece Edge | Favorece Centralizado |
|---|---|---|
| Latência crítica | < 50ms obrigatório | 100–500ms aceitável |
| Conectividade local | Instável ou cara | Estável e abundante |
| Tamanho do fleet | < 200 nós | > 500 nós sem automação madura |
| Homogeneidade de hardware | Alta | Baixa (múltiplas gerações) |
| Pessoal técnico local | Presente | Remoto |
| Frequência de deploy | < 1x/mês | > 1x/semana |
| Dados processados | Gerados localmente, alta volume | Dados externos, volume moderado |
| Compliance de dados | Requer localidade | Centralizado aceitável |
O uso dessa matriz não garante a decisão correta, mas força a conversa sobre os fatores que normalmente ficam fora da análise inicial.
O que SREs experientes sabem e raramente colocam em apresentações
Existe um conhecimento tácito entre engenheiros que operaram frotas edge em produção por mais de 18 meses. É o tipo de conhecimento que não aparece em documentação técnica nem em posts de marketing.
O primeiro é que a complexidade do fleet não escala linearmente com o número de nós, ela escala com o número de estados únicos possíveis do fleet. Dois nós com versões diferentes, configurações diferentes, e históricos de uptime diferentes representam uma combinação de estado que é virtualmente impossível de testar com antecedência. À medida que o fleet cresce, o espaço de estados possíveis cresce exponencialmente, e a confiança operacional diminui proporcionalmente.
O segundo é que o conceito de “nó saudável” é mais difuso na borda do que em nuvem. Um nó que está respondendo a health checks pode ter disco perto do limite, temperatura elevada, ou uma versão de dependência levemente incompatível que só se manifestará sob carga específica. Essas condições de falha latente são invisíveis para ferramentas de observabilidade mal configuradas e são exatamente o tipo de problema que gera incidentes em horário de pico.
O terceiro e talvez o mais contraintuitivo, é que a automação que deveria simplificar a operação de frota edge frequentemente cria uma nova camada de complexidade. Um sistema de auto-healing que detecta nós degradados e tenta remediação automática pode, em determinadas condições, criar loops de reinicialização que tornam o nó inacessível por horas. Automação incorreta em escala é amplificada pelo número de nós que ela afeta simultaneamente.
A pergunta que deveria ser feita antes do commit
Antes de qualquer decisão de migrar para edge, existe uma bateria de perguntas operacionais que deveria ser tão rigorosa quanto a análise técnica de latência:
Qual é o MTTR esperado para os três tipos de incidente mais prováveis, falha de hardware, bug de aplicação, e falha de rede, em cada nó individual? E qual é a estratégia de contenção para cada um?
Como será executado o rollback de emergência para 100% do fleet dentro de uma janela de 2 horas? Essa operação foi testada em ambiente que simula conectividade parcial?
Qual é o custo mensal de observabilidade projetado para o fleet completo, incluindo custo de ingestão, armazenamento de séries temporais e retenção de logs por 30, 90 e 365 dias? Esse número foi validado com as ferramentas reais que serão usadas?
Como será detectado configuration drift entre nós? Com que frequência a auditoria de conformidade será executada? Qual é o custo humano desse processo?
Se um nó em campo não consegue completar um rollback e fica em estado inoperante, qual é o processo de recuperação? Qual é o SLA para esse cenário?
Essas perguntas raramente aparecem nos documentos de decisão de arquitetura. Quando aparecem, frequentemente revelam que a capacidade operacional da organização não está dimensionada para o modelo que está sendo proposto.
Onde a arquitetura distribuída faz sentido e onde não faz
Em seu melhor cenário, edge computing resolve um problema genuíno de forma elegante: processa dados onde eles são gerados, reduz a dependência de conectividade para operações críticas, e entrega latência que arquiteturas centralizadas simplesmente não conseguem atingir. Para aplicações de controle industrial, veículos autônomos, sistemas de visão computacional em ambientes controlados, e processamento local de dados sensíveis, edge é a resposta correta.
A partir de um estudo publicado na ScienceDirect sobre manutenção preditiva, sistemas edge conseguem prevenir 85–90% das falhas de início rápido que sistemas cloud perdem por latência. Esse é o tipo de resultado que justifica a complexidade operacional.
O caso do híbrido que é frequentemente a resposta mais honesta
Para a maioria das organizações que não opera em condições extremas de latência ou conectividade, a arquitetura mais defensável não é nem puramente centralizada nem puramente distribuída. É uma arquitetura híbrida que coloca na borda apenas o que é estritamente necessário estar lá, e mantém centralizado o que pode ser centralizado.
Esse modelo tem uma vantagem operacional específica: ele minimiza o número de nós que precisam de operações sofisticadas de ciclo de vida. Quanto menor o fleet edge, menor a sobrecarga de observabilidade, menor a complexidade de rollout, e menor a superfície de configuração que pode divergir. O ganho de latência pode ser menor do que em uma arquitetura totalmente distribuída, mas o custo de manutenção é radicalmente mais controlado.
A métrica que falta: custo por milissegundo ganho
No fim, o debate entre centralizado e edge deveria ser conduzido por uma métrica que raramente aparece em análises: o custo operacional por milissegundo de latência reduzido.
Se uma arquitetura edge reduz 40ms de latência e adiciona US$ 80.000 anuais em custos operacionais, observabilidade, operações de fleet, incidentes adicionais, overhead de deploy, então cada milissegundo ganho custa US$ 2.000 por ano. Esse número, comparado com o valor de negócio gerado pelos 40ms de redução, é o trade-off real.
Esse cálculo é difícil de fazer com precisão antes da implementação. Mas é exatamente esse tipo de estimativa que diferencia uma decisão de arquitetura madura de uma decisão baseada em um número bonito de latência em um slide.
A latência reduzida é real. O valor dela também pode ser real. Mas o custo de manter esse valor funcionando, medido com a mesma rigorosidade com que se mede o ganho de performance, raramente aparece na planilha de decisão.
Até aparecer, o projeto vai custar mais do que foi prometido e a equipe de operações vai saber o porquê antes do primeiro post-mortem.
