Técnico

De retransmissores de nuvem a orquestradores de ponta: escolhendo sua arquitetura de IoT

March 4th, 2026

Leonel Barragán

Ssr. DevOps Engineer

Introdução: O dilema da arquitetura de nuvem da IoT

A implantação de dispositivos de IoT em grande escala leva a um conjunto de perguntas que são fáceis de responder durante a prototipagem, mas que se tornam essenciais na produção:

Como os dispositivos se conectam à nuvem?
Como enviamos atualizações?
Como gerenciamos uma frota?

O cenário oferece várias respostas para cada pergunta, e as escolhas nem sempre são independentes. Um cliente MQTT direto é simples, mas deixa o gerenciamento de atualizações inteiramente para você. Um orquestrador de ponta, como o Azure IoT Edge ou o AWS Greengrass, gerencia a conectividade e a implantação do módulo, mas adiciona a sobrecarga de recursos. O gerenciamento de frotas pode ser delegado a plataformas dedicadas, gerenciado pelo orquestrador ou implementado como uma solução personalizada de gerenciamento de frotas.

Esta publicação documenta diferentes abordagens para esses problemas, começando com um cliente MQTT/AMQP independente da nuvem, explorando orquestradores de ponta e, finalmente, abordando as opções de gerenciamento de frota e as considerações práticas que surgiram de implantações reais.

Arquitetura independente de nuvem com MQTT/AMQP

A primeira abordagem priorizou a flexibilidade sobre os recursos. O objetivo era criar um cliente independente de nuvem que pudesse se conectar ao Azure IoT Hub ou ao AWS IoT Core, alternando entre eles com base apenas na configuração.

Na prática, esse cliente é executado entre sensores ou aplicativos locais e o serviço de nuvem selecionado. Seu trabalho é simples: coletar dados, formatá-los de acordo com o que a nuvem espera e transmiti-los com segurança.

Destaques arquitetônicos

Seleção dinâmica da nuvem: Ao usar um PROVEDOR_DA_NUVEM variável de ambiente, o dispositivo pode alternar seu destino upstream entre Azure e AWS em tempo real sem precisar de um flash de firmware.
Identidade X.509 na borda: Priorizamos a segurança implementando a autenticação autoassinada X.509. Isso substitui cadeias de conexão estáticas por identidades criptográficas exclusivas.
Adesiva mínima: Os benchmarks de desempenho validaram a eficiência dessa abordagem, com métricas do sistema registrando um uso da CPU de apenas ~ 0,3% e uma pegada de memória de ~ 13,4% em ambientes de teste.

Na prática, essa abordagem funciona bem porque:

Depuração simples: quando algo quebra, a causa geralmente é óbvia.
Verdadeira flexibilidade multinuvem: troque de provedor sem nenhuma alteração de código.

Mas também tem limitações:

Sem recursos off-line nativos: as mensagens são perdidas se não houver conexão.
A atualização da lógica requer a reimplantação o contêiner inteiro em uma configuração monolítica. Com um design de vários contêineres, atualizações parciais são possíveis (veja a nota abaixo).
Sem processamento local antes de enviar para a nuvem.
O Store-and-Forward deve ser construído manualmente se necessário.

Uma observação sobre a granularidade da atualização: Essa limitação depende de como a arquitetura foi projetada. Em uma configuração monolítica, qualquer alteração no código força uma reconstrução completa e a reinicialização do contêiner. No entanto, dividir essas responsabilidades em serviços separados em um arquivo docker-compose permite atualizações parciais: alterar o serviço X aciona apenas a reconstrução e a reinicialização do X, enquanto Y e Z permanecem intocados. Orquestradores de ponta, como o Greengrass, levam isso mais longe. O Greengrass gerencia os componentes como um processo independente em seu tempo de execução e, quando uma implantação é acionada na nuvem, somente o componente de destino é atualizado sem reiniciar o próprio contêiner do Greengrass.

