Um dos aspectos mais importantes em arquitetura para IoT é o como os dados gerados nos dispositivos serão ingeridos no servidor. Ou seja, como os dados serão direcionados/roteados, processados, agregados, transformados, armazenados, entre outras coisas. Neste post, mostramos duas abordagens razoáveis para aplicação de parte dessas atividades. Uma delas, custando muito menos e entregando, potencialmente, muito mais.

Cenário que queremos tratar

Uma aplicação comum para IoT implica no suporte de algum tipo de telemetria. Onde, os dados são coletados por dispositivos leves, na ponta, e processados na nuvem.

Os dados, coletados na ponta, geralmente são normalizados e processados na nuvem e podendo servir para a geração de alertas, por exemplo.

Consideremos, por exemplo, que os dispositivos na ponta são termômetros coletando espalhados em uma fazenda e que estão alimentando a nuvem para análises e alertas de antecipação de mudanças climáticas.

Geralmente, o tratamento que é feito na nuvem contempla na introdução de vários operadores no stream para seleção, agregação e persistência dos dados coletados.

Na prática, cada dispositivo coleta dados em intervalos regulares e os envia para o servidor formando um “streaming” a ser analisado de maneira reativa. A análise desse stream acontece por meio de operadores (arquitetura PIPES AND FILTERS) que fazem a agregação, transformação e persistência.

Primeiro cenário

Considerando apenas tecnologias Microsoft, poderíamos fazer a ingestão utilizando o Azure Hub  IoT para receber informações, Azure Stream Analytics para processar o stream , com relatórios e painéis em ferramentas como o Power BI consumindo dados persistidos com SQL Server (Cabe a ressalva sobre uso de bases relacionais para IoT, mas isso é assunto para outro post).

Hub IoT + Azure Stream Analytics permite consumo de dados em consultas escritas em uma linguagem bem semelhante a SQL ANSI. O que torna todo o processo mais amistoso para desenvolvedores.

O tratamento inteligente do stream permite, entre outras coisas, agregação de eventos dentro de uma determinada janela, reduzindo e qualificando os dados que serão considerados.

Falamos então de um serviço que permite entradas e saídas e manipula os dados, permitindo sua saída tratada com a possibilidade de criarmos janelas de tempo para esse processamento como por exemplo obter médias e máximas agrupadas das medidas de temperatura durante janelas de 10 minutos e somente este dado ir para frente não gerando um volume desnecessário para os próximos elos da arquitetura.

Qual o problema desta solução? Nenhum! Trata-se de uma solução que transforma os dados, liga um dispositivo a um Power BI por exemplo, ou Salva os dados em uma base SQL Server para posterior análise. Precisamos mudar? Não! Este é um cenário que o ASA atende muito bem!

Vamos então mudar a visão no mesmo cenário e agora falar que precisamos gerar um alarme se a temperatura for alta demais e salvar os dados em uma base NoSQL. Podemos usar ASA para isso? Sim, mas tem algo que pode ser melhor, neste post o Elemar trouxe uma idéia sobre Azure Functions e o conceito de Serverless e é sobre isso que quero chamar sua atenção. Um dos modelos de bilhetagem de uma Function App é a ideia de pagar pelo uso, diferente de uma aplicação web que você paga pela plataforma, aqui o uso se define em GB/s, ou seja, tempo e consumo de memória. Cabe somar a esta informação que independente da necessidade, você tem resposta, aqui falamos de escalabilidade e disponibilidade para nossa aplicação, duas palavras que são importantes quando falamos de cenários de IoT onde podemos ter cargas maiores e dispositivos novos a todo tempo.

O desenho com a troca ficaria da seguinte forma:

Figura 3. Macro Visão de arquitetura de Sensor com uso de Azure Functions

O que muda além de trocar um serviço por outro? Primeiro ponto a entendermos é que os serviços fazem coisas diferentes, no ASA tenho manipulação dos dados, com Functions posso manipular dados e muito mais em uma única chamada. Potencializando e flexibilizando aquele ponto da arquitetura, vamos trazer uma análise simplória de custos para um cenário simples de 2 sensores que enviam dados a cada 1 minuto e precisamos salvar os dados brutos e mostrar em tempo real em um painel de controle usando Power BI.

Rapidamente vamos calcular o número de mensagens e seu tamanho: ([2 x 100bytes]  x 60 por hora x 24 por dia x 30 por mês), por dia temos 2880 mensagens de 100 bytes cada, trafegadas pelo IoT Hub e por mês temos 86.400 mensagens.

Solução 1 com Azure Stream Analytics:

Para este cenário vamos imaginar que podemos usar a menor instância do ASA e que ela irá dar conta do recado.

IoT Hub + Storage + Power BI + ASA  = $25 + $4 + $10 + 81,30 = $120,3

Considerei um storage de 200Gb e um IoT Hub S1 (embora desnecessário poderia ser o gratuito para esse volume) e uma licença de Power BI Pro + a menor instância do Stream Analytics.

Solução 2 com Azure Functions:

IoT Hub + Storage + Power BI + Azure Functions = $25 + $4 + $10 + $0 = $39

Considerei um storage de 200Gb e um IoT Hub S1 (embora desnecessário poderia ser o gratuito para esse volume) e uma licença de Power BI Pro + 86400 execuções de Azure Functions com 512Mb Ram sendo usados por 3 segundos por execução. Para efeito de bilhetagem das Azure Functions os primeiros 400.000 GB/s de execução e as primeiras 1.000.000 execuções são gratuitos

Este é um cenário de exemplo e simples, mas posso garantir que se bem utilizado e desenhado um projeto de IoT com Azure Functions tem muito mais aderência de custos, neste desenho colocamos uma ação simples de pegar e salvar ou repassar para o Power BI, mas podemos ir muito além. Deixe sua opinião aqui nos comentários e vamos conversar!