Quando usar Edge Computing

Hoje em dia, a computação em nuvem anda dominando o mercado. É muito tentador colocar um hardware com o menor custo possível, com a menor quantidade de engenharia que der e realizar todo o trabalho sujo na nuvem. Vemos projetos inteiramente baseados em nuvem em que o dispositivo na ponta é um simples coletor de dados ou um atuador burro, que nada faz sozinho.

 

Aliado a isso, não é de hoje que o desenvolvimento de tecnologia é fortemente influenciado por moda e tendências. Se você perguntar, de verdade, o que é IoT para muitos engenheiros, eles sequer saberão exatamente como dar uma reposta concreta. Para finalizar, sabemos também que a interpretação do público leigo para tecnologia é completamente absurda.

 

Essas coisas acabam gerando a falsa sensação de que jogar tudo para nuvem é a melhor saída, seja por moda, marketing excessivo/repetitivo e pressão por hype. Nem sempre. Então, antes de iniciar um projeto e investir muitas horas de desenvolvimento em uma solução que se tornará impraticável (tipo pendurar uma fibra óptica em um drone aéreo), algumas ideias de quando se evitar o cloud computing e partir para o edge computing.

 

Um pouco de definição...

 

Que fique claro, cloud computing é o ato de usar um computador remotamente para a execução de uma tarefa. E só. Há quem diga que é usar os serviços computacionais de terceiros, mas é um tanto impreciso: quando uma pessoa monta um servidor em casa e acessa ele remotamente para fazer algo, acaba sendo computação em nuvem, mas uma nuvem proprietária.

 

Edge computing é um nome bonito para o uso de recursos computacionais locais. Isso quer dizer que o trabalho ou grande parte dele é realizado localmente pelo equipamento em questão. Existe um artigo sobre computação de borda no Embarcados.

 

Quando usar um ou outro? Isso é algo que precisa ser bem pensado. Alguns fatores são listados abaixo.

 

Largura de Banda

 

Eu já antecipei o exemplo. O engenheiro de sistemas cria um drone para coletar imagens que demandam alta resolução. Lá coloca uma camera de ultra HD (4k, estamos em 2019 e isso por enquanto é muito). Coloca um microcontrolador para fazer o controle de estabilidade e um link GPRS.

 

Começa o problema.

 

Transmitir vídeo 4k cru exige muita banda. Então o sujeito muda para wifi. Isso limita o alcance. Muda para algum tipo de LTE. Acaba então, para ter um drone barato, entupindo a solução geral com uma parafernalha que poderia ser resolvida caso usasse um processador melhor que pelo menos comprimisse o vídeo.

 

Energia

 

Nem sempre processar localmente é sinônimo de gastar mais energia. Transmitir informação, como indicado no item anterior, além de ter todo o problema de banda em si, ainda consome muita energia. Quanto maior a banda necessária e maior a distância, maior o consumo de energia.

 

Dependendo da quantidade de dados a serem enviados, pode haver picos de consumo durante os períodos de transmissão. Sistemas com pouca memória e pouco poder de processamento não têm condições de criar buffers grandes para escoar essa informação de forma mais uniforme, gerando tais picos. Baterias, em geral, não gostam de surtos no consumo, pois a durabilidade e capacidade são melhor aproveitadas com um consumo médio regular.

 

Um sistema com maior poder de processamento pode, em tese, agendar tal processamento para operar na menor quantidade de energia possível ao fazê-lo localmente e ainda armazenar dados em buffers para que sejam transmitidos mais continuamente. Tudo isso pode levar a um menor consumo energético.

 

Tamanho

 

Esse, na verdade, serve para desmistificar que o problema de se processar as coisas na ponta é tamanho. Uma Raspberry Pi tem um poder de processamento enorme e é muito pequena. FPGAs e GPUs são chips relativamente pequenos com altíssimo poder de processamento tanto para Machine/Deep Learning, Vision e IA.

 

Argumentar que o processamento na ponta iria demandar grandes computadores demonstra que o sistema foi pensado apenas em ser operado remotamente e não levou em conta nenhuma tecnologia para processamento na ponta. Quando um projeto negligencia determinado tema, vale assumir que ele não foi bem planejado não só neste aspecto, mas provavelmente em outros também.

 

Capacidade

 

Na mesma linha anterior, estão à disposição sistemas com altíssima capacidade de processamento para utilização em qualquer tipo de equipamento remoto. Argumentar que são necessárias horas de treinamento das máquinas para determinada tarefa além de demonstrar que há pouco conhecimento sobre o que se faz, ainda determina que a análise foi incompleta. Geralmente, capacidade e tamanho são argumentos que andam juntos.

 

Em sistemas embarcados, a máxima de "vale quanto pesa" não é bem verdade...

 

Custo

 

