3 coisas que a rede deve fornecer para IoT

A Internet das Coisas (IoT) continua sendo um tópico de interesse. E embora os gadgets e engenhocas voltados para o consumidor tendam a fazer manchetes, são os bastidores, no trabalho de preparação do data center conduzido pelos primeiros usuários, que continuam sendo mais fascinantes para mim.

Provavelmente porque há muito trabalho a ser feito para dar suporte a um esforço de IoT em larga escala. E não existe realmente algo como uma implementação de IoT em pequena escala quando a "coisa" tem como alvo os consumidores. Porque, caso você não tenha notado, há muitos consumidores por aí. E eles adoram os brilhantes.

Com isso em mente, há muito mais acontecendo agora na indústria de tecnologia para dar suporte àqueles que estão integrando IoT com ofertas existentes (carros, eletrodomésticos, brinquedos), bem como àqueles que esperam ser o próximo grande sucesso com coisas totalmente novas que você não sabia que precisava até ter uma.

Realmente. Embora o governo domine os setores que compram para IoT (de acordo com nosso State of Application Delivery 2016), os provedores de serviços de telecomunicações, tecnologia e nuvem não ficam muito atrás. De fato, todos os setores tiveram uma taxa de compra muito boa nos últimos doze meses, indicando que há muito mais trabalho em andamento com a IoT do que seria óbvio se você apenas observasse o espaço do consumidor. 

Muito do que está acontecendo está na infraestrutura; na rede que está fornecendo conectividade e rapidez de resposta pelos aplicativos no back-end que gerenciam, medem, monitoram, protegem e interagem com aqueles pequenos chips fofos embutidos no ursinho de pelúcia favorito do seu filho.

Como qualquer aplicativo ou cliente (porque é isso que essas coisas remotas são, clientes), há um conjunto básico de serviços que eles precisam para operar de forma consistente, previsível e confiável. Ou seja, eles precisam de serviços que permitam segurança, entrega e visibilidade.

segurança

A segurança tende a ser a última coisa em que focamos com novas tecnologias, então vou começar com ela, porque são as violações de segurança que tendem a receber mais atenção atualmente, mesmo para uma tecnologia incipiente como a IoT.

As coisas precisam se comunicar com aplicativos de back-end. Seja para salvar dados, recuperar atualizações ou patches, ou alterar configurações, as coisas devem se comunicar – com segurança – com aplicativos de back-end. Isso significa suporte a túnel seguro, via SSL ou TLS. Isso significa usar HTTP seguro, não texto simples, e também significa não codificar chaves em suas coisas. Estou falando sério sobre isso. Não faça isso.  

Segurança também significa validação de identidade. Sim, eu sei que essa coisa é um carro, mas *de quem* é esse carro? Precisamos de serviços que possam identificar coisas de forma rápida e precisa e associá-las aos seus usuários e proprietários autorizados para mitigar a possibilidade de meu vizinho decidir que meu rádio deve ser sintonizado em outra estação que não seja uma estação de heavy metal. O horror!

Por fim, segurança também significa análise de protocolo. Isso é importante especialmente considerando os novos protocolos que estão sendo considerados para padronização em todo o universo da IoT. Inseguranças de protocolo podem ser um risco significativo (você deve se lembrar do Heartbleed) e tendem a ser difíceis de resolver em tempo hábil. A capacidade de detectar possíveis abusos de protocolos pode corrigir riscos antecipadamente.

Entrega

Dados, transacionais e outros, precisam ser entregues a coisas e a aplicativos de back-end. Fazer isso nem sempre é apenas uma questão de enviar um monte de bits codificados em JSON para uma API REST em algum lugar. Muitas coisas falam as novas linguagens da IoT: MQTT, CoAP e AQMP. Mas e seus respectivos aplicativos de back-end? Eles falam REST porque eles também estão fornecendo acesso a aplicativos web e móveis aos mesmos recursos e informações. O que significa, em última análise, que em algum lugar no caminho de entrega existe um gateway; um tradutor; um intermediário que fornece interoperabilidade de protocolo.

Isso permite que o dispositivo no seu carro envie dados ou mensagens via MQTT que podem ser compreendidos pelo aplicativo de back-end que fala REST. O intermediário intercepta e traduz (com segurança) para fornecer conversas contínuas entre seu dispositivo e seus aplicativos. Pense no intermediário como C3PO, e seu carro (ou outra coisa) é R2D2. Isso significa suporte a protocolos nativos, bem como uma abordagem definida por software que fornece uma plataforma de script por meio da qual o suporte para outros protocolos pode ser rapidamente desenvolvido. O script do caminho de dados é um dos três principais componentes da programabilidade de rede, mas é o menos mencionado. Quando se trata de IoT e de oferecer suporte ao que provavelmente será uma grande variedade de protocolos e linguagens, a flexibilidade oferecida por esse recurso muitas vezes desconhecido será inestimável.

Mencionei a escala como uma consideração anteriormente, e é aqui na entrega que vemos esse requisito suportado. Para dimensionar o suporte para um milhão de coisas, por exemplo, você provavelmente usará uma arquitetura de aplicativo baseada em decomposição. Talvez não sejam microsserviços completos, mas é provável que você separe domínios funcionais, pelo menos, para permitir a escala de diferentes funções com uma metodologia mais eficiente (e econômica).

É aí que entra algo como balanceamento de carga baseado em mensagens. Você pode se lembrar desse conceito mencionado no espaço do provedor de serviços em conjunto com protocolos como Diameter e SIP , onde a eficácia e a relação custo-benefício da escala são essenciais.

O balanceamento de carga baseado em mensagens é importante porque protocolos como MQTT são baseados em mensagens. Eles são um modelo pub-sub (publicar – assinar) não muito diferente do middleware baseado em mensagens que você pode ter ouvido falar que existe nas profundezas da empresa. De qualquer forma, elas são baseadas em mensagens, e essas mensagens precisam ser analisadas e enviadas ao serviço ou dispositivo apropriado. Para fazer isso e escalar, o serviço de balanceamento de carga deve ser capaz de analisar a mensagem e determinar para onde enviá-la e, então, selecionar um recurso apropriado para lidar com ela.

Isso não é tão fácil quanto parece, pois os balanceadores de carga básicos têm capacidades limitadas de análise de aplicativos.  Mas será um requisito para dar suporte ao dimensionamento dos protocolos que os dispositivos IoT preferem.

Visibilidade

Por fim, a infraestrutura precisa dar suporte à visibilidade. Isso significa a capacidade de ver o que está acontecendo. É a visibilidade das transações seguras (inspeção SSL) que permite que a segurança tome medidas e identifique os malfeitores. É a visibilidade dos padrões de uso que pode impulsionar o dimensionamento automático dos serviços apropriados.

Visibilidade não se trata apenas de “big data” fornecendo análises operacionais robustas, mas também de relatórios e registros. A solução de problemas vai ficar realmente complicada nessas arquiteturas complexas e o registro será essencial para que ferramentas e pessoas rastreiem o problema. 

Escalar e dar suporte à IoT não envolve apenas os gadgets. Há muito trabalho a ser feito na rede, na infraestrutura e nas estruturas operacionais necessárias para dar suporte a ela. A boa notícia é que se você é uma dessas pessoas trabalhando nas (muito importantes) arquiteturas de back-end que darão suporte a algum gadget bacana, você sempre pode argumentar que precisa de uma (ou três) para testes.