3 cosas que la red debe proporcionar para IoT

La Internet de las cosas (IoT) sigue siendo un tema de interés. Y aunque los dispositivos y aparatos orientados al consumidor tienden a ser noticia, es el trabajo detrás de escena, en el trabajo de preparación del centro de datos que realizan los primeros usuarios, lo que sigue siendo más fascinante para mí.

Probablemente porque hay mucho trabajo por hacer para respaldar un esfuerzo de IoT a gran escala. Y realmente no existe tal cosa como un lanzamiento de IoT a pequeña escala cuando el objetivo es los consumidores. Porque por si no os habéis dado cuenta, hay muchísimos consumidores ahí fuera. Y les encantan los artículos brillantes.

Con eso en mente, hay mucho más sucediendo en este momento en la industria tecnológica para apoyar a aquellos que están integrando IoT con ofertas existentes (automóviles, electrodomésticos, juguetes), así como a aquellos que esperan ser la próxima gran novedad con cosas completamente nuevas que no sabían que necesitaban hasta que obtuvieron una.

En realidad. Si bien el gobierno domina las industrias que compran para IoT (según nuestro Informe sobre el estado de la entrega de aplicação 2016), los proveedores de telecomunicaciones, tecnología y servicios en la nube no se quedan atrás. De hecho, cada industria tuvo una tasa de compra bastante buena durante los doce meses anteriores, lo que indica que se está haciendo mucho más trabajo con IoT de lo que parece si solo se observa el espacio de consumo. 

Gran parte de lo que sucede está en la infraestructura; en la red que proporciona conectividad e inmediatez de respuesta por parte de las aplicações en el back-end que administran, miden, monitorean, aseguran e interactúan con esos simpáticos chips incrustados en el osito de peluche favorito de tu hijo.

Como cualquier aplicación o cliente (porque eso es realmente lo que son estas cosas remotas, clientes), hay un conjunto básico de servicios que necesitan para funcionar de manera consistente, predecible y confiable. Es decir, necesitan servicios que permitan la seguridad, la entrega y la visibilidad.

Seguridad

La seguridad tiende a ser lo último en lo que nos centramos cuando se trata de nuevas tecnologías, así que voy a empezar por ello, porque son las brechas de seguridad las que suelen recibir la mayor atención hoy en día, incluso para una tecnología incipiente como la IoT.

Las cosas necesitan comunicarse con aplicaciones back-end. Ya sea para guardar datos, recuperar actualizaciones o parches o cambiar configuraciones, las cosas deben comunicarse, de forma segura, con las aplicaciones back-end. Esto significa soporte de túnel seguro, a través de SSL o TLS. Significa utilizar HTTP seguro, no texto simple, y además significa no codificar claves en tus cosas. Lo digo en serio. No lo hagas.  

Seguridad también significa validación de identidad. Sí, sé que esto es un coche, pero ¿de *quién* es el coche? Necesitamos servicios que puedan identificar cosas con rapidez y precisión y asociarlas con sus usuarios y propietarios autorizados para mitigar la posibilidad de que mi vecino decida que mi radio debería estar sintonizada en algo que no sea una estación de heavy metal. ¡El horror!

Por último, seguridad también significa análisis de protocolos. Esto es importante especialmente dados los nuevos protocolos que se están considerando para la estandarización en todo el universo de IoT. Las inseguridades del protocolo pueden ser un riesgo importante (quizás recuerdes Heartbleed) y tienden a ser difíciles de abordar de manera oportuna. La capacidad de detectar posibles abusos de los protocolos puede corregir el riesgo desde el principio.

Delivery

Los datos, transaccionales o de otro tipo, deben entregarse a las cosas y a las aplicaciones back-end. Hacerlo no siempre es simplemente una cuestión de enviar un montón de bits codificados en JSON a una API REST en algún lugar. Muchas cosas hablan los nuevos lenguajes del IoT: MQTT, CoAP y AQMP. ¿Pero sus respectivas aplicaciones back-end? Ellos Hablan de REST porque también brindan acceso a aplicaciones web y móviles a las mismas capacidades e información. Lo que en última instancia significa que en algún lugar del camino de entrega hay una puerta de enlace, un traductor, un intermediario que garantiza la interoperabilidad del protocolo.

Esto permite que el dispositivo en su automóvil envíe datos o mensajes a través de MQTT que la aplicación back-end que habla REST puede entender. El intermediario intercepta y traduce (de forma segura) para proporcionar conversaciones fluidas entre su dispositivo y sus aplicaciones. Piense en el intermediario como C3PO, y su automóvil (u otra cosa) es R2D2. Esto significa soporte de protocolo nativo, así como un enfoque definido por software que proporciona una plataforma de scripts a través de la cual se puede desarrollar rápidamente soporte para otros protocolos. La creación de scripts de ruta de datos es uno de los tres componentes clave de la programabilidad de la red, pero es el que menos se menciona. Cuando se trata de IoT y de soportar lo que probablemente será una amplia variedad de protocolos y lenguajes, la flexibilidad que ofrece esta capacidad a menudo olvidada será invaluable.

Mencioné la escala como un factor a tener en cuenta anteriormente, y es aquí en la entrega donde vemos que se respalda ese requisito. Para escalar el soporte para un millón de cosas, por ejemplo, probablemente usarás una arquitectura de aplicación basada en descomposición. Quizás no sean microservicios completos, pero es probable que separes los dominios funcionales, al menos, para permitir la escala de diferentes funciones con una metodología más eficiente (y rentable).

Ahí es donde entra en juego algo así como el equilibrio de carga basado en mensajes. Es posible que recuerdes este concepto mencionado en el espacio de proveedores de servicios junto con protocolos como Diameter y SIP , donde la eficacia y la rentabilidad de la escala son imperativas.

El equilibrio de carga basado en mensajes es importante porque los protocolos como MQTT se basan en mensajes. Se trata de un modelo pub-sub (publicar-suscribirse) no muy diferente del middleware basado en mensajes del que quizá hayamos oído hablar y que existe en lo profundo de la empresa. De todos modos, se basan en mensajes, y esos mensajes deben analizarse y enviarse al servicio o dispositivo apropiado. Para hacer eso y escalar, el servicio de equilibrio de carga debe poder analizar el mensaje y determinar dónde enviarlo y luego seleccionar un recurso apropiado para manejarlo.

Esto no es tan fácil como parece, ya que los balanceadores de carga básicos tienen capacidades limitadas de análisis de aplicação .  Pero será un requisito soportar la ampliación de los protocolos que prefieren los dispositivos IoT.

Visibilidad

Por último, la infraestructura debe soportar la visibilidad. Eso significa la capacidad de ver lo que está pasando. Es la visibilidad de las transacciones seguras (inspección SSL) lo que permite que la seguridad tome medidas e identifique a los actores maliciosos. Es la visibilidad de los patrones de uso lo que puede impulsar el escalamiento automático de los servicios adecuados.

La visibilidad no se trata solamente de “big data” que proporcione análisis operativos sólidos, sino también de informes y registros. La resolución de problemas se volverá realmente complicada en estas arquitecturas complejas y el registro será fundamental para que las herramientas y las personas puedan rastrear el problema. 

Escalar y soportar el IoT no es solo cuestión de dispositivos. Hay mucho trabajo por hacer en la red, en la infraestructura y en los marcos operativos necesarios para respaldarla. La buena noticia es que si eres una de esas personas que trabajan en las (muy importantes) arquitecturas back-end que darán soporte a algún gadget interesante, siempre puedes argumentar que necesitas una (o tres) para realizar pruebas.