Na prática, isso significa ciclos de atualização mais rápidos com menos interrupções: uma atualização de componente leva segundos sem interromper outros componentes em execução ou a conectividade de nuvem do dispositivo, enquanto uma atualização de contêiner exige a extração de uma nova imagem, a interrupção e a reinicialização do serviço (ou seja, interrompa temporariamente e consuma mais largura de banda). Para mudanças pequenas e frequentes na lógica do aplicativo, as atualizações no nível do processo reduzem o tempo e o risco de implantação.

Azure IoT Edge em comparação com o AWS IoT Greengrass

Quando as limitações da abordagem independente da nuvem se tornam bloqueadoras, os orquestradores de computação de ponta entram em cena. Ambos Azure IoT Edge e AWS Greengrass V2 oferecem tempos de execução que são executados no dispositivo e permitem recursos difíceis de criar do zero.

Arquitetura do Azure IoT Edge

Azure IoT Edge estende Hub IoT do Azure capacidades até o limite por meio de três componentes principais:

Daemon de segurança IoT Edge (aziot-edged): gerencia o ciclo de vida do módulo, a comunicação segura e a identidade do dispositivo.
Agente Edge ($edgeAgent): recebe instruções de implantação da nuvem e gerencia quais módulos devem ser executados no dispositivo.
Edge Hub ($edgeHub): atua como um proxy local para o Hub IoT, gerenciando o roteamento de mensagens entre os módulos e para a nuvem, incluindo “armazenar e encaminhar” (buffer offline) quando a conexão é perdida.

Executar o IoT Edge dentro de um contêiner requer habilitação systemd e uma gestão cuidadosa do config.toml geração a partir de variáveis de ambiente. Isso aumenta a complexidade, mas permite todos os recursos de orquestração.

Implantação de módulos a partir da nuvem

Uma das vantagens mais significativas do IoT Edge é implantar módulos sem tocar na imagem base do dispositivo. O fluxo de trabalho:

Crie o módulo como um Contêiner Docker.
Empurre para um registro (Registro de contêineres do Azure, Docker Hub)
Configurar o manifesto de implantação no Portal do Azure (ou por meio da CLI do Azure).
O Agente Edge puxa e executa o módulo automaticamente.

AWS Greengrass: arquitetura e conceitos-chave

AWS IoT Greengrass V2 oferece recursos semelhantes a uma arquitetura diferente. Onde o Azure IoT Edge depende de uma arquitetura de microsserviços com vários daemons gerenciados pelo systemd, o Greengrass é construído em torno de um único tempo de execução (ou Greengrass Core) que atua como o mecanismo principal do dispositivo.

The Greengrass Core é um processo de JVM que gerencia todo o ciclo de vida do componente: instalação, inicialização, monitoramento e atualizações. Ele se comunica com AWS IoT Core para receber instruções de implantação e relacionar o status do dispositivo. O IoT Core gerencia a comunicação do dispositivo com a nuvem e o Greengrass estende isso até a borda executando o software localmente no dispositivo. Cada dispositivo Greengrass também é um núcleo de IoT coisa.

Componentes são a unidade de implantação no Greengrass. Eles podem ser:

Processos nativos (scripts, binários) em execução diretamente no dispositivo.
Contêineres Docker gerenciado pelo componente gerenciador de aplicativos Docker.
Funções lambda implantado na borda.

Cada componente tem um receita (YAML ou JSON) que define seu ciclo de vida, dependências e configuração. Quando um implantação é criado a partir da nuvem, o Nucleus baixa somente os componentes atualizados e gerencia seu ciclo de vida sem ser reiniciado.

O Greengrass tende a ser mais “amigável ao contêiner” porque não depende do systemd como processo de inicialização. O Nucleus é um processo Java independente que pode ser executado diretamente sem exigir um sistema de inicialização completo, o que simplifica a conteinerização.

Gerenciamento de frotas: opções e considerações

Independentemente da abordagem de conectividade escolhida, gerenciar as atualizações do sistema operacional e do dispositivo em grande escala continua sendo um desafio. Existem várias opções, cada uma com diferentes vantagens e desvantagens.