Total cost of ownership. Em geral, brasileiros avaliam de forma muito leviana este aspecto. Tanto que compras parceladas com juros ainda são um meio muito utilizado pelos consumidores brasileiros.

 

Total cost of ownership (TCO) is a financial estimate intended to help buyers and owners determine the direct and indirect costs of a product or system.

 

O principal argumento é que um sistema mais complexo custaria mais caro, tanto em projeto quanto em homem-hora para ser concluído. De fato, isso é uma verdade.

 

Por outro lado, ao avaliar os custos de operação, isso pode mudar. Uma conexão limitada com a internet aliada a processamento em nuvem sobre um hardware limitado, demandam uma maior habilidade na gestão dos recursos deste hardware. O custo de manutenção do sistema, embora não apareçam imediatamente, acabam se tornando um problema no longo prazo.

 

É a velha briga do CAPEX contra o OPEX.

 

Portanto...

 

Que processar as coisas em nuvem foi um grande avanço, sim, foi. Que é muito bom poder contar com este tipo de serviço, sem dúvidas. Porém, enquanto profissionais desenvolvedores de sistemas, deve ser parte da conduta profissional avaliar o tipo de serviço e ferramenta disponível para cumprir determinada tarefa.

 

Deixar-se levar por pressão de fornecedores por um caminho A ou B só favorece a estes fornecedores, que terão suas metas cumpridas mesmo que isso leve o seu cliente a uma solução inviável. Pior ainda é deixar-se levar por modismos e jargões. Para quem não acredita, já me disseram que o CEO de uma empresa disse:

 

Precisamos de alguma iniciativa com blockchain, IoT e IA para eu poder falar a respeito disso.

 

Saiba mais

 

NEWSLETTER

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Obrigado! Sua inscrição foi um sucesso.

Ops, algo deu errado. Por favor tente novamente.

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

Ricardo Tafas
Ricardo F. Tafas Jr é Engenheiro Eletricista pela UFRGS com ênfase em Sistemas Digitais e mestre em Engenharia Elétrica pela PUC com ênfase em Gestão de Sistemas de Telecomunicações. É também escritor e autor do livro Autodesenvolvimento para Desenvolvedores. Possui +10 anos de experiência na gestão de P&D e de times de engenharia e +13 anos no desenvolvimento de sistemas embarcados. Seus maiores interesses são aplicação de RH Estratégico, Gestão de Inovação e Tecnologia Embarcada como diferenciais competitivos e também em Sistemas Digitais de alto desempenho em FPGA. Atualmente, é editor e escreve para o "Repositório” (https://www.repositorio.blog), é membro do editorial do Embarcados (https://www.embarcados.com.br) e é Especialista em Gestão de P&D e Inovação pela Repo Dinâmica - Aceleradora de Produtos.

5
Deixe um comentário

avatar
 
2 Comment threads
3 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
Carlos Eduardo Affonso HenriquesRicardo TafasRonaldo Nunez Recent comment authors
  Notificações  
recentes antigos mais votados
Notificar
Carlos Eduardo Affonso Henriques
Membro

Mas tem umas coisas que podemos contornar. Por exemplo... Um sistema de reconhecimento facial ou de objetos por exemplo: Você não precisa enviar um vídeo 4k, pode enviar apenas os frames que interessam... aumenta a complexidade do projeto mas é mais eficiente ou ainda não enviar frame algum, apenas a informação sobre o que se deseja reconhecer na forma de um hash. Fiz algo parecido em um contador de veículos com o Python e OpenCV onde o que era enviado era apenas o resultado das contagens e não havia qualquer armazenamento do vídeo. Mas cada caso é um caso. Pelas… Leia mais »

Ronaldo Nunez
Visitante
Ronaldo Nunez

Excelente artigo, Ricardo. Nos projetos de dispositivos IoT que já trabalhei, o fator que mais pesava em favor do "edge computing" era a disponibilidade de rede. As horas offline, em função de deficiências na infraestrutura de rede fornecida por terceiros (seja o cliente, uma operadora ou um integrador), acabava levando a solução mais "burra" para uma solução mais "inteligente", para aproveitarmos melhor os momentos em que a rede estava disponível. Claro que isso acarretava em aumento de custos, pois demandava mais horas de engenharia.

Carlos Eduardo Affonso Henriques
Membro

Infelizmente aqui no Brasil, disponibilidade de rede é algo que ainda está muito aquém do minimamente esperado. A algum tempo atrás trabalhei em uma empresa em que isso era um dos maiores entraves. Usávamos um dispositivo baseado em Raspberry Pi que fazia a coleta dos dados localmente. Esses dados eram temporariamente armazenados em fila em um ramdisk (tmpfs) e enviado pouco a pouco para a infra da empresa, caso houvesse problema com a rede do cliente os dados eram armazenados no cartão SD. Isso gerava dois problemas sérios o primeiro era a redução da vida útil do cartão SD visto… Leia mais »