O problema do gerenciamento de frotas

O gerenciamento de centenas de dispositivos periféricos distribuídos em diferentes locais apresenta desafios específicos:

Implantando atualizações com segurança sem acesso físico.
Tratamento de reversões quando uma atualização falha.
Configure dispositivos individualmente sem manter as imagens separadas.
Monitoramento da saúde da frota em tempo real.

Abordagens disponíveis

Plataformas dedicadas de gerenciamento de frotas (por exemplo, Balena): forneça atualizações OTA atômicas no nível do sistema operacional e do aplicativo, atualizações delta para minimizar a largura de banda, a configuração remota e os recursos de reversão. Eles absorvem grande parte da complexidade, mas introduzem a dependência da plataforma.
Gerenciamento nativo do orquestrador (por exemplo, AWS Greengrass ou Azure IoT Edge): usa os recursos de implantação do orquestrador de nuvem para gerenciar o software do dispositivo. Embora essa abordagem reduza o número de ferramentas externas para permanecer em um único ecossistema, ela normalmente é limitada à camada de aplicação (contêineres ou componentes). Isso deixa as atualizações do sistema operacional host, a integridade do kernel e a recuperação de baixo nível do sistema como desafios separados que ainda precisam ser resolvidos.
Soluções personalizadas: Crie mecanismos de atualização personalizados para requisitos específicos. Ofereça flexibilidade máxima, mas exige um esforço significativo de desenvolvimento e teste. Faz sentido para implantações altamente especializadas ou quando as ferramentas existentes não atendem às restrições.

A escolha depende do tamanho da frota, da frequência de atualização, dos padrões de conectividade e da complexidade operacional que a equipe pode absorver.

Casos de uso: escolhendo a abordagem correta

A escolha da arquitetura depende fundamentalmente do caso de uso. Aqui estão alguns cenários e a abordagem recomendada para cada um.

Caso 1: Monitoramento ambiental

Cenário: Sensores distribuídos que relacionam temperatura, umidade e qualidade do ar a cada cinco minutos. Conectividade WiFi estável. Nenhum processamento local é necessário.

Abordagem recomendada: cliente Cloud Agnostic (MQTT/AMQP direto)

Por quê?: A simplicidade é suficiente. Não há necessidade de recursos off-line avançados com conectividade estável. O baixo consumo de recursos permite o uso de hardware mais barato. O intervalo significa que perder algumas mensagens durante as reconexões não é essencial.

Caso 2: Telemetria de equipamentos industriais

Cenário: Os dispositivos são instalados em canteiros de obras ou fábricas e dependem da conectividade celular. Os dados de telemetria são usados para manutenção preditiva, e a perda de dados durante interrupções não é aceitável.

Abordagem recomendada: Azure IoT Edge ou AWS Greengrass (idealmente combinado com uma plataforma dedicada ao gerenciamento de frota)

Por quê?: o armazenamento e encaminhamento nativos garantem que a telemetria coletada durante as interrupções seja preservada e carregada quando a conectividade for restaurada. A capacidade de implantar atualizações lógicas remotamente permite que os modelos de manutenção e as regras de processamento de dados evoluam sem substituir as imagens do dispositivo ou exigir intervenção no local.

Considerações e lições aprendidas

A implantação de sistemas de IoT em grande escala apresenta desafios que nem sempre são óbvios durante a prototipagem. As considerações a seguir surgiram de implementações reais e devem informar as decisões de arquitetura no início do processo.

Planejamento de recursos

Os orçamentos de memória são restrições reais: Os orquestradores Edge consomem aproximadamente 500 MB no modo inativo. Em dispositivos com pouca RAM, isso deixa uma capacidade limitada para cargas de trabalho de aplicativos.‍
Armazenamento para armazenamento em buffer offline: O armazenamento e o encaminhamento requerem espaço em disco. Calcula o volume esperado de mensagens durante a duração máxima de interrupção esperada e adiciona margem.

Estratégias de atualização e implantação

As implantações canárias são essenciais em grande escala: Nunca envie atualizações para uma frota inteira simultaneamente. Comece com uma pequena porcentagem (por exemplo, 10%), monitore os problemas e expanda gradualmente.
A reversão deve ser automática e testada: Defina verificações de integridade claras que acionem a reversão automática. Teste o mecanismo de reversão tão rigorosamente quanto o mecanismo de atualização.
As atualizações da Delta são importantes em redes restritas: Os planos de dados celulares geralmente são médios ou têm limitações de largura de banda. Transferir imagens completas para pequenas alterações é um desperdício e é lento.‍
Controle de versão e compatibilidade com versões anteriores: Os formatos de carregamento úteis e os esquemas de comando devem ser versionados explicitamente. O software do dispositivo evolui mais lentamente do que os serviços em nuvem, e a compatibilidade com versões anteriores se torna crítica quando as frotas são implantadas.

Gerenciamento de segurança e credenciais

O armazenamento de certificados requer um design cuidadoso: Os certificados X.509 para autenticação na nuvem devem ser armazenados com segurança no dispositivo. As opções incluem sistemas de arquivos criptografados ou variáveis de ambiente injetadas em tempo de execução. Cada um tem diferentes vantagens operacionais e de segurança.‍
Princípio do menor privilégio: Cada dispositivo só deve ter permissões para o que precisa. Evite credenciais compartilhadas entre dispositivos (o comprometimento de um dispositivo não deve comprometer a frota).

Conectividade e resiliência

Suponha que a conectividade falhe: Projeto para conectividade intermitente desde o início, mesmo que a implantação atual tenha redes confiáveis.‍
Considerações sobre proxy e firewall: Os ambientes corporativos geralmente exigem que o tráfego passe por proxies. Certifique-se de que a pilha de conectividade ofereça suporte à configuração de proxy e que os endpoints necessários estejam na lista branca.

Visibilidade operacional

Registro e coleta de métricas: decida com antecedência como os registros e as métricas serão coletados dos dispositivos. Armazenamento local, upload em lote, streaming em tempo real (cada um tem implicações de largura de banda e armazenamento).‍
Capacidades de depuração remota: Quando algo falha em um local remoto, como isso será diagnosticado? Planeje o acesso remoto ao shell, a recuperação de registros e os comandos de diagnóstico.

Conclusão

As três perguntas feitas no início desta postagem (como se conectar, como atualizar e como gerenciar) não têm uma única resposta. Mas eles têm uma estrutura de decisão clara.

Para Conectividade na nuvem, a escolha varia de clientes MQTT/AMQP diretamente a orquestradores completos, como Azure IoT Edge ou AWS Greengrass. A abordagem independente da nuvem oferece simplicidade, flexibilidade e baixo consumo de recursos (ideal para protótipos, MVPs e cenários com conectividade estável). Os orquestradores de borda adicionam complexidade e sobrecarga de recursos, mas fornecem recursos testados: operação off-line, implantação de módulo remoto e processamento local. O custo adicional é justificado quando esses requisitos são críticos.

Para Gestão de frotas, as opções incluem plataformas dedicadas, ferramentas de orquestração ou soluções personalizadas. Cada um vem com diferentes vantagens e desvantagens em complexidade operacional, dependência de fornecedores e esforço de desenvolvimento. A escolha deve ser avaliada independentemente da abordagem de conectividade.

Além da arquitetura, considerações práticas o planejamento de recursos, as estratégias de implantação, a segurança e a visibilidade operacional geralmente determinam o sucesso ou o fracasso em grande escala. Essas preocupações devem informar as decisões mais cedo, não após a implantação.

Não existe uma solução universal. A escolha certa depende das condições de conectividade, das restrições de recursos, dos requisitos de atualização, da postura de segurança, da experiência da equipe e das capacidades operacionais. Compreender as opções disponíveis (e as considerações práticas que vêm com a escala) é o primeiro passo para tomar uma decisão informada.